HTTP/2 и HTTP/3: что это и как включить

Почему HTTP/1.1 перестало хватать

HTTP/1.1, разработанный в 1997 году, десятилетиями оставался стандартом веб-протокола, но его архитектура не была рассчитана на современные страницы с десятками и сотнями отдельных ресурсов — изображений, файлов CSS и JavaScript, шрифтов, иконок. Каждое TCP-соединение в HTTP/1.1 обрабатывает запросы строго последовательно (или требует открытия нескольких параллельных соединений), что создаёт заметные задержки при загрузке насыщенной ресурсами страницы.

Эта проблема получила название head-of-line blocking — если один запрос в очереди соединения выполняется медленно, все последующие запросы в этом же соединении вынуждены ждать, даже если сервер уже готов на них ответить. Браузеры обходили ограничение, открывая до 6-8 параллельных TCP-соединений к одному домену, но это решение имеет свою цену — каждое новое соединение требует времени на TCP-рукопожатие и TLS-согласование.

Мы наблюдали, что современная веб-страница загружает в среднем более 100 отдельных ресурсов — модель, при которой каждый ресурс либо ждёт своей очереди, либо требует отдельного дорогого TCP-соединения, попросту не масштабируется.

Обоснование разработки протокола HTTP/2 рабочей группой IETF

HTTP/2, стандартизированный в 2015 году, и HTTP/3, стандартизированный в 2022 году, решают эту проблему двумя разными, но взаимодополняющими способами — эта статья разбирает оба протокола и показывает, как включить их на практике.

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

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

Дополнительно HTTP/2 использует бинарный формат кадров вместо текстового формата HTTP/1.1 (что эффективнее разбирается компьютером, хотя менее читаемо человеком напрямую) и сжатие заголовков запросов через алгоритм HPACK — заголовки на многих сайтах занимают значительный объём в каждом запросе, особенно с учётом cookies, и их сжатие даёт заметную экономию трафика при большом количестве запросов.

Функция server push, изначально заявленная как часть HTTP/2 (позволяющая серверу проактивно отправлять ресурсы, которые точно понадобятся браузеру, не дожидаясь явного запроса), на практике не оправдала ожиданий — из-за сложности эффективного использования большинство браузеров, включая Chrome, отказались от её поддержки, и эта возможность считается фактически устаревшей.

Включение HTTP/2 в Nginx

В современных сборках Nginx (начиная с версии 1.25.1) поддержка HTTP/2 включена в основной сборке и активируется одним параметром в директиве listen — никаких дополнительных модулей устанавливать не нужно.

server {
    listen 443 ssl;
    http2 on;
    server_name example.ru;
    ssl_certificate /etc/letsencrypt/live/example.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.ru/privkey.pem;
}

В более старых версиях Nginx (до 1.25.1) синтаксис отличался — параметр http2 указывался прямо в директиве listen через пробел после ssl: listen 443 ssl http2;. Стоит свериться с версией установленного Nginx командой nginx -v перед выбором конкретного синтаксиса конфигурации.

nginx -v
nginx -t
systemctl reload nginx

Включение HTTP/2 в Apache

В Apache HTTP/2 требует явно подключённого модуля mod_http2, который присутствует не во всех готовых сборках хостинг-панелей — для его использования модуль нужно включить отдельно, а затем указать протокол в конфигурации виртуального хоста.

a2enmod http2
systemctl restart apache2

<VirtualHost *:443>
    Protocols h2 http/1.1
    ServerName example.ru
    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/example.ru/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.ru/privkey.pem
</VirtualHost>

Директива Protocols h2 http/1.1 задаёт приоритет протоколов — сервер предложит клиенту HTTP/2 (h2), и только если клиент его не поддерживает, соединение откатится на HTTP/1.1 автоматически через механизм согласования ALPN на этапе TLS-рукопожатия.

HTTP/3 и QUIC: решение проблемы на уровне транспорта

HTTP/2 решил проблему блокировки на уровне приложения (мультиплексирование потоков), но оставил нерешённой блокировку на уровне транспортного протокола TCP: если один пакет TCP теряется по дороге, все данные, следующие за ним в этом соединении, блокируются до тех пор, пока потерянный пакет не будет повторно передан — независимо от того, к какому HTTP-потоку эти данные относятся.

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

QUIC — это TCP и TLS, переосмысленные заново с нуля с учётом того, что мы знаем о проблемах современного веба, включая блокировку и медленное восстановление после потери пакетов на нестабильных мобильных сетях.

Общая характеристика QUIC в технических публикациях IETF

Дополнительное практическое преимущество QUIC — более быстрое установление соединения: TLS 1.3 встроен в сам протокол QUIC на уровне рукопожатия, что позволяет объединить сетевое и криптографическое согласование в меньшее число обменов пакетами по сравнению с классической связкой TCP плюс отдельное TLS-рукопожатие. На практике это означает, что первый байт полезных данных долетает до браузера быстрее, особенно заметно на соединениях с высокой задержкой, например при подключении к серверу из другого региона мира.

