TCP/IP状态图 && TIME_WAIT作用

摘要: TCP/IP状态图 && TIME_WAIT作用

TCP/IP状态图 && TIME_WAIT作用

在TCP/IP状态图中，有很多种的状态，它们之间有的是可以互相转换的，也就是说，从一种状态转到另一种状态，但是这种转换不是随便发送的，是要满足一定的条件。TCP/IP状态图看起来更像是自动机。下图即为TCP/IP状态。

由上图可以看出，一共有11种不同的状态。这11种状态描述如下：

CLOSED：关闭状态，没有连接活动或正在进行；

LISTEN：监听状态，服务器正在等待连接进入；

SYN_RCVD：收到一个连接请求，尚未确认；

SYN_SENT：已经发出连接请求，等待确认；

ESTABLISHED：连接建立，正常数据传输状态；

FIN_WAIT 1：（主动关闭）已经发送关闭请求，等待确认；

FIN_WAIT 2：（主动关闭）收到对方关闭确认，等待对方关闭请求；

TIME_WAIT：完成双向关闭，等待所有分组死掉；

CLOSING：双方同时尝试关闭，等待对方确认；

CLOSE_WAIT：（被动关闭）收到对方关闭请求，已经确认；

LAST_ACK：（被动关闭）等待最后一个关闭确认，并等待所有分组死掉。

在这11中状态当中，TIME_WAIT这种状态是最重要的，也是最难理解的。

1.CLOSED：起始点，在超时或者连接关闭时候进入此状态。

2.LISTEN：服务端在等待连接过来时候的状态，服务端为此要调用socket，bind，listen函数，就能进入此状态。此称为应用程序被动打开（等待客户端来连接）。

3.SYN_SENT:客户端发起连接，发送SYN给服务器端。如果服务器端不能连接，则直接进入CLOSED状态。

4.SYN_RCVD：跟3对应，服务器端接受客户端的SYN请求，服务器端由LISTEN状态进入SYN_RCVD状态。同时服务器端要回应一个ACK，同时发送一个SYN给客户端；另外一种情况，客户端在发起SYN的同时接收到服务器端得SYN请求，客户端就会由SYN_SENT到SYN_RCVD状态。

5.ESTABLISHED：服务器端和客户端在完成3次握手进入状态，说明已经可以开始传输数据了。

以上是建立连接时服务器端和客户端产生的状态转移说明。相对来说比较简单明了，如果你对三次握手比较熟悉，建立连接时的状态转移还是很容易理解。

下面，我们来看看连接关闭时候的状态转移说明，关闭需要进行4次双方的交互，还包括要处理一些善后工作（TIME_WAIT状态），注意，这里主动关闭的一方或被动关闭的一方不是指特指服务器端或者客户端，是相对于谁先发起关闭请求来说的：

6.FIN_WAIT_1:主动关闭的一方，由状态5进入此状态。具体的动作是发送FIN给对方。

7.FIN_WAIT_2:主动关闭的一方，接收到对方的FIN-ACK(即fin包的回应包)，进入此状态。

8.CLOSE_WAIT：接收到FIN以后，被动关闭的一方进入此状态。具体动作是接收到FIN，同时发送ACK。(之所以叫close_wait可以理解为被动关闭方此时正在等待上层应用发出关闭连接指令)

9.LAST_ACK：被动关闭的一方，发起关闭请求，由状态8进入此状态。具体动作是发送FIN给对方，同时在接收到ACK时进入CLOSED状态。

10.CLOSING：两边同时发起关闭请求时，会由FIN_WAIT_1进入此状态。具体动作是接收到FIN请求，同时响应一个ACK。

11.TIME_WAIT：最纠结的状态来了。从状态图上可以看出，有3个状态可以转化成它，我们一一来分析：

• a.由FIN_WAIT_2进入此状态：在双方不同时发起FIN的情况下，主动关闭的一方在完成自身发起的关闭请求后，接收到被动关闭一方的FIN后进入的状态。

• b.由CLOSING状态进入:双方同时发起关闭，都做了发起FIN的请求，同时接收到了FIN并做了ACK的情况下，由CLOSING状态进入。

• c.由FIN_WAIT_1状态进入：同时接受到FIN（对方发起），ACK（本身发起的FIN回应），与b的区别在于本身发起的FIN回应的ACK先于对方的FIN请求到达，而b是FIN先到达。这种情况概率最小。

 

 

为什么需要 TIME_WAIT 状态

