HTTP/2 и HTTP/3: переход на современные протоколы

Скорость загрузки сайта — это не роскошь, а необходимость. Исследования показывают, что каждая дополнительная секунда загрузки снижает конверсию на 7%, а 53% пользователей уходят, если страница грузится дольше 3 секунд. Google учитывает скорость как фактор ранжирования. И один из самых эффективных способов ускорить сайт — перейти на современные версии протокола HTTP.

В этой статье мы подробно разберём:

Что такое HTTP/1.1, HTTP/2 и HTTP/3, чем они отличаются.
Проблемы HTTP/1.1: head-of-line blocking, ограничение соединений, избыточность заголовков.
HTTP/2: мультиплексирование, сжатие заголовков (HPACK), приоритизация, Server Push.
HTTP/3: QUIC, UDP, 0-RTT, устранение HOL-блокировки на транспортном уровне.
Как включить HTTP/2 в Nginx и Apache.
Как включить HTTP/3 (QUIC) в Nginx.
Проверку поддержки и тестирование.
Оптимизацию под HTTP/2 и HTTP/3.
Частые ошибки и лучшие практики.

1. Эволюция HTTP

1.1 HTTP/0.9 (1991)

Первый протокол. Только GET, только HTML, без заголовков. Ответ — просто поток байтов.

1.2 HTTP/1.0 (1996)

Добавлены заголовки, методы (POST, HEAD), статус-коды, поддержка разных типов контента. Но каждое соединение — один запрос. После ответа соединение закрывается.

1.3 HTTP/1.1 (1997)

Самый распространённый на сегодня. Добавлены:

Keep-Alive — переиспользование соединения.
Chunked transfer encoding — потоковая передача.
Кеширование (Cache-Control, ETag).
Виртуальные хосты (заголовок Host).

Проблемы HTTP/1.1:

Head-of-line blocking (HOL) — запросы в одном соединении обрабатываются последовательно. Медленный запрос блокирует остальные.
Ограничение на количество соединений — браузеры обычно открывают 6–8 соединений на домен. Остальные запросы ждут.
Избыточность заголовков — каждый запрос отправляет полные заголовки (cookie, User-Agent и т.д.), часто одни и те же.
Нет приоритизации — браузер не может сказать серверу, что важнее.

Костыли, которые использовали разработчики:

Domain sharding — раздача статики с нескольких поддоменов, чтобы обойти лимит соединений.
Спрайты — объединение множества изображений в одно.
Конкатенация CSS/JS — объединение множества файлов в один.
Inline-ресурсы — встраивание CSS и JS в HTML.

Все эти хаки — следствие ограничений HTTP/1.1. С HTTP/2 они не нужны (и даже вредны).

2. HTTP/2

HTTP/2 (изначально SPDY, разработан Google) был стандартизирован в 2015 году. Он сохраняет семантику HTTP/1.1 (методы, статус-коды, заголовки), но меняет способ передачи данных.

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

Ключевое отличие. В HTTP/1.1 одно соединение — один запрос за раз. В HTTP/2 в одном TCP-соединении может быть множество параллельных потоков (streams). Каждый поток — это отдельный запрос-ответ.

Что это даёт:

Браузеру не нужно открывать 6–8 соединений — достаточно одного.
Медленный запрос не блокирует остальные (на уровне HTTP).
Отпадает необходимость в domain sharding, спрайтах и конкатенации.

Пример:
На странице 30 картинок, 5 CSS, 5 JS. В HTTP/1.1 браузер откроет 6 соединений и будет загружать файлы порциями. В HTTP/2 — одно соединение, и все 40 запросов идут параллельно.

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

В HTTP/1.1 заголовки повторяются в каждом запросе (cookie, User-Agent, Accept и т.д.). В HTTP/2 используется алгоритм HPACK, который:

Индексирует часто используемые заголовки.
Сжимает их с помощью таблицы Хаффмана.

Что это даёт: экономию трафика до 30–50% на заголовках, что особенно важно для мобильных сетей.

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

Клиент может указать, какие потоки важнее. Например, CSS и HTML — приоритетнее картинок.

Форматы:

