我正在与一位工程师讨论 Websocket 开销，我们都不确定 Websocket 如何实际检测客户端连接的状态。
我很惊讶我在 SO 上找不到这个答案，但这可能是我的错误。我发现this answer 解决了可扩展性问题，但这不是我在这里要问的。 This answer 涉及实施，但不是我在这里追求的深度。
【问题讨论】：
标签： networking tcp websocket network-protocols
webSocket 连接是使用 webSocket 协议的 TCP 连接。默认情况下，只有当底层 TCP 意识到连接已关闭并且 webSocket 层正在侦听连接上的关闭事件时，服务器或客户端才会知道连接何时消失，因此会以这种方式通知它。
webSocket 协议本身并不需要可以定期测试连接是否仍在工作的心跳包。 TCP 套接字可能看起来仍然是活动的，但实际上连接可能仍然无法正常工作。另一端可能已经消失或在两者之间被中断，并且一个或两个端点可能在任何给定时间都不知道。
Socket.io 建立在 webSocket 之上，使用 ping 和 pong 数据包实现心跳，定期测试连接，实际上会在客户端检测到无效连接，关闭套接字，然后自动重新连接。
是否定期向客户端/服务器发送“状态”数据包？
对于常规的 webSocket 连接默认情况下不是。
它与低级 API 中的 ping 或 pong 有什么关系吗？
这取决于客户端或服务器是否要自己发送 ping 或 pong 数据包以实现某种连接验证检测。
帧呢？
webSocket 帧是通过 webSocket 发送数据的数据格式。他们与这个问题没有任何关系。
Websocket 如何检测到它在客户端断开连接？服务器？
如上所述。除非客户端/服务器实现自己的 ping/pong 系统来检测连接何时出错，否则它们仅依靠 TCP 信号来了解连接何时被另一端关闭。在客户端或服务器尝试发送之前，WebSocket 连接可能无法正常工作。
当浏览器窗口/选项卡打开 webSocket 连接，然后窗口/选项卡被重定向到新 URL 时，浏览器将关闭与该窗口/选项卡关联的所有资源，包括任何 webSocket 连接。如果此时客户端和服务器之间的链接正常，那么服务器将被告知底层 TCP 连接（以及 webSocket）已关闭。如果网络链接断开，然后用户将该窗口/选项卡移动到新 URL，则服务器不一定知道连接不起作用，而不依赖 ping/pong 类型的信号来定期测试连接。
如果浏览器崩溃，操作系统应该关闭该进程打开的所有套接字。
如果计算机/操作系统崩溃，套接字可能不会正常关闭（尽管这可能在某种程度上取决于操作系统，也可能取决于崩溃）。
【讨论】：