Альтернативные пути: QUIC 0-RTT, WebSocket upgrade, миграция соединения

Мобильный пользователь в поезде сообщает, что сайт перезагружается каждый раз, когда поезд проезжает тоннель. Тем временем дашборд в реальном времени на основе WebSocket тихо теряет сообщения, когда один клиент медленно их потребляет. У обеих проблем одна первопричина: транспорт был разработан для стабильных соединений, но реальность нестабильна. HTTP/3 и WebSocket справляются с этим по-разному — и оба отказывают способами, которые нужно явно проектировать.

Путь A: HTTP/3 поверх QUIC

Почему QUIC вместо TCP. TCP мультиплексирует потоки через одно соединение, но один потерянный пакет останавливает весь TCP receive window до повторной передачи. У HTTP/2 поверх TCP именно эта проблема: один медленный поток блокирует все остальные потоки того же соединения. QUIC реализует потоки как независимые сущности — потерянный пакет в потоке A не блокирует потоки B, C или D. Эта независимость потоков — главное преимущество в сетях с потерями (мобильные, межконтинентальные линки).

Объединённое рукопожатие. TCP требует отдельного трёхстороннего handshake (1 RTT) до начала TLS (ещё минимум 1 RTT). QUIC их объединяет: Initial-пакет QUIC несёт TLS ClientHello. Сервер отвечает одним пакетом, содержащим транспортные параметры QUIC и TLS ServerHello. Итого: 1 RTT для нового соединения вместо 2.

0-RTT возобновление. Для тёплых соединений (пользователь возвращается к тому же origin в пределах срока действия session ticket), клиент отправляет данные приложения внутри Initial-пакета QUIC — до того как сервер ответил. Эффективный RTT для первого байта: 0 дополнительных round-trips. Ограничение: 0-RTT безопасен только для идемпотентных методов (GET, HEAD). Запросы POST/PUT должны ждать завершения handshake (сервер отклоняет 0-RTT для неидемпотентных запросов с 425 Too Early).

Максимальный объём ранних данных 0-RTT. Серверы ограничивают количество байт ранних данных (обычно: 16–64 КБ). Если HTTP-запрос + заголовки превышают это, остаток отправляется после handshake. Это ограничение предотвращает использование злоумышленниками 0-RTT для внедрения большой нагрузки до завершения аутентификации.

Миграция соединения (мобильные сети)

Когда телефон Бэа переключается с WiFi на мобильный интернет, её IP-адрес меняется. При TCP+HTTP/2 TCP-четвёрка (src IP, src port, dst IP, dst port) является частью идентификатора соединения — смена IP разрывает соединение. Бэа должна заново установить TCP + TLS + HTTP, заплатив полную стоимость handshake.

При QUIC соединения идентифицируются Destination Connection ID — непрозрачным токеном, выданным Свеном при handshake, выбранным Свеном, присутствующим в каждом заголовке пакета QUIC. Ядро Бэа отправляет фрейм PATH_CHALLENGE с нового IP. Свен отвечает PATH_RESPONSE с тем же Connection ID, подтверждая, что смена IP легитимна (а не злоумышленник подделывает исходный IP Бэа). Все потоки в полёте продолжаются по новому пути. Миграция стоит один дополнительный round-trip (~50 мс в хорошей сети), но позволяет избежать повторного установления всего соединения.

Путь B: WebSocket upgrade для коммуникации в реальном времени

HTTP работает по схеме запрос-ответ — один запрос, один ответ. Для двунаправленной коммуникации в реальном времени (чат, совместное редактирование, live-дашборды) клиенту нужно получать сообщения от сервера без нового запроса для каждого. WebSocket решает это, обновляя HTTP-соединение до постоянного полнодуплексного канала.

Upgrade handshake. Клиент отправляет:

GET /ws HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: <base64 random 16 bytes>

Сервер отвечает:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: <HMAC of key + magic string>

После 101 TCP-соединение перепрофилируется как WebSocket. Обе стороны обмениваются фреймами асинхронно — без порядка запрос-ответ, без заголовков на каждое сообщение.

Структура фрейма. Каждый WebSocket-фрейм несёт:

• FIN бит (1 = финальный фрагмент, 0 = следуют ещё фрагменты)
• Opcode (1=текст, 2=двоичный, 8=закрытие, 9=ping, 10=pong)
• Маскирование (клиент→сервер обязательно, XOR с 4-байтовым маскирующим ключом — защита от отравления кэша)
• Длина нагрузки + нагрузка

Большие сообщения фрагментируются по нескольким фреймам (FIN=0 для фрагментов, FIN=1 для финального). Получатель буферизирует до FIN=1 перед доставкой приложению.

Keepalive через ping/pong. У WebSocket нет встроенного keepalive на уровне TCP. Примерно через 75 с без фрейма многие сетевые устройства таймаутируют простаивающие TCP-соединения. Решение: отправлять ping-фреймы каждые 15–30 с. Получатель отвечает pong. Если pong не получен в течение таймаута, соединение мертво и должно быть переустановлено.

Отказ из-за backpressure. Если приложение Бэа медленно потребляет сообщения (например, тяжёлая JavaScript-обработка каждого сообщения), send buffer Свена заполняется. Когда Свен вызывает write() на сокете, ядро возвращает WOULDBLOCK. Наивный серверный код, закрученный на WOULDBLOCK, повышает CPU; наивный код, теряющий сообщения, теряет данные. Правильный паттерн: Свен прекращает читать от Бэа (приостанавливает входящий поток) до опустошения исходящего буфера. Правильные библиотеки WebSocket реализуют это через async/await и API backpressure потоков.