TCP连接的状态与关闭方式，及其对Server与Client的影响

转自: 最初的幸福ever

原文地址: https://www.cnblogs.com/fczjuever/archive/2013/04/05/3000680.html

 

1. TCP连接的状态

　　首先介绍一下TCP连接建立与关闭过程中的状态。TCP连接过程是状态的转换，促使状态发生转换的因素包括用户调用、特定数据包以及超时等，具体状态如下所示：

• CLOSED：初始状态，表示没有任何连接。
• LISTEN：Server端的某个Socket正在监听来自远方的TCP端口的连接请求。
• SYN_SENT：发送连接请求后等待确认信息。当客户端Socket进行Connect连接时，会首先发送SYN包，随即进入SYN_SENT状态，然后等待Server端发送三次握手中的第2个包。
• SYN_RECEIVED：收到一个连接请求后回送确认信息和对等的连接请求，然后等待确认信息。通常是建立TCP连接的三次握手过程中的一个中间状态，表示Server端的Socket接收到来自Client的SYN包，并作出回应。
• ESTABLISHED：表示连接已经建立，可以进行数据传输。
• FIN_WAIT_1：主动关闭连接的一方等待对方返回ACK包。若Socket在ESTABLISHED状态下主动关闭连接并向对方发送FIN包（表示己方不再有数据需要发送），则进入FIN_WAIT_1状态，等待对方返回ACK包，此后还能读取数据，但不能发送数据。在正常情况下，无论对方处于何种状态，都应该马上返回ACK包，所以FIN_WAIT_1状态一般很难见到。
• FIN_WAIT_2：主动关闭连接的一方收到对方返回的ACK包后，等待对方发送FIN包。处于FIN_WAIT_1状态下的Socket收到了对方返回的ACK包后，便进入FIN_WAIT_2状态。由于FIN_WAIT_2状态下的Socket需要等待对方发送的FIN包，所有常常可以看到。若在FIN_WAIT_1状态下收到对方发送的同时带有FIN和ACK的包时，则直接进入TIME_WAIT状态，无须经过FIN_WAIT_2状态。
• TIME_WAIT：主动关闭连接的一方收到对方发送的FIN包后返回ACK包（表示对方也不再有数据需要发送，此后不能再读取或发送数据），然后等待足够长的时间（2MSL）以确保对方接收到ACK包（考虑到丢失ACK包的可能和迷路重复数据包的影响），最后回到CLOSED状态，释放网络资源。
• CLOSE_WAIT：表示被动关闭连接的一方在等待关闭连接。当收到对方发送的FIN包后（表示对方不再有数据需要发送），相应的返回ACK包，然后进入CLOSE_WAIT状态。在该状态下，若己方还有数据未发送，则可以继续向对方进行发送，但不能再读取数据，直到数据发送完毕。
• LAST_ACK：被动关闭连接的一方在CLOSE_WAIT状态下完成数据的发送后便可向对方发送FIN包（表示己方不再有数据需要发送），然后等待对方返回ACK包。收到ACK包后便回到CLOSED状态，释放网络资源。
• CLOSING：比较罕见的例外状态。正常情况下，发送FIN包后应该先收到（或同时收到）对方的ACK包，再收到对方的FIN包，而CLOSING状态表示发送FIN包后并没有收到对方的ACK包，却已收到了对方的FIN包。有两种情况可能导致这种状态：其一，如果双方几乎在同时关闭连接，那么就可能出现双方同时发送FIN包的情况；其二，如果ACK包丢失而对方的FIN包很快发出，也会出现FIN先于ACK到达。

　　TCP连接的状态转换如下图所示

 

 

2. TCP连接的关闭方式

　　建立TCP连接需要三次握手，而关闭连接则需要四次握手，并且分为主动关闭和被动关闭。这是由于TCP连接是全双工的，我关了你的连接，并不等于你关了我的连接，因此双方都必须单独进行关闭。当一方完成它的数据发送任务后可以发送FIN包来终止这个方向的连接，表明自己不再有数据需要发送；收到FIN包的那一方虽然不能再读取数据，但仍能发送数据。以Client主动关闭连接为例：

1. Client向Server发送FIN包，表示Client主动关闭连接，然后进入FIN_WAIT_1状态，等待Server返回ACK包。此后Client不能再向Server发送数据，但能读取数据。
2. Server收到FIN包后向Client发送ACK包，然后进入CLOSE_WAIT状态，此后Server不能再读取数据，但可以继续向Client发送数据。Client收到Server返回的ACK包后进入FIN_WAIT_2状态，等待Server发送FIN包。
3. Server完成数据的发送后，将FIN包发送给Client，然后进入LAST_ACK状态，等待Client返回ACK包，此后Server既不能读取数据，也不能发送数据。
4. Client收到FIN包后向Server发送ACK包，然后进入TIME_WAIT状态，接着等待足够长的时间（2MSL）以确保Server接收到ACK包，最后回到CLOSED状态，释放网络资源。Server收到Client返回的ACK包后便回到CLOSED状态，释放网络资源。

