A menos que um FIN ou RST seja enviado, a única outra maneira que o TCP padrão sabe se o outro lado parou ou se foi, é um tempo limite de expiração.
Este é realmente o melhor que você pode fazer projetando se estiver fazendo a menor quantidade possível de suposições do "outro lado" possível, e sua única conexão com esse "outro lado" é uma única interface de rede.
Um evento menor no modelo OSI pode fazer com que o sistema operacional encerre a conexão sozinho ou forneça informações que poderiam fazer com que o cliente desistisse, como a remoção do adaptador de rede em questão ou o link estado mudando para ser desconectado. Isso não precisa acontecer, no entanto.
A solução geral é enviar mensagens periódicas sem dados significativos, chamados de keepalive, através da conexão. O TCP suporta isso, mas você também pode fazê-lo na camada de aplicativos.
- O FileZilla pode ser configurado para enviar mensagens keepalive. Você pode vê-lo enviar comandos que não fazem nada útil, mas são emitidos apenas para jogar algo no tubo e mantê-lo "ocupado".
- PuTTY, por exemplo, tem opções keepalive também .
- Você também pode definir opções keepalive no servidor também, mas geralmente é melhor definir isso no SSH cliente.
- Muitos protocolos de roteamento enviam keepalives na camada de aplicativo para verificar se outras rotas estão funcionando e disponíveis, BGP , por um.
- O TCP também suporta nativamente as mensagens keepalive, elas são basicamente pacotes nulos enviados de tempos em tempos para verificar a conexão. Este artigo do tldp.org explica bem.