HTTP — это клиент-серверный протокол: запросы отправляются одним субъектом, пользователем-агентом (или прокси от его имени). В большинстве случаев пользователем-агентом является веб-браузер, но это может быть что угодно, например, робот, который просматривает сеть для заполнения и поддержания индекса поисковой системы.

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

На самом деле между браузером и сервером, обрабатывающим запрос, находится больше компьютеров: маршрутизаторы, модемы и многое другое. Благодаря многослойному дизайну сети эти компоненты скрыты на уровнях сети и транспорта. HTTP находится на вершине, на уровне приложений. Хотя они важны для диагностики проблем сети, лежащие в основе уровни в основном не имеют отношения к описанию HTTP.

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

Браузер всегда является субъектом, инициирующим запрос. Он никогда не является сервером (хотя в течение многих лет были добавлены некоторые механизмы для имитации сообщений, инициируемых сервером).

Для отображения веб-страницы браузер отправляет оригинальный запрос для получения HTML-документа, который представляет собой страницу. Затем он анализирует этот файл, делая дополнительные запросы, соответствующие скриптам выполнения, информации о макете (CSS) для отображения и подресурсам, содержащимся на странице (обычно изображениям и видео). Затем веб-браузер объединяет эти ресурсы для представления полного документа, веб-страницы. Скрипты, выполняемые браузером, могут получать больше ресурсов на последующих этапах, и браузер обновляет веб-страницу соответствующим образом.

Веб-страница — это гипертекстовый документ. Это означает, что некоторые части отображаемого содержимого являются ссылками, которые можно активировать (обычно щелчком мыши) для получения новой веб-страницы, позволяя пользователю направлять своего пользовательского агента и перемещаться по сети. Браузер преобразует эти инструкции в запросы HTTP и далее интерпретирует ответы HTTP, чтобы предоставить пользователю четкий ответ.

На противоположной стороне канала связи находится сервер, который служит документом по запросу клиента. Сервер виртуально выглядит как единственная машина, но на самом деле он может быть коллекцией серверов, распределяющих нагрузку (балансировка нагрузки), или сложным программным обеспечением, запрашивающим другие компьютеры (например, кэш, сервер базы данных или серверы электронной коммерции), полностью или частично генерирующим документ по требованию.

Сервер не обязательно является одной машиной, но несколько экземпляров программного обеспечения сервера могут быть размещены на одной машине. С HTTP/1.1 и заголовком Host они даже могут использовать один и тот же IP-адрес.

Между веб-браузером и сервером многочисленные компьютеры и машины ретранслируют сообщения HTTP. Благодаря многослойной структуре стека веб-технологий большинство из них работают на транспортном, сетевом или физическом уровнях, становясь прозрачными на уровне HTTP и потенциально оказывающими значительное влияние на производительность. Те, кто работают на уровне приложений, обычно называются прокси. Они могут быть прозрачными, перенаправляя полученные запросы без каких-либо изменений, или непрозрачными, в этом случае они каким-то образом изменяют запрос перед передачей его серверу. Прокси могут выполнять множество функций:

• кэширование (кэш может быть общедоступным или частным, как кэш браузера)
• фильтрация (например, сканирование антивирусом или родительский контроль)
• балансировка нагрузки (для того, чтобы несколько серверов могли обслуживать различные запросы)
• аутентификация (для управления доступом к различным ресурсам)
• ведение журнала (для хранения исторической информации)

HTTP в целом разработан для простоты и читаемости человеком, даже с добавлением сложности в HTTP/2 путем инкапсуляции сообщений HTTP в кадры. Сообщения HTTP могут быть прочитаны и поняты человеком, что упрощает тестирование для разработчиков и снижает сложность для новичков.

Введенные в HTTP/1.0, заголовки HTTP делают этот протокол легким для расширения и экспериментирования. Новая функциональность может быть даже добавлена путем простого соглашения между клиентом и сервером о семантике нового заголовка.

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

