WebSocketstem a opção de enviar pings para o outro extremo, onde o outro extremo deve responder com um pong.

Após o recebimento de um quadro de Ping, um terminal DEVE enviar um quadro de Pong em resposta, a menos que já tenha recebido um quadro de Fechamento. DEVE responder com moldura Pong o mais rápido possível.

TCPoferece algo semelhante sob a forma de keepalive:

[Y] você envia ao seu parceiro um pacote de sonda keepalive sem dados e o sinalizador ACK ativado. Você pode fazer isso devido às especificações TCP / IP, como uma espécie de ACK duplicado, e o terminal remoto não terá argumentos, pois o TCP é um protocolo orientado a fluxo. Por outro lado, você receberá uma resposta do host remoto (que não precisa oferecer suporte ao keepalive, apenas TCP / IP), sem dados e com o ACK definido.

Eu acho que o TCP keepalive é mais eficiente, porque pode ser manipulado no kernel sem a necessidade de transferir dados para o espaço do usuário, analisar um quadro do websocket, criar um quadro de resposta e devolvê-lo ao kernel para transmissão. Também é menos tráfego de rede.

Além disso, WebSocketssão explicitamente especificados sempre atropelar o TCP; eles não são independentes da camada de transporte; portanto, o keepalive do TCP está sempre disponível:

O protocolo WebSocket é um protocolo independente baseado em TCP.

Então, por que alguém iria querer usar o ping / pong WebSocket em vez do TCP keepalive?