gRPC 2025: Nginx vs Envoy vs HAProxy — практическое сравнение

gRPC зрел, и в 2025-м мы уже не спорим, «нужно ли http2», а обсуждаем, как аккуратно проложить его через proxy, сохранить стриминг, согласовать ALPN и включить наблюдаемость. В обзоре сравню три самых частых варианта на периметре и внутри кластера — Nginx, Envoy и HAProxy — через призму реальных задач: маршрутизация, таймауты, ретраи, health-checks, http3, gRPC-Web и телеметрия.

Коротко: что важно для gRPC-прокси в 2025

• Протоколы и ALPN: клиенту нужен http2 (или h2c), всё это съезжается на TLS/ALPN. http3 (QUIC) добавляет нюансов.
• Полноценный стриминг: bidi, server-streaming без буферизации и вмешательства в трейлеры.
• Header hygiene: TE: trailers, сохранение метаданных, корректная передача трейлеров и статусов grpc-status.
• Ретраи с пониманием кодов gRPC: не превращать любые ошибки в повтор, отличать UNAVAILABLE от бизнес-ошибок.
• Health-checks: активные проверки gRPC-сервисов, а не поверхностные TCP/HTTP.
• Наблюдаемость: метрики по http2-стримам, p50/p95/p99, ошибки по grpc-status, трассировка.
• http3 готовность: где уже можно включать, а где пока лучше завершать на h2.

Главная особенность gRPC — это не «RPC поверх HTTP», а строгая зависимость от http2-семантики и трейлеров. Любая «магия» прокси, ломающая трейлеры, будет болезненной.

Nginx: минимализм, предсказуемость, зрелый http2

Nginx остаётся хорошим базовым вариантом для gRPC: стабильная реализация http2, простая конфигурация, умеренная память и CPU. Основной сценарий — TLS-терминация и проксирование gRPC на upstream по h2 или h2c. С http3 в роли фронта для gRPC нужно осторожно: классический модуль grpc рассчитан на http2, а поддержка gRPC поверх http3 в экосистеме клиентов и прокси ещё выравнивается. Практически чаще всего делают h3 на фронте для обычного HTTP, а gRPC оставляют на h2. На периметре используйте валидный сертификат; при необходимости оформите SSL-сертификаты.

Плюсы Nginx для gRPC:

• Простая конфигурация и управляемые таймауты (grpc_read_timeout, grpc_send_timeout).
• Предсказуемость стриминга и низкая накладная.
• Гибкая маршрутизация по путям методов (например, /package.Service/Method).

Ограничения:

• Активные gRPC health-checks в OSS-версии отсутствуют; как правило, полагаются на пассивное обнаружение сбоев и сторонние пробы.
• gRPC‑aware ретраи из коробки не делаются — только общие по таймаутам/ошибкам соединения.
• http3 для gRPC-клиентов пока не основная рекомендация.

Базовая конфигурация Nginx для gRPC

events {}
http {
    log_format grpc '$remote_addr - $request_time - $status/$grpc_status "$request"';
    access_log /var/log/nginx/grpc.log grpc;

    upstream grpc_backend {
        keepalive 32;
        server 127.0.0.1:50051;
    }

    server {
        listen 443 ssl http2;
        server_name example.org;

        ssl_certificate /etc/ssl/certs/fullchain.pem;
        ssl_certificate_key /etc/ssl/private/privkey.pem;
        ssl_protocols TLSv1.2 TLSv1.3;
        ssl_prefer_server_ciphers on;
        ssl_ciphers HIGH:!aNULL:!MD5;

        location /package.Service/ {
            grpc_set_header TE trailers;
            grpc_pass grpc://grpc_backend;
            grpc_read_timeout 3600s;
            grpc_send_timeout 3600s;
        }
    }
}

Важные нюансы:

• ALPN: у слушателя должен быть http2, иначе gRPC-клиент упадёт на TLS-рукопожатии.
• TE: trailers гарантирует корректный трейлерный обмен для gRPC.
• Логи: $grpc_status позволяет разносить сетевые ошибки и бизнес-коды.
• Для h2c к upstream используйте grpc_pass grpc:// (без TLS) и держите keepalive.

Envoy: gRPC‑native, динамика и http3

Envoy исторически «глубоко понимает» gRPC: активные gRPC health-checks, ретраи по gRPC-кодам, встроенная поддержка gRPC‑Web, богатая телеметрия и xDS для динамической конфигурации. Для сценариев с микросервисами, API‑шлюзом, zero‑trust, canary и traffic‑shaping — это почти «дефолт» в 2025-м.

Плюсы Envoy для gRPC:

