TCP使用4次挥手释放连接
- 起初是连接已建立的状态
- 第一次挥手:客户端发起TCP连接释放请求报文,进入
终止等待1状态
FIN=1 ACK=1 seq=u ack=v...
表示释放连接,ACK=1
表示这也是一个回复确认报文,回复确认了之前的数据传输报文
- 第二次挥手:服务器对客户端的请求进行回复确认,进入
关闭等待状态
然后通知应用程序,让应用程序发送还没发完的数据ACK=1 seq=v ack=u+1...
表示对请求的确认,因为FIN=1
的报文不携带数据但是消耗一个序号,所以ack=u+1
- 第三次挥手:服务器那边的应用程序将数据发送完后,服务器发送TCP连接释放请求,进入
最后确认状态
FIN=1 ACK=1 seq=w ack=u+1...
表示释放连接,ACK=1
表明是一个回复确认报文,其实是对第一次挥手的重复确认,ack=u+1
也印证了这一点
- 第四次挥手:客户端对服务器的请求进行回复确认,进入
时间等待状态
,等到2个MSL后自动进入关闭状态
ACK=1 seq=u+1 ack=w+1...
表示客户端对请求的回复,ACK=1
,表明这是一个回复请求报文,其实这就是一个普通的不携带数据的确认报文
- 服务端收到确认后,进入
关闭状态
问题:为什么客户端在第四次挥手之后还进入了时间等待状态,需要等待两个MSL才进入关闭状态?取消这个等待可以吗?
回答:不可以!原因有二,如下所述:
-
在没有时间等待状态情况下,如果客户端的第四次挥手报文在网络中丢失了,那么服务器将不断超时重传TCP连接断开请求,并一直处于
最后确认状态
,无法进入关闭状态;如果有了2MSL的时间等待,假如客户端的第四次挥手丢失,服务端因为接收不到响应,就会进行重传,此时客户端的连接还没关闭,就可以再次发送第4次挥手确认报文,让服务端顺利进入关闭状态
,如下图所示:
-
2个MSL之后,本次连接产生的所有网络包都会从网络中消失,使下次TCP连接中不会有旧的网络包
- 为什么会消失?哈哈哈,因为MSL就是最长报文寿命啊!