TCP 三次握手，第二次握手报文丢失会发生什么？

TCP 三次握手，第一次握手报文丢失会发生什么？

服务端收到客户端的 SYN 报文后，会回给客户端 SYN+ACK 报文

第二次握手的 SYN+ACK 报文其实有两个目的：

• 第二次握手中的 ACK，是对第一次握手的确认报文
• 第二次握手中的 SYN，是服务端请求建立 TCP 连接的报文

如果第二次握手报文丢失了：

• 客户端
  因为第二次握手包含对第一次握手的确认报文，如果客户端迟迟收不到第二次握手报文，客户端就会觉得自己的 SYN 报文丢失了，于是触发「超时重传」机制，重新发送 SYN 报文
• 服务端
  因为第二次握手包含服务端请求建立 TCP 连接的 SYN 报文，客户端收到后会回给服务端 ACK 报文，如果第二次握手报文丢失了，服务端也就收不到第三次握手报文，于是就会触发「超时重传」机制，重新发送 SYN+ACK 报文

下图以 Linux(6.14.7) TCP 第二次握手报文丢失为例，其中参数 tcp_syn_retries 值为 2， tcp_synack_retries 参数值为 3

上图没有体现出服务端收到客户端两次重传的 SYN 报文后回复 SYN+ACK 报文的过程，我们抓包看下，验证环境上 tcp_syn_retries 和 tcp_synack_retries 值均为 5

RTO(Retransmission Timeout)

TCP 重传超时时间

注意

• Linux(6.14.7) RTO 初始值为 1s
• Linux(6.14.7) RTO 最大值为 120s

/* Linux Kernel 6.14.7 tcp.h */
#define TCP_RTO_MAX	((unsigned)(120*HZ))
#define TCP_RTO_MIN	((unsigned)(HZ/5))

#define TCP_TIMEOUT_INIT ((unsigned)(1*HZ))	/* RFC6298 2.1 initial RTO value	*/
#define TCP_TIMEOUT_FALLBACK ((unsigned)(3*HZ))	/* RFC 1122 initial RTO value, now
						 * used as a fallback RTO for the
						 * initial data transmission if no
						 * valid RTT sample has been acquired,
						 * most likely due to retrans in 3WHS.
						 */

TCP 三次握手，第三次握手报文丢失会发生什么？