关于TCP状态的一些思考
关于TCP状态的一些思考
TCP连接在整个生存期内,有一系列状态,这些状态是:LISTEN
, SYN-SEND
,SYN-RECEIVED
,ESTABLISHED
,FIN-WAIT-1
,FIN-WAIT-2
,CLOSE-WAIT
,CLOSING
,LAST-ACK
,TIME-WAIT
和CLOSED
。
LISTEN
: 表示等待TCP连接请求
SYN-SEND
: 表示在已经发送连接请求后等待匹配的连接请求。
SYN-RECEIVED
:表示在已经接收和发送连接请求后,等待一个确认连接请求ACK
。
ESTABLISHED
:表示连接已经建立,接收到的数据可以传递给用户。这个是数据传输阶段的正常状态。
FIN-WAIT-1
:表示等待远端TCP的连接终止请求,或对先前发送的连接终止请求的确认。
FIN-WAIT-2
:表示等待远端TCP的连接终止请求。
CLOSE-WAIT
: 表示等待本地用户的连接终止请求。
CLOSING
: 表示等待远端TCP的连接终止请求ACK
。
LAST-ACK
: 表示等待先前发送给远端TCP的连接终止请求的ACK
(包括其连接终止请求的ACK
)。
TIME-WAIT
:表示等待经过足够长时间以确保远端TCP收到其连接终止请求
CLOSED
: 表示连接已经断开。
关于一次正常的TCP连接与断开过程中对TCP状态的理解:
下图是通过一个完整的TCP连接与断开来更加清楚理解在这个过程中TCP连接的不同状态:
注:MSL(最大分段生存期)指明TCP报文在Internet上最长生存时间,每个具体的TCP实现都必须选择一个确定的MSL值.RFC 1122建议是2分钟,但BSD传统实现采用了30秒.TIME_WAIT 状态最大保持时间是2 * MSL,也就是1-4分钟.
为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态?
虽然双方都同意关闭连接了,而且握手的4个报文也都协调和发送完毕,按理可以直接回到CLOSED状态(就好比从SYN_SEND状态到ESTABLISH状态那样);但是因为我们必须要假想网络是不可靠的,你无法保证你最后发送的ACK报文会一定被对方收到,因此对方处于LAST_ACK状态下的SOCKET可能会因为超时未收到ACK报文,而重发FIN报文,所以这个TIME_WAIT状态的作用就是用来重发可能丢失的ACK报文,并保证于此。
在看https://tools.ietf.org/html/rfc793
文档的时候,在RFC文档中关于TCP状态还有一种情况:
在TCP状态中,会存在从FIN WAIT-1
直接到CLOSING
状态,自己思考的会不会是如下图所描述的过程:
前面的TCP三次握手那里没有什么不同的,但是在断开连接的时候,server和 client同时发送了FIN消息,那么这个时候双方的状态都会变成FIN WAIT-1
状态,而当彼此收到对方的FIN消息之后,就会发送ACK, 那么这个时候又分别进入到CLOSING状态,那么这个时候会不会双方都会进入到等待2MSL
这个状态?
没有找到相关结果
0 个回复