Быстро понять протокол HTTP

задняя часть внешний интерфейс HTTP
Быстро понять протокол HTTP

предисловие

Я чувствую, что в последние полгода активность Наггетс шла одна за другой🎁

Сегодня увидел, что в Creator Center есть еще одна техническая тема call for papers, по поводу сетевых протоколов, в ней есть комментарий:

У вас много занятий по самородкам, но, к сожалению, я об этом не знаю.

Это действительно говорит мое сердце😢... Для меня сетевой протокол всегда был знакомым и незнакомым, и еще более незнакомым, потому что, хотя я слушал, я действительно не тратил время, чтобы понять это, Это правда, что это событие может не быть написанным

Однако после того, как подумал об этом позже, я просто хочу узнать его, если я этого не знаю, поэтому я планирую воспользоваться событием, чтобы принять участие в знаниях, связанных с сетевыми протоколами.

Примечание:

  • из-заHTTPСпецификации, включенные в соглашение, особенно велики.Эта статья посвящена только грамотности.Пожалуйста, поверните налево 👈🏻
  • В статье содержится ссылка на большое количество общедоступных онлайн-материалов (включая Википедию,runoobд.), впитайте и систематизируйте в этой статье, если у вас есть какие-либо вопросы, пожалуйста, оставьте сообщение~

Чтобы вам было понятно, я организовал структуру каталогов статей следующим образом:

image.png

Прочитав эту статью, вы поймете соответствующие точки знаний на картинке выше.

Введение

Начнем с того, что такое протокол HTTP

Что такое HTTP-протокол

HTTPдаHyper Text Transfer ProtocolАббревиатура для , который является протоколом передачи для передачи гипертекста с сервера World Wide Web в локальный браузер и основан наTCP/IPпротокол связи для передачи данных

Проще говоря, это согласованное протокольное соглашение между клиентом и сервером.

Резюме выглядит следующим образом:

image.png

История и ее издания

оHTTPЯ лично считаю, что история соглашения достаточно важна.С одной стороны, я больше интересуюсь историей, а с другой стороны, я надеюсь развить хорошую грамотность и знать суть!

HTTPРазвитие можно условно разделить на следующие этапы.

  1. 1991 год,Tim Berners-Leeразработал простой однострочный протокол обмена гипертекстом, также известный какHTTP/0.9, который является исходным протоколом HTTP
  2. С бурным развитием Интернета примитивныеHTTPУ протокола много проблем, многие улучшения HTTP являются спонтанными, и ирония заключается в том, что децентрализованная сеть требует централизованного управляющего органа, чтобы избежать несовместимости, вызванной фрагментацией.Tim Berners-LeeОсознавая опасность, Консорциум Всемирной паутины был создан в 1994 году в качестве первого шага к приведению большего количества норм в существующую среду. время пришломай 1996 г., они задокументировали некоторые из наиболее часто используемых функций HTTP в то время и назвали ихHTTP/1.0протокол
  3. январь 1997 г.Исправлены несоответствия HTTP/1.0 и настроен протокол для лучшей работы в новой веб-экосистеме.HTTP/1.1, двумя наиболее важными изменениями, внесенными в новую версию, являются использование по умолчанию постоянных TCP-соединений (сохранение активности) и конвейерная обработка HTTP. И долгое время HTTP/1.1 работал очень хорошо.
  4. Google выпустил браузер Chrome в 2008 году, этот браузер из-за его быстрого и инновационного и роста по популярности. Он делает Google с сильным голосом в технических проблемах в Интернете. В начале 2010 года Google добавила поддержку для своего веб-протокола SPDY в Chrome. По последующим событиям, вмай 2015 г., новая версия протокола HTTP была официально выпущена в качестве интернет-стандарта.HTTP/2 ,HTTP/2 Стандарт основан на SPDY с некоторыми улучшениями, он был выпущен для решения многих проблем в Интернете, таких как мультиплексирование, отправка на сервер, сжатие заголовков и т. д.
  5. Ну наконец тоHTTP/3, HTTP/3Кроме того, в настоящее время это самый передовой стандарт Интернета.Хотя основная среда еще не полностью переведена на HTTP/3, развитие HTTP/3 должно быть неостановимым.

Длинная река истории постоянно движется вперед и повторяется.HTTP/3Идеального не будет, лучше в постоянном развитии

Резюме выглядит следующим образом:

image.png

процесс коммуникации

Обзор

давай поговоримHTTPпроцесс сетевого взаимодействия