假设最终的 ACK 丢失 ， server 将重发 FIN ， client 必须维护 TCP 状态信息以便可以重发最终的 ACK ，否则会发送RST ，结果 server 认为发生错误。 TCP 实现必须可靠地终止连接的两个方向 ( 全双工关闭 ) ， client 必须进 TIME_WAIT状态，因为 client 可能面临重发最终 ACK 的情形。先调用 close() 的一方会进入 TIME_WAIT 状态

 

 

为什么 TIME_WAIT 状态需要保持 2MSL 的时间

如果 TIME_WAIT 状态保持时间不足够长 ( 比如小于 2MSL) ，第一个连接就正常终止了。 第二个拥有相同相关五元组的连接出现，而第一个连接的重复报文到达，干扰了第二个连接。 TCP 实现必须防止某个连接的重复报文在连接终止后出现，所以让 TIME_WAIT 状态保持时间足够长 (2MSL) ，连接相应方向上的 TCP 报文要么完全响应完毕，要么被丢弃。建立第二个连接的时候，不会混淆。

 

根据《TCP/IP详解》中的TCP的建立和终止中有关"TCP的终止"的讲解

TCP的终止通过双方的四次握手实现。发起终止的一方执行主动关闭，响应的另一方执行被动关闭。

发起方更改状态为FIN_WAIT_1，关闭应用程序进程，发出一个TCP的FIN段；

接收方收到FIN段，返回一个带确认序号的ACK，同时向自己对应的进程发送一个文件结束符EOF，同时更改状态为CLOSE_WAIT，发起方接到 ACK后状态更改为FIN_WAIT_2；

接收方关闭应用程序进程，更改状态为LAST_ACK，并向对方发出一个TCP的FIN段；

发起方接到FIN后状态更改为TIME_WAIT，并发出这个FIN的ACK确认。ACK发送成功后(2MSL内)双方TCP状态变为CLOSED。

我们不难看出上面的显示的结果的意思。根据TCP协议，主动发起关闭的一方，会进入TIME_WAIT状态(TCP实现必须可靠地终止连接的两个方向(全双工关闭))，持续2*MSL (Max Segment Lifetime)，缺省为240秒。

 

 

TIME_WAIT状态的作用

主动关闭的Socket端会进入TIME_WAIT状态，并且持续2MSL时间长度，MSL就是maximum segment lifetime(最大分节生命期），这是一个IP数据包能在互联网上生存的最长时间，超过这个时间将在网络中消失。MSL在RFC 1122上建议是2分钟，而源自berkeley的TCP实现传统上使用30秒，因而，TIME_WAIT状态一般维持在1-4分钟。

 

 

TIME_WAIT状态存在的理由

1）可靠地实现TCP全双工连接的终止

在进行关闭连接四路握手协议时，最后的ACK是由主动关闭端发出的，如果这个最终的ACK丢失，服务器将重发最终的FIN，因此客户端必须维护状态信息允 许它重发最终的ACK。如果不维持这个状态信息，那么客户端将响应RST分节，服务器将此分节解释成一个错误（在java中会抛出connection reset的SocketException)。因而，要实现TCP全双工连接的正常终止，必须处理终止序列四个分节中任何一个分节的丢失情况，主动关闭 的客户端必须维持状态信息进入TIME_WAIT状态。

2）允许老的重复分节在网络中消逝

TCP分节可能由于路由器异常而“迷途”，在迷途期间，TCP发送端可能因确认超时而重发这个分节，迷途的分节在路由器修复后也会被送到最终目的地，这个 原来的迷途分节就称为lost duplicate。在关闭一个TCP连接后，马上又重新建立起一个相同的IP地址和端口之间的TCP连接，后一个连接被称为前一个连接的化身 （incarnation)，那么有可能出现这种情况，前一个连接的迷途重复分组在前一个连接终止后出现，从而被误解成从属于新的化身。为了避免这个情 况，TCP不允许处于TIME_WAIT状态的连接启动一个新的化身，因为TIME_WAIT状态持续2MSL，就可以保证当成功建立一个TCP连接的时 候，来自连接先前化身的重复分组已经在网络中消逝。

本博客文章除特别声明，全部都是原创！

尊重原创，转载请注明： 转载自过往记忆（http://www.iteblog.com/）

本文链接地址: 《TCP/IP状态图的TIME_WAIT作用》（http://www.iteblog.com/archives/169）

参考：http://www.cricode.com/3568.html

 

https://my.oschina.net/xinxingegeya/blog/483922