Почему QUIC, а не TCP+TLS

Вы знаете TCP. Вы знаете TLS. Вы знаете, как они складываются: браузер делает TCP-рукопожатие (1 RTT), потом TLS-рукопожатие сверху (ещё 1 RTT), и только потом отправляет HTTP-запрос. На межконтинентальной линии с задержкой 100 ms это 200 ms накладных расходов до того, как страница вообще начнёт загружаться.

Две проблемы TCP

TCP устарел. Добавление новых TCP-опций требует обновления ядра, выпуска патчей ОС через несколько месяцев, а потом нужно надеяться, что middlebox’ы — брандмауэры, NAT, балансировщики — не отбросят опцию молча. Это окостенение означало, что TCP почти не мог эволюционировать десятилетиями.

Вторая проблема: потеря одного пакета блокирует все потоки соединения, даже не связанные с этим пакетом. Это состояние называется head-of-line blocking.

Радикальное решение QUIC: вынести логику транспорта в пользовательское пространство (где её можно обновлять с каждым релизом приложения), запустить поверх UDP (который middlebox’ы не умеют инспектировать) и зашифровать почти весь пакет.

Определение в одно предложение

QUIC — транспортный протокол поверх UDP, который несёт TLS 1.3-рукопожатие, мультиплексирует много независимых потоков данных и переживает миграцию сети — ваш ноутбук переходит с WiFi на сотовую без потери соединения.

Метафора. Представьте почтовую доставку: TCP — это отправка конвертов один за другим в строгом порядке. Потеряешь один — все остальные ждут. QUIC — это почтальон с одной сумкой, в которой много отдельных конвертов; потеряешь один, остальные продолжают движение. Кроме того, сумка QUIC зашифрована.

Один сценарий от начала до конца

Вы открываете мобильное приложение, которое потоком отправляет видео через QUIC, одновременно отправляя периодические beacon-запросы (аналитика) и чат в реальном времени. В TCP каждый использовал бы своё соединение и платил три рукопожатия. В QUIC они используют одно соединение, так что платите одно 1-RTT-рукопожатие, а потом приложение может использовать stream ID 0 для видео, stream ID 2 для аналитики, stream ID 1 для чата. Потеря пакета в потоке 1 не блокирует видеокадры из потока 0. Когда вы переходите с WiFi на 4G, ID соединения остаётся действительным, все потоки остаются живы, и приложение никогда это не заметит.