HAProxy с HTTP/3/QUIC: TLS‑терминация и проксирование к HTTP/1.1/2 бэкендам

Инструкции
30 окт, 2025
Время на чтение: ~12 мин
Автор: AI (GPT 5)

Искусственный интеллект Fastfox

Данная статья была создана с использованием искусственного интеллекта (GTP-5). Пожалуйста, имейте в виду, что текст может содержать неточности или ошибки.

HTTP/3 на базе QUIC давно перестал быть экспериментом и уже заметно ускоряет доставки для мобильных и географически распределённых пользователей: меньше задержек за счёт отказа от head-of-line blocking уровня TCP, быстрая установка соединения и более устойчивое поведение к потере пакетов. Практичный паттерн для продакшена — терминировать TLS и HTTP/3 на фронтовом HAProxy и проксировать запросы на бэкенды по HTTP/1.1 или HTTP/2. В результате мы получаем совместимость со старыми клиентами и выгоду от HTTP/3 для новых, сохраняя лаконичную конфигурацию и единый порт 443 с ALPN.

Что даёт связка HAProxy + HTTP/3/QUIC

Ключевые преимущества для фронтенда:

Сокращение латентности на старте за счёт QUIC и TLS 1.3.
Отсутствие head-of-line blocking: потеря одного пакета не блокирует весь поток запросов.
Единый порт 443 с ALPN: клиенты автоматически выбирают лучший доступный протокол — h3, h2 или http/1.1.
Прозрачная работа с привычными бэкендами: можно оставить HTTP/1.1 либо перейти на HTTP/2 там, где это приносит пользу.

Важно: HTTP/3 в HAProxy доступен в актуальных стабильных ветках (2.9/3.0+). Убедитесь, что бинарь собран с поддержкой QUIC и подходящей TLS-библиотеки.

Требования и проверка сборки

Перед настройкой проверьте окружение:

Версия HAProxy 2.9 или новее (желательно текущий LTS/Stable).
Сборка с поддержкой QUIC. Проверяем:

haproxy -vv | grep -i quic

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

Откройте в файрволе 443/TCP и 443/UDP (QUIC — это UDP).
Сертификаты TLS (желательно комплект ECDSA+RSA для лучшей совместимости) и промежуточные цепочки корректно объединены в файлы сертификатов HAProxy. При отсутствии валидного сертификата оформите SSL-сертификаты.

Для безопасного пилота и нагрузочного теста удобно развернуть стенд на отдельном сервере — например, на VDS, чтобы не трогать боевые инстансы.

Фрагмент конфигурации HAProxy с ALPN h3,h2,http/1.1 и параметром quic на 443

Базовая схема и порты

Мы слушаем порт 80 для редиректа на HTTPS и порт 443 для TLS‑терминации. На 443 включаем alpn с приоритетом h3, далее h2, затем http/1.1. Один bind на 443 обслуживает и TCP, и UDP сокеты, так что клиенты сами договорятся о протоколе через ALPN.

Базовая конфигурация HAProxy (HTTP/3 фронт, HTTP/1.1 бэкенд)

Стартовая конфигурация, с которой удобно начать. Она включает логирование, безопасные таймауты, редирект с 80 на HTTPS, ALPN и заголовок Alt-Svc для рекламы HTTP/3.

global
  log stdout format raw daemon
  master-worker
  nbthread 2
  maxconn 10000
  tune.ssl.default-dh-param 2048
  ssl-default-bind-options prefer-client-ciphers no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets
  ssl-default-bind-ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256
  stats socket /run/haproxy/admin.sock mode 660 level admin
  # Лёгкий тюнинг QUIC: экономичные, но практичные значения
  tune.quic.max-idle-time 5s

defaults
  mode http
  log global
  option httplog
  option dontlognull
  timeout connect 5s
  timeout client 30s
  timeout server 30s
  option http-keep-alive
  http-reuse safe
  option forwardfor

frontend fe_http
  bind :80
  http-request redirect scheme https code 301 unless { ssl_fc }

frontend fe_https
  bind :443 ssl crt /etc/haproxy/certs/ alpn h3,h2,http/1.1 quic
  # Пробрасываем схему, полезно для приложений/логики редиректов
  http-request set-header X-Forwarded-Proto https if { ssl_fc }
  # Рекомендуем клиентам HTTP/3
  http-response set-header alt-svc h3=":443"; ma=86400
  default_backend be_app_h1

backend be_app_h1
  balance roundrobin
  http-reuse safe
  server app1 127.0.0.1:8080 check
  # Добавляйте узлы по мере необходимости

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

Вариант B: проксирование к HTTP/2 бэкенду

Если ваш бэкенд-стек хорошо масштабируется со множеством параллельных потоков (например, gRPC или активная загрузка ассетов), можно включить HTTP/2 «за» HAProxy. Есть два режима: h2c (чистый HTTP/2 без TLS) и HTTP/2 поверх TLS. Первый быстрее и проще внутри доверенной сети, второй уместен, если требуется шифрование и проверка сертификатов до точки назначения.

HTTP/2 без TLS (h2c) к бэкенду

backend be_app_h2c
  mode http
  balance roundrobin
  # Ваш origin должен уметь cleartext HTTP/2 (h2c)
  server app1 127.0.0.1:8082 proto h2 check
  server app2 127.0.0.1:8083 proto h2 check

Далее в фронтенде можно маршрутизировать часть доменов на h2c‑бэкенд:

frontend fe_https
  bind :443 ssl crt /etc/haproxy/certs/ alpn h3,h2,http/1.1 quic
  acl host_h2c hdr(host) -i h2c.example.test
  use_backend be_app_h2c if host_h2c
  default_backend be_app_h1

