предисловие
Я чувствую, что в последние полгода активность Наггетс шла одна за другой🎁
Сегодня увидел, что в Creator Center есть еще одна техническая тема call for papers, по поводу сетевых протоколов, в ней есть комментарий:
У вас много занятий по самородкам, но, к сожалению, я об этом не знаю.
Это действительно говорит мое сердце😢... Для меня сетевой протокол всегда был знакомым и незнакомым, и еще более незнакомым, потому что, хотя я слушал, я действительно не тратил время, чтобы понять это, Это правда, что это событие может не быть написанным
Однако после того, как подумал об этом позже, я просто хочу узнать его, если я этого не знаю, поэтому я планирую воспользоваться событием, чтобы принять участие в знаниях, связанных с сетевыми протоколами.
Примечание:
- из-за
HTTPСпецификации, включенные в соглашение, особенно велики.Эта статья посвящена только грамотности.Пожалуйста, поверните налево 👈🏻 - В статье содержится ссылка на большое количество общедоступных онлайн-материалов (включая Википедию,
runoobд.), впитайте и систематизируйте в этой статье, если у вас есть какие-либо вопросы, пожалуйста, оставьте сообщение~
Чтобы вам было понятно, я организовал структуру каталогов статей следующим образом:
Прочитав эту статью, вы поймете соответствующие точки знаний на картинке выше.
Введение
Начнем с того, что такое протокол HTTP
Что такое HTTP-протокол
HTTPдаHyper Text Transfer ProtocolАббревиатура для , который является протоколом передачи для передачи гипертекста с сервера World Wide Web в локальный браузер и основан наTCP/IPпротокол связи для передачи данных
Проще говоря, это согласованное протокольное соглашение между клиентом и сервером.
Резюме выглядит следующим образом:
История и ее издания
оHTTPЯ лично считаю, что история соглашения достаточно важна.С одной стороны, я больше интересуюсь историей, а с другой стороны, я надеюсь развить хорошую грамотность и знать суть!
HTTPРазвитие можно условно разделить на следующие этапы.
-
1991 год,
Tim Berners-Leeразработал простой однострочный протокол обмена гипертекстом, также известный какHTTP/0.9, который является исходным протоколом HTTP - С бурным развитием Интернета примитивные
HTTPУ протокола много проблем, многие улучшения HTTP являются спонтанными, и ирония заключается в том, что децентрализованная сеть требует централизованного управляющего органа, чтобы избежать несовместимости, вызванной фрагментацией.Tim Berners-LeeОсознавая опасность, Консорциум Всемирной паутины был создан в 1994 году в качестве первого шага к приведению большего количества норм в существующую среду. время пришломай 1996 г., они задокументировали некоторые из наиболее часто используемых функций HTTP в то время и назвали ихHTTP/1.0протокол -
январь 1997 г.Исправлены несоответствия HTTP/1.0 и настроен протокол для лучшей работы в новой веб-экосистеме.
HTTP/1.1, двумя наиболее важными изменениями, внесенными в новую версию, являются использование по умолчанию постоянных TCP-соединений (сохранение активности) и конвейерная обработка HTTP. И долгое время HTTP/1.1 работал очень хорошо. - Google выпустил браузер Chrome в 2008 году, этот браузер из-за его быстрого и инновационного и роста по популярности. Он делает Google с сильным голосом в технических проблемах в Интернете. В начале 2010 года Google добавила поддержку для своего веб-протокола SPDY в Chrome. По последующим событиям, вмай 2015 г., новая версия протокола HTTP была официально выпущена в качестве интернет-стандарта.
HTTP/2,HTTP/2Стандарт основан на SPDY с некоторыми улучшениями, он был выпущен для решения многих проблем в Интернете, таких как мультиплексирование, отправка на сервер, сжатие заголовков и т. д. - Ну наконец то
HTTP/3,HTTP/3Кроме того, в настоящее время это самый передовой стандарт Интернета.Хотя основная среда еще не полностью переведена на HTTP/3, развитие HTTP/3 должно быть неостановимым.
Длинная река истории постоянно движется вперед и повторяется.HTTP/3Идеального не будет, лучше в постоянном развитии
Резюме выглядит следующим образом:
процесс коммуникации
Обзор
давай поговоримHTTPпроцесс сетевого взаимодействия
Мы знаем выше,HTTPПротокол работает между клиентом и сервером, в течение всего процесса коммуникации браузер будет выступать в ролиHTTPклиент черезURLКHTTPсерверная частьWEBСервер отправляет все запросы,WebВ соответствии с полученным запросом сервер отправит ответную информацию клиенту.
будь осторожен
Но есть несколько замечаний:
-
HTTPОграничьте обработку только одним запросом на соединение.После того, как сервер обработает запрос клиента и получит ответ клиента, соединение будет разорвано. -
HTTPнезависим от носителя, любой тип данных может быть отправлен по HTTP, если клиент и сервер знают, что делать с содержимым данных -
HTTPНе имеет состояния, протокол не имеет возможности памяти для обработки транзакций. Отсутствие состояния означает, что если предыдущая информация требуется для последующей обработки, она должна быть передана повторно, что может привести к увеличению объема данных, передаваемых за одно соединение. С другой стороны, сервер быстрее отвечает, когда ему не нужна предыдущая информация.
Резюме в 4 шага
Для удобства весь процесс общения можно сократить следующим образом.4шаг:
HTTP-сообщение
HTTPПод сообщением можно понимать то, что передается, то есть то, что передается вышеописанным коммуникативным процессом.
Существует два вида сообщений: сообщения-запросы от клиента к серверу и сообщения-ответы или сообщения-ответы от сервера к клиенту.
сообщение запроса
- Формат сообщения запроса следующий:
Строка запроса — Заголовок общей информации — Заголовок запроса — Заголовок сущности — Тело сообщения
Строка запроса начинается с поля метода, за которым следуетURLполя иHTTPполе версии протокола, оканчивающееся наCRLFконец.SPявляется разделителем. кроме как в последнийCRLFв последовательностиCFа такжеLFЗа исключением того, что это необходимо, другие могут быть опущены. Конкретное содержание заголовков общей информации, заголовков запросов и заголовков сущностей см. в соответствующих документах.
ответное сообщение
- Формат ответного сообщения следующий:
Строка состояния - Заголовок общей информации - Заголовок ответа - Заголовок сущности - Тело сообщения
Код состояния задается3Число цифр, указывающее, был ли запрос понят или выполнен. Анализ причины представляет собой краткое описание кода состояния исходного текста, код состояния используется для поддержки автоматической работы, а анализ причины используется для пользователя. Клиент не нужно использовать для проверки или отображения синтаксиса. Конкретное содержание заголовков общей информации, заголовков ответов и заголовков сущностей см. в соответствующих документах.
Резюме выглядит следующим образом:
9 способов сделать запрос
HTTP определено в соглашении9способ показать, чтоRequest-URIРазличные способы эксплуатации указанного ресурса, гдеHTTP1.0 Определенный3методы запроса:GET, POSTа такжеHEADметод,HTTP1.1 недавно добавленный6методы запроса:OPTIONS,PUT,PATCH,DELETE,TRACEа также CONNECTметод
-
GET: сделать запрос к определенному ресурсу -
POST: отправка данных на указанный ресурс для обработки запросов (например, отправки формы или загрузки файла). Данные включаются в тело запроса.POSTЗапросы могут привести к созданию новых ресурсов и/или изменению существующих ресурсов. -
HEAD: запросите у сервера ответ, соответствующий запросу GET, но тело ответа не будет возвращено. Этот метод позволяет получить метаинформацию, содержащуюся в заголовках ответов, без необходимости передачи всего содержимого ответа. -
OPTIONS: возвращает методы HTTP-запроса, поддерживаемые сервером для определенного ресурса. Также есть возможность протестировать работоспособность сервера с помощью запросов к веб-серверу -
PUT: загрузить свой последний контент в указанное расположение ресурса -
PATCH:правдаPUTДополнение к методам локального обновления известных ресурсов -
DELETE: Запрашивает сервер удалить ресурс, указанный Request-URI. -
CONNECT:HTTP/1.1Протокол зарезервирован для прокси-сервера, который может перевести соединение в режим канала. -
TRACE: повторить запрос, полученный сервером, в основном для тестирования или диагностики
В практических приложениях обычно используетсяgetа такжеpost
Резюме выглядит следующим образом:
Общая информация заголовка запроса
Для краткости он непосредственно организован следующим образом:
Accept:
Допустимые типы содержимого ответа (Content-Types)
Accept-Charset:
приемлемый набор символов
Accept-Encoding:
Приемлемая кодировка содержимого ответа.
Accept-Language:
Список допустимых языков содержимого ответа.
Accept-Datetime:
приемлемые версии содержания ответа с точки зрения времени
Authorization:
Информация аутентификации, используемая для указания ресурса аутентификации, необходимого в протоколе HTTP.
Cache-Control:
Используется для указания, следует ли использовать механизм кэширования в текущем запросе/ответе.
Connection:
Тип соединения, которое клиент (браузер) хочет использовать в первую очередь
Cookie:
Файл cookie протокола HTTP, установленный предыдущим сервером с помощью Set-Cookie (см. ниже).
Content-Length:
Длина тела запроса в восьмеричном формате
Content-MD5:
Двоичный хэш MD5 (цифровая подпись) содержимого тела запроса, закодированный в Base64.
Content-Type:
MIME-тип тела запроса (используется в запросах POST и PUT)
Date:
Дата и время отправки сообщения (отправлено в формате «Дата HTTP», как определено в RFC 7231)
Expect:
Указывает, что клиент просит сервер выполнить определенное действие
From:
Адрес электронной почты пользователя, который инициировал этот запрос
Host:
Указывает доменное имя сервера и номер порта, который прослушивает сервер. Если запрошенный порт является стандартным портом (80) соответствующей службы, номер порта можно не указывать.
If-Match:
Соответствующая операция выполняется только в том случае, если объект, предоставленный клиентом, соответствует соответствующему объекту на сервере. В основном используется в таких методах, как PUT, для обновления ресурса, только если он не был изменен с момента последнего обновления пользователем.
If-Modified-Since:
Позволяет вернуть 304 Not Modified, если соответствующий ресурс не был изменен
If-None-Match:
Допускается возвращать 304 Not Modified (304 Not Modified), если соответствующий контент не был изменен, см. тег сущности протокола передачи гипертекста.
If-Range:
Если объект не был изменен, верните отсутствующую часть или части. В противном случае вернуть всю новую сущность
If-Unmodified-Since:
Отправлять ответ только в том случае, если сущность не изменялась с определенного времени.
Max-ForwardsОграничивает количество раз, которое это сообщение может быть перенаправлено прокси-серверами и шлюзами.
Origin:
Инициировать запрос на совместное использование ресурсов между источниками (этот запрос требует, чтобы сервер добавил к ответу заголовок сообщения Access-Control-Allow-Origin, указывающий источник, разрешенный контролем доступа).
Pragma:
В зависимости от конкретной реализации эти поля могут создаваться в любой точке цепочки запроса/ответа.
Proxy-Authorization:
Информация об аутентификации, используемая для аутентификации на прокси.
Range:
Указывает, что запрашивается часть объекта, а смещение в байтах начинается с 0.
Referer:
Указывает на предыдущую страницу, посещенную браузером, которую можно рассматривать как ссылку на ранее посещенную страницу, которая привела браузер на текущую страницу. Referer на самом деле является словом Referrer, но оно было написано с ошибкой, когда RFC создавал стандарт, а позже Referer использовался неправильно.
TE:
Кодировка передачи, которую браузер ожидает получить: можно использовать заголовок ответа
Transfer-Encoding:
Значение in (вы также можете использовать «трейлеры», чтобы указать, как данные передаются фрагментами) используется для указания того, что браузер ожидает получить некоторые дополнительные поля после последнего фрагмента размера 0.
User-Agent:
Идентификационная строка браузера
Upgrade:
Требуется обновление сервера до более высокой версии протокола.
Via:
Сообщите серверу, какие прокси сделали этот запрос.
Warning:
Общее предупреждение о том, что в теле содержимого объекта может быть ошибка.
Код состояния и классификация
Когда браузер посещает веб-страницу, браузер браузера отправляет запрос на сервер, на котором расположена веб-страница. Когда браузер получает и отображает веб-страницу, сервер, на котором находится веб-страница, возвращаетHTTPЗаголовок кода состояния, используемый для ответа на запросы браузера
Общие коды состояния HTTP
Раньше это было решено следующим образом
- 100
ContinueПродолжать. Клиент должен продолжить свой запрос - 101
Switching ProtocolsПереключение протоколов. Сервер переключает протоколы по запросу клиента. Переключитесь только на протокол более высокого уровня, например, на более новую версию HTTP. - 200
OKЗапрос выполнен успешно. обычно используется дляGETа такжеPOSTпросить - 201
Createdсозданный. Успешно запрошен и создан новый ресурс - 202
Acceptedпринятый. Заявка принята, но не выполнена - 203
Non-Authoritative InformationНесанкционированная информация. Запрос выполнен успешно. но вернулсяmetaИнформация не на оригинальном сервере, а на копии - 204
No ContentБез содержания. Сервер успешно обработал, но не вернул содержимого. Гарантирует, что браузер продолжает отображать текущий документ без обновления веб-страницы. - 205
Reset ContentСбросить содержимое. Серверный процесс выполнен успешно, и пользовательский терминал (например, браузер) должен сбросить представление документа. Поля формы браузера можно очистить с помощью этого кода возврата. - 206
Partial ContentЧасть. Сервер успешно обработал разделGETпросить - 300
Multiple Choicesмножественный выбор. Запрошенный ресурс может включать несколько местоположений, и, соответственно, список характеристик и адресов ресурса может быть возвращен для выбора пользовательского терминала (например, браузера). - 301
Moved PermanentlyПереехать навсегда. Запрошенный ресурс был окончательно перемещен на новыйURI, информация о возврате будет включать новыйURI, браузер автоматически перенаправляется на новыйURI. Любые новые запросы в будущем должны использовать новыйURIзаменять - 302
FoundВременный переезд. а также301аналогичный. Но ресурс перемещается только временно. Клиенты должны продолжать использовать исходный URI. - 303
See OtherПосмотрите другие адреса. а также301аналогичный. использоватьGETа такжеPOSTзапрос на просмотр - 304
Not ModifiedБез изменений. Запрошенный ресурс не был изменен, и ресурс не будет возвращен, когда сервер вернет этот код состояния. Клиенты обычно кэшируют посещенные ресурсы, предоставляя заголовок, указывающий, что клиент хочет вернуть только ресурсы, измененные после указанной даты. - 305
Use ProxyИспользуйте прокси. Запрошенный ресурс должен быть доступен через прокси - 306
UnusedустаревшийHTTPкод состояния - 307
Temporary RedirectВременная переадресация. а также302аналогичный. использоватьGETзапросить перенаправление - 400
Bad RequestВ клиентском запросе есть синтаксическая ошибка, которую сервер не может понять. - 401
UnauthorizedЗапрос требует аутентификации пользователя - 402
Payment Requiredзарезервировано для использования в будущем - 403
ForbiddenСервер понимает запрос запрашивающего клиента, но отказывается выполнять запрос - 404
Not FoundСервер не смог найти ресурс (веб-страницу) по запросу клиента. С помощью этого кода веб-дизайнеры могут настроить персонализированную страницу с надписью «запрошенный вами ресурс не найден». - 405
Method Not Allowedметод в клиентском запросе запрещен - 406
Not AcceptableСервер не может выполнить запрос на основе характеристик содержимого запроса клиента. - 407
Proxy Authentication RequiredЗапрос требует проверки подлинности прокси-сервера, аналогичной 401, но запрашивающая сторона должна использовать прокси-сервер для авторизации. - 408
Request Time-outСервер слишком долго ждет запроса, отправленного клиентом, и истекает время ожидания. - 409
ConflictЭтот код может быть возвращен, когда сервер завершает запрос клиента PUT, и при обработке запроса сервером возникает конфликт. - 410
GoneРесурс, запрошенный клиентом, больше не существует. 410 В отличие от 404, код 410 может использоваться, если ресурс ранее был окончательно удален, а код 301 может использоваться дизайнерами веб-сайтов для указания нового местоположения ресурса. - 411
Length RequiredСервер не может обработатьContent-Lengthинформация о запросе - 412
Precondition FailedИнформация о запросе клиента с неправильными предварительными условиями - 413
Request Entity Too LargeЗапрос был отклонен, так как запрошенный объект был слишком большим для обработки сервером. Чтобы предотвратить непрерывные запросы от клиентов, сервер может закрыть соединение. Если просто сервер временно не может его обработать, он будет содержатьRetry-Afterответная информация - 414
Request-URI Too LargeпросилURIслишком долго (URIОбычно это URL), сервер не может обработать - 415
Unsupported Media TypeСервер не может обработать формат мультимедиа, прикрепленный к запросу. - 416
Requested range not satisfiableНедопустимая область действия, запрошенная клиентом - 417
Expectation FailedСервер не может удовлетворитьExpectзапрашивать информацию заголовка - 500
Internal Server ErrorВнутренняя ошибка сервера, невозможно выполнить запрос - 501
Not ImplementedСервер не поддерживает запрошенную функцию и не может выполнить запрос - 502
Bad GatewayСервер, работающий в качестве шлюза или прокси, получил неверный ответ от удаленного сервера при попытке выполнить запрос - 503
Service UnavailableИз-за перегрузки или обслуживания системы сервер временно не может обработать запрос клиента. Продолжительность задержки может быть включена вRetry-Afterв заголовке - 504
Gateway Time-outСервер, выступающий в роли шлюза или прокси, не получил вовремя запрос от удаленного сервера. - 505
HTTP Version not supportedСервер не поддерживает запрошенныйHTTPВерсия протокола, не удалось завершить обработку
Классификация кодов состояния
HTTPКод состояния состоит из трех десятичных чисел. Первое десятичное число определяет тип кода состояния, а последние два числа не имеют функции классификации.
из-заHTTPКодов состояния много, для удобства разделим их на следующие5типы, как показано ниже:
Типы содержимого и типы сетевых файлов
Вот тип контента -Content-Type
Тип содержимого
Content-TypeИспользуется для определения типа сетевого файла и кодировки веб-страницы, определяет, в какой форме и в какой кодировке браузер будет читать файл.
Примерный синтаксис выглядит следующим образом:
Content-Type: text/html; charset=utf-8
Content-Type: multipart/form-data; boundary=something
в,text/htmlа такжеmultipart/form-dataЭто все типы сетевых файлов, давайте примерно их разберем.
Типы веб-файлов
Существует много типов сетевых файлов, в основном разделенных на следующие категории:
Распространенные типы сетевых файлов
-
text/html: формат HTML -
text/plain: обычный текстовый формат -
text/xml: формат XML -
image/gif: формат изображения GIF -
image/jpeg: формат изображения jpg -
image/png: формат изображения png
начиная с заявки
-
application/xhtml+xml: формат XHTML -
application/xml: формат данных XML -
application/atom+xml: Формат агрегации Atom XML -
application/json: формат данных JSON -
application/pdf: формат пдф -
application/msword: Формат документа Word -
application/octet-stream: данные двоичного потока (например, загрузка обычных файлов) -
application/x-www-form-urlencoded:<form encType=””>В encType по умолчанию данные формы кодируются как формат ключ/значение и отправляются на сервер (формат данных отправки формы по умолчанию).
используется при загрузке файлов
-
multipart/form-data: Вам нужно использовать этот формат, когда вам нужно загрузить файлы в форме
Конечно, есть и другие типы, и больше файлов соответствует конкретнымContent-Type, вы можете обратиться кДиаграмма
END
Ну вот и все содержание этой статьи, если есть вопросы, поправьте меня~