老王再叙TIME_WAIT

之所以起这样一个题目是因为很久以前我曾经写过一篇介绍TIME_WAIT的文章，不过当时基本属于浅尝辄止，并没深入说明问题的来龙去脉，碰巧这段时间反复被别人问到相关的问题，让我觉得有必要全面总结一下，以备不时之需。

讨论前大家可以拿手头的服务器摸摸底，记住「ss」比「netstat」快：

shell> ss -ant | awk '{++s[$1]} END {for(k in s) print k,s[k]}'

如果你只是想单独查询一下TIME_WAIT的数量，那么还可以更简单一些：

shell> cat /proc/net/sockstat

我猜你一定被巨大无比的TIME_WAIT网络连接总数吓到了！以我个人的经验，对于一台繁忙的Web服务器来说，如果主要以短连接为主，那么其TIME_WAIT网络连接总数很可能会达到几万，甚至十几万。虽然一个TIME_WAIT网络连接耗费的资源无非就是一个端口、一点内存，但是架不住基数大，所以这始终是一个需要面对的问题。

为什么会存在TIME_WAIT？

TCP在建立连接的时候需要握手，同理，在关闭连接的时候也需要握手。为了更直观的说明关闭连接时握手的过程，我们引用「The TCP/IP Guide」中的例子：

TCP Close

因为TCP连接是双向的，所以在关闭连接的时候，两个方向各自都需要关闭。先发FIN包的一方执行的是主动关闭；后发FIN包的一方执行的是被动关闭。主动关闭的一方会进入TIME_WAIT状态，并且在此状态停留两倍的MSL时长。

穿插一点MSL的知识：MSL指的是报文段的最大生存时间，如果报文段在网络活动了MSL时间，还没有被接收，那么会被丢弃。关于MSL的大小，RFC 793协议中给出的建议是两分钟，不过实际上不同的操作系统可能有不同的设置，以Linux为例，通常是半分钟，两倍的MSL就是一分钟，也就是60秒，并且这个数值是硬编码在内核中的，也就是说除非你重新编译内核，否则没法修改它：

#define TCP_TIMEWAIT_LEN (60*HZ)

如果每秒的连接数是一千的话，那么一分钟就可能会产生六万个TIME_WAIT。

为什么主动关闭的一方不直接进入CLOSED状态，而是进入TIME_WAIT状态，并且停留两倍的MSL时长呢？这是因为TCP是一个建立在不可靠网络上的可靠的协议，主动关闭的一方收到被动关闭的一方发出的FIN包后，回应ACK包，同时进入TIME_WAIT状态，但是因为网络原因，主动关闭的一方发送的这个ACK包很可能延迟，从而触发被动连接一方重传FIN包。极端情况下，这一去一回，就是两倍的MSL时长。如果主动关闭的一方跳过TIME_WAIT直接进入CLOSED，或者在TIME_WAIT停留的时长不足两倍的MSL，那么当被动关闭的一方早先发出的延迟包到达后，就可能出现类似下面的问题：

• 旧的TCP连接已经不存在了，系统此时只能返回RST包
• 新的TCP连接被建立起来了，延迟包可能干扰新的连接

不管是哪种情况都会让TCP不在可靠，所以TIME_WAIT状态有存在的必要性。

如何控制TIME_WAIT的数量？

从前面的描述我们可以得出这样的结论：TIME_WAIT这东西没有的话不行，有的话太多也是个麻烦事。下面让我们看看有哪些方法可以控制TIME_WAIT数量，这里只说一些常规方法，另外一些诸如SO_LINGER之类的方法太过偏门，略过不谈。

ip_conntrack：顾名思义就是跟踪连接。一旦激活了此模块，就能在系统参数里发现很多用来控制网络连接状态超时的设置，其中自然也包括TIME_WAIT：

shell> modprobe ip_conntrack
shell> sysctl net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait

我们可以尝试缩小它的设置，比如十秒，甚至一秒，具体设置成多少合适取决于网络情况而定，当然也可以参考相关的案例。不过就我的个人意见来说，ip_conntrack引入的问题比解决的还多，比如性能会大幅下降，所以不建议使用。

tcp_tw_recycle：顾名思义就是回收TIME_WAIT连接。可以说这个内核参数已经变成了大众处理TIME_WAIT的万金油，如果你在网络上搜索TIME_WAIT的解决方案，十有八九会推荐设置它，不过这里隐藏着一个不易察觉的陷阱：