HTTP/1.1, HTTP/2 и HTTP/3

01HTTP/1.1: по одному запросу за раз

HTTP/1.1 (1997, уточнён в RFC 9112) — текстовый протокол. Keep-alive позволяет переиспользовать соединение, но на каждом соединении запросы обслуживаются строго один за другим: если один ответ медленный, всё, что за ним, ждёт. Это head-of-line blocking на уровне HTTP. Браузеры обходят его, открывая около шести соединений на хост, а разработчики придумывали трюки: domain sharding на несколько hostname'ов, спрайты изображений и склейку всего JavaScript в один файл. Заголовки передаются обычным текстом с каждым запросом, поэтому cookie и user agent повторяются тысячи раз. Аналогия: одна касса, где следующий покупатель ждёт, пока закончит предыдущий, поэтому магазины открывают шесть касс.

02HTTP/2: мультиплексирование и HPACK

HTTP/2 (2015, сейчас RFC 9113) сохраняет те же методы, заголовки и статус-коды, но меняет формат передачи на бинарные фреймы. Его главная особенность — мультиплексирование: множество запросов и ответов одновременно идут по одному TCP-соединению как независимые потоки, перемежаясь фрейм за фреймом. Один медленный ответ больше не блокирует остальные на уровне HTTP. HPACK сжимает заголовки с помощью таблицы ранее отправленных значений, поэтому повторяющиеся cookie и заголовки стоят всего несколько байт. Приоритизация позволяет браузеру сообщить, что важнее. Server push существовал, но его убрали из браузеров, потому что он редко помогал; его заменяет 103 Early Hints с preload. На практике браузеры используют HTTP/2 только поверх TLS, договариваясь о нём через ALPN во время рукопожатия.

• Одно соединение на origin вместо шести — меньше рукопожатий.
• Domain sharding теперь вредит: он заставляет открывать лишние соединения.
• Много маленьких файлов — это нормально; делите бандлы по маршрутам вместо одного гигантского файла.

03Оставшаяся проблема: head-of-line blocking в TCP

HTTP/2 устранил блокировку на уровне HTTP, но не ниже. TCP гарантирует, что байты приходят по порядку. Если теряется один пакет, TCP задерживает всё, что идёт после него, до повторной передачи, — даже данные, относящиеся к другим потокам. В чистой офисной сети это редкость. В мобильных сетях с потерей пакетов 1–2% один потерянный пакет тормозит все изображения, скрипты и API-вызовы на этом соединении. В плохих условиях HTTP/2 на одном соединении может быть даже медленнее, чем HTTP/1.1 на шести. Кроме того, TCP живёт в ядре операционной системы, поэтому его улучшение занимает годы обновлений ОС. Вот почему понадобился новый транспорт.

04HTTP/3: QUIC поверх UDP

HTTP/3 (RFC 9114, 2022) работает поверх QUIC (RFC 9000) — транспорта, построенного на UDP. QUIC сам реализует надёжность, управление перегрузкой и потоки, и каждый поток независим: потерянный пакет задерживает только свой поток. TLS 1.3 встроен в QUIC, поэтому новому соединению нужен один круговой путь вместо двух-трёх у TCP плюс TLS, а возобновлённые соединения могут отправлять данные сразу (0-RTT; его стоит ограничивать безопасными идемпотентными запросами, потому что такой запрос можно воспроизвести повторно). Соединения идентифицируются по connection ID, а не по IP и порту, поэтому телефон, переключившийся с Wi-Fi на мобильный интернет, сохраняет соединение. Заголовки сжимаются QPACK — вариантом HPACK. Браузеры узнают о HTTP/3 из заголовка Alt-Svc или DNS-записи HTTPS и откатываются на HTTP/2, если UDP 443 заблокирован.

05Как включить в nginx и Cloudflare

В nginx 1.25.1 и новее HTTP/2 включается директивой http2 (старый параметр listen ... http2 устарел), а HTTP/3 — quic-listener'ом на том же порту при сборке с модулем QUIC, который есть в текущих официальных пакетах. Анонсируйте HTTP/3 заголовком Alt-Svc и откройте UDP 443 в файрволе. В Cloudflare HTTP/2 и HTTP/3 для посетителей включены по умолчанию; проверить их можно в настройках Speed или Network. Соединение от Cloudflare до вашего origin — отдельное: оно использует HTTP/1.1 или HTTP/2 поверх TCP, поэтому origin за Cloudflare не нуждается в HTTP/3. Проверяйте через curl или колонку Protocol во вкладке Network браузера.

1server {
2    listen 443 ssl;
3    listen 443 quic reuseport;   # reuseport only once per port
4    http2 on;
5    http3 on;
6    server_name example.com;
7    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
8    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
9    ssl_protocols TLSv1.2 TLSv1.3;
10    add_header Alt-Svc 'h3=":443"; ma=86400' always;
11}
12# sudo ufw allow 443/udp
13# curl -sI --http2 https://example.com/ | head -1

06Что это значит для работы над производительностью

