TCP的三次握手

59 阅读3分钟

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

三次握手

20200818230916131.png

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

image.png

第一次握手: 客户端向服务端发送连接请求报文段。该报文段中包含自身的数据通讯初始序号。请求发送后,客户端便进入 SYN-SENT 状态。

image.png

第二次握手: 服务端收到连接请求报文段后,如果同意连接,则会发送一个应答,该应答中也会包含自身的数据通讯初始序号,发送完成后便进入 SYN-RECEIVED 状态。

image.png

第三次握手: 当客户端收到连接同意的应答后,还要向服务端发送一个确认报文。客户端发完这个报文段后便进入 ESTABLISHED 状态,服务端收到这个应答后也进入 ESTABLISHED 状态,此时连接建立成功。

image.png

这些都是正常的情况,但是网络环境肯定是不稳定的。时好时坏,发送的途中,会存在丢失的情况,那么这种情况下,三次握手会是什么样的呢?

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

第一次握手丢失

如果第一次成功了,那是不是会返回 SYN-ACK 报文。这时候客户端就会知道第一次握手成功了,但是现在第一次握手丢失了,客户端无法收到 SYN-ACK 报文,就会认为可能是自己的第一次没有发送成功,所以就会触发超时重传机制,重传 SYN 报文。当达到最大重传次数如果服务端仍然没有回应 ACK,客户端就不再发送 SYN 包,断开 TCP 连接。

image.png

第二次握手丢失

如果第二次成功了,站在服务端的角度来说,应该会收到客户端的 ACK 确认报文,但是现在没有。所以服务端可能会认为自己的发送的没有成功,于是服务端这边会触发超时重传机制,重传 SYN-ACK 报文

站在客户端的角度来说,可能会认为是自己的 SYN 报文丢了,服务端没有收到,所以,第二次才迟迟没有发送,于是客户端就会触发超时重传机制,重传 SYN 报文

总结:客户端会重传 SYN 报文,服务端会重传 SYN-ACK 报文

image.png

第三次握手丢失

如果第三次成功了,对于服务端来说,应该会收到来自客户端的 ACK 报文,但是现在没有,那服务端可能会认为是自己的 ACK 确认报文没有发送成功,导致了客户端迟迟不回应。所以服务端那一方迟迟收不到这个确认报文,就会触发超时重传机制,重传 SYN-ACK 报文,直到收到第三次握手,或者达到最大重传次数。

image.png