HTTP/2 или HTTP/3: мультиплексирование, QUIC и поведение при потерях пакетов

Семантика HTTP во всех версиях одна: методы, заголовки, коды ответа, адреса. Меняется способ доставки этих сообщений по сети. HTTP/1.1 отправлял запросы текстом и по одному на соединение, из-за чего браузер открывал несколько соединений параллельно.

HTTP/2 ввёл бинарный формат, сжатие заголовков и мультиплексирование: много запросов идёт по одному соединению TCP одновременно. HTTP/3 сохраняет эту идею, но заменяет транспорт: вместо TCP используется QUIC, протокол поверх UDP, в который встроено шифрование TLS 1.3.

Для пользователя переход обычно незаметен: сайт открывается, а версию выбирают браузер и сервер при согласовании.

Главная проблема HTTP/2 связана с TCP. Мультиплексирование происходит выше транспортного уровня, а TCP видит единый поток байтов. Если потерялся один пакет, TCP ждёт повторной отправки и удерживает все данные после него, даже если они относились к другим запросам. Так один потерянный пакет тормозит все ресурсы страницы.

В QUIC потоки независимы: потеря затрагивает только тот поток, к которому относился пакет, остальные продолжают загружаться. На хорошем проводном канале разница почти не видна, на нестабильном Wi-Fi или мобильной сети она заметнее. Насколько именно, зависит от условий, и заранее давать цифры нельзя.

Поэтому улучшения HTTP/3 в первую очередь ощущаются на мобильных и беспроводных сетях, где потери пакетов обычное дело, а не на стабильном кабеле в офисе.

У HTTP/2 поверх TCP и TLS для установки защищённого соединения нужно несколько обменов. HTTP/3 объединяет установку транспорта и шифрования, за счёт чего первое соединение открывается быстрее, а повторное может отправлять данные почти сразу, с оговорками о безопасности такого режима.

Вторая особенность: QUIC использует идентификатор соединения, а не набор адресов и портов. Если телефон переключился с Wi-Fi на мобильную сеть, соединение может продолжиться без нового рукопожатия. В TCP такое соединение обрывается, и приходится начинать заново. Для мобильных устройств это заметное практическое преимущество, особенно при потоковом видео и звонках.

Стоит отметить, что использование идентификатора соединения даёт не только удобство, но и вопросы приватности, которые разработчики протокола учитывали, предусматривая смену идентификаторов.

HTTP/3 работает поверх UDP, а не все сети относятся к нему дружелюбно. Некоторые корпоративные и общественные сети ограничивают UDP или пропускают только определённые порты, и тогда браузер возвращается к HTTP/2 или HTTP/1.1. Клиенты обычно так и делают автоматически, поэтому страница откроется, просто без ускорения.

Сетевые устройства хуже умеют анализировать QUIC: шифрованию подвергаются не только данные, но и часть служебной информации транспорта. Это усложняет отладку и фильтрацию для администраторов. Кроме того, серверные программы обрабатывают QUIC пока с большей нагрузкой на процессор, чем TCP, что учитывают при планировании ресурсов.

Для администраторов это означает необходимость обновить средства мониторинга и правила экранов, чтобы они корректно учитывали трафик UDP на порту 443.

В инструментах разработчика браузера на вкладке сети можно включить столбец протокола: там указано h2 для HTTP/2 и h3 для HTTP/3. Некоторые сайты сообщают о доступности HTTP/3 через специальный заголовок, и браузер запоминает это для следующих обращений, поэтому первый заход может идти по h2, а второй по h3.

Если вы владелец сайта, включайте HTTP/3 как дополнение, а не замену: клиенты без поддержки продолжат работать по HTTP/2. Проверьте, что UDP-порт 443 открыт на экране сервера. Если вы пользователь и подозреваете, что новый протокол вызывает проблемы, тестовый переход на предыдущую версию в настройках браузера поможет локализовать причину.

Выбирать между версиями чаще всего не нужно: поддержку определяют браузер и сервер, и оба варианта сосуществуют. Для сайта разумно включить оба. Для сети с нестабильным каналом преимущества HTTP/3 обычно заметнее, для стабильного проводного соединения разница мала.

Не ждите чудес: скорость загрузки страницы зависит от размера ресурсов, кеширования, расстояния до сервера и качества канала не меньше, чем от версии протокола. Прежде чем связывать медленный сайт с HTTP, проверьте эти факторы.