Включение HTTP/3 в Nginx

Поддержка HTTP/3 требует сборки Nginx с модулем ngx_http_v3_module — начиная с версии 1.25.0 эта поддержка включена в основную сборку как экспериментальная возможность, а с более поздних версий стабилизирована для production-использования.

server {
    listen 443 ssl;
    listen 443 quic reuseport;
    http2 on;
    http3 on;
    add_header Alt-Svc 'h3=":443"; ma=86400';
    server_name example.ru;
    ssl_certificate /etc/letsencrypt/live/example.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.ru/privkey.pem;
}

Заголовок Alt-Svc обязателен для HTTP/3 — именно через него сервер сообщает браузеру, что по этому же домену доступен HTTP/3 через QUIC на UDP-порту 443, и браузер может попробовать использовать его при следующем обращении к сайту, не дожидаясь специальной настройки на стороне клиента.

Директива reuseport в listen 443 quic позволяет нескольким рабочим процессам Nginx эффективно принимать UDP-пакеты на один и тот же порт без конкуренции за единственный сокет — это важно для правильной балансировки нагрузки между рабочими процессами при высокой посещаемости сайта в часы пик.

Firewall и HTTP/3: не забыть про UDP

HTTP/3 работает поверх UDP, а не TCP — если firewall на сервере настроен по классической схеме «открыть TCP 443 для веб-сервера», UDP-трафик на этом же порту останется заблокированным, и HTTP/3 не будет доступен клиентам, даже если веб-сервер настроен правильно.

ufw allow 443/tcp
ufw allow 443/udp

Эта деталь — частая причина, почему HTTP/3 «не работает» сразу после, казалось бы, корректной настройки Nginx: конфигурация веб-сервера правильная, но firewall до сих пор пропускает только TCP-трафик на 443 порту, полностью блокируя UDP. Подробнее о настройке firewall — в статье «Firewall на Linux: ufw и iptables простыми словами».

0-RTT и повторные соединения: ещё немного скорости

И HTTP/2 через TLS 1.3, и особенно HTTP/3 через QUIC поддерживают механизм 0-RTT (zero round-trip time) — если клиент уже подключался к серверу ранее и сохранил параметры предыдущей сессии, он может отправить данные (например, сам HTTP-запрос) уже в первом пакете нового соединения, не дожидаясь полного цикла рукопожатия.

Это особенно заметно для посетителей, которые возвращаются на сайт повторно в течение относительно короткого времени, — соединение устанавливается быстрее, и первый байт полезных данных доходит до сервера раньше. Оговорка: 0-RTT данные теоретически уязвимы для атак повторного воспроизведения (replay attacks), поэтому такой режим обычно используют только для безопасных с точки зрения повторного выполнения запросов, таких как GET, а не для запросов, изменяющих данные.

Настройка 0-RTT в Nginx требует отдельного включения и должна применяться с пониманием этого компромисса — для большинства обычных сайтов прирост скорости от базового HTTP/2 или HTTP/3 без 0-RTT уже достаточно заметен, и включать 0-RTT стоит осознанно, а не автоматически ради галочки в списке возможностей.

Как проверить, что протокол реально используется

Самый быстрый способ проверки — вкладка Network в инструментах разработчика браузера, где столбец Protocol показывает, какой именно протокол использовался для каждого запроса (h2 для HTTP/2, h3 для HTTP/3). Альтернатива — явная проверка через curl с указанием желаемой версии протокола.

curl -I --http2 https://example.ru
curl -I --http3 https://example.ru

Стоит иметь в виду, что для проверки HTTP/3 через curl нужна версия curl, собранная с поддержкой HTTP/3 (не все системные сборки включают эту поддержку по умолчанию) — если команда возвращает ошибку о неподдерживаемом протоколе, это может означать проблему именно с локальной версией curl на компьютере администратора, а не с самим сервером.

Внешние онлайн-инструменты проверки протокола (по запросу «HTTP/3 test» в поисковике) — более простой способ для быстрой проверки без необходимости разбираться с локальными версиями инструментов командной строки, особенно удобный при диагностике с чужого компьютера, где нет привычного набора утилит администратора.

Влияние на реальную производительность и Core Web Vitals

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

HTTP/3 особенно выигрывает на нестабильных сетях с потерей пакетов — мобильный интернет в движении, забитый Wi-Fi — где классический TCP из-за блокировки одним потерянным пакетом деградирует заметнее, чем независимые потоки QUIC. Это напрямую влияет на метрику LCP (Largest Contentful Paint) из набора Core Web Vitals, разобранного в отдельной статье базы знаний, за счёт более быстрой и стабильной загрузки основного контента страницы.

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

