这也能考虑到？TCP 有点牛逼

我在网站看到一位老哥问了个问题。

简单点说，为什么在 TCP 三次握手过程中，如果客户端收到的 SYN-ACK 报文的确认号不符合预期的话，为什么是回 RST，而不是丢弃呢？

我说回 RST 就回 RST 吗？

当然不是，我也是看 RFC 标准确认过。

我来先描述下这个场景吧：

• 客户端向服务端发送 SYN 报文（seq=100），但是网络中有个不速之客，一个历史的 SYN 报文（seq=90）先抵达服务端；
• 服务端收到历史的 SYN 报文，就会对此 SYN 报文做了确认，回了 SYN-ACK 报文，确认号为 90+1；
• 客户端收到 SYN-ACK 报文后，诶发现不对劲，他明明发的是 SYN 报文（seq=100），按道理 SYN-ACK 报文中的确认号是 100+1，可现在收到的确认号为 90+1 的 SYN-ACK 报文，所以礼貌地回了 RST 给服务端；
• 服务端收到 RST 报文后，服务端就断开处于 SYN_RECEVIED 状态的连接；
• 最后正常的 SYN 报文（seq=100）终于抵达了服务端，经过三次握手后，双方的 TCP 连接都建立完成。

上面这个过程，就是 TCP 三次握手防止历史连接建立的过程，之所以 TCP 需要三次握手，首要原因是为了防止旧的重复连接初始化造成混乱，其次原因是可靠的同步双方的序列号。

那为什么要设计成，当客户端收到不符合期望的 SYN-ACK 报文，是回 RST，而不是丢弃呢？

现在我们来假设是丢弃处理，看看会发生什么？

可以看到，当处于 SYN_SENT 状态连接的客户端收到不符合期望的 SYN-ACK 报文时，如果选择的处理是「丢弃」，那么双方都会触发超时重传，直到达到最大的重传次数才会进入 CLOSE 状态，这个过程需要持续 10-20 秒。

从客户端的角度看，就是迟迟与服务端建立不来连接，因为服务端这边已经存在一个相同四元组的旧连接，如果不把服务端这个连接干掉，那么是无法确认客户端新的连接（SEQ=100），因为非 LISTEN 状态下，如果收到 SYN，都是回 challenge ack，这个 ack 并不是对收到 SYN 报做确认，而是继续回复上一次已发送 ACK。

是不是有种服务端的旧连接（SEQ=90）占着茅坑不拉屎的感觉？

所以啊，干掉服务端的旧连接的工作，就交给了客户端来做了。

当处于 SYN_SENT 状态连接的客户端，在收到不符合期望的 SYN-ACK 报文时，就直接 RST 给服务端，干掉服务端的旧连接，这样客户端的新连接才能快速建立。

怎么样，TCP 处处是细节啊！

再次感受到了 TCP 的博大精深

以上就是良许教程网为各位朋友分享的Linu系统相关内容。想要了解更多Linux相关知识记得关注公众号“良许Linux”，或扫描下方二维码进行关注，更多干货等着你 ！