HTTP, HTTPS и TLS: Часть 3 — HTTP/1.1, HTTP/2 и HTTP/3: чем отличаются версии

У HTTP три версии в активном использовании: HTTP/1.1, HTTP/2 и HTTP/3. Методы, заголовки и коды состояния у них одинаковые, поэтому приложению обычно всё равно, по какой версии пришёл запрос. Разница в том, как сообщения упакованы и переданы по сети, и именно от неё зависит скорость загрузки страниц с десятками ресурсов и поведение на плохой мобильной связи.

HTTP/1.1

Версия 1997 года (сейчас — RFC 9112). Сообщения — текст, соединение TCP держится открытым между запросами (keep-alive).

Главное ограничение — очередь. По одному соединению нельзя отправить второй запрос, пока не пришёл ответ на первый. Механизм конвейеризации (pipelining), позволявший отправить несколько запросов подряд, в стандарте был, но ответы всё равно должны были идти по порядку, и одна медленная картинка задерживала всё остальное. Браузеры его так и не включили.

Обходные пути эпохи HTTP/1.1:

• до шести соединений к одному хосту в браузере;
• шардирование доменов — раздача статики с static1.example.ru, static2.example.ru, чтобы получить больше соединений;
• склейка скриптов и стилей в один файл, спрайты из картинок.

Каждое новое соединение — это рукопожатие TCP и TLS, отдельный медленный старт TCP и лишняя нагрузка на сервер.

HTTP/2

Стандарт 2015 года (сейчас — RFC 9113), вырос из протокола SPDY компании Google.

Двоичные кадры вместо текста. Сообщение разбито на кадры (frames): кадр заголовков, кадры данных. Каждый кадр помечен номером потока.

Мультиплексирование. В одном TCP-соединении одновременно идут десятки потоков (streams), по одному на запрос. Кадры разных ответов перемежаются, и медленный ответ не держит остальные. Браузеру хватает одного соединения на сайт, а шардирование доменов и склейка файлов становятся лишними и даже вредными: несколько доменов — это несколько соединений и DNS-запросов.

Сжатие заголовков HPACK. В HTTP/1.1 каждый запрос заново передаёт User-Agent, Cookie, Accept — сотни байт, повторяющихся от запроса к запросу. HPACK держит у обеих сторон таблицу уже переданных заголовков и отправляет только ссылки на неё.

Псевдозаголовки. Стартовая строка заменена полями :method, :path, :scheme, :authority (вместо Host) в запросе и :status в ответе. Все имена заголовков — строчными буквами.

Server push — отправка сервером ресурсов, о которых клиент ещё не спросил. На практике экономии почти не давал, и Chrome отключил его в версии 106 (2022). Вместо push используют ответ 103 Early Hints и <link rel="preload">.

Только с TLS в браузерах. Стандарт допускает HTTP/2 без шифрования (h2c), но ни один браузер его не поддерживает. Версия выбирается во время рукопожатия TLS расширением ALPN: клиент предлагает h2, http/1.1, сервер выбирает. h2c встречается во внутренних сетях, например в gRPC между сервисами.

Проблема, которая осталась. Мультиплексирование устранило очередь на уровне HTTP, но не на уровне TCP. TCP доставляет байты строго по порядку, и если потерялся один пакет, все потоки в соединении ждут его повторной отправки, даже те, чьих данных в нём не было. Это называется блокировкой начала очереди (head-of-line blocking). На стабильном канале это незаметно, а при потерях 1–2 % на мобильной сети HTTP/2 с одним соединением может работать хуже, чем HTTP/1.1 с шестью.

HTTP/3 и QUIC

HTTP/3 (RFC 9114, 2022) работает поверх QUIC (RFC 9000) — транспортного протокола на UDP, который взял на себя задачи TCP и TLS.

Потоки на уровне транспорта. QUIC сам знает о потоках, и потеря пакета задерживает только тот поток, чьи данные в нём были. Блокировка начала очереди исчезает.

