HTTP

Материал из llmdocs — справочник разработчика
HTTP
Полное названиеHyperText Transfer Protocol
АвторТим Бернерс-Ли (CERN)
Появился1991 (HTTP/0.9)
ВерсииHTTP/1.1, HTTP/2, HTTP/3
СпецификацияRFC 9110 (семантика), RFC 9112 (HTTP/1.1), RFC 9113 (HTTP/2), RFC 9114 (HTTP/3)
ТранспортTCP (HTTP/1.1, HTTP/2), QUIC (HTTP/3)
Порты80 (HTTP), 443 (HTTPS)
СтандартизацияIETF, W3C (ранние версии)

HTTP (англ. HyperText Transfer Protocol — «протокол передачи гипертекста») — прикладной протокол, по которому браузеры получают веб-страницы, а программы обмениваются данными через API. Работа устроена по схеме «запрос — ответ»: клиент отправляет запрос (метод, адрес, заголовки, иногда тело), сервер возвращает ответ (код состояния, заголовки, тело). HTTPS — тот же HTTP, передаваемый по защищённому каналу TLS.

Изначально HTTP создавался для передачи HTML-документов, но сегодня по нему передаются изображения, видео, JSON для REST-API, потоковые данные и даже ответы языковых моделей.

История

Тим Бернерс-Ли разработал HTTP в CERN в 1989–1991 годах вместе с HTML и первым браузером. Первая версия, позже названная HTTP/0.9, умела только одно — GET документа по пути, без заголовков. HTTP/1.0 (RFC 1945, 1996) добавил заголовки, коды состояния и разные типы содержимого.[4] HTTP/1.1 (1997, затем RFC 2616 в 1999 году) ввёл постоянные соединения, обязательный заголовок Host для виртуального хостинга и улучшенное кэширование.

В 2015 году вышел двоичный HTTP/2, а в 2022 году — HTTP/3 поверх QUIC (см. HTTP/2 и HTTP/3).[6] В том же 2022 году IETF переработала спецификации: общая семантика — методы, коды, заголовки — описана в RFC 9110 независимо от версии, а форматы передачи — в отдельных документах.[1]

Запрос и ответ

В HTTP/1.1 сообщения — обычный текст:[2]

GET /api/users/42 HTTP/1.1
Host: example.com
Accept: application/json
Authorization: Bearer eyJhbGciOi...
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 46
Cache-Control: max-age=60

{"id": 42, "name": "Алиса", "role": "admin"}

Первая строка запроса содержит метод, путь и версию; первая строка ответа — версию и код состояния. Затем идут заголовки, пустая строка и необязательное тело. В HTTP/2 и HTTP/3 смысл сообщений тот же, но они кодируются в двоичные кадры.

Методы

Метод Назначение Безопасный Идемпотентный
GET получить ресурс да да
HEAD как GET, но без тела да да
POST создать ресурс или выполнить действие нет нет
PUT заменить ресурс целиком нет да
PATCH частично изменить ресурс нет нет
DELETE удалить ресурс нет да
OPTIONS узнать возможности сервера (в том числе для CORS) да да

Безопасный метод не меняет состояние сервера, идемпотентный даёт тот же результат при повторе. Это важно на практике: клиент или прокси может автоматически повторить идемпотентный запрос после обрыва связи, а повтор POST способен, например, дважды списать деньги.

Заголовки

  • Содержимое: Content-Type (тип данных: text/html, application/json), Content-Length, Content-Encoding (сжатие gzip, br, zstd).
  • Согласование: Accept, Accept-Language, Accept-Encoding — что клиент готов принять.
  • Аутентификация: Authorization, WWW-Authenticate; состояние между запросами хранят cookie (Set-Cookie, Cookie).
  • Кэширование: Cache-Control, ETag, Last-Modified, If-None-Match — позволяют не передавать неизменившиеся данные повторно.[3]
  • Безопасность: Strict-Transport-Security, Content-Security-Policy, заголовки CORS.

Отсутствие состояния

HTTP — протокол без сохранения состояния (stateless): каждый запрос самодостаточен, и сервер не обязан помнить предыдущие. Это упрощает масштабирование — любой запрос может обработать любой экземпляр сервера за балансировщиком. «Память» о пользователе реализуется поверх протокола: cookie с идентификатором сессии или токены в заголовке Authorization (см. OAuth 2.0 и OpenID Connect).

Соединения и версии

HTTP/1.1 передаёт запросы в одном TCP-соединении строго по очереди, поэтому браузеры открывают до шести соединений на сайт. HTTP/2 мультиплексирует много запросов в одном соединении и сжимает заголовки; HTTP/3 переносит это на QUIC и избавляется от блокировки всех потоков при потере одного пакета. Для приложений семантика всех версий одинакова — меняется только способ доставки.

Практика

curl -i https://example.com              # заголовки и тело ответа
curl -v https://example.com 2>&1 | less  # подробности: TLS, версия, заголовки
curl -X POST --json '{"name":"Алиса"}' https://api.example.com/users

Для отладки используют curl, вкладку «Сеть» в инструментах разработчика браузера и прокси вроде mitmproxy. Подробный справочник по заголовкам и методам — на MDN.[5]

См. также

Источники

  1. RFC 9110 — HTTP Semantics
  2. RFC 9112 — HTTP/1.1
  3. RFC 9111 — HTTP Caching
  4. RFC 1945 — Hypertext Transfer Protocol — HTTP/1.0
  5. MDN — An overview of HTTP
  6. RFC 9114 — HTTP/3