Keep-Alive

Keep-Alive, no contexto de conexões persistentes através de um proxy, é um mecanismo HTTP que permite que uma única conexão TCP permaneça aberta e seja reutilizada para múltiplas requisições e respostas HTTP entre um cliente e um proxy, e entre um proxy e um servidor de origem, reduzindo assim o overhead de estabelecer novas conexões a cada transação.

Entendendo o Keep-Alive

O Keep-Alive do HTTP, também conhecido como conexões persistentes, é uma otimização fundamental para o desempenho web. Sem Keep-Alive, cada requisição HTTP exigiria o estabelecimento de uma nova conexão TCP (handshake TCP), seguido da transferência de dados e do encerramento da conexão. Esse processo gera um overhead significativo, especialmente em conexões seguras, que também exigem um handshake TLS.

Benefícios das conexões persistentes

• Menor latência: elimina a latência associada aos handshakes TCP e TLS nas requisições subsequentes feitas pela mesma conexão. Isso é particularmente perceptível para clientes com tempos de ida e volta (RTT) altos.
• Menor uso de CPU e memória: estabelecer e encerrar conexões com menos frequência reduz a carga computacional em clientes, proxies e servidores de origem. Isso inclui ciclos de CPU para operações de socket, memória para o estado da conexão e uso de descritores de arquivo.
• Menor congestionamento de rede: menos conexões TCP sendo abertas e fechadas significa menos tráfego de sinalização (pacotes SYN, SYN-ACK, FIN, FIN-ACK) na rede.
• Melhor throughput: permite um uso mais eficiente dos mecanismos de controle de congestionamento do TCP, já que as conexões conseguem atingir taxas de throughput mais altas ao longo do tempo.

Keep-Alive no HTTP/1.x

A implementação e o comportamento padrão do Keep-Alive diferem entre HTTP/1.0 e HTTP/1.1.

Keep-Alive no HTTP/1.0

No HTTP/1.0, conexões persistentes não eram o padrão. Os clientes precisavam solicitar o Keep-Alive explicitamente, incluindo o cabeçalho Connection: keep-alive em suas requisições. Os servidores respondiam com o mesmo cabeçalho para indicar suporte a conexões persistentes. Se uma das partes não incluísse esse cabeçalho, a conexão era fechada após a resposta atual.

Keep-Alive no HTTP/1.1

O HTTP/1.1 tornou as conexões persistentes o comportamento padrão. A menos que se declare explicitamente o contrário, clientes e servidores assumem que a conexão deve permanecer aberta após uma transação. Para fechar uma conexão, qualquer uma das partes precisa enviar o cabeçalho Connection: close. Essa mudança melhorou significativamente o desempenho web por padrão.

O cabeçalho Connection como cabeçalho hop-by-hop

O cabeçalho Connection é um cabeçalho hop-by-hop. Isso significa que ele se destina apenas à conexão direta entre duas partes que se comunicam (por exemplo, cliente para proxy, ou proxy para servidor de origem) e não deve ser retransmitido por proxies ou intermediários. Os proxies precisam remover ou modificar cabeçalhos hop-by-hop antes de encaminhar requisições ou respostas. Não fazer isso pode levar a violações de protocolo e comportamentos inesperados, já que o servidor ou o cliente do outro lado pode interpretar mal as instruções de gerenciamento da conexão.

Outros cabeçalhos hop-by-hop comuns incluem Keep-Alive, Proxy-Authenticate, Proxy-Authorization, TE, Trailers e Upgrade.

Keep-Alive através de um proxy

Os proxies têm um papel crítico no gerenciamento de conexões persistentes. Normalmente, eles mantêm dois conjuntos de conexões persistentes:

1. Conexões cliente-para-proxy: o proxy mantém conexões persistentes com seus clientes.
2. Conexões proxy-para-origem: o proxy mantém conexões persistentes com os servidores de origem para os quais encaminha requisições.

O papel do proxy no gerenciamento de cabeçalhos

Quando um proxy recebe um cabeçalho Connection: keep-alive de um cliente, ele entende que o cliente quer manter a conexão com o proxy aberta. No entanto, o proxy não deve encaminhar esse cabeçalho Connection ao servidor de origem. Em vez disso, o proxy decide de forma independente se estabelece uma conexão persistente com o servidor de origem, com base na sua própria configuração e nas capacidades do servidor de origem.

Um padrão comum em proxies, especialmente com HTTP/1.1, é remover o cabeçalho Connection das requisições recebidas do cliente e gerenciar separadamente a conexão upstream com o servidor de origem. Se o proxy quiser usar conexões persistentes HTTP/1.1 no upstream, basta omitir o cabeçalho Connection: close.

# Exemplo de configuração Nginx para proxy HTTP/1.1 com Keep-Alive
location / {
    proxy_pass http://backend_server;
    proxy_http_version 1.1; # Instrui o Nginx a usar HTTP/1.1 no upstream
    proxy_set_header Connection ""; # Remove o cabeçalho Connection das requisições do cliente
                                    # para garantir que o Nginx gerencie o Keep-Alive upstream de forma independente.
                                    # Isso é essencial para o tratamento correto de cabeçalhos hop-by-hop.
}

