Os batimentos de WebSocket no navegador exigem um protocolo de aplicação
Projete um batimento de aplicação acordado quando o JavaScript do navegador não consegue enviar diretamente quadros WebSocket Ping.
A API WebSocket do navegador tem send(). Ela não expõe um método ping() genérico para o JavaScript enviar quadros Ping do protocolo.
Se a sua aplicação envia uma mensagem de texto como {"type":"heartbeat"}, isso são dados de aplicação. O servidor precisa entender a mensagem e definir uma resposta. Um servidor que não implementa esse contrato não é obrigado a responder com um Pong do protocolo só porque o texto contém a palavra ping.
Defina o que significa uma confirmação, como ela identifica o batimento pendente e quando uma confirmação antiga chega tarde demais. Mantenha isso separado da confirmação de uma operação de negócio.
Um temporizador JavaScript também tem restrições de agendamento. Abas em segundo plano e threads principais ocupadas podem atrasar os callbacks. Não interprete um limite exato de temporizador perdido como prova conclusiva de que o proxy parou de encaminhar.
O navegador pode tratar internamente os quadros de controle do protocolo, mas isso não dá ao código da aplicação uma visão portátil de cada Ping ou Pong. Se a página precisa da própria decisão de vitalidade, use um contrato de aplicação explícito e uma política de recuperação.
Um socket cujo readyState é OPEN é considerado aberto localmente; isso não é uma medição independente de que a aplicação remota processou a sua última mensagem. Use a evidência que corresponde à pergunta que você realmente precisa responder.