Conexão persistente HTTP - HTTP persistent connection
| HTTP |
|---|
| Métodos de solicitação |
| Campos de cabeçalho |
| Códigos de status de resposta |
| Métodos de controle de segurança de acesso |
| Vulnerabilidades de segurança |
A conexão persistente HTTP , também chamada de HTTP keep-alive ou reutilização de conexão HTTP , é a ideia de usar uma únicaconexão TCP para enviar e receber várias solicitações / respostas HTTP , em vez de abrir uma nova conexão para cada par de solicitação / resposta. Oprotocolo HTTP / 2 mais recenteusa a mesma ideia e vai além para permitir que várias solicitações / respostas simultâneas sejam multiplexadas em uma única conexão.
Operação
HTTP 1.0
No HTTP 1.0, as conexões sempre devem ser fechadas pelo servidor após o envio da resposta.
Desde o final de 1996, desenvolvedores de produtos populares (navegadores, servidores web, etc.) usando HTTP / 1.0, começaram a adicionar uma extensão não oficial (ao protocolo) chamada "keep-alive" para permitir a reutilização de uma conexão para múltiplos solicitações / respostas.
Se o cliente oferecer suporte a keep-alive, ele adicionará um cabeçalho adicional à solicitação:
Connection: keep-alive
Quando o servidor recebe essa solicitação e gera uma resposta, se ele oferece suporte para keep-alive, ele também adiciona o mesmo cabeçalho acima à resposta. Em seguida, a conexão não é interrompida, mas mantida aberta. Quando o cliente envia outra solicitação, ele usa a mesma conexão.
Isso continuará até que o cliente ou o servidor decida que a conversa acabou e, neste caso, eles omitem o "Connection:"cabeçalho da última mensagem enviada ou, melhor, adicionem a palavra-chave "fechar" a ele:
Connection: close
Depois disso, a conexão é fechada de acordo com as regras especificadas.
Desde 1997, as várias versões das especificações HTTP / 1.1 reconheciam o uso desta extensão não oficial e incluíam algumas ressalvas em relação à interoperabilidade entre HTTP / 1.0 (keep-alive) e HTTP / 1.1 clientes / servidores.
HTTP 1.1
No HTTP 1.1, todas as conexões são consideradas persistentes, a menos que seja declarado o contrário. As conexões persistentes HTTP não usam mensagens de manutenção de atividade separadas, elas apenas permitem que várias solicitações usem uma única conexão. No entanto, o tempo limite de conexão padrão do Apache httpd 1.3 e 2.0 é de apenas 15 segundos e apenas 5 segundos para o Apache httpd 2.2 e superior. A vantagem de um tempo limite curto é a capacidade de fornecer vários componentes de uma página da web rapidamente, sem consumir recursos para executar vários processos ou threads de servidor por muito tempo.
Keepalive com codificação de transferência fragmentada
O Keepalive torna difícil para o cliente determinar onde uma resposta termina e a próxima começa, especialmente durante a operação HTTP em pipeline. Este é um problema sério quando Content-Lengthnão pode ser usado devido ao streaming. Para resolver esse problema, o HTTP 1.1 introduziu uma codificação de transferência em partes que define um last-chunkbit. O last-chunkbit é definido no final de cada resposta para que o cliente saiba onde começa a próxima resposta.
Vantagens
- Latência reduzida em solicitações subsequentes (sem handshaking ).
- Uso reduzido da CPU e viagens de ida e volta devido a menos conexões novas e handshakes TLS .
- Ativa o pipelining HTTP de solicitações e respostas.
- Congestionamento de rede reduzido (menos conexões TCP ).
- Os erros podem ser relatados sem a penalidade de fechar a conexão TCP.
De acordo com a RFC 7230, seção 6.4 , "um cliente deve limitar o número de conexões abertas simultâneas que mantém para um determinado servidor". A versão anterior da especificação HTTP / 1.1 declarava valores máximos específicos, mas nas palavras do RFC 7230 "isso foi considerado impraticável para muitos aplicativos ... em vez disso ... seja conservador ao abrir várias conexões". Essas diretrizes têm como objetivo melhorar os tempos de resposta HTTP e evitar congestionamentos. Se o pipelining HTTP for implementado corretamente, não haverá benefício de desempenho a ser obtido com conexões adicionais, enquanto conexões adicionais podem causar problemas de congestionamento.
Desvantagens
Se o cliente não fechar a conexão quando todos os dados necessários forem recebidos, os recursos necessários para manter a conexão aberta no servidor não estarão disponíveis para outros clientes. O quanto isso afeta a disponibilidade do servidor e por quanto tempo os recursos ficam indisponíveis depende da arquitetura e configuração do servidor.
Além disso, uma condição de corrida pode ocorrer quando o cliente envia uma solicitação ao servidor ao mesmo tempo em que o servidor fecha a conexão TCP. Um servidor deve enviar um código de status 408 Request Timeout ao cliente imediatamente antes de fechar a conexão. Quando um cliente recebe o código de estado 408, após ter enviado o pedido, pode abrir uma nova ligação ao servidor e reenviar o pedido. Nem todos os clientes reenviarão a solicitação e muitos que o farão somente o farão se a solicitação tiver um método HTTP idempotente .
Use em navegadores da web
Todos os navegadores modernos, incluindo Google Chrome , Firefox , Internet Explorer (desde 4.01), Opera (desde 4.0) e Safari usam conexões persistentes.
Por padrão, as versões 6 e 7 do Internet Explorer usam duas conexões persistentes, enquanto a versão 8 usa seis. As conexões persistentes expiram após 60 segundos de inatividade, que pode ser alterado por meio do Registro do Windows.
No Firefox , o número de conexões simultâneas pode ser personalizado (por servidor, por proxy, total). As conexões persistentes expiram após 115 segundos (1,92 minutos) de inatividade, que pode ser alterado por meio da configuração.
Veja também
- Pipelining HTTP , por meio do qual várias solicitações podem ser enviadas sem esperar por uma resposta
- HTTP / 2 , que permite o pipelining fora de ordem de solicitações e respostas, e também o envio preditivo de conteúdo antes de ser solicitado