WebSocket RFC是否规定服务端应进入TIME_WAIT状态？

1. 规范是否要求服务端主动发起TCP关闭、进入TIME_WAIT状态？ #

是的，该结论成立。
RFC 6455 5.5.1节的规定原文为：

The server MUST close the underlying TCP connection immediately;
the client SHOULD wait for the server to close the connection

翻译后含义为：服务端必须立即关闭底层TCP连接，客户端应当等待服务端完成连接关闭。
按照TCP四次挥手规则，主动发起FIN请求的一方会最终进入TIME_WAIT状态，因此该规范下服务端会作为主动关闭方承担TIME_WAIT状态。

2. 该设计的原因是什么？ #

• 安全风险兜底：WebSocket关闭触发场景中很多属于异常场景，比如服务端检测到帧格式非法、协议违规、权限校验失败、跨域伪造请求等，服务端主动立即切断连接可以避免恶意客户端占用连接、发送恶意数据，从协议层面降低安全风险。
• 服务端资源优先释放：服务端需要承载海量客户端连接，文件描述符、socket缓冲区等资源远紧张于客户端，主动关闭可以第一时间回收相关资源，不需要等待客户端的超时处理逻辑，避免连接泄漏拖垮服务端负载。
• 降低实现复杂度：统一由服务端作为关闭发起方，避免两端同时发起关闭导致的状态冲突，客户端不需要处理复杂的关闭仲裁逻辑，只需要监听服务端的关闭信号即可，大幅降低两端的实现兼容成本。

3. 和常规"客户端承担TIME_WAIT最佳实践"的差异原因 #

常规HTTP短连接场景下推荐客户端主动承担TIME_WAIT，是因为短连接关闭频率极高，单个客户端发起的连接数少，TIME_WAIT压力分散到各个客户端不会造成单点瓶颈，该实践和WebSocket的设计并不冲突，核心原因是两者的应用场景完全不同：

• WebSocket是长连接，正常业务场景下连接生命周期普遍较长，主动关闭的触发频率远低于HTTP短连接，即使服务端承担TIME_WAIT，累计的状态数量也非常有限，不会对服务端造成压力。
• 触发服务端主动关闭的场景大多为异常请求，这类请求在正常业务中的占比极低，TIME_WAIT的累积风险完全可控。
• 目前服务端的内核参数可以通过优化消化TIME_WAIT的开销，比如开启tcp_tw_reuse、调整tcp_max_tw_buckets阈值等，相比安全风险、连接泄漏的影响，TIME_WAIT的开销完全可接受。

内容的提问来源于stack exchange，提问作者Todd Wong