解析字节一面：TCP 次握手，问的好细！2022/12/27 8:07:52

哦不明白

TCP次握手中，客户端收到的第二次握手中确认号不是自己期望的，会发生什么是直接丢弃回RST报文大家好，我是小林。icp备案查询的相关资讯可以到我们网站了解一下，从专业角度出发为您解答相关问题，给您优质的服务！

有位读者在面试字节时，被问到这么个问题：



概括起来，是这两个问题：

TCP次握手中，客户端收到的第二次握手中确认号不是自己期望的，会发生什么是直接丢弃回RST报文

什么情况下会收到不正确的（第二次握手中的）呢

问题解答不卖关子，直接说这个问题，是回RST报文。过程如下图：



次握手避免历史连接

当客户端连续发送多次建立连接的SYN报文，然后在络拥堵的情况，就会发生客户端收到不正确的的情况。具体过程如下：

客户端先发送了SYN（=90）报文，但是被络阻塞了，服务端并没有收到，接着客户端又重新发送了SYN（=100）报文，注意不是重传SYN，重传的SYN的序列号是一样的。「旧SYN报文」比「比较新的SYN」报文早到达了服务端，那么此时服务端就会回一个SYN+ACK报文给客户端，此报文的确认号是91（90+1）。客户端收到后，发行自己期望收到的确认号应该是100+1，而不是90+1，于是就会回RST报文。服务端收到RST报文后，就会中止连接。后续比较新的SYN抵达了服务端后，客户端与服务端就可以正常的完成次握手了。上述中的「旧SYN报文」称为历史连接，TCP使用次握手建立连接的比较主要原因就是防止「历史连接」初始化了连接。

我们也可以从RFC793知道TCP连接使用次握手的首要原因：

T-

简单来说，次握手的首要原因是为了防止旧的重复连接初始化造成混乱。RFC给出的次握手防止历史连接的案例图如下：



RFC793

如果是两次握手连接，就法阻止历史连接，那为什么TCP两次握手为什么法阻止历史连接呢

我先直接说结论，主要是因为在两次握手的情况下，「被动发起方」没有中间状态给「主动发起方」来阻止历史连接，导致「被动发起方」可能建立一个历史连接，造成资源浪费。

你想想，两次握手的情况下，「被动发起方」在收到SYN报文后，就进入ESTABLISHED状态，意味着这时可以给对方发送数据给，但是「主动发」起方此时还没有进入ESTABLISHED状态，假设这次是历史连接，主动发起方判断到此次连接为历史连接，那么就会回RST报文来断开连接，而「被动发起方」在首次握手的时候就进入ESTABLISHED状态，所以它可以发送数据的，但是它并不知道这个是历史连接，它只有在收到RST报文后，才会断开连接。



两次握手法阻止历史连接

可以看到，上面这种场景下，「被动发起方」在向「主动发起方」发送数据前，并没有阻止掉历史连接，导致「被动发起方」建立了一个历史连接，又白白发送了数据，妥妥地浪费了「被动发起方」的资源。

因此，要解决这种现象，比较好就是在「被动发起方」发送数据前，也就是建立连接之前，要阻止掉历史连接，这样就不会造成资源浪费，而要现这个功能，就需要次握手。

源码分析我说回RST就回RST吗当然不是了，肯定得用源码证明我说的这个结论。

听到要源码分析，可能有的同学就怂了。

其要分析我们今天这个问题，只要懂就行了，我也会用中文来表述代码的逻辑，所以单纯看我的文字也是可以的。

这次我们重点分析的是，在SYN_SENT状态下，收到不正确的确认号的+报文是如何处理的。

处于SYN_SENT状态下的客户端，在收到服务端的+报文后，比较终会调用___，在这里会根据TCP状态做对应的处理，这里我们只关注SYN_SENT状态。

4_4___(*,_*){=0;(-_){TCP_CLOSE:TCP_LISTEN:TCP_SYN_SENT:=____(,,);(=0);}

可以看到，接下来，会继续调用____函数。

____(*,_*,*){(-){*793:*"ISYN-SENT*ACK*IACK*ISEGACK=ISS,SEGACKSNDNXT,*(RST,*)"*的确认号不是预期的(!(TCP_SKB_CB()-_,-_)||(TCP_SKB_CB()-_,-_))回RST报文__;}从上面的函数，就可以得知了，客户端在SYN_SENT状态下，收到不正确的确认号的+报文会回RST报文。

小结TCP次握手中，客户端收到的第二次握手中确认号不是自己期望的，会发生什么是直接丢弃回RST报文

回RST报文。

什么情况下会收到不正确的（第二次握手中的）呢

当客户端发起多次SYN报文，然后络拥堵的情况下，「旧的SYN报文」比「新的SYN报文」早抵达服务端，此时服务端就会按照收到的「旧的SYN报文」回复+报文，而此报文的确认号并不是客户端期望收到的，于是客户端就会回RST报文。