Weighted tree (приоритетное дерево) — устарел, плохо поддерживается.
HTTP/2 Priority Hints — новый механизм через заголовок priority.

2.4 Server Push

Сервер может отправить клиенту ресурсы, которые тот ещё не запросил. Например, если клиент запросил index.html, сервер может сразу отправить style.css и script.js.

Проблема: Server Push сложно реализовать эффективно. Часто отправляются ненужные ресурсы, что только замедляет загрузку. Chrome удалил поддержку Server Push в 2022 году.

ВАЖНО! Не используйте Server Push в продакшене: современные браузеры его игнорируют, а сервер может зря тратить трафик

Современная альтернатива: <link rel="preload"> и HTTP 103 Early Hints.

2.5 Бинарный протокол

HTTP/1.1 — текстовый протокол (легко читается человеком, но требует парсинга). HTTP/2 — бинарный (компактнее, быстрее парсится, но нечитаем без специальных инструментов).

2.6 Один TCP-соединение — проблема

HTTP/2 решает HOL-блокировку на уровне HTTP, но остаётся HOL-блокировка на уровне TCP. Если один TCP-пакет потерялся, всё соединение ждёт его переотправки, даже если другие потоки могли бы продолжить.

Пример: у вас одно TCP-соединение, в нём 10 потоков. Пакет одного потока потерялся. Все 10 потоков ждут восстановления пакета. Это называется TCP head-of-line blocking.

Именно эту проблему решает HTTP/3.

3. HTTP/3

HTTP/3 — новый стандарт, опубликованный в 2022 году. Главное отличие — он работает не на TCP, а на QUIC (Quick UDP Internet Connections) — протоколе на основе UDP.

3.1 QUIC

QUIC — это транспортный протокол, разработанный Google и стандартизированный IETF. Он объединяет в себе функции TCP, TLS и частично HTTP/2.

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

Работает поверх UDP (не требует изменений в ядре ОС).
Встроенное шифрование (TLS 1.3).
Устранение HOL-блокировки на транспортном уровне.
Быстрое установление соединения (0-RTT или 1-RTT).
Миграция соединения (при смене сети, например, с Wi-Fi на LTE).

ВАЖНО! 0-RTT ускоряет соединение, но несёт риски: повторная отправка запроса может привести к двойному выполнению. Не используйте 0-RTT для запросов с побочными эффектами (POST, PUT, DELETE)

3.2 Устранение HOL-блокировки

В QUIC каждый поток передаётся независимо. Если один пакет потерялся, ждёт только его поток, а остальные продолжают работу.

Сравнение:

HTTP/1.1: HOL на уровне HTTP + TCP.
HTTP/2: HOL только на уровне TCP.
HTTP/3: нет HOL на уровне HTTP (мультиплексирование) и нет на уровне транспорта (QUIC).

3.3 Быстрое установление соединения

HTTP/2 + TCP + TLS:

TCP handshake: 1 RTT.
TLS handshake: 1–2 RTT.
Итого: 2–3 RTT до первого байта данных.

HTTP/3 + QUIC:

QUIC handshake: 1 RTT (объединяет TCP и TLS).
Повторное подключение: 0 RTT (если клиент уже подключался).
Итого: 1 RTT или 0 RTT.

Что это даёт: на медленных мобильных сетях выигрыш может достигать 1–2 секунд.

3.4 Миграция соединения

Если пользователь переключается с Wi-Fi на LTE, TCP-соединение разрывается и его нужно переустанавливать. QUIC использует Connection ID, а не IP-адрес, поэтому соединение сохраняется.

3.5 Проблемы HTTP/3

UDP может блокироваться некоторыми провайдерами и корпоративными файрволами.
Меньше поддержки в старых браузерах и инструментах.
Более высокая нагрузка на CPU (шифрование и обработка QUIC).
Отладка сложнее — трафик зашифрован, обычные анализаторы не работают.

4. Сравнение протоколов