TLS 1.3 встроен. Шифрование в QUIC обязательно, отдельного рукопожатия TLS поверх транспорта нет — ключи согласуются в первых же пакетах QUIC. Новое соединение устанавливается за один круг обмена (1-RTT) вместо двух для TCP + TLS 1.3, повторное — может отправлять данные сразу (0-RTT). Шифруются и служебные поля транспорта, которые в TCP видны всем: номера пакетов, подтверждения.

Миграция соединения. Соединение QUIC определяется не парой IP-адрес и порт, а идентификатором соединения. Когда телефон переходит с Wi-Fi на мобильную сеть, загрузка продолжается без нового рукопожатия.

Сжатие заголовков QPACK — вариант HPACK, приспособленный к тому, что потоки приходят не по порядку.

Как браузер узнаёт о HTTP/3. Первое подключение к сайту идёт по TCP (HTTP/2 или 1.1). Сервер сообщает о поддержке HTTP/3 заголовком:

alt-svc: h3=":443"; ma=86400

и браузер при следующих запросах пробует QUIC на UDP-порт 443. Второй способ — DNS-запись типа HTTPS с параметром alpn="h3": тогда браузер может пойти по HTTP/3 сразу.

Ограничения. UDP/443 закрыт в части корпоративных сетей, а в некоторых сетях QUIC режется или замедляется целенаправленно. Браузеры в этом случае незаметно для пользователя возвращаются на TCP, поэтому HTTP/3 всегда включают дополнительно к HTTP/2, а не вместо него. Обработка QUIC в пространстве пользователя расходует больше процессора на сервере, чем TCP в ядре.

Сводная таблица

Включение в Nginx

HTTP/2 в Nginx 1.25.1 и новее включается отдельной директивой (старая форма listen 443 ssl http2 устарела). HTTP/3 — через listen ... quic, модуль ngx_http_v3_module есть в официальных пакетах с nginx.org начиная с 1.25:

server {
    listen 443 ssl;
    listen 443 quic reuseport;   # reuseport — только в одном server на порт
    listen [::]:443 ssl;
    listen [::]:443 quic reuseport;

    http2 on;
    http3 on;

    server_name example.ru;
    ssl_certificate     /etc/letsencrypt/live/example.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.ru/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;   # для QUIC нужен TLSv1.3

    add_header Alt-Svc 'h3=":443"; ma=86400' always;
}

Не забудьте открыть UDP/443 в межсетевом экране — это самая частая причина, по которой HTTP/3 «не включается»:

ufw allow 443/udp

Caddy включает HTTP/2 и HTTP/3 сам, без настройки. В HAProxy HTTP/3 есть с версии 2.6 (bind quic4@:443 ssl crt ... alpn h3).

Как проверить версию

curl показывает согласованную версию в выводе -v и в переменной http_version:

curl -sI --http2 https://example.ru/ -o /dev/null -w '%{http_version}\n'
# 2

curl -sI --http3 https://example.ru/ -o /dev/null -w '%{http_version}\n'
# 3 — если curl собран с поддержкой HTTP/3

Поддерживает ли ваш curl HTTP/3, видно в строке Features вывода curl --version (слово HTTP3). Системный curl в macOS и многих дистрибутивах собран без него. Проверить можно Docker-образом, в котором curl собран с HTTP/3, либо через браузер: в инструментах разработчика на вкладке Network включите колонку Protocol — там будет h2 или h3.

Ключ --http3 пробует QUIC, но параллельно запускает попытку по TCP и возвращается на неё, если QUIC не ответил. Чтобы проверить именно QUIC без отката, используйте --http3-only.

Типичные ошибки

• HTTP/3 включён в конфиге, но UDP/443 закрыт на сервере или у хостера — браузеры молча остаются на HTTP/2.
• reuseport указан в нескольких блоках server на один адрес — Nginx не запустится с ошибкой о дублирующемся параметре.
• Внутренние сервисы за прокси ждут HTTP/2 (gRPC), а прокси ходит к ним по HTTP/1.1 — в Nginx для этого нужен grpc_pass, а не proxy_pass.
• Склейка всех скриптов в один огромный файл по привычке времён HTTP/1.1 — при HTTP/2 мелкие файлы грузятся параллельно и лучше кешируются по отдельности.