Сети и протоколы
QUIC внутри: докажи на проводе
Читать про QUIC — не то же самое, что увидеть в захвате пакетов, как соединение переживает смену сети. Подними реальный HTTP/3-сервер, докажи на проводе каждое громкое утверждение юнита, затем измерь счёт за CPU — чтобы решение о развёртывании опиралось на твои числа, а не на маркетинг.
Преврати ментальную модель юнита в доказательства: захвати и прочитай рукопожатие 1-RTT, продемонстрируй независимость stream’ов при потерях, посмотри, как соединение мигрирует через смену IP, вскрой риск replay для 0-RTT и измерь CPU-цену QUIC против TCP на быстром линке — затем напиши вывод о развёртывании.
Запусти HTTP/3 (QUIC)-сервер и базовый TCP/HTTP-2 и подготовь отчёт с доказательствами на проводе, демонстрирующий пять ключевых механизмов юнита и квантифицирующий компромисс QUIC CPU-против-задержки — каждое утверждение подкреплено захватом, трассой или измерением.
- Аннотированный артефакт рукопожатия (qlog или трасса), показывающий QUIC на 1 RTT и TCP+TLS на 2 RTT до первого байта приложения, с отмеченными round-trip'ами.
- Сравнение с инъекцией потерь: трасса или метрика, доказывающая, что QUIC стопорит только потерянный stream, пока HTTP/2 стопорит все при тех же потерях, с указанными временами пер-stream-задержки.
- Захват миграции, показывающий один Connection ID на двух source-адресах плюс пару PATH_CHALLENGE/PATH_RESPONSE, и подтверждение, что повторного рукопожатия не было.
- До/после для защиты 0-RTT: переигранный запрос, выполняющийся дважды без защиты, и отклонённый (или 425 Too Early) с ней.
- Таблица CPU-против-goodput: QUIC и TCP на одном битрейте, QUIC с UDP GSO и без, с пер-байтовым CPU-оверхедом и восстановлением от GSO в процентах.
- Одностраничная рекомендация по развёртыванию, называющая, какие пути (WAN/mobile vs быстрый LAN) должны бежать на QUIC, а какие на TCP, обоснованная твоими числами по рукопожатию, потерям и CPU.
- Смени congestion-контроллер (NewReno → CUBIC → BBR) на QUIC-сервере и сравни goodput и tail-задержку при тех же внесённых потерях, иллюстрируя, почему подключаемый CC делает кросс-стек-бенчмарки нечестными.
- Построй небольшой слой наблюдаемости: распарси qlog в четыре сигнала, которые сетевая команда потеряла, когда пакеты стали непрозрачными (счётчики запросов по stream'ам, RTT, доля потерь, доля fallback), и покажи, что он восстанавливает то, что tcpdump больше не может.
- Ротируй Connection ID (NEW_CONNECTION_ID) при миграции и подтверди в захвате, что on-path-наблюдатель не может связать идентичности до и после миграции.
- Добавь проверку anti-amplification: отправь Initial с подделанным source меньше 1200 байт и подтверди, что сервер отказывается переотвечать, затем проверь, что он соблюдает бюджет 3x к невалидированному адресу.
Вот как QUIC перестаёт быть абстракцией: ты наблюдаешь рукопожатие 1-RTT, видишь, как один stream стопорится, пока остальные текут, захватываешь соединение, переживающее смену IP, и сам триггеришь replay 0-RTT перед тем, как его исправить, — затем ставишь число на счёт за CPU и пишешь вывод о развёртывании. Сделав это раз на проводе, ты превращаешь утверждения юнита в проверенное, а не прочитанное, — именно та позиция, что нужна, когда production-решение ложится тебе на стол.