SPDY, QUIC, HTTP/2 и HTTP/3: кратко

Написал “лонг-рид” про веб-протоколы.

Уже в конце нулевых стало понятно, что HTTP/1 не очень хватает для растущего трафика в интернетах: например, хотелось выкачивать больше данных впалалелль по одному соединению, открывать соединения быстрее и тд.

Cтали разрабатываться новые стандарты:

🤩 SPDY (2009) Goolgle внес гигантский вклад в изменения HTTP. Первой ласточкой был SPDY (“спиди”). Основные идеи: бинарный протокол (экономим на парсинге), мультиплексирование (много параллельных запросов в одном соединении), server push (отправка заранее данных, которые клиент ещё не запросил)

🤩 HTTP/2 (RFC 7540, 2015) — стандартизация бинарного протокола поверх TCP с мультиплексированием. Но из-за TCP остаётся проблема Head-of-Line Blocking — потеря одного пакета тормозит все потоки сразу.

🤩 QUIC — транспортный протокол поверх UDP. Появился раньше HTTP/2 как эксперимент: Google разработал свой gQUIC и развернул в Chrome ещё в 2013-м. В 2016-м работу передали в IETF (открытое сообщество для выратботки стандартов интернета). Протокол переделали: например, заменили самописную крипту на стандартный TLS 1.3, и финализировали как RFC 9000 в 2021-м. Теперь QUIC сам берёт на себя нумерацию пакетов, контроль порядка и скорости, шифрование встроено в протокол. Потоки независимы, поэтому потеря пакета не блокирует остальные.

🤩 HTTP/3 (RFC 9114, 2022) — финальная стандартизация и HTTP-семантика поверх IETF QUIC. Даёт быстрое установление соединения: QUIC объединяет транспортный и TLS-хендшейк в один раунд вместо раздельных рукопожатий TCP и TLS. 0-RTT — для уже знакомого сервера клиент шлёт данные сразу с первым пакетом, не дожидаясь хендшейка. Миграция при смене IP — соединение опознаётся по специальному идентификатору, а не по паре IP:порт, и поэтому переживает переход Wi-Fi→LTE или смену адреса в NAT без обрыва.

HTTP/3 добавлял особенностей для внедрения:

🤩TLS 1.3 теперь обязателен и вшит внутрь кода сервера — в QUIC шифрование не опционально, а вшито в транспорт (RFC 9001), причём именно версии 1.3. Сложность не в самом TLS 1.3, а в том, что QUIC использует его нестандартно: ему нужен особый низкоуровневый API, которого штатный OpenSSL долго не имел. Из-за этого ранние реализации HTTP/3 тащили альтернативные библиотеки (BoringSSL, QuicTLS), теряя привычную развязку, когда крипто-уязвимости чинятся обновлением ОС без правок самого сервера.

🤩Анонс через Alt-Svc — в отличие от HTTP/2, HTTP/3 нельзя “выбрать” сразу: браузер делает первый контакт по TCP, ещё не зная, умеет ли сервер QUIC. Сервер сообщает об этом заголовком Alt-Svc: h3=":443" в обычном ответе — «умею UDP/QUIC на порту 443», тогда браузер пробует HTTP/3 уже на следующих запросах. Отсюда сложности: первое соединение всегда «потеряно» (идёт по HTTP/2, выигрыша на первой загрузке нет); время жизни анонса (ma) надо настраивать аккуратно; но главное — если что-то в цепочке сломано (UDP зарезан, не та TLS-библиотека, порт не совпал с анонсом), браузер молча откатывается на HTTP/2. Всё работает, ошибки нет — и легко поверить, что HTTP/3 включён, но надо аккуратно дебажить и смотреть в трафик, это просто добавляет кучу сложности.

🤩 Корпорации могут резать UDP-трафик — QUIC работает поверх UDP, а многие корпоративные фаерволы и старое сетевое оборудование по умолчанию режут или ограничивают UDP (его исторически использовали в основном для DNS и атак), пропуская только TCP. Если UDP заблокирован, HTTP/3 просто не установится, и клиент молча откатится на HTTP/2.

Короче, стали внедрять: LiteSpeed, затем Caddy, Nginx, IIS и HAProxy. Caddy включает HTTP/3 по умолчанию, Nginx — с версии 1.25. Также есть поддержка у Angie. Про особенности, сложности, особенно в области безопасности, а также про недавние успехи Angie на поприще внедрения HTTP/3 — в следукющем посте.

Интересно про трафик и веб-серверы? Онлайн-встреча по балансировке и Angie уже в этот четверг, 28 мая, в 18:00 MSK. Информация и запись - в боте @devhands_meetup_bot

🔥 да, больше мяса и хардов!
👍 папа, с кем ты сейчас разговаривал?