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]