Соединение контролируется на транспортном уровне и, следовательно, принципиально не входит в область действия HTTP. HTTP не требует, чтобы лежащий в основе транспортный протокол был ориентирован на соединение; он только требует, чтобы он был надежным или не терял сообщений (как минимум, представляя ошибку в таких случаях). Из двух наиболее распространенных транспортных протоколов в Интернете TCP надежен, а UDP — нет. Поэтому HTTP полагается на стандарт TCP, который ориентирован на соединение.

Прежде чем клиент и сервер смогут обменяться парой запрос/ответ HTTP, они должны установить TCP-соединение, процесс, который требует нескольких обменов.

По умолчанию поведение HTTP/1.0 заключается в открытии отдельного TCP-соединения для каждой пары запрос/ответ HTTP. Это менее эффективно, чем использование одного TCP-соединения, когда отправляется несколько запросов подряд.

Чтобы уменьшить этот недостаток, HTTP/1.1 ввел пипелинирование (которое оказалось трудно реализовать) и постоянные соединения: подлежащее TCP-соединение можно частично контролировать, используя заголовок Connection. HTTP/2 продвинулся дальше, мултиплексируя сообщения по одному соединению, что помогает поддерживать соединение в рабочем состоянии и повысить эффективность.

Проводятся эксперименты по разработке лучшего транспортного протокола, более подходящего для HTTP. Например, Google экспериментирует с QUIC, который строится на основе UDP для предоставления более надежного и эффективного транспортного протокола.

Эта расширяемая природа HTTP со временем позволила получить больший контроль и функциональность в Интернете. Методы кеширования и аутентификации были функциями, обработанными на ранних этапах истории HTTP. Возможность ослабления ограничения происхождения, напротив, была добавлена только в 2010-х годах.

Вот список распространенных функций, которые можно контролировать с помощью HTTP:

• Кэширование Способ кэширования документов можно контролировать с помощью HTTP. Сервер может давать указания прокси-серверам и клиентам о том, что нужно кэшировать и на какой срок. Клиент может дать указание промежуточным прокси-серверам кэша игнорировать сохраненный документ.
• Ослабление ограничения происхождения Для предотвращения слежки и других вторжений в частную жизнь веб-браузеры применяют строгую изоляцию веб-сайтов. Только страницы из одного источника могут получить доступ ко всей информации веб-страницы. Хотя такое ограничение является бременем для сервера, HTTP-заголовки могут ослабить эту строгую изоляцию на стороне сервера, позволяя документу стать набором информации, полученной из разных доменов; для этого могут быть даже причины, связанные с безопасностью.
• Аутентификация Некоторые страницы могут быть защищены таким образом, что только определенные пользователи могут к ним получить доступ. Базовая аутентификация может быть обеспечена HTTP, либо с помощью WWW-Authenticate и подобных заголовков, либо путем установки определенной сессии с помощью HTTP-cookie.
• Прокси и туннелирование Серверы или клиенты часто находятся во внутренних сетях и скрывают свой настоящий IP-адрес от других компьютеров. Затем HTTP-запросы проходят через прокси, чтобы пересечь этот сетевой барьер. Не все прокси-серверы являются HTTP-прокси-серверами. Например, протокол SOCKS работает на более низком уровне. Другие протоколы, такие как ftp, могут обрабатываться этими прокси.
• Сессии Используя HTTP-cookie, можно связать запросы с состоянием сервера. Это создает сессии, несмотря на то, что базовый HTTP является бессостоятельным протоколом. Это полезно не только для корзинок покупок в электронной коммерции, но и для любого сайта, позволяющего пользователю настраивать вывод.

Когда клиент хочет связаться с сервером, либо с конечным сервером, либо с промежуточным прокси-сервером, он выполняет следующие шаги:

1. Открытие TCP-соединения: TCP-соединение используется для отправки запроса или нескольких запросов и получения ответа. Клиент может открыть новое соединение, повторно использовать существующее соединение или открыть несколько TCP-соединений к серверам.
2. Отправка HTTP-сообщения: HTTP-сообщения (до HTTP/2) легко читаемы человеком. С HTTP/2 эти простые сообщения инкапсулированы в кадры, что делает их нечитаемыми непосредственно, но принцип остается тем же. Например:

   GET / HTTP/1.1
   Host: developer.mozilla.org
   Accept-Language: fr
   

