TIME_WAIT状态

TIME_WAIT 定义：

TCP 连接终止时，主机 1 先发送 FIN 报文，主机 2 进入 CLOSE_WAIT 状态，并发送一个 ACK 应答，同时，主机 2 通过 read 调用获得 EOF，并将此结果通知应用程序进行主动关闭操作，发送 FIN 报文。主机 1 在接收到 FIN 报文后发送 ACK 应答，此时主机 1 进入 TIME_WAIT 状态。

TIME_WAIT状态的存在主要基于两个目的：

1、实现可靠的连接终止。

2、让老的重复的报文段在网络中过期失效，这样在建立新的连接的时将不在接收他们。

举例说明：

TCP 在设计的时候，做了充分的容错性设计，比如，TCP 假设报文会出错，需要重传。在这里，如果图中主机 1 的 ACK 报文没有传输成功，那么主机 2 就会重新发送 FIN 报文。如果主机 1 没有维护 TIME_WAIT 状态，而直接进入 CLOSED 状态，它就失去了当前状态的上下文，只能回复一个 RST 操作，从而导致被动关闭方出现错误（上图例子中的主机2）。

现在主机 1 知道自己处于 TIME_WAIT 的状态，就可以在接收到 FIN 报文之后，重新发出一个 ACK 报文，使得主机 2 可以进入正常的 CLOSED 状态。

TIME_WAIT 状态区别于其他状态的地方在于：导致从改状态迁移到其他状态（到CLOSED状态）的事件是超时。这个超时时间为2倍的MSL（2MSL），这里的MSL（报文最大生存时间）是TCP报文在网络中的最大生存时间。

TIME_WAIT 的危害：过多的 TIME_WAIT 的主要危害有两种。

第一是内存资源占用，这个目前看来不是太严重，基本可以忽略。

第二是对端口资源的占用，一个 TCP 连接至少消耗一个本地端口。要知道，端口资源也是有限的，一般可以开启的端口为 32768～61000 ，也可以通过net.ipv4.ip_local_port_range指定，如果 TIME_WAIT 状态过多，会导致无法创建新连接。这个也是我们在一开始讲到的那个例子。

如何优化 TIME_WAIT？

在高并发的情况下，如果我们想对 TIME_WAIT 做一些优化，来解决我们一开始提到的例子，该如何办呢？

net.ipv4.tcp_tw_reuse：更安全的设置

当然有。这就是net.ipv4.tcp_tw_reuse选项。

Linux 系统对于net.ipv4.tcp_tw_reuse的解释如下:

Allow to reuse TIME-WAIT sockets for new connections when it is safe from protocol viewpoint. Default value is 0.It should not be changed without advice/request of technical experts.

这段话的大意是从协议角度理解如果是安全可控的，可以复用处于 TIME_WAIT 的套接字为新的连接所用。

那么什么是协议角度理解的安全可控呢？主要有两点：

1、只适用于连接发起方（C/S 模型中的客户端）；

2、对应的 TIME_WAIT 状态的连接创建时间超过 1 秒才可以被复用。

使用这个选项，还有一个前提，需要打开对 TCP 时间戳的支持，即net.ipv4.tcp_timestamps=1（默认即为 1）。

总结：

在今天的内容里，我讲了 TCP 的四次挥手，重点对 TIME_WAIT 的产生、作用以及优化进行了讲解，你需要记住以下三点：

1、TIME_WAIT 的引入是为了让 TCP 报文得以自然消失，同时为了让被动关闭方能够正常关闭；

2、不要试图使用SO_LINGER设置套接字选项，跳过 TIME_WAIT；

3、现代 Linux 系统引入了更安全可控的方案，可以帮助我们尽可能地复用 TIME_WAIT 状态的连接。

思考题

最后按照惯例，我留两道思考题，供你消化今天的内容。

1、最大分组 MSL 是 TCP 分组在网络中存活的最长时间，你知道这个最长时间是如何达成的？换句话说，是怎么样的机制，可以保证在 MSL 达到之后，报文就自然消亡了呢？

2、RFC 1323 引入了 TCP 时间戳，那么这需要在发送方和接收方之间定义一个统一的时钟吗？

   不需要统一时钟，可以在第一次交换双方的时钟，之后用相对时间就可以了。