TCP 两次握手为什么无法阻止历史连接?
2023-02-18 15:36:30 时间
摘要:在两次握手的情况下,「被动发起方」没有中间状态给「主动发起方」来阻止历史连接,导致「被动发起方」可能建立一个历史连接,造成资源浪费。
本文分享自华为云社区《TCP 两次握手为什么无法阻止历史连接?》,作者:小林coding 。
两次握手的情况下,「被动发起方」在收到 SYN 报文后,就进入 ESTABLISHED 状态,意味着这时可以给对方发送数据给,但是「主动发」起方此时还没有进入 ESTABLISHED 状态,假设这次是历史连接,主动发起方判断到此次连接为历史连接,那么就会回 RST 报文来断开连接,而「被动发起方」在第一次握手的时候就进入 ESTABLISHED 状态,所以它可以发送数据的,但是它并不知道这个是历史连接,它只有在收到 RST 报文后,才会断开连接。
可以看到,上面这种场景下,「被动发起方」在向「主动发起方」发送数据前,并没有阻止掉历史连接,导致「被动发起方」建立了一个历史连接,又白白发送了数据,妥妥地浪费了「被动发起方」的资源。
因此,要解决这种现象,最好就是在「被动发起方」发送数据前,也就是建立连接之前,要阻止掉历史连接,这样就不会造成资源浪费,而要实现这个功能,就需要三次握手。
三次握手阻止历史连接的过程如下图,注意图中的两个连接的序列号是不一样的,因此新旧 SYN 报文并不是发生了超时重传,两个都是独立的连接。
客户端连续发送多次 SYN 建立连接的报文,在网络拥堵情况下:
- 一个「旧 SYN 报文」比「最新的 SYN 」 报文早到达了服务端;
- 那么此时服务端就会回一个 SYN + ACK 报文给客户端;
- 客户端收到后可以根据自身的上下文,判断这是一个历史连接(序列号过期),那么客户端就会发送 RST 报文给服务端,表示中止这一次连接。
可以看到,在三次握手的情况下, 可以在服务端建立连接之前,可以阻止掉了历史连接,从而保证建立的连接不是历史连接。
相关文章
- Redis 定长队列的探索和实践
- 基于微前端qiankun的多页签缓存方案实践
- 从RabbitMQ平滑迁移到RocketMQ技术实战
- 服务器内存故障预测居然可以这样做!
- 推荐系统-协同过滤在Spark中的实现
- vivo官网APP全机型UI适配方案
- 工作流引擎在vivo营销自动化中的应用实践 | 引擎篇03
- RocketMQ之消费者启动与消费流程
- CSS Houdini:用浏览器引擎实现高级CSS效果
- Lepton 无损压缩原理及性能分析
- 从0到1建设智能灰度数据体系:以vivo游戏中心为例
- 一种跳板机的实现思路
- Elasticsearch 在地理信息空间索引的探索和演进
- 剖析 SPI 在 Spring 中的应用
- vivo 容器集群监控系统架构与实践
- 如何在Vue项目中,通过点击DOM自动定位VScode中的代码行?
- vivo大规模 Kubernetes 集群自动化运维实践
- 探究Presto SQL引擎(3)-代码生成
- Kafka 负载均衡在 vivo 的落地实践
- C/C++ 单元自动化测试解决方案实践