tcp - WebSockets ping/pong，为什么不是 TCP keepalive？

Question

WebSockets have the option发送 ping 到另一端，另一端应该用 pong 响应。

Upon receipt of a Ping frame, an endpoint MUST send a Pong frame inresponse, unless it already received a Close frame. It SHOULDrespond with Pong frame as soon as is practical.

TCP offers something similar以keepalive的形式:

[Y]ou send your peer a keepalive probe packet with no data in it and the ACK flag turned on. You can do this because of the TCP/IP specifications, as a sort of duplicate ACK, and the remote endpoint will have no arguments, as TCP is a stream-oriented protocol. On the other hand, you will receive a reply from the remote host (which doesn't need to support keepalive at all, just TCP/IP), with no data and the ACK set.

我认为 TCP keepalive 更有效，因为它可以在内核中处理，而不需要将数据传输到用户空间，解析 websocket 帧，制作响应帧，然后将其交还给内核传播。它还减少了网络流量。

此外，WebSockets are explicitly specified始终运行在 TCP 上；它们与传输层无关，因此 TCP keepalive 始终可用:

The WebSocket Protocol is an independent TCP-based protocol.

那么为什么人们会想要使用 WebSocket ping/pong 而不是 TCP keepalive？

Answer 1

TCP keepalive存在的问题是:

1. 默认关闭。
2. 默认情况下，它每两小时运行一次，而不是像 Ping/Pong 协议(protocol)提供的那样按需运行。
3. 它在代理之间而不是端到端运行。
4. 正如@DavidSchwartz 所指出的，它在 TCP 堆栈之间运行，而不是在应用程序之间运行，因此它不会告诉我们应用程序是否处于事件状态。

与 WebSockets ping/pong 的比较没有意义。 TCP keepalive 是自动的，并且在启用时是定时的，而 WebSocket ping/pong 是根据应用程序的要求执行的。