HTTP/2 поверх TLS к бэкенду

Когда соединение до бэкенда должно быть шифровано (например, между датацентрами), используйте TLS с ALPN на серверных линиях. Внутренний CA можно указать для проверки, либо временно ослабить проверку на этапе миграции.

backend be_app_h2_tls
  balance roundrobin
  # Если есть корпоративный CA, укажите verify required ca-file /etc/ssl/internal_ca.pem
  server app1 app.internal:8443 ssl verify none alpn h2,http/1.1 check
  server app2 app2.internal:8443 ssl verify none alpn h2,http/1.1 check

При маршрутизации:

frontend fe_https
  bind :443 ssl crt /etc/haproxy/certs/ alpn h3,h2,http/1.1 quic
  acl host_h2tls hdr(host) -i h2tls.example.test
  use_backend be_app_h2_tls if host_h2tls
  default_backend be_app_h1

ALPN: порядок имеет значение

Строка alpn h3,h2,http/1.1 на фронтенде определяет приоритет предложений клиенту. Современные браузеры выберут h3, если поддерживают QUIC и видят UDP‑443. Если UDP закрыт либо клиент старый — произойдёт откат на h2 или http/1.1. На серверных строках ALPN помогает HAProxy выбрать протокол к апстриму: для TLS‑бэкендов явное alpn h2,http/1.1 гарантирует попытку HTTP/2 прежде, чем fallback на HTTP/1.1.

Логи, диагностика и проверка

Проверка с клиента:

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

Проверка UDP‑доступности (с внешнего узла):

nmap -sU -p 443 example.test

Мониторинг QUIC‑сессий через сокет управления:

echo 'show quic' | socat - /run/haproxy/admin.sock

Чтобы видеть выбранный протокол на фронте, добавьте кастомный формат логов, включающий %[ssl_fc_alpn], и анализируйте долю h3/h2/h1 в трафике.

Проверка HTTP/3 и HTTP/2 через curl и мониторинг QUIC-сессий

Тюнинг производительности: практичные пресеты

Оптимальные значения зависят от профиля трафика. Ниже — безопасная отправная точка и пояснения, куда смотреть при росте нагрузки.

Конкурентность: nbthread, привязка к CPU и maxconn под пиковую RPS. Не забываем о лимитах ядра и дескрипторов.
Таймауты: timeout connect 5s, timeout client/server 30s подходят для большинства сайтов; для API с длительными потоками увеличивайте аккуратно.
HTTP‑reuse: http-reuse safe снижает издержки установки соединений к бэкендам, не ломая совместимость.
HTTP/2: при активном использовании настроить лимит потоков и размер окна. Аккуратно повышайте tune.h2.max-concurrent-streams и следите за нагрузкой на приложение.
QUIC: начинайте с консервативного tune.quic.max-idle-time. Если много мобильных клиентов — разумно увеличить до 10–15s, чтобы уменьшить частоту новых рукопожатий.

Не забывайте профилировать не только сам HAProxy, но и апстримы: рост параллелизма HTTP/2 может упереться во внутренние пулы подключений, блокировки, GC и т. п.

Безопасность TLS и совместимость

HTTP/3 обязан использовать TLS 1.3; на фронте логично ограничить набор шифров до современных (см. ssl-default-bind-ciphersuites в примере).
Комплект сертификатов с ECDSA и RSA помогает старым клиентам. Убедитесь, что цепочки оформлены корректно.
Alt-Svc безопасно рекламирует h3, но не навязывает; клиенты сами переключатся при возможности.
Следите за OCSP stapling и сроками действия цепочки, чтобы избежать деградации при возобновлениях рукопожатий.

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Плавная миграция и откат

Стратегия внедрения без сюрпризов выглядит так:

Откройте UDP‑443 на периметре, разверните фронт с ALPN, но сначала оставьте alt-svc только на небольшой доле доменов.
Наблюдайте логи: доля h3, латентность, ошибки, загрузка CPU/сетевого стека.
Увеличивайте процент доменов/трафика, переводимых на HTTP/3.
Для быстрого отката достаточно убрать h3 из alpn на фронтенде и перезагрузить конфигурацию.

Частые ошибки и их признаки

Забыт UDP‑443 в файрволе: HTTP/3 не виден, клиенты всегда откатываются на h2/h1. Проверьте порты и маршрутизацию.
Некорректная цепочка сертификатов: всплеск рукопожатий/ошибок, нестабильные возобновления. Пересоберите файл crt с полной цепочкой.
Не тот порядок ALPN: если http/1.1 стоит раньше h2, некоторые клиенты никогда не выберут HTTP/2. Следите за порядком — h3,h2,http/1.1.
Слишком агрессивные таймауты: на мобильных сетях возможны ложные обрывы. Поднимите tune.quic.max-idle-time и timeout client.
h2c к бэкенду без поддержки: origin не умеет HTTP/2 без TLS, соединения рвутся. Используйте proto h2 только там, где это подтверждено.

Чеклист перед продакшеном

HAProxy 2.9/3.0+ с поддержкой QUIC (haproxy -vv подтверждает).
Открыты 443/TCP и 443/UDP; мониторинг доступности снаружи.
На фронтах: bind :443 ssl crt ... alpn h3,h2,http/1.1 quic, корректный Alt-Svc.
Бэкенды: явный ALPN для TLS‑узлов, proto h2 — только к h2c‑совместимым приложениям.
Логи включают %[ssl_fc_alpn] для разбора распределения по протоколам.
Таймауты и reuse согласованы с профилем трафика, есть headroom по maxconn.
Подготовлен план отката: убрать h3 из ALPN и перезагрузить конфигурацию.

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

Поделиться статьей