这也能考虑到?TCP 有点牛
2023-04-18 14:57:54 时间
大家好,我是小林。
我在网站看到一位老哥问了个问题。
简单点说,为什么在 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 处处是细节啊!
相关文章
- 【技术种草】cdn+轻量服务器+hugo=让博客“云原生”一下
- CLB运维&运营最佳实践 ---访问日志大洞察
- vnc方式登陆服务器
- 轻松学排序算法:眼睛直观感受几种常用排序算法
- 十二个经典的大数据项目
- 为什么使用 CDN 内容分发网络?
- 大数据——大数据默认端口号列表
- Weld 1.1.5.Final,JSR-299 的框架
- JavaFX 2012:彻底开源
- 提升as3程序性能的十大要点
- 通过凸面几何学进行独立于边际的在线多类学习
- 利用行动影响的规律性和部分已知的模型进行离线强化学习
- ModelLight:基于模型的交通信号控制的元强化学习
- 浅谈Visual Source Safe项目分支
- 基于先验知识的递归卡尔曼滤波的代理人联合状态和输入估计
- 结合网络结构和非线性恢复来提高声誉评估的性能
- 最佳实践丨云开发CloudBase多环境管理实践
- TimeVAE:用于生成多变量时间序列的变异自动编码器
- 具有线性阈值激活的神经网络:结构和算法
- 内网渗透之横向移动 -- 从域外向域内进行密码喷洒攻击