Uma conexão ociosa e longa pode significar que a conexão foi interrompida (um dos lados teve o aplicativo travado, cabo de rede desconectado, etc), mas os recursos ainda seriam alocados, o que significa que:
- O desempenho seria um pouco afetado.
- Seu aplicativo pode ter um limite de X conexões simultâneas e, portanto, você pode estar negando acesso a novos clientes que, na realidade, não estão conectados.
- Você não pode reconectar um cliente se estivesse usando portas fixas para origem e destino (um pouco incomum, mas possível).
- Você pode atingir limites de conexão / roteamento, impedindo novas conexões com qualquer outra porta ou causando comportamentos inesperados ou um travamento do próprio servidor.
- Muitos aplicativos não param até que todas as conexões sejam fechadas corretamente, portanto, desligar ou reiniciar um serviço levaria mais tempo
- Você não conseguirá distinguir entre uma conexão interrompida e uma ativa sem inspecionar o tráfego do TPC por um tempo ou confiar nos registros do aplicativo
- A maioria dos aplicativos clientes não sabe como reagir em conexões interrompidas: alguns aguardarão um tempo limite interno, mas outros aguardarão para sempre, causando uma possível perda de dados se o cliente precisar de uma reinicialização.
O último também ocorrerá se você definir um tempo limite ocioso de TCP menor que o necessário, já que alguns sistemas simplesmente descartariam a conexão de suas tabelas TCP enquanto outros enviariam um pacote RST para a outra parte.
Use tempos limite ociosos de acordo com o tipo de tráfego que você gerencia (por exemplo, os servidores Apache têm um tempo limite padrão de 5 minutos, portanto, nenhuma conexão ficará inativa por mais de 5 minutos [e alguns segundos]), mas nunca estabelecer um limite de tempo ocioso TCP menor (ou exatamente igual) do que o tempo limite do seu aplicativo. Implemente keep-alive em conexões de longa data pelo menos a cada poucos minutos para garantir que a conexão esteja ativa (keepalives TCP definidos na criação de socket têm um timeout de duas horas, o que eu considero muito alto). O software interativo ao usuário (como sessões ssh, área de trabalho remota, FTP) ficaria ocioso por alguns minutos enquanto o usuário lê, então eu não ficaria por menos de 15 minutos.
Observação: eu não recomendaria nenhum tempo limite ocioso do TCP abaixo de alguns minutos, exceto em conexões altamente intensivas que não ficarão inativas por mais de alguns segundos. Se possível, defina diferentes tempos ociosos dependendo do seu tráfego (ou seja, 6 minutos para servidores web, 15 para sessões ssh, etc).
Se precisar de tempos limite mais altos (alguém solicita uma conexão TCP "eterna"), tente usar keepalive na camada de aplicativos.