Важная оговорка: сами по себе HTTP/2 и HTTP/3 не заменяют базовую оптимизацию — сжатие изображений, минификацию CSS и JS, эффективное кэширование. Эти протоколы устраняют накладные расходы транспортного уровня, но не могут компенсировать тяжёлую неоптимизированную страницу с мегабайтами неоптимизированных изображений и избыточным количеством стороннего JavaScript-кода.

Приоритизация и вес потоков в HTTP/2

Помимо мультиплексирования, HTTP/2 вводит понятие приоритизации потоков — браузер может сообщить серверу, какие ресурсы важнее получить в первую очередь (например, CSS для отрисовки страницы важнее второстепенного изображения ниже видимой области экрана), чтобы сервер распределял пропускную способность соединения соответствующим образом.

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

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

Совместимость с CDN и облачными сервисами

Многие CDN и сервисы защиты от DDoS (например, Cloudflare) включают поддержку HTTP/2 и HTTP/3 на своей стороне независимо от того, что настроено на исходном сервере — трафик от браузера до CDN может идти по HTTP/3, а от CDN до происхождения сайта (origin) — по более простому протоколу, и конечный пользователь всё равно получает преимущества более нового протокола на самом важном для задержки последнем участке пути.

Эта архитектура делает переход на HTTP/3 особенно простым для сайтов, уже использующих популярные CDN — часто достаточно включить соответствующую опцию в панели управления CDN, без необходимости обновлять или переконфигурировать сам исходный сервер целиком. Стоит только убедиться, что настройки CDN не заставляют его обращаться к origin-серверу способом, требующим специфичной дополнительной конфигурации на его собственной стороне.

Если сайт работает напрямую без CDN, вся ответственность за корректную настройку HTTP/2 и HTTP/3 лежит на конфигурации собственного сервера — именно этот сценарий подробно разбирается в этой статье применительно к Nginx и Apache.

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

Типичные ошибки при переходе на новые протоколы

Включение http3 on в конфигурации Nginx без соответствующего открытия UDP-порта 443 в firewall — сервер формально поддерживает протокол, но клиенты не могут установить QUIC-соединение из-за блокировки на уровне сети.

Забытый заголовок Alt-Svc при включении HTTP/3 — без него браузеры не узнают о доступности HTTP/3 на сайте и продолжат использовать HTTP/2, даже если сервер технически готов к более новому протоколу.

Использование устаревшей версии Nginx без поддержки HTTP/3, установленной из стандартных репозиториев дистрибутива вместо актуальной сборки — для HTTP/3 обычно нужна более свежая версия, чем предустановлена по умолчанию в LTS-релизах некоторых дистрибутивов.

Ожидание принципиального изменения в результатах Google PageSpeed Insights или аналогичных инструментов сразу после включения HTTP/2 или HTTP/3 без другой оптимизации — протоколы улучшают транспортный уровень, но не заменяют работу над самим содержимым и структурой страницы.

Чек-лист внедрения HTTP/2 и HTTP/3

Шаг 1. Убедитесь, что сайт работает по HTTPS с действующим сертификатом — оба протокола требуют TLS в подавляющем большинстве практических конфигураций.

Шаг 2. Проверьте версию веб-сервера и при необходимости обновите до версии с нужной поддержкой (Nginx 1.25.1+ для современного синтаксиса HTTP/2, более новые версии для HTTP/3).

Шаг 3. Включите HTTP/2 в конфигурации server-блока или VirtualHost, проверьте синтаксис командой nginx -t или apachectl configtest перед применением.

Шаг 4. Для HTTP/3 добавьте директиву listen с параметром quic, включите http3 on и обязательно добавьте заголовок Alt-Svc.

Шаг 5. Откройте и TCP, и UDP на порту 443 в firewall — без UDP HTTP/3 не заработает, даже если конфигурация веб-сервера верна.

Шаг 6. Проверьте результат через вкладку Network в инструментах разработчика браузера или командой curl с явным указанием протокола.

Итог: два протокола, решающие проблему с разных сторон

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

Оба протокола включаются на уровне конфигурации сервера без изменений в коде самого сайта, и современные CMS и хостинг-платформы всё чаще предоставляют эту возможность из коробки. Если не уверены, поддерживает ли ваш текущий сервер HTTP/2 или HTTP/3, или нужна помощь с настройкой — оставьте заявку внизу страницы, поможем настроить актуальные протоколы под конкретный стек вашего проекта.

По мере роста поддержки HTTP/3 браузерами и провайдерами CDN разумно ожидать, что этот протокол постепенно станет таким же стандартом по умолчанию, каким сегодня является HTTP/2, — включение обоих протоколов заранее избавляет от необходимости срочно нагонять упущенное, когда конкуренты и стандарты индустрии уйдут вперёд.