字节一面TCP三次握手，问的好细

　　大家好，我是小林。
　　有位读者在面试字节时，被问到这么个问题：
　　概括起来，是这两个问题：TCP三次握手中，客户端收到的第二次握手中ack确认号不是自己期望的，会发生什么？是直接丢弃or回RST报文？什么情况下会收到不正确的ack（第二次握手中的ack）呢？问题解答
　　不卖关子，直接说这个问题，是回RST报文。过程如下图：
　　三次握手避免历史连接
　　当客户端连续发送多次建立连接的SYN报文，然后在网络拥堵的情况，就会发生客户端收到不正确的ack的情况。具体过程如下：客户端先发送了SYN（seq90）报文，但是被网络阻塞了，服务端并没有收到，接着客户端又重新发送了SYN（seq100）报文，注意不是重传SYN，重传的SYN的序列号是一样的。旧SYN报文比最新的SYN报文早到达了服务端，那么此时服务端就会回一个SYNACK报文给客户端，此报文的确认号是91（901）。客户端收到后，发行自己期望收到的确认号应该是1001，而不是901，于是就会回RST报文。服务端收到RST报文后，就会中止连接。后续最新的SYN抵达了服务端后，客户端与服务端就可以正常的完成三次握手了。
　　上述中的旧SYN报文称为历史连接，TCP使用三次握手建立连接的最主要原因就是防止历史连接初始化了连接。
　　我们也可以从RFC793知道TCP连接使用三次握手的首要原因：
　　Theprinciplereasonforthethreewayhandshakeistopreventoldduplicateconnectioninitiationsfromcausingconfusion。
　　简单来说，三次握手的首要原因是为了防止旧的重复连接初始化造成混乱。RFC给出的三次握手防止历史连接的案例图如下：
　　RFC793
　　如果是两次握手连接，就无法阻止历史连接，那为什么TCP两次握手为什么无法阻止历史连接呢？
　　我先直接说结论，主要是因为在两次握手的情况下，被动发起方没有中间状态给主动发起方来阻止历史连接，导致被动发起方可能建立一个历史连接，造成资源浪费。
　　你想想，两次握手的情况下，被动发起方在收到SYN报文后，就进入ESTABLISHED状态，意味着这时可以给对方发送数据给，但是主动发起方此时还没有进入ESTABLISHED状态，假设这次是历史连接，主动发起方判断到此次连接为历史连接，那么就会回RST报文来断开连接，而被动发起方在第一次握手的时候就进入ESTABLISHED状态，所以它可以发送数据的，但是它并不知道这个是历史连接，它只有在收到RST报文后，才会断开连接。
　　两次握手无法阻止历史连接
　　可以看到，上面这种场景下，被动发起方在向主动发起方发送数据前，并没有阻止掉历史连接，导致被动发起方建立了一个历史连接，又白白发送了数据，妥妥地浪费了被动发起方的资源。
　　因此，要解决这种现象，最好就是在被动发起方发送数据前，也就是建立连接之前，要阻止掉历史连接，这样就不会造成资源浪费，而要实现这个功能，就需要三次握手。源码分析
　　我说回RST就回RST吗？当然不是了，肯定得用源码证明我说的这个结论。
　　听到要源码分析，可能有的同学就怂了。
　　其实要分析我们今天这个问题，只要懂ifelse就行了，我也会用中文来表述代码的逻辑，所以单纯看我的文字也是可以的。
　　这次我们重点分析的是，在SYNSENT状态下，收到不正确的确认号的synack报文是如何处理的。
　　处于SYNSENT状态下的客户端，在收到服务端的synack报文后，最终会调用tcprcvstateprocess，在这里会根据TCP状态做对应的处理，这里我们只关注SYNSENT状态。netipv4tcpipv4。cinttcprcvstateprocess（structsocksk，structskbuffskb）｛。。。intqueued0；。。。switch（skskstate）｛caseTCPCLOSE：。。。caseTCPLISTEN：。。。caseTCPSYNSENT：。。。。queuedtcprcvsynsentstateprocess（sk，skb，th）；if（queued0）returnqueued；。。。｝
　　可以看到，接下来，会继续调用tcprcvsynsentstateprocess函数。staticinttcprcvsynsentstateprocess（structsocksk，structskbuffskb，conststructtcphdrth）｛。。。。if（thack）｛rfc793：IfthestateisSYNSENTthenfirstchecktheACKbitIftheACKbitissetIfSEG。ACKISS，orSEG。ACKSND。NXT，sendareset（unlesstheRSTbitisset，ifsodropthesegmentandreturn）ack的确认号不是预期的if（！after（TCPSKBCB（skb）ackseq，tpsnduna）after（TCPSKBCB（skb）ackseq，tpsndnxt））回RST报文gotoresetandundo；。。。｝
　　从上面的函数，就可以得知了，客户端在SYNSENT状态下，收到不正确的确认号的synack报文会回RST报文。小结
　　TCP三次握手中，客户端收到的第二次握手中ack确认号不是自己期望的，会发生什么？是直接丢弃or回RST报文？
　　回RST报文。
　　什么情况下会收到不正确的ack（第二次握手中的ack）呢？
　　当客户端发起多次SYN报文，然后网络拥堵的情况下，旧的SYN报文比新的SYN报文早抵达服务端，此时服务端就会按照收到的旧的SYN报文回复synack报文，而此报文的确认号并不是客户端期望收到的，于是客户端就会回RST报文。
　　完！
　　用RFC文档源码的方说明我的结论，这么严谨的小林，没谁了吧
　　原文链接：https：mp。weixin。qq。comssqkYBM4l4qFFPkjYzCJA