WebSockets可以选择将ping发送到另一端，另一端应该用pong响应。
在收到Ping帧时，端点必须发送Pong帧作为响应，除非它已经收到Close帧。它应该尽快响应Pong帧。
TCP offers something similar以keepalive的形式：
[Y]ou向您的对等方发送一个没有数据的keepalive探测数据包，并打开ACK标志。您可以这样做，因为TCP/IP规范，作为一种重复的ACK，并且远程端点将没有参数，因为TCP是面向流的协议。另一方面，您将收到来自远程主机的回复（它根本不需要支持keepalive，只需TCP/IP），没有数据和ACK设置。
我认为TCP keepalive更有效，因为它可以在内核中处理，而不需要将数据传输到用户空间，解析WebSocket帧，制作响应帧，然后将其返回内核进行传输。这也减少了网络流量。
此外，WebSockets被明确指定为始终在TCP上运行;它们不是传输层不可知的，因此TCP keepalive始终可用：
WebSocket协议是一个独立的基于TCP的协议。
那么，为什么人们要使用WebSocket ping/pong而不是TCP keepalive呢？
5条答案
按热度按时间6qqygrtg1#
TCP keepalive的问题是：
1.默认情况下，它处于关闭状态。
1.默认情况下，它以两小时的间隔运行，而不是像Ping/Pong协议提供的那样按需运行。
1.它在代理之间运行，而不是端到端。
1.正如@DavidSchwartz所指出的，它在TCP堆栈之间运行，而不是在应用程序之间运行，因此它不会告诉我们应用程序是否活着。
与WebSockets ping/pong的比较没有意义。TCP keepalive在启用时是自动和定时的，而WebSocket ping/pong则根据应用程序的要求执行。
ibps3vxo2#
除了EJP的答案之外，我认为它也可能与HTTP代理机制有关。WebSocket连接也可以通过（HTTP）代理服务器运行。在这种情况下，TCP keepalive将只检查到代理的连接，而不是端到端连接。
j1dl9f463#
http://www.whatwg.org/specs/web-apps/current-work/multipage/network.html#ping-and-pong-frames
3.4乒乓球架
WebSocket协议规范定义了Ping和Pong帧，可用于保持活动、心跳、网络状态探测、延迟检测等。这些当前未在API中公开。
用户代理可以根据需要发送ping和主动pong帧，例如，试图维护本地网络NATMap，检测失败的连接，或向用户显示延迟度量**。用户代理不得使用ping或未经请求的pong来帮助服务器;假定服务器将在适合于服务器需要的任何时候请求PONG。
WebSockets是在考虑RTC的情况下开发的，所以当我查看ping/pong功能时，我也看到了一种测量延迟的方法。pong必须返回与ping相同的有效载荷，这使得发送时间戳非常方便，然后计算从客户端到服务器的延迟，反之亦然。
ki1q1bka4#
TCP keepalive不会通过Web代理进行传递。WebSocket ping/pong将通过Web代理转发。TCP keepalive旨在监督TCP端点之间的连接。Web Socket终结点不等于TCP终结点。一个WebSocket连接可以在两个WebSocket端点之间使用多个TCP连接。
niwlg2el5#
更新：虽然有HTTP/1.1在UDP上的实现，但WebSocket协议不能在UDP上工作（它需要可靠的底层传输）。
原始（不正确）答案如下：
除了指出TCP keepalive存在有效问题的所有答案（主要是它不通过代理）之外，请记住HTTP（以及WebSocket扩展）也被设计为在UDP上工作。