GProxy: HTTP/2 прокси – поддержка нового протокола

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

Что такое HTTP/2 и почему он важен?

HTTP/2, стандартизированный в 2015 году как RFC 7540, является вторым основным пересмотром протокола HTTP. Его разработка была мотивирована необходимостью повышения производительности веб-приложений без изменения базовой семантики HTTP/1.1. Основные улучшения HTTP/2 включают:

Бинарное кадрирование (Binary Framing): Вся коммуникация разбивается на мелкие бинарные кадры, что упрощает парсинг и мультиплексирование.
Мультиплексирование (Multiplexing): Множество запросов и ответов могут передаваться асинхронно по одному TCP-соединению, устраняя проблему "блокировки начала очереди" (Head-of-Line Blocking) HTTP/1.1.
Приоритизация потоков (Stream Prioritization): Клиент может указывать приоритеты для различных потоков, позволяя серверу отправлять более важные ресурсы раньше.
Сжатие заголовков HPACK: Заголовки HTTP сжимаются для уменьшения накладных расходов, особенно для повторяющихся заголовков.
Серверный пуш (Server Push): Сервер может отправлять ресурсы клиенту до того, как клиент явно их запросит, потенциально сокращая время загрузки страницы.

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

Сравнение HTTP/1.1 и HTTP/2

Характеристика	HTTP/1.1	HTTP/2
Формат данных	Текстовый	Бинарный
Соединения	Одно соединение на запрос (или pipelining)	Одно соединение для множества запросов (мультиплексирование)
Параллелизм	Ограничен (Head-of-Line Blocking)	Полный (потоки)
Сжатие заголовков	Отсутствует (только GZIP для тела)	HPACK (сжатие заголовков)
Серверный пуш	Отсутствует	Присутствует
Приоритизация	Отсутствует	Присутствует (потоки)
TLS/SSL	Опционально	Де-факто обязательно (ALPN)

Механизмы HTTP/2, влияющие на прокси

Фундаментальные изменения в HTTP/2 на уровне протокола оказывают прямое влияние на работу прокси-серверов.

Бинарное кадрирование

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

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

Мультиплексирование позволяет множеству HTTP-запросов и ответов (потоков) одновременно использовать одно TCP-соединение. Для прокси это означает:

Идентификация запросов: Логирование, аудит и мониторинг должны быть привязаны к конкретным потокам, а не к TCP-соединениям, как это было в HTTP/1.1.
Балансировка нагрузки: "Липкие" сессии (sticky sessions) должны поддерживаться на уровне потоков или более высокого уровня, а не на уровне соединений, что усложняет распределение трафика.
Управление ресурсами: Прокси должен эффективно управлять ресурсами для каждого потока в рамках одного соединения.

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

HPACK использует статическую и динамическую таблицы для эффективного сжатия заголовков. Прокси, которые модифицируют заголовки (например, добавляют X-Forwarded-For), должны:

Декодировать заголовки HPACK.
Внести изменения.
Заново закодировать заголовки в HPACK, поддерживая состояние динамической таблицы.

Неправильная обработка HPACK может привести к потере эффективности сжатия или ошибкам протокола.

Серверный пуш

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

Типы прокси и поддержка HTTP/2

Поддержка HTTP/2 прокси-серверами зависит от их типа и роли в сетевой архитектуре.

Прямые прокси (Forward Proxies)

Прямые прокси выступают посредниками между клиентом и внешними ресурсами.

HTTP/2 over TLS (h2): Большинство HTTP/2 трафика передается поверх TLS (шифрованное соединение). В этом сценарии прямой прокси обычно использует метод CONNECT для установления TCP-туннеля до целевого сервера. Прокси в данном случае не видит содержимое HTTP/2 кадров, а лишь передает зашифрованный трафик. Это обеспечивает конфиденциальность, но ограничивает возможности прокси по инспекции или модификации трафика.
HTTP/2 без TLS (h2c): HTTP/2 может работать и по незашифрованному TCP-соединению, используя механизм Upgrade из HTTP/1.1. В этом случае прямой прокси может действовать как полноценный HTTP/2 прокси, инспектируя и модифицируя трафик. Однако h2c используется редко и не рекомендован для публичного интернета.