• Полноценные gRPC health-checks на базе стандартного сервиса grpc.health.v1.Health.
• Ретраи с матрицей по grpc-status, включая бюджет повторов и джиттер.
• Поддержка gRPC‑Web без дополнительных прослоек.
• Готовность к http3/QUIC на фронте и, при необходимости, на апстриме.
• Широкие метрики и логирование; интеграция с трассировкой.

Цена вопроса — ресурсы и сложность конфигураций. На кластере, где нужна динамика и политика, эта сложность оправдана.

Минимальный Envoy под gRPC

static_resources:
  listeners:
  - name: grpc_listener
    address:
      socket_address: { address: 0.0.0.0, port_value: 443 }
    filter_chains:
    - transport_socket:
        name: envoy.transport_sockets.tls
        typed_config:
          '@type': type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.DownstreamTlsContext
          common_tls_context:
            alpn_protocols: ["h2", "http/1.1"]
            tls_certificates:
            - certificate_chain: { filename: "/etc/ssl/certs/fullchain.pem" }
              private_key: { filename: "/etc/ssl/private/privkey.pem" }
      filters:
      - name: envoy.filters.network.http_connection_manager
        typed_config:
          '@type': type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
          codec_type: AUTO
          stat_prefix: ingress_http
          route_config:
            name: local_route
            virtual_hosts:
            - name: grpc
              domains: ["*"]
              routes:
              - match: { prefix: "/" }
                route: { cluster: grpc_svc }
          http_filters:
          - name: envoy.filters.http.router
  clusters:
  - name: grpc_svc
    type: STATIC
    connect_timeout: 1s
    load_assignment:
      cluster_name: grpc_svc
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address: { address: 127.0.0.1, port_value: 50051 }
    http2_protocol_options: {}

При необходимости дополняйте retry policy по кодам gRPC и включайте активные проверки здоровья. Отдельно оцените http3 только после нагрузочных тестов: выигрыш бывает на высоких RTT и потере, но на локальных сетях/ЦОДах у http2 часто ниже накладные.

HAProxy: скорость, гибкость правил и зрелый http2/http3 стек

HAProxy известен «сырым» performance на L4/L7 и тонкой настройкой TLS/ALPN. Сегодня это зрелый вариант для gRPC: поддерживает h2 на фронте и бэкендах, устойчив к стримингу, умеет QUIC/http3, а также предоставляет gRPC‑ориентированные проверки.

Плюсы HAProxy для gRPC:

• Отличная пропускная способность и низкие задержки.
• Тонкая конфигурация TLS и ALPN (например, alpn h2 на bind).
• Поддержка http3 на фронте с пониженной задержкой в сетях с потерями.
• gRPC‑health-checks и гибкие правила маршрутизации по псевдозаголовкам.

Ограничения: нет «родной» поддержки gRPC‑Web; ретраи по кодам gRPC придётся описывать правилами и аккуратно подбирать условия.

Минимальный HAProxy под gRPC

global
    log stdout format raw local0
    tune.h2.max-concurrent-streams 128

defaults
    mode http
    log global
    option httplog
    timeout connect 5s
    timeout client  1h
    timeout server  1h

frontend fe_grpc
    bind :443 ssl crt /etc/ssl/private/example.pem alpn h2,http/1.1
    acl is_grpc path_beg -i /
    use_backend be_grpc if is_grpc

backend be_grpc
    option http-use-htx
    http-reuse safe
    default-server proto h2 check
    # gRPC health-check (метод Health/Check)
    option grpc-check
    grpc-check /grpc.health.v1.Health/Check
    server app1 127.0.0.1:50051

Практика показывает, что большинство gRPC-сервисов отлично ездят через HAProxy при корректном ALPN и proto h2 к апстриму. Проверьте, что ваши клиенты всегда договариваются на h2; отключите «fallback» на http/1.1. Для вариантов с QUIC полезно посмотреть практику терминации HTTP/3 в HAProxy.

http2, http3 и ALPN: краткий ликбез без мифов

• gRPC по TLS использует ALPN для выбора h2. Если сервер не объявляет h2, рукопожатие пройдёт, но вызов упадёт.
• h2c — это cleartext http2. Удобен во внутренних сетях и через прямые TCP-балансы, но на периметре безопаснее TLS.
• http3 (QUIC) снижает задержки и лучше переносит потери, но tooling и драйверы ядра под UDP ещё требуют внимания. Для gRPC http3 логичен в мобильных и высоколатентных сценариях, при этом апстрим можно оставить на h2.

Если у вас нет чёткой причины включать http3 сегодня, начните с h2 «от клиента до прокси» и h2/h2c «от прокси до сервиса». Это предсказуемо и проще.

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

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

Подробнее

gRPC‑Web: где проще всего

