Анатомия HTTP-запроса

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

Эта статья разбирает структуру HTTP-запроса в различных версиях протокола и освещает то, что фронтенд-разработчикам необходимо знать о современных HTTP-заголовках и их практическом применении.

Структура HTTP-запроса: основные компоненты

HTTP-запрос состоит из трех частей: строки запроса (или её эквивалента), заголовков и необязательного тела.

В HTTP/1.1 запрос выглядит следующим образом:

POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Content-Length: 45

{"username": "dev", "email": "dev@example.com"}

Строка запроса содержит метод (POST), целевой путь (/api/users) и версию протокола. Заголовки предоставляют метаданные — тип контента, аутентификацию, директивы кэширования. Тело несет полезную нагрузку, когда это необходимо.

Эта структура остается семантически идентичной в HTTP/1.1, HTTP/2 и HTTP/3. Меняется способ представления и передачи этих компонентов.

HTTP-запросы в HTTP/1.1 vs HTTP/2 vs HTTP/3

HTTP/1.1: текстовый формат и последовательная обработка

HTTP/1.1 передает запросы в виде обычного текста через TCP. Запросы обрабатываются последовательно в рамках одного соединения. Хотя HTTP/1.1 поддерживает постоянные соединения (keep-alive) и конвейеризацию (pipelining), браузеры обычно избегают конвейеризации из-за блокировки начала очереди (head-of-line blocking). Вместо этого браузеры обходят ограничение одного запроса, открывая несколько параллельных соединений, обычно шесть на источник.

Заголовок Host обязателен в HTTP/1.1 — он сообщает серверу, какой виртуальный хост должен обработать запрос.

HTTP/2: бинарное фреймирование и мультиплексирование

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

• :method — HTTP-метод
• :path — путь и строка запроса
• :scheme — http или https
• :authority — эквивалент заголовка Host в HTTP/2+, используется для идентификации целевого источника

Несколько запросов используют одно TCP-соединение благодаря мультиплексированию. Заголовки сжимаются с помощью HPACK, устраняя избыточность повторения похожих заголовков в разных запросах.

HTTP/3: QUIC и устойчивость соединения

HTTP/3 использует QUIC поверх UDP вместо TCP. Это устраняет блокировку начала очереди TCP на транспортном уровне — если один поток останавливается, другие продолжают работать без помпомех. Миграция соединения позволяет запросам переживать изменения сети, что особенно полезно на мобильных устройствах при переключении между Wi-Fi и сотовой связью.

Сжатие заголовков в HTTP/3 использует QPACK вместо HPACK, адаптированный для корректной работы с независимыми потоками QUIC.

Семантика запросов остается прежней. Ваш код не меняется — меняется транспорт.

Современные HTTP-заголовки, которые имеют значение

Помимо базовых заголовков, таких как Content-Type и Authorization, несколько современных заголовков заслуживают внимания:

Заголовки Fetch Metadata (Sec-Fetch-Site, Sec-Fetch-Mode, Sec-Fetch-Dest) позволяют серверам понимать контекст запроса — является ли он запросом с того же источника, межсайтовым или инициированным навигацией, а не скриптом.

Client Hints (Sec-CH-UA, Sec-CH-UA-Platform, Sec-CH-UA-Mobile) предоставляют информацию об устройстве и браузере в структурированном, ориентированном на приватность виде, снижая зависимость от устаревшей строки User-Agent во многих случаях использования.

Заголовок Priority сигнализирует серверу о важности ресурса, помогая ему решить, что отправить первым через мультиплексированные соединения, хотя реальная поддержка варьируется между серверами и CDN.

Практические последствия для фронтенд-разработчиков

Приоритизация производительности

Заголовок Priority (определенный в RFC 9218) влияет на то, как серверы и CDN упорядочивают ответы. Он заменяет модель веса и зависимости потоков эпохи HTTP/2 более простой схемой, использующей параметры urgency и incremental. Критические ресурсы, такие как шрифты или изображения в видимой части страницы, могут быть помечены высоким приоритетом, чтобы они прибывали первыми.

Соображения безопасности

Обращайте внимание на конфликтующие заголовки Content-Length и Transfer-Encoding — это несоответствие может позволить атаки типа request smuggling. Серверы должны отклонять неоднозначные запросы, но понимание риска помогает при отладке неожиданного поведения.

Эволюционирующая модель cookie

Cookie теперь по умолчанию имеют значение SameSite=Lax в современных браузерах, что ограничивает отправку cookie в межсайтовых подзапросах, если явно не настроено иначе. Партиционированные cookie (CHIPS) изолируют сторонние cookie для каждого сайта верхнего уровня, влияя на то, как встроенный контент управляет состоянием.

Заключение

Анатомия HTTP-запроса — метод, цель, заголовки, тело — остается последовательной во всех версиях протокола. Меняется формат передачи по сети: текст в HTTP/1.1, бинарные фреймы в HTTP/2, потоки QUIC в HTTP/3.

Для фронтенд-разработки сосредоточьтесь на понимании псевдо-заголовков при отладке HTTP/2+, используйте современные заголовки, такие как Fetch Metadata и Client Hints, и следите за изменениями в безопасности и cookie, которые влияют на поведение запросов. Протокол обрабатывает сложность транспорта. Ваша задача — знать, что вы на самом деле отправляете.

Часто задаваемые вопросы

Gain control over your UX

See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.