Характеристика	HTTP/1.1	HTTP/2	HTTP/3
Транспорт	TCP	TCP	QUIC (UDP)
Мультиплексирование	Нет	Да	Да
HOL-блокировка	HTTP + TCP	TCP	Нет
Сжатие заголовков	Нет	HPACK (В HTTP/3 сжатие заголовков реализовано через QPACK — аналог HPACK для QUIC. Он решает проблему блокировки при потере пакетов, которая возникала в HPACK при работе поверх TCP)	QPACK
Шифрование	Опционально (HTTPS)	Обязательно (HTTPS)	Обязательно (TLS 1.3)
Server Push	Нет	Да (устарел)	Да (ограничен)
Установление соединения	1 RTT + TLS	1 RTT + TLS	1 RTT или 0 RTT
Поддержка браузерами	Все	Все современные	Chrome, Firefox, Safari, Edge (2023+)
Поддержка серверами	Все	Nginx, Apache, Caddy	Nginx 1.25+, Caddy, HAProxy

5. Включение HTTP/2

5.1 Nginx

HTTP/2 включается одной директивой в блоке server:

Nginx

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # ... остальные настройки ...
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # ... остальные настройки ...
}

Важно: HTTP/2 в Nginx работает только поверх HTTPS. По HTTP (порт 80) он не поддерживается (кроме h2c, но это редкость).

Bash

nginx -t
sudo systemctl reload nginx

nginx -t
sudo systemctl reload nginx

5.2 Apache

В Apache HTTP/2 включается модулем mod_http2.

Bash

sudo a2enmod http2
sudo systemctl restart apache2

sudo a2enmod http2
sudo systemctl restart apache2

Затем в конфигурации виртуального хоста:

Apache

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

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

5.3 Caddy

Caddy включает HTTP/2 и HTTP/3 автоматически, если настроен HTTPS:

example.com {
    root * /var/www/html
    file_server
}

5.4 Проверка поддержки

Через браузер:

Откройте DevTools → Network.
Посмотрите колонку Protocol (может быть скрыта, включите её).
Должно быть h2 (HTTP/2) или h3 (HTTP/3).

Через curl:

Bash

curl -I --http2 https://example.com

curl -I --http2 https://example.com

Через онлайн-сервисы: есть сервисы, которые показывают, какой протокол используется для сайта.

Быстрый способ без DevTools:

Bash

curl -sI https://example.com | grep -i "protocol"

curl -sI https://example.com | grep -i "protocol"

Или, если curl поддерживает HTTP/2:

Bash

curl --silent --head --http2 https://example.com 2>/dev/null | head -n 1

curl --silent --head --http2 https://example.com 2>/dev/null | head -n 1

6. Включение HTTP/3 (QUIC)

6.1 Nginx

HTTP/3 поддерживается в Nginx 1.25+ (собран с модулем ngx_http_v3_module).

Nginx

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    
    # HTTP/3 на UDP
    listen 443 quic reuseport;
    listen [::]:443 quic reuseport;
    
    server_name example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # HTTP/2
    http2 on;

    # Сообщаем браузеру, что доступен HTTP/3
    add_header Alt-Svc 'h3=":443"; ma=86400';

    # ... остальные настройки ...
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    
    # HTTP/3 на UDP
    listen 443 quic reuseport;
    listen [::]:443 quic reuseport;
    
    server_name example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # HTTP/2
    http2 on;

    # Сообщаем браузеру, что доступен HTTP/3
    add_header Alt-Svc 'h3=":443"; ma=86400';

    # ... остальные настройки ...
}

Что здесь важно:

listen 443 quic — включает HTTP/3 на UDP-порту 443.
reuseport — оптимизация для многопроцессорных систем.
Alt-Svc — заголовок, сообщающий браузеру о доступности HTTP/3 на том же порту. Браузер при следующем запросе попробует HTTP/3.
http2 on — включает HTTP/2 как fallback.

Важно: HTTP/3 требует, чтобы UDP-порт 443 был открыт в фаерволе.

Bash

sudo ufw allow 443/udp

sudo ufw allow 443/udp

6.2 Caddy

Caddy включает HTTP/3 автоматически.

6.3 HAProxy

HAProxy поддерживает HTTP/3 начиная с версии 2.6.

6.4 Проверка

Через браузер:

Chrome: chrome://flags → включить Experimental QUIC protocol (обычно включён).
DevTools → Network → Protocol → h3.

