压测场景下的 TIME_WAIT 处理

简介： 压测场景下的 TIME_WAIT 处理

 

1. 序

某专有云项目具备压测场景，在Windows的压测机上用 LoadRunner 进行业务的压力测试，压测运行一段时间后出现大量端口无法分配的报错。
其实通过问题描述，以及 Windows的报错信息基本确定是压测机的问题。但可能原因较多，一直未能达成一致。所以，趁机分析了客户端的压测机成为压测瓶颈的可能，除了CPU、网络、 I/O 等机器性能参数外，仍需考虑网络协议引入的资源短缺问题。
注：以下内容的目的是理清TCP协议中比较模糊的内容，对协议比较熟悉的可以忽略。

2. TIME_WAIT基础：RFC 793 TCP协议

众所周知， TCP存在三次握手，四次挥手过程。其具体设计的目的，简而言之，是为了在不稳定的物理网络环境中确保可靠的数据传输；因此，TCP在具体实现中加入了很多异常状况的处理，整体协议就变得比较复杂。
要理解TCP协议，推荐阅读 RFC 793，可参考文后链接了解详情[1]。同时，也要理解“TCP state transition”状态机，如下图所示，可参考文后资料了解详情[2]。

 

图1. TCP状态转换图

本文仅针对 TW 在TCP协议中的作用进行讨论，不涉及整体协议的分析。四次挥手后的TIME_WAIT 状态，后续将以TW缩写替代。

2.1 TW 作用

首先，主要作用是保证TCP连接关闭的可靠性。
考虑下在四次挥手过程中，如果主动关闭方发送的LAST_ACK丢失，那么被动关闭方会重传FIN。此时，如果主动关闭方对应的TCP Endpoint没有进入TW状态而是直接在内核中清理了，根据协议，主动关闭方会认为自己没有打开过这个端口，而以RST响应被动关闭方重传的FIN。最终该行为导致被动关闭方认为连接异常关闭，在业务上可能会收到异常报错等情况。
其次，TW状态同时也能避免相同的TCP端口收到在网络上前一个连接的重复数据包。
理论上，数据包在网络上过期时间对应即MSL（Maximal Segment Lifetime），随着操作系统的不断发展，也有例外情况，这部分搜索PAWS应该可以看到不少类似的文章说明。<