HTTP/2 e proxy

Serviços de proxy oferecem suporte a HTTP/2 atuando como intermediários que podem tanto terminar as conexões HTTP/2 e encaminhar as requisições por HTTP/1.1 até os servidores de origem, quanto repassar HTTP/2 de ponta a ponta entre cliente e origem.

O HTTP/2 é uma revisão significativa do protocolo HTTP, projetada para melhorar o desempenho da web ao resolver limitações inerentes ao HTTP/1.1. Entre os principais recursos estão a multiplexação completa de requisições e respostas, a compressão de cabeçalhos via HPACK, o server push e a priorização de requisições. Para um serviço de proxy, gerenciar esses recursos exige considerações arquiteturais específicas, para aproveitar os benefícios do HTTP/2 mantendo compatibilidade e controle.

Fundamentos do protocolo HTTP/2

O HTTP/2 opera sobre uma única conexão TCP, estabelecendo múltiplos streams bidirecionais para troca simultânea de requisições e respostas. Essa multiplexação elimina o head-of-line blocking presente no HTTP/1.1. A compressão de cabeçalhos (HPACK) reduz o overhead ao codificar os cabeçalhos HTTP em um formato binário compacto e manter uma tabela dinâmica compartilhada. O server push permite que o servidor envie proativamente ao cliente recursos que ele antecipa serem necessários, reduzindo a latência.

Esses recursos, embora benéficos, introduzem complexidades para serviços de proxy que tradicionalmente operam em um modelo de requisição-resposta sobre conexões TCP individuais.

Arquiteturas de proxy para HTTP/2

Serviços de proxy normalmente implementam uma de duas arquiteturas principais para suporte a HTTP/2: terminação ou ponta a ponta.

Terminação HTTP/2 (frontend HTTP/2, backend HTTP/1.1)

Nesse modelo, o servidor proxy estabelece uma conexão HTTP/2 com o cliente. Ele termina o protocolo HTTP/2, decodifica as requisições e as encaminha ao servidor de origem usando HTTP/1.1. As respostas do servidor de origem (HTTP/1.1) são então transcodificadas de volta para HTTP/2 e enviadas ao cliente.

Fluxo do processo:

1. O cliente inicia uma conexão HTTP/2 com o proxy (normalmente sobre TLS, com ALPN negociando h2).
2. O proxy recebe os frames HTTP/2 e reconstrói requisições no estilo HTTP/1.1 (incluindo a decodificação dos cabeçalhos HPACK).
3. O proxy encaminha as requisições HTTP/1.1 ao servidor de origem.
4. O servidor de origem responde com HTTP/1.1.
5. O proxy recebe as respostas HTTP/1.1, codifica-as em frames HTTP/2 (incluindo a compressão HPACK) e as envia ao cliente.

Vantagens:

• Compatibilidade com o backend: os servidores de origem não precisam suportar HTTP/2. Isso é útil para sistemas legados ou serviços que ainda não foram atualizados.
• Offloading: o proxy assume o custo computacional da negociação do protocolo HTTP/2, da compressão/descompressão de cabeçalhos e do gerenciamento de streams, reduzindo a carga nos servidores de origem.
• Controle: é mais fácil executar funções tradicionais de proxy, como cache, balanceamento de carga, modificação de requisições e filtragem de segurança, que costumam ser projetadas para a semântica do HTTP/1.1.

Desvantagens:

• Perda de recursos: recursos do HTTP/2, como o server push do servidor de origem, não podem ser repassados diretamente. O proxy precisaria implementar sua própria lógica de server push.
• Overhead de incompatibilidade de protocolo: a transcodificação constante entre HTTP/2 e HTTP/1.1 acrescenta overhead de processamento no proxy.
• Latência maior: essa etapa adicional de processamento pode introduzir uma pequena latência em comparação com uma conexão HTTP/2 direta.

Caso de uso: ideal para cenários em que se deseja os ganhos de desempenho do HTTP/2 no lado do cliente, mas a infraestrutura de backend ainda não está pronta para HTTP/2, ou quando é necessária uma manipulação extensa das requisições do lado do proxy.

HTTP/2 ponta a ponta (proxy completo)

Em uma configuração de proxy HTTP/2 ponta a ponta, o proxy mantém conexões HTTP/2 tanto com o cliente quanto com o servidor de origem. O proxy atua como intermediário transparente, encaminhando frames ou streams HTTP/2 diretamente, sem conversão de protocolo.

Fluxo do processo:

1. O cliente inicia uma conexão HTTP/2 com o proxy.
2. O proxy estabelece uma conexão HTTP/2 com o servidor de origem.
3. O proxy encaminha os frames/streams HTTP/2 entre cliente e origem.
4. O proxy gerencia os IDs de stream e, potencialmente, prioriza os streams.

Vantagens:

• Preservação completa dos recursos: todos os recursos do HTTP/2, incluindo o server push da origem, a priorização de streams e a compressão HPACK, são preservados de ponta a ponta.
• Menor latência: elimina o overhead de transcodificação, o que pode levar a menor latência se o servidor de origem estiver geograficamente próximo ou for altamente otimizado para HTTP/2.
• Menor overhead no proxy: o papel do proxy é principalmente encaminhar frames e gerenciar streams, em vez de fazer conversão completa de protocolo.

Desvantagens:

• Exigência do servidor de origem: requer que o servidor de origem suporte HTTP/2 integralmente.
• Menos visibilidade/controle: a manipulação direta de cabeçalhos HTTP ou corpos de requisição pelo proxy torna-se mais complexa por causa da compressão HPACK e da natureza binária dos frames HTTP/2. A inspeção profunda de pacotes normalmente exige decodificar e recodificar os frames por completo.
• Implicações de segurança: se a conexão com a origem também usar TLS, o proxy atua como ponto de terminação TLS e restabelece uma nova conexão TLS com a origem, o que pode afetar a postura de segurança ou exigir gerenciamento de certificados.

Caso de uso: mais adequado quando tanto os clientes quanto os servidores de origem suportam HTTP/2 e o objetivo é maximizar os ganhos de desempenho do HTTP/2 em todo o caminho da conexão, com interferência mínima do proxy além de roteamento e balanceamento de carga.

Considerações essenciais para serviços de proxy

Application-Layer Protocol Negotiation (ALPN)

O HTTP/2 normalmente é negociado sobre TLS usando ALPN. Quando um cliente se conecta a um proxy, ele envia uma extensão ALPN na mensagem TLS ClientHello, indicando suporte a h2 (HTTP/2 sobre TLS) e a http/1.1. O proxy seleciona o protocolo preferido.

Exemplo (handshake ALPN conceitual):

ClientHello (ALPN: [h2, http/1.1]) -> Proxy
Proxy selects h2
ServerHello (ALPN: h2) <- Proxy

Tradução de cabeçalhos e HPACK

Ao fazer a transição entre HTTP/2 e HTTP/1.1 (modelo de terminação), o proxy precisa descomprimir os cabeçalhos HPACK das requisições HTTP/2 e recodificar os cabeçalhos HTTP/1.1 em HPACK para as respostas HTTP/2. Isso envolve gerenciar a tabela dinâmica do HPACK, que mantém estado.

Gerenciamento e priorização de streams

O HTTP/2 permite múltiplos streams simultâneos sobre uma única conexão. Um proxy precisa gerenciar esses streams, mapeando-os para conexões de backend (no caso de backends HTTP/1.1) ou encaminhando-os respeitando as dicas de prioridade. Um gerenciamento incorreto de streams pode anular os benefícios da multiplexação do HTTP/2.

Tratamento do server push

• Terminação: se o proxy termina o HTTP/2, ele não consegue encaminhar diretamente as requisições de server push vindas da origem. O proxy pode implementar sua própria lógica de server push com base em análise de conteúdo ou configuração.
• Ponta a ponta: em uma configuração ponta a ponta, os frames de server push da origem são encaminhados diretamente ao cliente.

Inspeção e modificação de tráfego

Inspecionar ou modificar tráfego HTTP/2 é mais desafiador que no HTTP/1.1.
* Criptografia: o HTTP/2 é usado quase universalmente com TLS, exigindo que o proxy termine o TLS para fazer inspeção.
* Compressão de cabeçalhos: modificar cabeçalhos exige decodificar, modificar e recodificar com HPACK, o que mantém estado e pode ser complexo.

Balanceamento de carga

Com HTTP/2, várias requisições de um mesmo cliente podem chegar por uma única conexão. Os balanceadores de carga precisam decidir se roteiam todos os streams de uma conexão de cliente para um único servidor de backend (session stickiness) ou se distribuem os streams individuais entre vários servidores de backend. A segunda opção exige um balanceamento de carga mais sofisticado, ciente dos streams.

Exemplos de configuração (Nginx)

O Nginx, um proxy reverso comum, suporta tanto a terminação HTTP/2 quanto o proxy ponta a ponta.

Terminação HTTP/2 (frontend HTTP/2, backend HTTP/1.1):

server {
    listen 443 ssl http2; # Habilita HTTP/2 para as conexões dos clientes
    server_name example.com;

    ssl_certificate /etc/nginx/certs/example.com.crt;
    ssl_certificate_key /etc/nginx/certs/example.com.key;

    location / {
        proxy_pass http://backend_servers; # O backend é HTTP/1.1
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
        # O Nginx converte automaticamente as requisições HTTP/2 do cliente em HTTP/1.1 para o backend
    }
}

upstream backend_servers {
    server 192.168.1.100:80;
    server 192.168.1.101:80;
}

HTTP/2 ponta a ponta (frontend HTTP/2, backend HTTP/2):

server {
    listen 443 ssl http2; # Habilita HTTP/2 para as conexões dos clientes
    server_name example.com;

    ssl_certificate /etc/nginx/certs/example.com.crt;
    ssl_certificate_key /etc/nginx/certs/example.com.key;

    location / {
        proxy_pass https://backend_h2_servers; # O backend é HTTP/2
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_ssl_server_name on; # Repassa o SNI ao backend
        proxy_http_version 2; # Instrui o Nginx a usar HTTP/2 na conexão com o backend
    }
}

upstream backend_h2_servers {
    server 192.168.1.100:443;
    server 192.168.1.101:443;
}

Comparação: terminação HTTP/2 vs. ponta a ponta

Implicações práticas

Implementar HTTP/2 em um serviço de proxy impacta diretamente a experiência do usuário e a eficiência da infraestrutura. Os usuários se beneficiam de carregamentos de página mais rápidos e de uma web mais responsiva graças à multiplexação e à compressão de cabeçalhos. Para a infraestrutura de proxy, dar suporte a HTTP/2 exige um gerenciamento cuidadoso de recursos, especialmente quanto ao uso de CPU para terminação TLS e processamento HPACK. A escolha entre terminação e ponta a ponta depende da arquitetura de backend existente, das metas de desempenho e da necessidade de controle do tráfego no nível do proxy. A segurança continua sendo prioritária, com o TLS como pré-requisito para a maioria das implantações HTTP/2, exigindo gerenciamento robusto de certificados e configuração segura.