Через curl (требует поддержки HTTP/3):

Bash

curl --http3 -I https://example.com

curl --http3 -I https://example.com

ВАЖНО! curl должен быть собран с поддержкой HTTP/3. Если команда выдаёт ошибку — скорее всего, ваш curl не умеет работать с QUIC

Онлайн-сервисы: есть сервисы, которые проверяют поддержку HTTP/3.

6.5 Если HTTP/3 не работает

Проверьте, что UDP-порт 443 открыт.
Проверьте, что Nginx собран с поддержкой HTTP/3 (nginx -V | grep http_v3).
Проверьте, что провайдер не блокирует UDP.
Убедитесь, что Alt-Svc заголовок отдаётся.

7. Оптимизация под HTTP/2 и HTTP/3

С переходом на HTTP/2 и HTTP/3 многие старые оптимизации становятся вредными:

Старая оптимизация	Почему вредна сейчас	Что делать
Domain sharding	Мультиплексирование делает его ненужным и вредным (больше соединений — больше overhead)	Использовать один домен
Спрайты	Мультиплексирование загружает картинки параллельно	Отдавать отдельные файлы (проще кешировать)
Конкатенация CSS/JS	Мультиплексирование загружает файлы параллельно; большой файл блокирует рендеринг	Разбивать на модули
Inline CSS/JS	Нарушает кеширование	Отдавать отдельными файлами
Отложенная загрузка (lazy loading)	Всё ещё актуальна для больших изображений и видео	Использовать `loading="lazy"` для изображений

Что становится важным:

Приоритизация ресурсов. Критический CSS — первым, остальное — потом.
Preload и prefetch. <link rel="preload" href="style.css" as="style">.
Early Hints (HTTP 103). Сервер отправляет заголовки заранее, пока готовит тело ответа.
Оптимизация изображений. WebP, AVIF, адаптивные размеры (srcset).
Минификация. Всё ещё полезна (меньше байтов).
Кеширование. Cache-Control, ETag.
CDN. Ускоряет доставку статики.

8. Практические примеры

8.1 Полная конфигурация Nginx с HTTP/2 и HTTP/3

Nginx

server {
    listen 80;
    listen [::]:80;
    server_name example.com;
    return 301 https://$server_name$request_uri;
}

server {
    # HTTP/2 over TCP
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    # HTTP/3 over UDP
    listen 443 quic reuseport;
    listen [::]:443 quic reuseport;

    server_name example.com;

    root /var/www/html;
    index index.html index.php;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers off;

    add_header Alt-Svc 'h3=":443"; ma=86400' always;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Content-Type-Options "nosniff" always;

    location ~* \.(jpg|jpeg|png|gif|ico|css|js|svg|woff2)$ {
        expires 30d;
        add_header Cache-Control "public, immutable";
        access_log off;
    }

    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }

    location / {
        try_files $uri $uri/ /index.php?$args;
    }
}

server {
    listen 80;
    listen [::]:80;
    server_name example.com;
    return 301 https://$server_name$request_uri;
}

server {
    # HTTP/2 over TCP
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    # HTTP/3 over UDP
    listen 443 quic reuseport;
    listen [::]:443 quic reuseport;

    server_name example.com;

    root /var/www/html;
    index index.html index.php;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers off;

    add_header Alt-Svc 'h3=":443"; ma=86400' always;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Content-Type-Options "nosniff" always;

    location ~* \.(jpg|jpeg|png|gif|ico|css|js|svg|woff2)$ {
        expires 30d;
        add_header Cache-Control "public, immutable";
        access_log off;
    }

    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }

    location / {
        try_files $uri $uri/ /index.php?$args;
    }
}

8.2 Настройка фаервола

Bash

# HTTP/2 работает по TCP
sudo ufw allow 443/tcp

# HTTP/3 работает по UDP
sudo ufw allow 443/udp

# HTTP/2 работает по TCP
sudo ufw allow 443/tcp

# HTTP/3 работает по UDP
sudo ufw allow 443/udp

8.3 Проверка через curl

Bash

# HTTP/2
curl -I --http2 https://example.com

# HTTP/3 (если curl собран с поддержкой)
curl --http3 -I https://example.com

