HTTP/2

HTTP/2 — это вторая крупная версия протокола передачи гипертекста (HTTP), используемого для передачи данных во Всемирной паутине. Он основан на протоколе SPDY, разработанном компанией Google, и стандартизирован в 2015 году как RFC 7540 (позднее обновлён до RFC 9113). Основная цель HTTP/2 — повышение производительности веб-приложений за счёт уменьшения задержек, более эффективного использования сетевых ресурсов и устранения некоторых недостатков HTTP/1.1, таких как блокировка начала очереди (head-of-line blocking). Протокол сохраняет семантику HTTP, включая методы, коды состояния и заголовки, но полностью меняет способ их передачи по сети.

История

Разработка HTTP/2 началась в ответ на растущие ограничения HTTP/1.1, который, несмотря на свою распространённость, демонстрировал низкую эффективность при загрузке современных веб-страниц, состоящих из множества мелких ресурсов (изображений, скриптов, стилей). В 2009 году компания Google представила протокол SPDY, который ввёл такие концепции, как мультиплексирование потоков, сжатие заголовков и приоритизация запросов. Тесты показали, что SPDY может значительно ускорить загрузку страниц.

В 2012 году рабочая группа HTTPbis при Инженерном совете Интернета (IETF) начала работу над стандартизацией нового протокола на основе SPDY. В 2015 году был опубликован RFC 7540, описывающий HTTP/2, и RFC 7541, описывающий сжатие заголовков HPACK. Поддержка HTTP/2 была быстро внедрена в основные веб-серверы (Apache, Nginx, IIS) и браузеры (Chrome, Firefox, Safari, Edge). В 2022 году был опубликован RFC 9113, уточняющий и исправляющий некоторые аспекты протокола.

Ключевые особенности

HTTP/2 кардинально отличается от HTTP/1.1 по способу организации передачи данных. Основные нововведения включают:

Бинарный формат фреймов

В отличие от текстового формата HTTP/1.1, HTTP/2 использует бинарный протокол. Все данные и управляющие сообщения кодируются в фреймы (frames) — бинарные блоки фиксированной структуры. Это упрощает разбор и обработку данных на стороне сервера и клиента, снижает вероятность ошибок парсинга и повышает производительность.

Мультиплексирование потоков

Одно из главных нововведений. В HTTP/1.1 для параллельной загрузки нескольких ресурсов браузеру приходилось открывать несколько TCP-соединений (обычно до 6-8 на домен). HTTP/2 позволяет отправлять несколько запросов и получать несколько ответов одновременно в рамках одного TCP-соединения. Каждый запрос и ответ разбивается на фреймы, которые передаются вперемешку. Это устраняет проблему блокировки начала очереди (head-of-line blocking) на уровне протокола HTTP, когда один медленный ответ задерживает все последующие запросы в том же соединении.

Приоритизация потоков

Клиент может указать приоритет для каждого потока (запроса), сообщая серверу, какие ресурсы важнее загрузить в первую очередь. Например, критический CSS-файл может иметь более высокий приоритет, чем изображение в нижней части страницы. Сервер, в свою очередь, может использовать эту информацию для оптимального распределения пропускной способности.

Server Push

Сервер может отправлять клиенту ресурсы, которые, по его мнению, понадобятся для отображения страницы, без явного запроса от клиента. Например, при запросе HTML-страницы сервер может сразу же отправить связанные с ней CSS-файлы и JavaScript-скрипты. Это позволяет сократить количество циклов запрос-ответ и ускорить загрузку. Однако на практике Server Push оказался сложным в реализации и часто приводил к избыточной отправке данных, поэтому его использование снизилось, а в некоторых реализациях (например, в Chrome) он был отключён.

Сжатие заголовков (HPACK)

