Los latidos de WebSocket en el navegador necesitan un protocolo de aplicación
Diseñe un latido de aplicación acordado cuando el JavaScript del navegador no puede enviar directamente tramas Ping de WebSocket.
La API WebSocket del navegador tiene send(). No expone un método ping() general para que JavaScript envíe tramas Ping del protocolo.
Si su aplicación envía un mensaje de texto como {"type":"heartbeat"}, eso son datos de aplicación. El servidor debe entender el mensaje y definir una respuesta. Un servidor que no implementa ese contrato no está obligado a responder con un Pong del protocolo solo porque el texto contenga la palabra ping.
Defina qué significa un acuse de recibo, cómo identifica el latido pendiente y cuándo un acuse antiguo llega demasiado tarde. Manténgalo separado del acuse de una operación de negocio.
Un temporizador de JavaScript también tiene restricciones de planificación. Las pestañas en segundo plano y los hilos principales ocupados pueden retrasar las devoluciones de llamada. No interprete un límite exacto de temporizador incumplido como prueba concluyente de que el proxy dejó de reenviar.
El navegador puede gestionar internamente las tramas de control del protocolo, pero eso no da al código de la aplicación una visión portable de cada Ping o Pong. Si la página necesita su propia decisión de vitalidad, use un contrato de aplicación explícito y una política de recuperación.
Un socket cuyo readyState es OPEN se considera abierto localmente; no es una medición independiente de que la aplicación remota haya procesado su último mensaje. Use la evidencia que corresponda a la pregunta que realmente necesita responder.