HTTP/3 и QUIC: изоляция потерь на уровне потока

HTTP/2 исправил очередь на уровне приложения. TCP вернул ту же очередь на уровне байт. Ответ HTTP/3: выбросить TCP полностью и пересобрать надёжность на UDP — по-потоково, не по-соединению. Один потерянный пакет тормозит один поток, а не пятьдесят.

Почему QUIC вместо TCP

TCP гарантирует упорядоченную доставку. Пакет с байтами 1000–1099 потерян. TCP держит в буфере байты 1100–1199, ожидая повторной передачи. Только после её прихода приложение получает байты 1100+. На HTTP/2-уровне — поток #1 использует байты 1000–1099, поток #2 — 1100–1199: оба блокируются, хотя данные потока #2 уже пришли.

QUIC (RFC 9000) построен на UDP и переосмысляет надёжность на уровне потока:

• QUIC нумерует пакеты, не байтовые смещения единого потока. Каждый пакет несёт фреймы из одного или нескольких потоков, каждый фрейм с stream ID и смещением.
• Восстановление потерь per-stream. Когда пакет N потерян, повторно передаются только те потоки, чьи данные были в пакете N. Потоки в других пакетах продолжают работу.
• TLS 1.3 встроен в QUIC. QUIC-хендшейк и TLS-хендшейк происходят вместе — нет отдельного TCP-хендшейка затем TLS-хендшейка. Холодное QUIC-соединение стоит 1 RTT; с session resumption — 0 RTT для данных.

QPACK: сжатие заголовков без связи потоков

HTTP/3 заменяет HPACK на QPACK (RFC 9204). Проблема HPACK на QUIC: динамическая таблица упорядочена — если HEADERS-фрейм добавляющий индекс 60 приходит не в порядке (потерян или запоздал), все HEADERS ссылающиеся на индекс 60 блокируются. На TCP это незаметно; на QUIC-потоках это сломало бы изоляцию потоков.

Решение QPACK: вынести обновления динамической таблицы в отдельный управляющий поток. Обычные HEADERS-фреймы на потоках запросов ссылаются только на записи, которые кодировщик знает уже подтверждёнными декодером. HEADERS потока #3 никогда не блокируется обновлениями таблицы потока #1.

Статическая таблица QPACK содержит 99 прединдексированных записей (против 61 у HPACK), покрывая ещё больше общих заголовков.

Миграция соединения

QUIC-соединения идентифицируются connection ID — токеном выбранным при установке — а не 4-tuple (src IP, src port, dst IP, dst port). Когда мобильное устройство переключается с Wi-Fi на LTE (меняется IP), QUIC-соединение может мигрировать:

1. Клиент отправляет PATH_CHALLENGE с нового IP.
2. Сервер валидирует и отвечает PATH_RESPONSE.
3. Соединение продолжает без повторного хендшейка.

HTTP/2 поверх TCP потеряет соединение при смене IP — 4-tuple меняется, TCP-соединение сбрасывается, нужен новый хендшейк (1–2 RTT). Для мобильных пользователей миграция QUIC — ощутимый выигрыш при смене сети.

Согласование версии HTTP/3

HTTP/3 нельзя согласовать только через ALPN — QUIC-пакеты идут по UDP, а многие файрволы блокируют UDP/443. Два способа обнаружения:

1. Alt-Svc заголовок: ответ HTTP/1.1 или HTTP/2 содержит Alt-Svc: h3=":443"; ma=86400. Браузер сохраняет подсказку и пробует HTTP/3 при следующей навигации к этому origin (в пределах ma секунд).
2. HTTPS / SVCB DNS-записи (RFC 9460): сервер публикует DNS-запись с поддержкой HTTP/3, и браузеры могут попробовать его даже при первом соединении.

При первой навигации браузер использует TCP-based HTTP/1.1 или /2, узнаёт о /3 через Alt-Svc, затем пробует /3 при следующих. Если /3 не работает (UDP заблокирован), браузер молча фолбечится на /2.

0-RTT resumption

QUIC наследует 0-RTT resumption TLS 1.3: если у клиента есть session ticket от предыдущего соединения, первый QUIC-пакет может нести данные приложения (HTTP-запрос) вместе с материалом TLS-хендшейка. Экономит один RTT — значимо на межконтинентальных линках (100–300 мс).

То же предостережение что и для TLS 1.3 0-RTT: данные 0-RTT воспроизводимы. Сетевой атакующий может переиграть первый пакет. Серверы должны принимать 0-RTT только для идемпотентных методов (GET, HEAD). Для небезопасных методов (POST) современные стеки отвечают 425 Too Early.