HTTP/2: мультиплексирование, сжатие заголовков и приоритеты

Ранние версии HTTP работали по принципу очереди: в одном соединении запрос уходил, ответ приходил, и только потом можно было задавать следующий вопрос. Современная страница тянет десятки и сотни файлов, поэтому браузеры открывали по несколько параллельных соединений к одному серверу, а разработчики склеивали скрипты и рисовали спрайты, чтобы уменьшить число обращений. Всё это были временные приёмы, маскировавшие ограничение самого протокола.

HTTP/2, стандартизованный в 2015 году, сохранил прежнюю семантику: те же методы, коды статусов и заголовки. Изменился способ упаковки сообщений на проводе. Поэтому сайт, перешедший на новую версию, обычно не меняет логику приложения, а обновляет настройки веб-сервера.

Вместо текстовых сообщений HTTP/2 использует двоичные кадры. Каждый запрос вместе с ответом образует поток со своим номером, а кадры разных потоков перемешиваются в одном TCP-соединении и на приёмной стороне собираются обратно. Это и называется мультиплексированием. Один медленный ответ больше не задерживает остальные на уровне самого HTTP, и браузеру достаточно одного соединения на домен.

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

Отдельный практический эффект — исчезает смысл в старых приёмах вроде разнесения ресурсов по нескольким доменам. Раньше это давало больше параллельных соединений, а в HTTP/2 приводит к обратному: каждому домену нужно своё соединение и своё рукопожатие TLS, так что выигрыш от единого канала теряется.

Заголовки в HTTP/1.1 передавались каждый раз целиком, хотя от запроса к запросу почти не меняются: тот же Host, тот же User-Agent, те же cookie. HTTP/2 применяет сжатие HPACK. Обе стороны ведут общую таблицу уже встречавшихся полей, и повторяющийся заголовок заменяется коротким индексом. Оставшиеся значения кодируются алгоритмом Хаффмана.

Выбор HPACK вместо обычного gzip не случаен. Сжатие заголовков общим алгоритмом оказалось уязвимым к атакам, в которых по размеру сжатого сообщения можно угадывать секретные значения, вроде cookie. HPACK разрабатывался с учётом этого риска. Экономия особенно заметна на мобильных сетях, где каждый лишний килобайт запроса стоит времени.

Браузеры поддерживают HTTP/2 только поверх TLS, хотя сама спецификация допускает и работу без шифрования. Договориться о версии клиент и сервер могут прямо во время рукопожатия TLS с помощью расширения ALPN, поэтому лишний круг обращений не нужен. Большинство крупных сайтов и CDN отдают страницы по этому протоколу автоматически.

Заметнее всего выигрыш там, где много небольших ресурсов и высокая задержка. Для одного крупного файла разница с HTTP/1.1 может быть почти неощутимой. Функцию server push, при которой сервер отправлял ресурсы, о которых клиент ещё не просил, браузеры позднее убрали или отключили из-за низкой практической пользы, так что отдельным «плюсом» её считать не стоит.

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

Ещё одно заблуждение — что HTTP/2 сам шифрует трафик. Шифрование даёт TLS, а протокол лишь чаще всего работает поверх него. Проверить версию у себя можно в инструментах разработчика: во вкладке «Сеть» включите столбец «Протокол», и рядом с запросами появится обозначение h2.

Для владельца сайта переход обычно сводится к включению протокола в настройках веб-сервера или сети доставки контента и наличию действующего сертификата. Полезно после этого перепроверить прежние оптимизации: склейку файлов и спрайты уже не нужно делать любой ценой, поскольку множество мелких запросов перестало быть проблемой. Слепо удалять их тоже не следует, а измерять результат по реальным пользователям надёжнее.