WebSockets可以选择向另一端发送ping，而另一端应该以Pong响应。
收到Ping帧后，端点必须发送Pong帧作为响应，除非它已经接收到Close帧。在实际可行的情况下，应使用Pong框架进行响应。
TCP以keepalive形式提供类似的内容：
[Y]您向您的同伴发送一个没有数据的keepalive探测包，并且ACK标志已打开。由于TCP / IP规范（作为一种重复的ACK），您可以执行此操作，并且远程端点将没有参数，因为TCP是面向流的协议。另一方面，您将收到来自远程主机的答复（该主机根本不需要支持keepalive，仅支持TCP / IP），并且没有数据和ACK。
我认为TCP keepalive效率更高，因为它可以在内核中进行处理，而无需将数据传输到用户空间，解析websocket框架，制作响应框架并将其交还给内核进行传输。网络流量也更少。
此外，WebSockets被明确指定为始终在TCP上运行。它们与传输层无关，因此TCP keepalive始终可用：
WebSocket协议是一个独立的基于TCP的协议。
那么，为什么要使用WebSocket ping / pong代替TCP keepalive？
TCP keepalive的问题是：
与WebSockets ping / pong的比较没有意义。TCP keepalive是自动的，并且在启用时是定时的，而WebSocket ping / pong是根据应用程序的要求执行的。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句