# HTTP/2
curl -I --http2 https://example.com

# HTTP/3 (если curl собран с поддержкой)
curl --http3 -I https://example.com

8.4 Проверка через Chrome DevTools

Откройте DevTools (F12).
Перейдите в Network.
Включите колонку Protocol (правый клик на заголовках таблицы).
Обновите страницу.
Смотрите значения: h2 (HTTP/2), h3 (HTTP/3), http/1.1.

9. Частые ошибки и лучшие практики

Ошибка	Последствия	Решение
HTTP/2 включён без HTTPS	Не работает	HTTP/2 требует HTTPS (в браузерах).
UDP-порт 443 закрыт	HTTP/3 не работает	Откройте UDP-порт в фаерволе.
Alt-Svc не отдаётся	Браузер не знает про HTTP/3	Добавьте `add_header Alt-Svc`.
Server Push используется	Может замедлить загрузку	Используйте preload/early hints.
Домен sharding остался	Больше соединений — больше overhead	Откажитесь от sharding.
Спрайты и конкатенация остались	Не используются преимущества HTTP/2	Разбейте на отдельные файлы.
Nginx старый	Нет поддержки HTTP/3	Обновите до 1.25+.
Нет проверки поддержки	Непонятно, работает ли	Проверяйте через DevTools или curl.

Лучшие практики:

Всегда используйте HTTPS — HTTP/2 и HTTP/3 работают только с ним.
Включайте HTTP/2 как основной, HTTP/3 — как дополнительный.
Настраивайте Alt-Svc для HTTP/3.
Откажитесь от старых оптимизаций (спрайты, конкатенация, sharding).
Используйте preload для критических ресурсов.
Оптимизируйте изображения (WebP, AVIF).
Настройте кеширование статики.
Мониторьте производительность (Lighthouse, WebPageTest).

Сценарий проверки после включения HTTP/3:

Проверить, что Nginx собран с поддержкой QUIC: nginx -V | grep http_v3.
Убедиться, что UDP 443 открыт в фаерволе и на стороне хостинга.
Проверить заголовок Alt-Svc в ответе сервера.
Проверить через DevTools или curl, что браузер реально использует h3.
Замерить скорость загрузки в Lighthouse до и после — эффект особенно заметен на мобильных сетях.

HTTP/2 и HTTP/3 — это не просто «модные протоколы», а реальные инструменты ускорения сайта. Мы разобрали:

Эволюцию HTTP: от 0.9 до 3.
Проблемы HTTP/1.1 и как их решает HTTP/2.
Мультиплексирование, HPACK, приоритизацию, Server Push.
HTTP/3 и QUIC: устранение HOL-блокировки, 0-RTT, миграцию соединения.
Включение HTTP/2 и HTTP/3 в Nginx, Apache, Caddy.
Проверку поддержки через DevTools, curl, онлайн-сервисы.
Оптимизацию под новые протоколы: что убрать, что добавить.
Частые ошибки и лучшие практики.

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

HTTP/2 и HTTP/3: переход на современные протоколы

1. Эволюция HTTP

1.1 HTTP/0.9 (1991)

1.2 HTTP/1.0 (1996)

1.3 HTTP/1.1 (1997)

2. HTTP/2

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

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

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

2.4 Server Push

2.5 Бинарный протокол

2.6 Один TCP-соединение — проблема

3. HTTP/3

3.1 QUIC

3.2 Устранение HOL-блокировки

3.3 Быстрое установление соединения

3.4 Миграция соединения

3.5 Проблемы HTTP/3

4. Сравнение протоколов

5. Включение HTTP/2

5.1 Nginx

5.2 Apache

5.3 Caddy

5.4 Проверка поддержки

6. Включение HTTP/3 (QUIC)

6.1 Nginx

6.2 Caddy

6.3 HAProxy

6.4 Проверка

6.5 Если HTTP/3 не работает

7. Оптимизация под HTTP/2 и HTTP/3

8. Практические примеры

8.1 Полная конфигурация Nginx с HTTP/2 и HTTP/3

8.4 Проверка через Chrome DevTools

9. Частые ошибки и лучшие практики

Инструменты