Когда HTTP/2 или HTTP/3 включены, сосредоточьтесь на том, что по-прежнему стоит времени. Круговые пути всё ещё важны, поэтому держите критический путь коротким: делайте preload главного изображения и основного шрифта, избегайте длинных цепочек редиректов и отдавайте контент с CDN рядом с пользователями. Байты тоже важны, поэтому сжимайте и отправляйте меньше JavaScript. Склейка файлов менее важна, но тысячи крошечных модулей всё равно дают накладные расходы; оптимум — разбиение бандлов по маршрутам. Избегайте domain sharding и лишних сторонних origin'ов, ведь каждому новому origin нужны DNS, соединение и TLS; для тех, без которых не обойтись, используйте preconnect. Измеряйте на реальных пользователях: выигрыш от HTTP/3 заметен в основном в медленных сетях с потерями, а не на вашем быстром десктопе.

07Приоритизация: от деревьев зависимостей к Extensible Priorities

Мультиплексирование порождает новый вопрос: если двадцать ответов делят одно соединение, какие байты идут первыми? Изначально HTTP/2 позволял клиентам строить дерево зависимостей с весами, но оно было сложным, браузеры использовали его непоследовательно, а многие серверы игнорировали, поэтому RFC 9113 объявил его устаревшим. На смену пришли Extensible Priorities (RFC 9218), которые используют HTTP/2 и HTTP/3. Клиент отправляет простой заголовок или фрейм Priority: срочность u от 0 (самая высокая) до 7 и флаг incremental i, означающий, что ответ полезен по частям, как прогрессивное изображение. Серверы и CDN планируют отправку данных соответственно, так что CSS и LCP-изображение могут обогнать большой скрипт аналитики. На странице повлиять на то, что отправляет браузер, можно через fetchpriority и preload. Если где-то на пути приоритизация сломана, мультиплексирование может даже задерживать критичные файлы за большими.

1GET /css/main.css HTTP/2
2priority: u=0
3 
4GET /img/hero.avif HTTP/2
5priority: u=1, i
6 
7GET /js/analytics.js HTTP/2
8priority: u=5

08Flow control и атаки, специфичные для HTTP/2

У HTTP/2 и QUIC есть управление потоком на уровне stream и на уровне соединения: каждая сторона объявляет окно байтов, которое готова принять, и отправитель должен дождаться WINDOW_UPDATE, прежде чем слать больше. Маленькие окна по умолчанию могут ограничивать пропускную способность на быстрых длинных каналах, поэтому серверы их настраивают. Мультиплексирование также породило новые схемы отказа в обслуживании. В 2023 году атака Rapid Reset (CVE-2023-44487) открывала и сразу отменяла огромное количество stream, так что серверы выполняли работу по запросам, которые не учитывались в лимитах параллельности; это дало рекордные по мощности флуды. HPACK и QPACK требуют лимитов на размер таблицы заголовков, чтобы не допустить исчерпания памяти. Защита в основном — обновления и разумные лимиты: держите nginx и прокси пропатченными, ограничивайте число параллельных stream (http2_max_concurrent_streams, в nginx по умолчанию 128), ограничивайте размер заголовков и позвольте CDN поглощать объёмные атаки.

09QUIC изнутри: handshake, восстановление после потерь, миграция

Пакеты QUIC зашифрованы, включая большую часть заголовка, поэтому промежуточные устройства не могут анализировать или подменять транспортные детали, и протокол остаётся способным к развитию. Номера пакетов никогда не повторяются, даже при повторной отправке, что устраняет неоднозначность TCP в том, к какой копии относится подтверждение, и делает оценки round trip точнее. Пока адрес клиента не подтверждён, сервер может отправить не больше чем в три раза больше байтов, чем получил, — это не даёт использовать QUIC для атак с усилением; под нагрузкой пакет Retry с токеном позволяет сначала подтвердить адрес. Connection ID позволяют телефону сменить сеть без нового handshake, а endpoint проверяет новый путь, прежде чем ему доверять. Цена: QUIC работает в user space, шифрование идёт на каждый пакет, а пути отправки и приёма UDP оптимизированы хуже, чем у TCP, поэтому расход CPU на байт выше. Возможности ядра вроде UDP GSO и увеличенных буферов сокетов сокращают разрыв.

10Обнаружение, fallback и реальная картина

Браузер не может заранее знать, что сервер умеет HTTP/3. Обычный путь такой: первый визит идёт по HTTP/2 поверх TCP, в ответе есть Alt-Svc: h3=":443", и следующие соединения устраивают гонку QUIC против TCP, используя то, что сработало. DNS-запись HTTPS может объявить h3 ещё до первого соединения, пропуская этот шаг. Если UDP 443 заблокирован или ограничен файрволом, браузер тихо откатывается на TCP и может какое-то время помнить о неудаче, поэтому неправильно настроенный сервер редко выглядит сломанным — он просто никогда не получает HTTP/3-трафик. На сервере проверьте, что файрвол и облачные security group разрешают UDP 443, что на обоих listener отдаётся один и тот же сертификат и что балансировщики пробрасывают UDP. В логах записывайте протокол каждого запроса ($server_protocol в nginx), чтобы видеть реальную долю каждой версии.

1# Ask for HTTP/3 directly (curl built with HTTP/3 support)
2curl -sI --http3-only https://example.com/ | head -1
3# Is h3 advertised?
4curl -sI https://example.com/ | grep -i alt-svc
5dig example.com HTTPS +short
6# nginx log format: add the protocol per request
7# log_format main '$remote_addr "$request" $status $server_protocol';