QUIC-потоки и head-of-line blocking

В вашем HTTP/2-соединении три запроса в полёте. Один пакет теряется на перегруженном роутере. Теперь все три ответа зависли — хотя у двух из них все байты уже в буфере, готовы к доставке. QUIC создавался, чтобы сделать это невозможным.

Head-of-line blocking в TCP

TCP доставляет все байты в одном упорядоченном потоке. Если пакет N потерян, все байты после него — в каждом логическом сообщении — ждут переотправки пакета N, прежде чем приложение может их обработать.

HTTP/2 мультиплексирует пары запрос-ответ через одно TCP-соединение. Когда TCP теряет пакет, все HTTP/2-потоки зависают — даже те, чьи данные пришли целыми. Это head-of-line blocking на уровне соединения.

Числа: При 0,5% случайных потерь и RTT 100 ms сообщение, заблокированное в упорядоченной доставке TCP, ждёт ~230 ms. QUIC сокращает это до ~0,4 ms — улучшение в 575 раз.

Потоки QUIC независимы

QUIC мультиплексирует множество двунаправленных и однонаправленных потоков по одному соединению. Каждый поток имеет:

• Собственное окно управления потоком (фрейм max-stream-data).
• Собственное фреймирование на уровне приложения (STREAM-фреймы, каждый с ID потока и смещением).
• Независимое обнаружение потерь — повтор STREAM-фрейма затрагивает только его поток.

Когда STREAM-фрейм с данными потока 7 теряется, только получатель потока 7 ждёт переотправки; потоки 1, 3, 5 продолжают получать новые данные.

Распределение Stream ID

Stream ID кодирует инициатора и направление в двух младших битах:

• Клиент-инициированный двунаправленный: 0, 4, 8, 12, … (младшие 2 бита = 00)
• Сервер-инициированный двунаправленный: 1, 5, 9, 13, … (младшие 2 бита = 01)
• Клиент-инициированный однонаправленный: 2, 6, 10, 14, … (младшие 2 бита = 10)
• Сервер-инициированный однонаправленный: 3, 7, 11, 15, … (младшие 2 бита = 11)

В HTTP/3 каждая пара HTTP-запрос/ответ — это один клиент-инициированный двунаправленный поток (IDs 0, 4, 8…). Эта кодировка позволяет обеим сторонам выделять ID независимо, без координации.