Пример CONNECT запроса:

CONNECT example.com:443 HTTP/1.1
Host: example.com:443
Proxy-Connection: keep-alive

После успешного 200 Connection established прокси начинает просто туннелировать TCP-трафик между клиентом и example.com:443.

Обратные прокси (Reverse Proxies)

Обратные прокси размещаются перед веб-серверами и маршрутизируют запросы от клиентов к ним. Это наиболее распространенный сценарий для поддержки HTTP/2.

Клиент H2 – Прокси H2 – Сервер H1: Это наиболее распространенная конфигурация. Обратный прокси принимает HTTP/2 запросы от клиентов, демультиплексирует их, транслирует в HTTP/1.1 запросы и отправляет на бэкенд-серверы. Ответы от бэкендов в HTTP/1.1 затем транслируются обратно в HTTP/2 и отправляются клиенту. Прокси здесь выступает в роли "шлюза" (gateway), преобразуя протоколы. Это позволяет использовать преимущества HTTP/2 на клиентской стороне, не требуя немедленного обновления всех бэкенд-серверов.
Клиент H2 – Прокси H2 – Сервер H2: В этом сценарии прокси принимает HTTP/2 запросы и передает их на бэкенд-серверы, которые также поддерживают HTTP/2. Прокси может пересылать потоки или управлять ими, но протокол остается HTTP/2 на всем пути. Это обеспечивает максимальную производительность, но требует полной поддержки HTTP/2 на всех компонентах.

Вызовы и особенности реализации HTTP/2 в прокси

Трансляция протоколов

При работе в режиме H2-H1 прокси должен выполнять полную трансляцию:

Парсинг бинарных HTTP/2 кадров.
Декодирование заголовков HPACK.
Сборку HTTP/1.1 запроса.
Отправку на бэкенд.
Получение HTTP/1.1 ответа.
Сборку HTTP/2 ответа, кодирование заголовков HPACK.
Мультиплексирование в исходящее HTTP/2 соединение.

Этот процесс требует значительных вычислительных ресурсов.

Манипуляция заголовками

Прокси часто изменяют заголовки HTTP (например, X-Forwarded-For, Via, User-Agent). С HPACK это усложняется: прокси должен поддерживать собственную таблицу состояний HPACK для каждого соединения или потока, чтобы эффективно сжимать и распаковывать заголовки, не нарушая целостности.

Балансировка нагрузки

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

Распределять новые TCP-соединения равномерно.
Использовать более сложные алгоритмы, учитывающие количество активных HTTP/2 потоков или запросов на соединение.
Поддерживать "липкость" (stickiness) на основе HTTP-заголовков (например, куки) или IP-адреса, чтобы обеспечить корректную работу сессий, которые могут быть разбросаны по разным потокам.

Мониторинг и логирование

Мультиплексирование затрудняет традиционный мониторинг. Логи прокси должны явно указывать идентификаторы потоков, чтобы можно было отслеживать полный жизненный цикл запроса/ответа. Инструменты мониторинга должны быть адаптированы для работы с потоками, а не только с соединениями.

Безопасность (TLS и ALPN)

HTTP/2 почти всегда используется с TLS. Протокол Application-Layer Protocol Negotiation (ALPN) является обязательным для согласования HTTP/2 между клиентом и сервером (или прокси) во время рукопожатия TLS. Прокси должен поддерживать ALPN для успешной установки HTTP/2 соединений.

Примеры конфигурации прокси-серверов

Рассмотрим примеры настройки популярных прокси-серверов для поддержки HTTP/2.

Nginx

Nginx широко используется как обратный прокси и отлично поддерживает HTTP/2.

