我在网站看到一位老哥问了个问题。
我说回 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 的博大精深
审核编辑 :李倩
-
TCP
+关注
关注
8文章
1353浏览量
79059 -
RFC
+关注
关注
0文章
16浏览量
10101 -
服务端
+关注
关注
0文章
66浏览量
7006
原文标题:这也能考虑到?TCP 有点牛逼
文章出处:【微信号:小林coding,微信公众号:小林coding】欢迎添加关注!文章转载请注明出处。
发布评论请先 登录
相关推荐
评论