Seria incorreto supor que uma conexão precisa estar viva ou morta e que você pode dizer com segurança a diferença. Esse tipo de suposição leva a sistemas não confiáveis porque você pode acabar contando com uma heurística que não verifica a propriedade vital que você esperava.
Uma abordagem melhor é monitorar se a coisa que você precisa fazer a conexão para você está realmente funcionando. Por exemplo, se você precisa de um cliente específico para se conectar a um servidor específico, então é para isso que você deve monitorar. Contanto que os dois continuem se comunicando, você não se importa se uma heurística diferente consideraria a conexão baixa.
Se o monitoramento detectar um problema, talvez você queira que o monitoramento seja alertado sobre isso. Pode ser que você queira que o monitoramento não apenas detecte a conexão e esteja alerta, mas também tente corrigir o problema. Isso, no entanto, leva a mais perguntas.
Por exemplo, suponha que você possua hardware que possa desligar e ligar um componente de rede em caso de uma falha. Então, talvez você não queira fazer o ciclo de energia apenas porque o cliente e o servidor não podem se comunicar uns com os outros. Pode ser que a outra extremidade da conexão estivesse inativa e o ciclo de energia não fosse necessário. Pode até ser que a ciclagem de energia introduza uma interrupção própria ou atrapalhe a intervenção manual.
Existem maneiras de contornar esses problemas. Por exemplo, se a conexão com o servidor parece estar inativa, você pode enviar uma pesquisa de DNS para o servidor. Se você recebeu uma resposta, não foi porque a conexão está completamente inativa. Mas você nem precisa enviar a solicitação até o servidor DNS. Você poderia enviar a pesquisa de DNS com um limite de salto baixo. Por exemplo, se você enviar uma pesquisa de DNS com um limite de salto de 3 e obter um ICMP de volta a partir do terceiro salto, é improvável que a passagem de energia pelo 1º salto resolva o problema.
Isto, obviamente, não é uma bala de prata. Mesmo as melhores heurísticas às vezes dão errado. Se você alguma vez construir algo tentando reiniciar automaticamente uma conexão quebrada, certamente precisará garantir que ela tenha uma estratégia de recuo exponencial para impedi-la de reiniciar repetidamente.
Monitorar a conectividade obviamente não pode ser feito sem trocar nenhum pacote. Mas você quer limitar o custo de processamento desses pacotes. Por exemplo, embora você possa enviar um pacote com alguns saltos e receber uma mensagem de erro de um roteador específico, essa não é a operação mais barata para a maioria dos roteadores. Se você puder encontrar uma maneira de enviar um pacote para fora e voltar sem envolver nada, a não ser o hardware encaminhando parte dos roteadores, então isso é mais barato, mesmo que seja necessário mais saltos para fazê-lo.
Se você tiver mais sites, poderá melhorar a confiabilidade do monitoramento da conexão fazendo com que eles se comuniquem periodicamente uns com os outros emparelhados. Se um site perder a conectividade simultaneamente com todos os outros sites, é muito provável que esse site tenha um problema de conectividade.