TCP 三次握手四次挥手
2019-10-09 本文已影响0人
allenhaozi




四次挥手:
Client: 主动断开连接
Server: 被动断开连接
-
Client完成数据发送之后, 发送FIN给Server, Client进入 FIN_WAIT_1
-
Server收到FIN后, 回送ACK给Client, Server进入CLOSE-WAIT
-
Client收到B发送的ACK 进入 FIN_WAIT_2
此时处于半关闭, Server人仍然可以给Client发送数据 -
Server发送完数据, 发送FIN给Client Server进入LAST_ACK
-
Client收到FIN 回送ACK 自己进入TIME_WAIT 经过2MSL时间
-
Server收到Client的ACK 进入CLOSE
TIME_WAIT为什么要等2个MSL
-
为了保证客户端发送的最后一个ACK报文段能够到达服务器端
-
这个ACK报文段有可能丢失
- 因而使处在LASK—ACK端的服务器端收不到对已发送的FIN+ACK报文段。
- 会超时重传这个FIN+ACK报文段,而A就能在2MSL时间内收到这个重传的FIN+ACK报文段。
- 接着A重传一次确认,重新启动2MSL计时器。最后,A和B都正常进入到CLOSED状态。
-
如果CLIENT在TIME_WAIT状态不等待一段时间,而是在发送完ACK确认后立即释放连接,那么就无法收到B重传的FIN+ACK报文段,因而也不会再发送一次确认报文段,这样,B就无法正常进入CLOSED状态。