TCP的四次分手

136 阅读2分钟

开启掘金成长之旅!这是我参与「掘金日新计划 · 2 月更文挑战」的第 3 天,点击查看活动详情

四次分手

20200818231248103.png

很经典,有木有,记不住,没关系,打开 excalidraw

image.png

第一次挥手: 若客户端认为数据发送完成,则它需要向服务端发送连接释放请求,客户端处于 FIN_WAIT1 状态。

图片.png

第二次挥手:服务端收到连接释放请求后,会发送 ACK 确认报文,并进入 CLOSE_WAIT 状态,此时表明客户端到服务端的连接已经释放,不再接收客户端发的数据了。客户端接收到服务端的确认报文之后,进入 FIN_WAIT_2 状态。但是因为 TCP 连接是双向的,所以服务端仍旧可以发送数据给客户端。

图片.png

第三次挥手:服务端如果此时还有没发完的数据会继续发送,发送结束之后,会向客户端发送连接释放请求,然后服务端便进入 LAST-ACK 状态。

图片.png

  • 第四次挥手: 客户端收到释放请求后,向服务端发送确认应答,此时客户端进入 TIME-WAIT 状态。该状态会持续 2MSL 时间,若该时间段内没有服务端的重发请求的话,就进入 CLOSED 状态。当服务端收到确认应答后,也便进入 CLOSED 状态。

图片.png

以下文章参考:xiaolincoding.com/network/3_t…

第一次挥手丢失

如果第一次挥手成功了,那么客户端会收到来自服务端的 ACK 确认报文。当客户端收不到时,可能会认为是自己的 FIN 报文丢失,于是触发超时重传机制,重传 FIN 报文。当客户端重传 FIN 报文的次数超过规定次数后,就不再发送 FIN 报文。等待一段时间后,如果还是没能收到第二次挥手,那么直接进入到 close 状态。

image.png

第二次挥手丢失

ACK 报文是不会重传的,所以如果服务端的第二次挥手丢失了,客户端会认为可能是自己的 FIN 报文丢失,于是客户端就会触发超时重传机制,重传 FIN 报文,直到收到服务端的第二次挥手,或者达到最大的重传次数。

image.png

第三次挥手丢失

如果第三次成功,服务端会收到来自,客户端的 ACK 确认报文,但是现在没有,服务端可能会认为是自己的 FIN 报文没有到达,于是服务端就会重发 FIN 报文

image.png

第四次挥手丢失

如果第四次挥手的 ACK 报文没有到达服务端,服务端就会重发 FIN 报文

image.png