Un socket TCP vivo, un par WebSocket que responde y un progreso útil de la aplicación son observaciones distintas:

EvidenciaQué establece
Vitalidad a nivel de TCPLa ruta de transporte comprobada responde en ese nivel
Un WebSocket Pong coincidenteEl par respondió a esa trama de control
Un acuse de la aplicaciónLa aplicación confirmó una operación según su propio protocolo

Un proxy directo suele mantener conexiones separadas hacia el cliente y hacia el destino. El par TCP del cliente es el proxy, mientras que un Ping dentro de un túnel establecido viaja hasta el extremo WebSocket.

Un Pong coincidente

El protocolo exige que un Pong de respuesta lleve los datos de aplicación del Ping. Use esa correspondencia para identificar una sonda pendiente. Un Pong no solicitado está permitido, pero no pide acuse; enviar uno tras cada mensaje de datos aporta una evidencia distinta.

Prefiera el mecanismo de latido compatible con la biblioteca. El JavaScript del navegador necesita en cambio un contrato de latido a nivel de aplicación. Elija intervalos y umbrales de fallo según la carga y la política de red. Las pausas de planificación o un bucle de eventos sobrecargado pueden incumplir un umbral agresivo sin demostrar que la red falla.

Mantenga el receptor en marcha

El cliente necesita entrada y salida continua para recibir y procesar tramas de control. Bloquear ese mecanismo puede hacer que una escasez local parezca una caída.

Ping genera tráfico de túnel, pero cada intermediario decide qué satisface su política de inactividad. Ningún latido garantiza protección frente a un límite absoluto de vida de la conexión.

Un par puede responder a Ping mientras su aplicación deja de producir actualizaciones, y una suscripción silenciosa puede ser sana. Siga por separado el último Pong válido y el evento de aplicación significativo cuando ambos importan. Ante un fallo, conserve la ruta, los tiempos transcurridos y la sonda pendiente, y luego cierre o recupere mediante el ciclo de vida compatible.

Artículos relacionados