Мы знаем выше,HTTPПротокол работает между клиентом и сервером, в течение всего процесса коммуникации браузер будет выступать в ролиHTTPклиент черезURLКHTTPсерверная частьWEBСервер отправляет все запросы,WebВ соответствии с полученным запросом сервер отправит ответную информацию клиенту.

будь осторожен

Но есть несколько замечаний:

  1. HTTPОграничьте обработку только одним запросом на соединение.После того, как сервер обработает запрос клиента и получит ответ клиента, соединение будет разорвано.
  2. HTTPнезависим от носителя, любой тип данных может быть отправлен по HTTP, если клиент и сервер знают, что делать с содержимым данных
  3. HTTPНе имеет состояния, протокол не имеет возможности памяти для обработки транзакций. Отсутствие состояния означает, что если предыдущая информация требуется для последующей обработки, она должна быть передана повторно, что может привести к увеличению объема данных, передаваемых за одно соединение. С другой стороны, сервер быстрее отвечает, когда ему не нужна предыдущая информация.

Резюме в 4 шага

Для удобства весь процесс общения можно сократить следующим образом.4шаг:

image.png

HTTP-сообщение

HTTPПод сообщением можно понимать то, что передается, то есть то, что передается вышеописанным коммуникативным процессом.

Существует два вида сообщений: сообщения-запросы от клиента к серверу и сообщения-ответы или сообщения-ответы от сервера к клиенту.

сообщение запроса

  • Формат сообщения запроса следующий:

Строка запроса — Заголовок общей информации — Заголовок запроса — Заголовок сущности — Тело сообщения

Строка запроса начинается с поля метода, за которым следуетURLполя иHTTPполе версии протокола, оканчивающееся наCRLFконец.SPявляется разделителем. кроме как в последнийCRLFв последовательностиCFа такжеLFЗа исключением того, что это необходимо, другие могут быть опущены. Конкретное содержание заголовков общей информации, заголовков запросов и заголовков сущностей см. в соответствующих документах.

ответное сообщение

  • Формат ответного сообщения следующий:

Строка состояния - Заголовок общей информации - Заголовок ответа - Заголовок сущности - Тело сообщения

Код состояния задается3Число цифр, указывающее, был ли запрос понят или выполнен. Анализ причины представляет собой краткое описание кода состояния исходного текста, код состояния используется для поддержки автоматической работы, а анализ причины используется для пользователя. Клиент не нужно использовать для проверки или отображения синтаксиса. Конкретное содержание заголовков общей информации, заголовков ответов и заголовков сущностей см. в соответствующих документах.

Резюме выглядит следующим образом:

image.png

9 способов сделать запрос

HTTP определено в соглашении9способ показать, чтоRequest-URIРазличные способы эксплуатации указанного ресурса, гдеHTTP1.0 Определенный3методы запроса:GET, POSTа такжеHEADметод,HTTP1.1 недавно добавленный6методы запроса:OPTIONS,PUT,PATCH,DELETE,TRACEа также CONNECTметод

  1. GET: сделать запрос к определенному ресурсу
  2. POST: отправка данных на указанный ресурс для обработки запросов (например, отправки формы или загрузки файла). Данные включаются в тело запроса.POSTЗапросы могут привести к созданию новых ресурсов и/или изменению существующих ресурсов.
  3. HEAD: запросите у сервера ответ, соответствующий запросу GET, но тело ответа не будет возвращено. Этот метод позволяет получить метаинформацию, содержащуюся в заголовках ответов, без необходимости передачи всего содержимого ответа.
  4. OPTIONS: возвращает методы HTTP-запроса, поддерживаемые сервером для определенного ресурса. Также есть возможность протестировать работоспособность сервера с помощью запросов к веб-серверу
  5. PUT: загрузить свой последний контент в указанное расположение ресурса
  6. PATCH:правда PUTДополнение к методам локального обновления известных ресурсов
  7. DELETE: Запрашивает сервер удалить ресурс, указанный Request-URI.
  8. CONNECT:HTTP/1.1Протокол зарезервирован для прокси-сервера, который может перевести соединение в режим канала.
  9. TRACE: повторить запрос, полученный сервером, в основном для тестирования или диагностики

В практических приложениях обычно используетсяgetа такжеpost

Резюме выглядит следующим образом:

image.png

Общая информация заголовка запроса

Для краткости он непосредственно организован следующим образом:

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типы, как показано ниже:

image.png

Типы содержимого и типы сетевых файлов

Вот тип контента -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

Ну вот и все содержание этой статьи, если есть вопросы, поправьте меня~

использованная литература