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

Клиенты и серверы обмениваются отдельными сообщениями, а не потоками данных. Сообщения, отправленные клиентом, называются запросами, а сообщения, отправленные сервером в ответ, — ответами.

HTTP, разработанный в начале 1990-х годов, — это расширяемый протокол, который со временем эволюционировал. Это протокол прикладного уровня, передаваемый поверх TCP или зашифрованного с помощью TLS TCP-соединения, хотя теоретически можно использовать любой надёжный транспортный протокол. Благодаря своей расширяемости HTTP используется не только для получения гипертекстовых документов, но и для получения изображений и видео, а также для отправки содержимого на серверы, например результатов HTML-форм. HTTP также можно использовать для получения частей документов и обновления веб-страниц по запросу.

Компоненты систем на основе HTTP

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

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

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

Клиент: пользовательский агент

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

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

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

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

Веб-сервер

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

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

Прокси-серверы

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

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

Основные особенности HTTP

HTTP прост

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

HTTP расширяем

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

HTTP не сохраняет состояние, но поддерживает сеансы

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 со временем стало возможно лучше управлять Интернетом и расширять его функциональность. Кэширование и аутентификация обрабатывались средствами HTTP с самого начала его истории. Напротив, возможность ослабить ограничение по источнику появилась только в 2010-х годах.

Ниже приведён список распространённых возможностей, которыми можно управлять с помощью HTTP:

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

Процесс обмена данными по 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/2 на смену конвейеризации пришла более надёжная мультиплексированная передача запросов во фреймах.

HTTP-сообщения

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

Наиболее часто используемый API на основе HTTP — это Fetch API, который позволяет отправлять HTTP-запросы из JavaScript. Fetch API заменяет API XMLHttpRequest.

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

Заключение

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

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

См. также

• Эволюция HTTP
• Термины глоссария:
  • HTTP
  • HTTP/2
  • QUIC