gRPC‑Web нужен, когда браузерный клиент говорит с бэкендом. Envoy реализует gRPC‑Web нативно — это главный аргумент в его пользу на периметре с фронтендом. Через Nginx и HAProxy gRPC‑Web обычно закрывают дополнительным прокси/шлюзом или библиотеками в приложении. Если фронтенда много — возьмите Envoy; см. также подробное руководство по gRPC‑Web через Envoy.

Ретраи и идемпотентность

Ретраи в gRPC должны учитывать коды grpc-status и семантику метода. Повторять безопаснее идемпотентные вызовы и только на чёткий набор ошибок транспорта (UNAVAILABLE, DEADLINE_EXCEEDED, иногда RESOURCE_EXHAUSTED). Envoy умеет такую матрицу прямо из коробки; в Nginx и HAProxy ретраи проще делать на клиенте, а в прокси — ограничиваться перераспределением при разрывах соединения.

Health-checks

• Envoy: активные gRPC‑checks к стандартному методу Health/Check плюс outlier detection.
• HAProxy: option grpc-check с указанием пути метода; дополните observe layer7 и мягкими таймаутами.
• Nginx: в OSS — пассивные ошибки и простые проверки TCP на апстрим; активные gRPC‑checks придётся делать извне (k8s liveness/readiness, сторонний агент).

Наблюдаемость и логирование

Для продакшна важны p50/p95/p99, распределение длительных стримов и карта ошибок по grpc-status. Варианты:

• Nginx: настраиваемый формат логов с $grpc_status, метрики через экспортер.
• Envoy: обширные метрики, отчёты по маршрутам, встроенная интеграция с трассировкой.
• HAProxy: богатые счётчики, Prometheus-экспортер, логика на stick-tables для скоростных лимитов и аномалий.

Производительность (performance): ориентиры и практика

Бенчмарки зависят от нагрузки (unary vs streaming), размера сообщений, TLS-настроек и CPU. Общие наблюдения:

• HAProxy показывает лучшие задержки и throughput при большом числе параллельных потоков h2, особенно на коротких unary‑вызовах.
• Nginx стабилен на смешанных профилях, чуть проигрывая на пиковом RPS, но выигрывая простотой и предсказуемостью таймаутов.
• Envoy добавляет накладные за счёт фильтров/телеметрии, но даёт гибкость. На длинных стримах разница с Nginx/HAProxy минимальна, если выключить лишние фильтры.

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

• Увеличить лимит параллельных потоков h2 (в пределах разумного), чтобы не «душить» клиента.
• Включить TCP keepalive и следить за state-таблицами.
• Подобрать record size и шифры TLS для вашей библиотеки gRPC (TLSv1.3 по умолчанию норм).
• При http3 — уделить внимание UDP‑параметрам ядра, очередям и пейсингу.

Рецепты и подводные камни

• Не допускайте «скатывания» в http/1.1: чётко задавайте ALPN. Для HAProxy — alpn h2, для Nginx — http2 на listen, для Envoy — alpn_protocols с h2.
• Сохраняйте трейлеры: не включайте функции, которые транскодируют/буферизуют ответ и теряют grpc-status.
• Правильно задавайте дедлайны на клиенте: заголовок grpc-timeout должен соответствовать реальности. Прокси не обязан его понимать, но не должен мешать.
• Health/Check держите вне горячего тракта. Частые активные проверки на большом парке — это заметная нагрузка.

Кубернетес и ingress

В Kubernetes выбор часто коррелирует с экосистемой:

• Ingress на базе Nginx: зрелая поддержка gRPC по h2, понятные аннотации, простой rollout.
• Envoy Gateway и операторы: динамика, gRPC‑Web, политики, продвинутые ретраи и проверки.
• HAProxy Ingress: фокус на производительности и предсказуемой L7‑логике.

Если вы выносите прокси на отдельные узлы, удобный старт — развернуть их на облачном VDS и держать конфиги как код.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Итого: как выбрать

• Берите Nginx, если нужен простой, понятный и стабильный gRPC‑proxy с фокусом на h2 и минимуме функций.
• Берите Envoy, если требуются gRPC‑Web, динамическая маршрутизация, ретраи по кодам gRPC, богатая телеметрия и политика.
• Берите HAProxy, если ваша цель — максимум производительности и точный контроль над TLS/ALPN и http2/http3, плюс удобные gRPC‑проверки.

И, как всегда, финальное слово — за тестами под вашу нагрузку. Снимите метрики, посмотрите p95/p99 на реальном профиле трафика, сравните стоимость обслуживания. Технологии дозрели: сегодня любой из трёх вариантов можно безопасно вести в продакшен, если знать его сильные стороны и настроить аккуратно.