　　TCP连接的建立到关闭，需要经历以下状态迁移（假定Client发起连接，并主动关闭连接）：

• Client

　　CLOSED -> SYN_SENT -> ESTABLISHED -> FIN_WAIT_1 -> FIN_WAIT_2 -> TIME_WAIT -> CLOSED

• Server

　　CLODES -> LISTEN -> SYN_RECEIVED -> ESTABLISHED -> CLOSE_WAIT -> LAST_ACK -> CLOSED

3. 对Server与Client的影响

　　在详细了解TCP连接的状态和关闭方式后，我们会发现TIME_WAIT状态是一个坑爹的存在！主动关闭连接的一方在发送最后一个ACK包后，无论对方是否收到都会进入TIME_WAIT状态，等待2MSL的时间，然后才能释放网络资源。MSL就是Maximum Segment Lifetime（数据包的最大生命周期），是一个数据包能在互联网上生存的最长时间，若超过这个时间则该数据包将会消失在网络中。操作系统通常会将2MSL设为4分钟，最低不少于30秒，因而TIME_WAIT状态一般维持在30秒至4分钟。这个是TCP/IP协议必不可少的，是TCP/IP设计者设计的，也就是无法解决的。TIME_WAIT状态的存在主要有两个原因：

1. 可靠地实现TCP全双工连接的终止。在关TCP闭连接时，最后的ACK包是由主动关闭方发出的，如果这个ACK包丢失，则被动关闭方将重发FIN包，因此主动方必须维护状态信息，以允许它重发这个ACK包。如果不维持这个状态信息，那么主动方将回到CLOSED状态，并对被动方重发的FIN包响应RST包，而被动关闭方将此包解释成一个错误（在Java中会抛出connection reset的SocketException)。因而，要实现TCP全双工连接的正常终止，必须能够处理四次握手协议中任意一个包丢失的情况，主动关闭方必须维持状态信息进入TIME_WAIT状态。
2. 确保迷路重复数据包在网络中消失，防止上一次连接中的包迷路后重新出现，影响新连接。TCP数据包可能由于路由器异常而迷路，在迷路期间，数据包发送方可能因超时而重发这个包，迷路的数据包在路由器恢复后也会被送到目的地，这个迷路的数据包就称为Lost Duplicate。在关闭一个TCP连接后，如果马上使用相同的IP地址和端口建立新的TCP连接，那么有可能出现前一个连接的迷路重复数据包在前一个连接关闭后再次出现，影响新建立的连接。为了避免这一情况，TCP协议不允许使用处于TIME_WAIT状态的连接的IP和端口启动一个新连接，只有经过2MSL的时间，确保上一次连接中所有的迷路重复数据包都已消失在网络中，才能安全地建立新连接。

　　对于Client而言，每个连接都需要占用一个端口，而系统允许的可用端口数不足65000个（这也是在TCP参数优化后才能达到）。因此，如果Client发起过多的连接并主动关闭（假设没有重用端口或者连接多个Server），就会有大量的连接在关闭后处于TIME_WAIT状态，等待2MSL的时间后才能释放网络资源（包括端口），于是Client会由于缺少可用端口而无法新建连接。

　　对Server而言（特别是处理高并发短连接的Server），Server端与Client建立的连接是使用同一个端口的，即监听的端口，每个连接通过一个五元组区分，包括源IP地址、源端口、传输层协议号（协议类型）、目的IP地址、目的端口，因而在理论上，Server不受系统端口数的限制。但是，Server对每个端口上的连接数是有限制的，它要使用哈希表记录端口上的每个连接，并受到文件描述符的最大打开数的限制。所以，如果Server主动关闭连接，同样会有大量的连接在关闭后处于TIME_WAIT状态，等待2MSL的时间后才能释放网络资源（包括哈希表上的连接记录和文件描述符），于是Server会由于达到哈希表和文件描述符的限制而无法接受新连接，造成性能的急剧下滑，性能曲线会持续产生严重的波动。对于这种情况，有三种应对方式：

1. 试图让Client主动关闭连接，由于每个Client的并发量都比较低，因而不会产生性能瓶颈。
2. 优化Server的系统TCP参数，使其网络资源的最大值、消耗速度和恢复速度达到平衡。
3. 改写TCP协议，重新实现底层代码，不过该方式难度很大，而且系统的稳定性和安全性可能受到影响。