3. Чтение ответа, отправленного сервером, например:

   HTTP/1.1 200 OK
   Date: Sat, 09 Oct 2010 14:28:02 GMT
   Server: Apache
   Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
   ETag: "51142bc1-7449-479b075b2891b"
   Accept-Ranges: bytes
   Content-Length: 29769
   Content-Type: text/html
   
   <!DOCTYPE html>… (here come the 29769 bytes of the requested web page)
   

4. Закрытие или повторное использование соединения для дальнейших запросов.

Если активирован HTTP-пайплайнинг, несколько запросов можно отправлять без ожидания полного получения первого ответа. HTTP-пайплайнинг оказался сложным для реализации в существующих сетях, где старое программное обеспечение сосуществует с современным. HTTP-пайплайнинг был заменен в HTTP/2 более надежным множественным запросом в рамках кадра.

HTTP-сообщения, как определено в HTTP/1.1 и более ранних версиях, легко читаемы человеком. В HTTP/2 эти сообщения встроены в двоичную структуру — кадр, что позволяет оптимизировать, например, сжатие заголовков и мультиплексирование. Даже если в этой версии HTTP отправляется только часть исходного HTTP-сообщения, семантика каждого сообщения не меняется, и клиент воссоздает (виртуально) исходный HTTP/1.1-запрос. Поэтому полезно понимать HTTP/2-сообщения в формате HTTP/1.1.

Существует два типа HTTP-сообщений: запросы и ответы, каждый со своим форматом.

Пример HTTP-запроса:

Запросы состоят из следующих элементов:

• HTTP-метод, обычно глагол, такой как GET, POST, или существительное, такое как OPTIONS или HEAD, который определяет операцию, которую клиент хочет выполнить. Как правило, клиент хочет получить ресурс (используя GET) или отправить значение HTML-формы (используя POST) , хотя в других случаях могут потребоваться дополнительные операции.
• Путь к ресурсу для получения; URL ресурса, очищенного от элементов, которые очевидны из контекста, например, без протокола (http://), домена (здесь, developer.mozilla.org) или TCP-порта (здесь, 80).
• Версия протокола HTTP.
• Необязательные заголовки, которые передают дополнительную информацию серверам.
• Тело, для некоторых методов, таких как POST, аналогичное тем, что в ответах, которое содержит отправленный ресурс.

Пример ответа:

Ответы состоят из следующих элементов:

• Версия протокола HTTP, которому они следуют.
• Код состояния, указывающий, был ли запрос успешным или нет, и почему.
• Сообщение состояния, неавторитетное краткое описание кода состояния.
• HTTP-заголовки, подобные тем, что для запросов.
• Необязательно, тело, содержащее полученный ресурс.

Наиболее часто используемым API, основанным на HTTP, является XMLHttpRequest API, которое можно использовать для обмена данными между агентом пользователя и сервером. Современный Fetch API предоставляет те же функции с более мощным и гибким набором функций.

Другое API, события, отправляемые сервером, — это односторонний сервис, который позволяет серверу отправлять события клиенту с использованием HTTP в качестве транспортного механизма. Используя интерфейс EventSource, клиент открывает соединение и устанавливает обработчики событий. Браузер клиента автоматически преобразует сообщения, которые поступают по HTTP-потоку, в соответствующие Event объекты. Затем он передает их обработчикам событий, которые были зарегистрированы для type событий, если они известны, или обработчику события onmessage, если не был установлен обработчик событий для определенного типа.

HTTP — это расширяемый протокол, который легко использовать. Клиент-серверная структура в сочетании с возможностью добавления заголовков позволяет HTTP развиваться вместе с расширенными возможностями Интернета.

Хотя HTTP/2 добавляет некоторую сложность, встраивая HTTP-сообщения в кадры для повышения производительности, базовая структура сообщений осталась неизменной с HTTP/1.0. Поток сессий остается простым, позволяя его исследовать и отлаживать с помощью простого монитора HTTP-сообщений.