# В секции http или server
server {
    listen 443 ssl http2; # Включаем HTTP/2 для порта 443 с SSL
    listen [::]:443 ssl http2;

    server_name your_domain.com;

    ssl_certificate /etc/nginx/ssl/your_domain.crt;
    ssl_certificate_key /etc/nginx/ssl/your_domain.key;
    ssl_protocols TLSv1.2 TLSv1.3; # Рекомендуется использовать современные протоколы TLS
    ssl_ciphers "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384";
    ssl_prefer_server_ciphers on;

    # Конфигурация для бэкенда (H1)
    location / {
        proxy_pass http://backend_servers; # Проксирование на группу бэкендов по HTTP/1.1
        proxy_http_version 1.1; # Указываем HTTP/1.1 для соединения с бэкендом
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade"; # Важно для сохранения соединения keep-alive
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    # Конфигурация для бэкенда (H2)
    # Если бэкенд также поддерживает HTTP/2, можно использовать:
    # location / {
    #     proxy_pass https://backend_h2_servers; # Проксирование на группу бэкендов по HTTPS/2
    #     proxy_http_version 2.0; # Указываем HTTP/2 для соединения с бэкендом
    #     proxy_ssl_server_name on; # Для SNI
    #     proxy_set_header Host $host;
    #     # ... другие заголовки
    # }
}

# Пример группы бэкендов
upstream backend_servers {
    server 192.168.1.10:80;
    server 192.168.1.11:80;
}
# upstream backend_h2_servers {
#     server 192.168.1.12:443;
#     server 192.168.1.13:443;
# }

HAProxy

HAProxy также предлагает мощную поддержку HTTP/2.

global
    log /dev/log    daemon
    maxconn 25000
    chroot /var/lib/haproxy
    stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners
    stats timeout 30s
    user haproxy
    group haproxy
    daemon
    # Default SSL material locations
    ca-base /etc/ssl/certs
    crt-base /etc/ssl/private

defaults
    mode http
    log global
    option httplog
    option dontlognull
    timeout connect 5000
    timeout client  50000
    timeout server  50000
    errorfile 400 /etc/haproxy/errors/400.http
    errorfile 403 /etc/haproxy/errors/403.http
    errorfile 408 /etc/haproxy/errors/408.http
    errorfile 500 /etc/haproxy/errors/500.http
    errorfile 502 /etc/haproxy/errors/502.http
    errorfile 503 /etc/haproxy/errors/503.http
    errorfile 504 /etc/haproxy/errors/504.http

frontend http_front
    bind *:80
    redirect scheme https code 301 if !{ ssl_fc }

frontend https_front
    # Включаем ALPN для согласования h2 и http/1.1
    # crt /etc/haproxy/certs/your_domain.pem - это объединенный файл сертификата и ключа
    bind *:443 ssl crt /etc/haproxy/certs/your_domain.pem alpn h2,http/1.1

    # Если бэкенды ожидают HTTP/1.1
    default_backend backend_http1

    # Если бэкенды ожидают HTTP/2
    # use_backend backend_http2 if { ssl_c_alpn -i h2 } # Пример маршрутизации на H2 бэкенд

backend backend_http1
    # Опции для работы с HTTP/1.1 бэкендами
    option http-server-close # Закрывать соединение с бэкендом после каждого запроса (или keep-alive)
    # option http-keep-alive # Поддерживать keep-alive с бэкендом
    # option forwardfor # Добавлять X-Forwarded-For
    server s1 192.168.1.10:80 check
    server s2 192.168.1.11:80 check

backend backend_http2
    # Конфигурация для бэкендов, поддерживающих HTTP/2
    # proto h2 указывает HAProxy использовать HTTP/2 для соединения с бэкендом
    server s3 192.168.1.12:443 proto h2 check ssl verify none # verify none для тестовых сред
    server s4 192.168.1.13:443 proto h2 check ssl verify none

Анализ и проверка

Безопасность и сеть

Генераторы

9 инструментов

HTTP/2 и прокси