В HTTP/1.1 заголовки передавались в незашифрованном текстовом виде, что приводило к избыточному трафику, особенно при повторяющихся запросах (например, заголовки Cookie и User-Agent). HTTP/2 использует алгоритм сжатия HPACK, который основан на статической и динамической таблицах. Часто используемые заголовки кодируются короткими индексами, а повторяющиеся значения не передаются повторно. Это значительно сокращает объём передаваемых данных.

Отличия от HTTP/1.1

Устройство протокола

HTTP/2 работает поверх TCP-соединения. Вся коммуникация организована в виде последовательности фреймов, которые группируются в потоки (streams). Каждое TCP-соединение может содержать множество потоков, передаваемых одновременно.

• Фрейм (Frame): минимальная единица данных. Существуют различные типы фреймов: DATA (передача тела запроса/ответа), HEADERS (передача заголовков), SETTINGS (настройки соединения), PRIORITY (приоритеты), RST_STREAM (сброс потока) и другие.
• Поток (Stream): двунаправленная последовательность фреймов, представляющая собой один запрос-ответ. Каждый поток имеет уникальный идентификатор.
• Соединение (Connection): одно TCP-соединение, в рамках которого мультиплексируются все потоки.

Процесс установки соединения HTTP/2 начинается с согласования протокола. Обычно это происходит через расширение TLS ALPN (Application-Layer Protocol Negotiation), где клиент и сервер договариваются об использовании HTTP/2. Также возможен вариант без шифрования (h2c), но он редко применяется на практике, так как большинство браузеров поддерживают HTTP/2 только через TLS.

Применение и влияние

HTTP/2 стал стандартом де-факто для современных веб-сайтов. Его внедрение позволило:

• Ускорить загрузку страниц: за счёт мультиплексирования и сжатия заголовков время загрузки сложных страниц сократилось на 10-50% по сравнению с HTTP/1.1.
• Снизить нагрузку на серверы: меньшее количество TCP-соединений снижает потребление памяти и процессорного времени на стороне сервера.
• Улучшить пользовательский опыт: особенно на мобильных устройствах с высокими задержками (latency).

Однако HTTP/2 не лишён недостатков. Главная проблема — блокировка начала очереди на уровне TCP (TCP head-of-line blocking). Если один TCP-пакет теряется, все потоки в соединении задерживаются до его повторной передачи. Эта проблема решается в следующей версии протокола — HTTP/3, который работает на основе протокола QUIC (поверх UDP).

Критика

Основные критические замечания в адрес HTTP/2 касаются:

• Сложности реализации: бинарный протокол и управление потоками сложнее для реализации, чем текстовый HTTP/1.1.
• Проблем с Server Push: как упоминалось выше, Server Push часто оказывался неэффективным и мог приводить к избыточной передаче данных.
• Зависимости от TCP: уязвимость к TCP head-of-line blocking, особенно заметная на нестабильных каналах связи (например, мобильный интернет).
• Необходимости шифрования: хотя протокол может работать и без TLS, на практике все браузеры требуют шифрования, что может быть проблемой для некоторых внутренних или устаревших систем.

Интересные факты

• Протокол SPDY, ставший основой для HTTP/2, был разработан инженером Google Майком Белшем (Mike Belshe) и Роберто Пеоном (Roberto Peon).
• Стандарт RFC 7540 был опубликован в мае 2015 года и сразу же получил широкую поддержку.
• HTTP/2 не требует изменений в коде веб-приложений — все изменения касаются только транспортного уровня. Разработчики продолжают использовать привычные API (например, fetch в JavaScript).
• По состоянию на 2024 год, HTTP/2 поддерживается более чем 95% веб-сайтов, использующих HTTPS, и всеми современными браузерами.

Источники

• RFC 7540 — Hypertext Transfer Protocol Version 2 (HTTP/2)
• RFC 7541 — HPACK: Header Compression for HTTP/2
• RFC 9113 — HTTP/2 (обновлённая версия)
• Документация IETF HTTP Working Group
• Материалы конференций и публикации Google о протоколе SPDY