Neste exemplo do Nginx, proxy_http_version 1.1; garante que o Nginx use HTTP/1.1 ao se conectar ao backend_server. Por padrão, conexões HTTP/1.1 são persistentes. proxy_set_header Connection ""; remove explicitamente o cabeçalho Connection que possa ter vindo do cliente, impedindo que ele seja encaminhado ao servidor de origem e permitindo que o Nginx gerencie corretamente suas próprias conexões persistentes upstream.

Pool de conexões

Proxies costumam implementar pool de conexões para suas conexões upstream com servidores de origem. Isso significa que eles mantêm um pool de conexões TCP abertas e ociosas com vários servidores de origem. Quando chega uma nova requisição para uma origem específica, o proxy primeiro verifica se há uma conexão ociosa com essa origem disponível no pool. Se houver, ele reutiliza essa conexão. Se não, uma nova conexão é estabelecida. Isso aumenta ainda mais a eficiência ao reduzir o número de novas conexões que o proxy precisa estabelecer.

Timeouts de Keep-Alive e gerenciamento de recursos

Embora sejam benéficas, as conexões persistentes exigem gerenciamento cuidadoso para evitar o esgotamento de recursos no proxy e nos servidores de origem.

Mecanismos de timeout

Cada parte (cliente, proxy, servidor de origem) pode especificar um timeout de keep-alive. Se nenhum dado for trocado em uma conexão persistente dentro desse período de timeout, a conexão é fechada.

• Timeout do lado do cliente: o cliente pode fechar sua conexão com o proxy se não enviar outra requisição dentro de um determinado período.
• Timeout do lado do proxy: o proxy pode configurar seus próprios timeouts de keep-alive tanto para as conexões voltadas ao cliente quanto para as voltadas à origem. Se uma conexão ociosa cliente-para-proxy ou proxy-para-origem exceder seu timeout, o proxy a fechará.
• Timeout do servidor de origem: o servidor de origem fechará sua conexão com o proxy se ela permanecer ociosa por tempo demais.

Timeouts incompatíveis podem causar problemas. Por exemplo, se um servidor de origem tiver um timeout de keep-alive menor que o do proxy, a origem pode fechar uma conexão que o proxy ainda considera aberta. Quando o proxy tentar reutilizar essa conexão "obsoleta", encontrará um erro (por exemplo, um connection reset) e terá que repetir a requisição em uma nova conexão. Isso adiciona latência e aumenta as taxas de erro. Por isso, em geral é recomendável configurar os timeouts de keep-alive proxy-para-origem para serem ligeiramente menores ou iguais aos timeouts do servidor de origem.

Número máximo de conexões

Os proxies também precisam limitar o número total de conexões persistentes que mantêm, tanto com clientes quanto com servidores de origem. Cada conexão aberta consome recursos do sistema (memória, descritores de arquivo). Conexões persistentes sem limite podem levar a:

• Esgotamento de descritores de arquivo: o proxy fica sem descritores de arquivo disponíveis.
• Esgotamento de memória: conexões abertas em excesso consomem memória demais.
• Aumento da carga de CPU: gerenciar um grande número de conexões ociosas ainda gera algum overhead.

As configurações de proxy normalmente permitem que administradores definam keep-alive_timeout e keep-alive_requests (o número máximo de requisições permitidas em uma única conexão persistente antes que ela seja fechada e recriada).

# Exemplo Nginx: configurações de Keep-Alive para conexões voltadas ao cliente
http {
    keepalive_timeout 60s; # Timeout de keep-alive cliente-para-Nginx
    keepalive_requests 1000; # Máximo de requisições por conexão keep-alive cliente-para-Nginx
    # ...
}

# Exemplo Nginx: configurações de Keep-Alive para conexões proxy-para-origem
location / {
    proxy_pass http://backend_server;
    proxy_http_version 1.1;
    proxy_set_header Connection "";

    # Opcional: configure ajustes específicos de keep-alive upstream, se necessário
    # O comportamento padrão de keep-alive upstream do Nginx é reutilizar conexões
    # enquanto não forem explicitamente fechadas pelo upstream ou expiradas pelo Nginx.
    # Para um controle mais explícito sobre o pool de conexões upstream:
    # proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
    # proxy_connect_timeout 5s;
    # proxy_read_timeout 10s;
    # proxy_send_timeout 10s;
}

Keep-Alive no HTTP/2 e além

O HTTP/2 introduziu a multiplexação, permitindo que múltiplas requisições e respostas HTTP sejam enviadas simultaneamente por uma única conexão TCP. Isso oferece, de forma inerente, os benefícios do Keep-Alive sem precisar de cabeçalhos Connection: keep-alive explícitos na camada de aplicação. Uma conexão HTTP/2, uma vez estabelecida, é projetada para permanecer aberta e lidar com todo o tráfego entre cliente e servidor (ou cliente e proxy, proxy e origem) até ser explicitamente fechada ou expirar.

Embora o HTTP/2 abstraia o cabeçalho Keep-Alive explícito, o princípio subjacente de manter uma conexão TCP persistente para reduzir overhead continua sendo crucial. Proxies com suporte a HTTP/2 gerenciam uma conexão HTTP/2 persistente com o cliente e podem traduzir as requisições para conexões persistentes HTTP/1.1 ou conexões HTTP/2 com o servidor de origem, dependendo das capacidades da origem e da configuração do proxy. O papel do proxy em gerenciar essas conexões TCP subjacentes e seus timeouts continua sendo vital para o desempenho e o gerenciamento de recursos.

Resumo dos comportamentos do Keep-Alive