为什么这么设计（Why’sTHEDesign）是一系列关于计算机领域中程序设计决策的文章，我们在这个系列的每一篇文章中都会提出一个具体的问题并从不同的角度讨论这种设计的优缺点、对具体实现造成的影响。
在这个系列前面的文章中，我们已经多次讨论TCP协议的设计原理，其中包括TCP协议的三次握手、流量控制和重传机制、最大数据段以及粘包等问题。本文将继续分析TCP协议的实现细节，今天要分析的问题是为什么TCP协议需要TIME_WAIT状态以及该状态的作用究竟是什么。
TCP协议中包含11种不同的状态，TCP连接会根据发送或者接收到的消息转换状态，如下图所示的状态机展示了所有可能的转换，其中不仅包含了正常情况下的状态转换过程，还包含了异常状态下的状态转换：
图1-TCP协议状态
使用TCP协议通信的双方会在关闭连接时触发TIME_WAIT状态，关闭连接的操作其实是告诉通信的另一方自己没有需要发送的数据，但是它仍然保持了接收对方数据的能力，一个常见的关闭连接过程如下[^1]：
当客户端没有待发送的数据时，它会向服务端发送FIN消息，发送消息后会进入FIN_WAIT_1状态；服务端接收到客户端的FIN消息后，会进入CLOSE_WAIT状态并向客户端发送ACK消息，客户端接收到ACK消息时会进入FIN_WAIT_2状态；当服务端没有待发送的数据时，服务端会向客户端发送FIN消息；客户端接收到FIN消息后，会进入TIME_WAIT状态并向服务端发送ACK消息，服务端收到后会进入CLOSED状态；客户端等待两个最大数据段生命周期（Maximumsegmentlifetime，MSL）[^2]的时间后也会进入CLOSED状态；
图2-TCP关闭连接的过程
从上述过程中，我们会发现TIME_WAIT仅在主动断开连接的一方出现，被动断开连接的一方会直接进入CLOSED状态，进入TIME_WAIT的客户端需要等待2MSL才可以真正关闭连接。TCP协议需要TIME_WAIT状态的原因和客户端需要等待两个MSL不能直接进入CLOSED状态的原因是一样的[^3]：
防止延迟的数据段被其他使用相同源地址、源端口、目的地址以及目的端口的TCP连接收到；保证TCP连接的远程被正确关闭，即等待被动关闭连接的一方收到FIN对应的ACK消息；上述两个原因都相对比较简单，我们来展开介绍这两个原因背后可能存在的一些问题。
阻止延迟数据段
每一个TCP数据段都包含唯一的序列号，这个序列号能够保证TCP协议的可靠性和顺序性，在不考虑序列号溢出归零的情况下，序列号唯一是TCP协议中的重要约定，一旦违反了这条规则，就可能造成令人困惑的现象和结果。为了保证新TCP连接的数据段不会与还在网络中传输的历史连接的数据段重复，TCP连接在分配新的序列号之前需要至少静默数据段在网络中能够存活的最长时间，即MSL[^4]：
TobesurethataTCPdoesnotcreateasegmentthatcarriesasequencenumberwhichmaybeduplicatedbyanoldsegmentremaininginthenetwork,theTCPmustkeepquietforamaximumsegmentlifetime(MSL)beforeassigninganysequencenumbersuponstartinguporrecoveringfromacrashinwhichmemoryofsequencenumbersinusewaslost.
图3-TIME-WAIT较短导致的数据段延迟接收
在如上图所示的TCP连接中，服务端发送的SEQ=消息由于网络延迟直到TCP连接关闭后也没有收到；当使用相同端口号的TCP连接被重用后，SEQ=的消息才发送到客户端，然而这个过期的消息却可能被客户端正常接收，这就会带来比较严重的问题，所以我们在调整TIME_WAIT策略时要非常谨慎，必须清楚自己在干什么。
RFC中虽然指出了TCP连接需要在TIME_WAIT中等待2倍的MSL，但是并没有解释清楚这里的两倍是从何而来，比较合理的解释是—网络中可能存在来自发起方的数据段，当这些发起方的数据段被服务端处理后又会向客户端发送响应，所以一来一回需要等待2倍的时间[^5]。
RFC文档将MSL的时间设置为秒，即两分钟，然而这并不是一个经过严密推断的数值，而是工程上的选择，如果根据服务历史上的经验要求我们改变操作系统的设置，也是没有任何问题的；实际上，较早版本的Linux就开始将TIME_WAIT的等待时间TCP_TIMEWAIT_LEN设置成60秒，以便更快地复用TCP连接资源：
#defineTCP_TIMEWAIT_LEN(60*HZ)/*howlongtowaittodestroyTIME-WAIT *state,about60seconds */在Linux上，客户端的可以使用端口号32,~61,，总共28,个端口号与远程服务器建立连接，应用程序可以在将近3万的端口号中任意选择一个：
$sysctlnet.ipv4.ip_local_port_rangenet.ipv4.ip_local_port_range=3261但是如果主机在过去一分钟时间内创建的TCP连接数超过28,，那么再创建新的TCP连接就会发生错误，也就是说如果我们不调整主机的配置，那么每秒能够建立的最大TCP连接数为~[^6]。
保证连接关闭
从RFC对TIME_WAIT状态的定义中，我们可以发现该状态的另一个重要作用，等待足够长的时间以确定远程的TCP连接接收到了其发出的终止连接消息FIN对应的ACK：
TIME-WAIT-representswaitingforenoughtimetopasstobesuretheremoteTCPreceivedtheacknowledgmentofitsconnectionterminationrequest.
如果客户端等待的时间不够长，当服务端还没有收到ACK消息时，客户端就重新与服务端建立TCP连接就会造成以下问题—服务端因为没有收到ACK消息，所以仍然认为当前连接是合法的，客户端重新发送SYN消息请求握手时会收到服务端的RST消息，连接建立的过程就会被终止。
图4-TIME-WAIT较短导致的握手终止
在默认情况下，如果客户端等待足够长的时间就会遇到以下两种情况：
服务端正常收到了ACK消息并关闭当前TCP连接；服务端没有收到ACK消息，重新发送FIN关闭连接并等待新的ACK消息；只要客户端等待2MSL的时间，客户端和服务端之间的连接就会正常关闭，新创建的TCP连接收到影响的概率也微乎其微，保证了数据传输的可靠性。
总结
在某些场景下，60秒的等待销毁时间确实是难以接受的，例如：高并发的压力测试。当我们通过并发请求测试远程服务的吞吐量和延迟时，本地就可能产生大量处于TIME_WAIT状态的TCP连接，在macOS上可以使用如下所示的命令查看活跃的连接：
$netstat-tanActiveInternetconnections(includingservers)ProtoRecv-QSend-QLocalAddressForeignAddress(state)tcp..50...95.49..TIME_WAITtcp..50...95.49..TIME_WAIT...tcp..50....32..TIME_WAITtcp..50....32..TIME_WAITtcp..50....32..TIME_WAIT...当我们在主机上通过几千个并发来测试服务器的压力时，这些用于压力测试的连接会迅速消耗主机上的TCP连接资源，几乎所有的TCP都会处于TIME_WAIT状态等待销毁。如果我们真遇到不得不处理单机上的TIME_WAIT状态的时候，那么可以通过以下几种方法处理：
使用SO_LINGER选项并设置暂存时间l_linger为0，在这时如果我们关闭TCP连接，内核就会直接丢弃缓冲区中的全部数据并向服务端发送RST消息直接终止当前的连接[^7]；使用net.ipv4.tcp_tw_reuse选项，通过TCP的时间戳选项允许内核重用处于TIME_WAIT状态的TCP连接[^8]；修改net.ipv4.ip_local_port_range选项中的可用端口范围，增加可同时存在的TCP连接数上限；需要注意的是，另一个常见的TCP配置项net.ipv4.tcp_tw_recycle已经在Linux4.12中移除[^9]，所以我们不能再通过该配置解决TIME_WAIT设计带来的问题。
TCP的TIME_WAIT状态有着非常重要的作用，它是保证TCP协议可靠性不可缺失的设计，如果能通过加机器解决的话就尽量加机器，如果不能解决的话，我们就需要理解其背后的设计原理并尽可能避免修改默认的配置，就像Linux手册中说的一样，在修改这些配置时应该咨询技术专家的建议；在这里，我们再重新回顾一下TCP协议中TIME_WAIT状态存在的原因，如果客户端等待的时间不够长，那么使用相同端口号重新与远程建立连接时会造成以下问题：
因为数据段的网络传输时间不确定，所以可能会收到上一次TCP连接中未被收到的数据段；因为客户端发出的ACK可能还没有被服务端接收，服务端可能还处于LAST_ACK状态，所以它会回复RST消息终止新连接的建立；TIME_WAIT状态是TCP与不确定的网络延迟斗争的结果，而不确定性是TCP协议在保证可靠这条路的最大阻碍。到最后，我们还是来看一些比较开放的相关问题，有兴趣的读者可以仔细思考一下下面的问题：
net.ipv4.tcp_tw_reuse配置如何通过时间戳保证重用TCP连接的相对安全？net.ipv4.tcp_tw_recycle配置为什么被Linux从协议栈中移除？如果对文章中的内容有疑问或者想要了解更多软件工程上一些设计决策背后的原因，可以在博客下面留言，作者会及时回复本文相关的疑问并选择其中合适的主题作为后续的内容。
相关文章
为什么TCP协议有粘包问题为什么TCP建立连接需要三次握手为什么TCP/IP协议会拆分数据参考资料
[^1]:3.5.ClosingaConnection·TransmissionControlProtocolRFC