WebSocketstener la opción de enviar pings al otro extremo, donde se supone que el otro extremo debe responder con un pong.

Al recibir una trama Ping, un punto final DEBE enviar una trama Pong en respuesta, a menos que ya haya recibido una trama Cerrar. DEBE responder con el marco de Pong tan pronto como sea práctico.

TCPofrece algo similar en forma de keepalive:

[SÍ] le envía a su compañero un paquete de sonda keepalive sin datos y el indicador ACK está activado. Puede hacerlo debido a las especificaciones TCP / IP, como una especie de ACK duplicado, y el punto final remoto no tendrá argumentos, ya que TCP es un protocolo orientado a la transmisión. Por otro lado, recibirá una respuesta del host remoto (que no necesita admitir keepalive en absoluto, solo TCP / IP), sin datos y con el conjunto ACK.

Creo que TCP keepalive es más eficiente, ya que se puede manejar dentro del núcleo sin la necesidad de transferir datos al espacio del usuario, analizar un marco websocket, crear un marco de respuesta y devolverlo al núcleo para su transmisión. También es menos tráfico de red.

Además, WebSocketsse especifican explícitamente ejecutar siempre sobre TCP; no son independientes de la capa de transporte, por lo que TCP keepalive siempre está disponible:

El protocolo WebSocket es un protocolo independiente basado en TCP.

Entonces, ¿por qué alguien querría usar WebSocket ping / pong en lugar de TCP keepalive?