当前位置: 首页 > news >正文

【网络原理】TCP提升效率机制(三):延时应答和捎带应答

目录

一. 延时应答

二. 捎带应答


一. 延时应答

延时应答也是基于滑动窗口的一种提升传输效率的方式(减少ACK数量)

 接收方收到数据之后,不会立刻返回一个ACK确认报文,而是等一会再返回ACK报文

这样做的好处?

1)减少窗口大小的变化频率

在发送方中,存在接收缓冲区,发送方发送的数据会先存储在接受缓冲区中,如果发送方不停发送数据,接收方不断的取出数据,并返回ACK确认报文,这样会导致ACK返回的窗口大小不停的变动

2)增大返回的窗口大小

在延迟的过程中,接收方会不断的从缓冲区取出数据,最后导致缓冲区中的空余空间会变大,返回的ACK报文中的窗口大小也会变大

3)减少网络堵塞,节省开销

将多个ACK应答报文合并成一个ACK应答报文,返回一个较大值的序号(表示这个序号之前的数据已经全部收到了)


二. 捎带应答

如果说延时应答是通过减少ACK报文的数量提高效率,那么捎带应答就是增大报文数据提高效率

捎带应答是基于延时应答,扩展的机制

  • 正常情况下,客户端和服务器的交互方式都是一问一答,发送方发送数据,接收方返回ACK,接收方发送响应,发送方返回ACK
  • 接受方收到数据之后,会花费一定的时间计算响应
  • 由于延时应答的机制,很有可以会出现返回ACK报文和发送响应的时间间隔很短

既然间隔时间很短,那自然而然就将ACK报文和响应数据进行了合并 

  • ACK报文中,本身也不携带载荷部分,所以合并不会出现冲突问题
  • ACK报文中的确认序号和窗口大小,respond数据也不会涉及到,所以也不会出现冲突

 捎带应答是不是一直存在?

  • 捎带应答并不是一直存在的,只有ACK报文和数据报文之间的发送间隔很小(甚至重合),才会触发捎带应答
  • 不管是短连接还是长连接都可能会出现捎带应答,取决于发送时间间隔

 故因为延时应答和捎带应答机制的存在,可能会使四次挥手,合并为三次挥手

相关文章:

  • el-transfer穿梭框数据量过大的解决方案
  • 浏览器插件,提示:此扩展程序未遵循 Chrome 扩展程序的最佳实践,因此已无法再使用
  • 非标机械设备的动画制作
  • 如何通过Google Chrome增强网页内容的安全性
  • prompt提示词编写技巧
  • 【Pandas】pandas DataFrame rmod
  • Eureka 深度解析:从原理到部署的全场景实践
  • Spring生命周期
  • SNMP协议之详解(Detailed Explanation of SNMP Protocol)
  • 人工智能-深度学习之多层感知器
  • C++ 嵌套类 (详解 一站式讲解)
  • Flink Checkpoint 与实时任务高可用保障机制实战
  • SpeedyAutoLoot
  • Linux中的shell脚本练习
  • MCP之二_服务器与客户端实现
  • Python实例题:Pvthon实现键值数据库
  • 【计网】认识跨域,及其在go中通过注册CORS中间件解决跨域方案,go-zero、gin
  • 对VTK中的Volume Data体数据进行二维图像处理
  • 电子电器架构 ---电气/电子架构将在塑造未来出行方面发挥啥作用?
  • React速通笔记
  • 俄宣布停火三天,外交部:希望各方继续通过对话谈判解决危机
  • 找化学的答案,解人类的命题:巴斯夫的“变革者”成长之道
  • 事关稳就业稳经济,10张海报看懂这场发布会的政策信号
  • 商务部:将积极会同相关部门加快推进离境退税政策的落实落地
  • 持续更新丨伊朗官员:港口爆炸已致5人死亡超700人受伤
  • 三大猪企去年净利润同比均较大幅度增长,资产负债率齐降