TCP é a camada 4, camada HTTP 7.
No HTTP 1.0, o HTTP Keep-Alive é usado na camada 7 para simular conexões persistentes usando Connection header.
No HTTP 1.1, as conexões são assumidas como persistentes por padrão e, em seguida, dependem do TCP apenas para executar esse trabalho. As solicitações podem ser pipeleadas na mesma conexão TCP e, em seguida, um lado definirá Connection: close nos últimos cabeçalhos de solicitação ou resposta, portanto, os dois lados sabem que nenhuma solicitação HTTP pode ser trocada e a conexão será fechada.
Normalmente, no caso de um servidor web, o estado TIME_WAIT será o estado após o qual, uma vez decidido fechar a conexão ativamente, ele recebeu o pacote FIN do cliente e está enviando o último ACK de volta quatro vias de ruptura. Depois disso, ele aguarda 2 * MSL : é uma maneira de ter certeza de que a conexão está fechada. É daí que vem o 60s compilado no kernel. Desta forma, temos a certeza de que não receberemos em uma nova conexão, usando os mesmos pacotes de 4 tuplas fora de seqüência decorrentes da conexão anterior.
Você não quer alterá-lo .
No outro lado, server.max-keep-alive-idle é o tempo limite após o qual uma conexão ESTABLISHED será considerada inativa se nenhuma solicitação HTTP entrar e será ativamente fechada pelo servidor web. Quando essa decisão for tomada, como você entende agora, a desmontagem do TCP ocorrerá.
Tenha muito cuidado com tcp_tw_recycle , se seus visitantes vierem de trás de uma ampla rede NAT, isso poderá levar a várias conexões TCP com a mesma 4 tupla ocorrendo com timestamps fora de ordem, resultando na queda silenciosa das tentativas de conexão do cliente no lado do servidor.
Portanto, a melhor opção é ajustar o parâmetro que você viu no lighttpd. Em todo o sistema, você pode reduzir com segurança FIN_WAIT2 state e aumentar os buckets para soquetes em TIME_WAIT state com net.ipv4.tcp_fin_timeout e net.ipv4.tcp_max_tw_buckets .