Сети и протоколы
QUIC внутри: тест с множественным выбором
Суть Синтез с множественным выбором по всему юниту QUIC — транспорт в user space, независимость stream'ов, миграция, рукопожатие 1-RTT и 0-RTT, шифрование и CPU-цена развёртывания.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов через весь юнит. Каждый отражает реальное решение — когда выигрывает QUIC, когда TCP и что эта конструкция даёт и чего стоит, — а не определение для зубрёжки.
Цель
Убедись, что связываешь части: зачем QUIC живёт в user space, что на самом деле дают независимость stream’ов и Connection ID, где экономят рукопожатия 1-RTT и 0-RTT и где 0-RTT кусается, и почему тот же протокол, что выигрывает на мобильном, проигрывает на быстром LAN.
Викторина
Completed
Два сервиса отдают HTTP. Один — межконтинентальный API (мелкие payload'ы, RTT 120 мс, ~1% мобильных потерь); другой стримит статику на 1 Gbps клиентам в LAN. На каждом можно запустить HTTP/3 (QUIC) или HTTP/2 (TCP). Какая раскладка верна и почему?
Heads-up На быстром LAN пер-пакетный AES-GCM и user-space-фрейминг QUIC делают CPU узким местом раньше, чем заполнится линк; goodput падает ~45%, а на почти безпотерьном коротком пути выигрыша от head-of-line нет. Новее не значит быстрее везде.
Heads-up На пути API с RTT 120 мс и потерями узкое место — сеть, а не CPU, поэтому оверхед QUIC невидим, а рукопожатие 1-RTT и независимость stream'ов режут реальную задержку. Оверхед кусается только там, где CPU насыщается первым.
Heads-up Это инверсия компромисса. QUIC помогает там, где доминируют round-trip'ы и потери (API); kernel-offload TCP (kTLS, GSO, RSS) выигрывает там, где гонишь байты быстро по чистому линку (статика в LAN).
Викторина
Completed
Сервис на HTTP/2-over-TCP и сервис на HTTP/3-over-QUIC мультиплексируют по три параллельных ответа. При 0.5% потерь и RTT 100 мс теряется один пакет с ответом B. Что происходит с ответами A и C и почему?
Heads-up HTTP/2 мультиплексирует на уровне HTTP, но едет по одному упорядоченному TCP-stream'у, поэтому потеря блокирует всё. QUIC переносит мультиплексирование в транспорт, давая каждому stream'у свой порядок — это и есть исправление HoL, о котором юнит.
Heads-up Мультиплексирование HTTP/2 не помогает: блокировка идёт на транспорте TCP под ним. Только QUIC, владеющий транспортом, может изолировать stream'ы при потере.
Heads-up QUIC ретрансмитит только потерянный STREAM-фрейм для B; A и C нетронуты, соединение не сбрасывается. Пер-stream-восстановление — в этом весь смысл.
Викторина
Completed
Пользователь выходит из офиса; телефон переключается с WiFi на LTE посреди скачивания. Соединение QUIC выживает, а TCP бы умер. Что переносит соединение через смену IP и что сервер делает, прежде чем довериться новому адресу?
Heads-up Нового рукопожатия не происходит. Всё состояние stream'ов, flow-control и congestion выживает, потому что соединение идентифицирует Connection ID, а не IP. Повторное рукопожатие потеряло бы именно это состояние.
Heads-up UDP-пакеты всё равно несут source IP, а слепое переключение открыло бы вектор reflection-amplification. QUIC обязан валидировать новый путь через PATH_CHALLENGE/PATH_RESPONSE и дросселировать до 3x до этого.
Heads-up Keep-alive лишь не дают простаивающему соединению таймаутиться; они не сохранят соединение, чей 4-tuple сменился. Через миграцию выживает идентификация по Connection ID.
Викторина
Completed
Команда включает 0-RTT-resumption, чтобы срезать round-trip на переподключениях. Через неделю финансы сообщают об изредка дублирующихся переводах средств. В чём механизм и каков корректный фикс?
Heads-up 0-RTT зашифрован ключом session-ticket; атакующий не может его прочитать. Изъян в том, что тот же ciphertext можно переиграть и обработать повторно — это проблема replay, а не раскрытия.
Heads-up Полное отключение 0-RTT выбрасывает тот выигрыш по задержке, ради которого его включали. Стандартный фикс — проверка идемпотентности плюс 425 Too Early, что сохраняет 0-RTT для безопасных запросов.
Heads-up Congestion control тут ни при чём. Дублирующиеся переводы возникают из переигранных early-data 0-RTT, дважды выполняющих неидемпотентную операцию.
Викторина
Completed
После перехода на HTTP/3 сетевая команда жалуется, что их пакетные дашборды (счётчики запросов по flow, гистограммы RTT, детект медленных клиентов) погасли, и они больше не могут вбросить RST, чтобы убить плохой flow на middlebox. Как это читать?
Heads-up QUIC намеренно шифрует почти весь пакет end-to-end; у пассивного монитора ключей нет и не должно быть. Непрозрачность — это by design, а не ошибка конфигурации.
Heads-up QUIC работает на UDP 443. Метаданные отсутствуют потому, что зашифрованы, а не потому, что порт скрыт — смена порта ничего не меняет.
Heads-up И то, и другое исчезло по одной причине: packet number и payload зашифрованы, поэтому без ключа невозможны ни учёт запросов, ни поддельный RST. Потеря RST-инъекции — на деле выигрыш в безопасности.
Викторина
Completed
Коллега утверждает, что QUIC строго лучше TCP, потому что «он работает в user space, значит быстрее». Где ошибка в рассуждении и что на самом деле даёт размещение в user space?
Heads-up User-space QUIC добавляет syscall'ы (один sendmsg на датаграмму без GSO) и теряет NIC-offload крипто, поэтому он медленнее на байт. Его преимущество — гибкость и HoL-free stream'ы, а не throughput.
Heads-up QUIC работает в user space by design — отсюда и его CPU-цена, и способность эволюционировать без обновлений ядра. Местоположение названо верно; неверен вывод «быстрее».
Heads-up QUIC шифрует больше TCP, а не меньше — почти весь пакет, на каждый пакет. CPU-цена выше, а выигрыш — в скорости эволюции и независимости stream'ов.
Итог
Юнит сводится к одному взвешенному решению: QUIC меняет CPU на задержку и устойчивость. Размещение в user space даёт эволюционируемость (подключаемый CC, отсутствие ossification) ценой 15–30% CPU на байт; независимость stream’ов убивает head-of-line-блокировку при потерях; Connection ID переживают миграцию сети с валидацией пути и защитой 3x anti-amplification; объединённое рукопожатие 1-RTT экономит round-trip, а 0-RTT — ещё один ценой replay (только идемпотентное, 425 Too Early); почти полное шифрование блокирует RST-инъекции и сниффинг, но ослепляет пакетный мониторинг. Бери QUIC на путях, ограниченных round-trip’ами, потерями и мобильностью, — оставляй TCP там, где быстрый чистый линк делает CPU узким местом.