四次挥手详解
文章目录
- 一、四次挥手各状态
- FIN_WAIT_1
- CLOSE_WAIT
- FIN_WAIT_2
- LAST_ACK
- TIME_WAIT
- CLOSE
- 二、双方同时调用close(),FIN_WAIT_1状态后进入CLOSING状态
- CLOSING状态
- 三、TIME_WAIT状态详解
- (1) TIME_WAIT状态下的2MSL是什么
- MSL (报文最大生存时间)
- 为什么TIME__WAIT状态必须停留两倍MSL时间
- (2) TIME_WAIT存在的意义
- (3) 为什么会出现大量的TIME_WAIT状态
- (4) TIME_WAIT状态的影响
- 解决方法
- 四、HTTP中一般服务端是请求断开方
由于TCP连接是全双工的,因此每个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动,一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭,而另一方执行被动关闭。
一、四次挥手各状态
FIN_WAIT_1
当主动关闭方在ESTABLISHED状态时发送一个FIN,用来关闭数据传送,此时即进入到FIN_WAIT_1状态。
CLOSE_WAIT
处于ESTABILSHED状态的服务器收到FIN包,将发回一个ACK,确认序号为收到的序号加1。
CLOSE_WAIT: 这种状态表示在等待关闭。当对方发送FIN报文给自己,系统会回应一个ACK报文给对方,此时则进入到CLOSE_WAIT状态。如果还有数据发送给对方则可以在数据发送结束后再发送FIN报文来结束连接,所以这个状态是被断开方再等待自己数据发送结束后断开连接
FIN_WAIT_2
处于FIN_WAIT_1状态时,当接收到对方回应的ACK报文后,则进入到FIN_WAIT_2状态
LAST_ACK
被动关闭一方在发送FIN报文后,最后等待对方的ACK报文期间处于LAST_ACK状态
TIME_WAIT
time_wait 是「主动关闭 TCP 连接」一方的状态,可能是==「客服端」的,也可能是「服务器端」==的;
当TCP的一端发起主动关闭(收到 FIN 请求),即第3次握 手完成后,发送了第四次握手的ACK包后(最后的 ACK 是由「主动关闭连接」的一端发出的),就进入了TIME_WAIT状态。
CLOSE
当被动方收到ACK报文后,也即可以进入到CLOSED可用状态了。
二、双方同时调用close(),FIN_WAIT_1状态后进入CLOSING状态
CLOSING状态
CLOSING: 当发送FIN报文后进入fin_wait_1状态,过后并没有收到对方的ACK报文,反而也收到了对方的FIN报文。就是双方几乎在同时close一个SOCKET,然后就出现了双方同时发送FIN报文的情况,表示双方都正在关闭SOCKET连接。
closing状态收到ack报文以后即直接进入time_wait状态
三、TIME_WAIT状态详解
(1) TIME_WAIT状态下的2MSL是什么
MSL (报文最大生存时间)
任何报文在网络上存在的最长时间,超过这个时间报文将被丢弃。(IP 报文)
RFC 793中规定MSL为2分钟,实际应用中常用的是30秒,1分钟和2分钟等。
为什么TIME__WAIT状态必须停留两倍MSL时间
等待2MSL时间主要目的是怕最后一个 ACK包对方没收到,那么对方在超时后将重发第三次握手的FIN包,主动关闭端接到重发的FIN包后,可以再发一个ACK应答包。
当连接处于2MSL等待阶段时,任何迟到的报文段都将被丢弃。
(2) TIME_WAIT存在的意义
可靠的实现 TCP 全双工连接的终止:
四次挥手关闭 TCP 连接过程中,最后的 ACK 是由「主动关闭连接」的一端发出的,如果这个 ACK 丢失,则,对方会重发 FIN 请求,因此,在「主动关闭连接」的一段,需要维护一个 time_wait 状态,处理对方重发的 FIN 请求;
假设发起主动关闭方发送的ACK (4次交互的最后一个包)在网络中丢失,那么由于TCP的重传机制,被动关闭方需要重发FIN(第三次挥手),在该FIN到达主动发起方之前,client必须维护这条连接的状态(尽管它已调用过close),具体而言,就是这条TCP连接对应的(源IP,源端口)资源不能被立即释放或重新分配。直到对端重发的FIN达到,client也重发ACK后,该TCP连接才能恢复初始的CLOSED状态。如果主动方不进入TIME_WAIT以维护其连接状态,则当被动方重发的FIN达到时,主动方的TCP传输层会以RST包响应对方,这会被对方认为有错误发生(而事实上,这是正常的关闭连接过程,并非异常)。
处理延迟到达的报文:
由于路由器可能抖动,TCP 报文会延迟到达,为了避免「延迟到达的 TCP 报文」被误认为是「新 TCP 连接」的数据,则,需要在允许新创建 TCP 连接之前,保持一个不可用的状态,等待所有延迟报文的消失,一般设置为 2 倍的 MSL(报文的最大生存时间),解决「延迟达到的 TCP 报文」问题。
TCP是流式的,所有包到达的顺序是不一致的,依靠序列号由TCP协议栈做顺序的拼接;假设如果一个新连接建立后旧连接的seq=1000包到达对端,可能会顶替掉新连接的seq=1000,造成错误
(3) 为什么会出现大量的TIME_WAIT状态
大量的短连接存在
TCP 四次挥手关闭连接机制中,为了保证 ACK 重发和丢弃延迟数据,设置 time_wait 为 2 倍的 MSL(报文最大存活时间)
(4) TIME_WAIT状态的影响
time_wait 状态下,TCP 连接占用的端口,无法被再次使用, 要等到2MSL时间结束,才可继续使用,而TCP 端口数量上限是 6.5w(65535,16 bit)
大量 time_wait 状态存在,会导致新建 TCP 连接会出错,address already in use : connect 异常
解决方法
- 服务器端允许 time_wait 状态的 socket 被重用
- 缩减 time_wait 时间,设置为 1 MSL(即,2 mins)
四、HTTP中一般服务端是请求断开方
在HTTP1.1协议中,有个 Connection 头,Connection有两个值,close和keep-alive,这个头就相当于客户端告诉服务端,服务端你执行完成请求之后,是关闭连接还是保持连接,保持连接就意味着在保持连接期间,只能由客户端主动断开连接。还有一个keep-alive的头,设置的值就代表了服务端保持连接保持多久。
HTTP默认的Connection值为close,那么就意味着关闭请求的一方几乎都会是由服务端这边发起的。那么这个服务端产生TIME_WAIT过多的情况就很正常了。
虽然HTTP默认Connection值为close,但是,现在的浏览器发送请求的时候一般都会设置Connection为keep-alive了。所以,也有人说,现在没有必要通过调整参数来使TIME_WAIT降低了。