1986年的TCP拥塞崩溃事件让AIMD模型在1988年后出来应对时局,从此以后互联网协议的设计者和实现者聚焦于如何让网络不拥塞。

毫无疑问,这里最重要的是公平性,而非效率。不管是慢启动,加性增窗,乘性减窗,还是后来的Vegas算法的主动退让,其目标都在于保证多条流经过共享链路时能公平共享带宽。这种机制的目标不是让单条流跑得更快。

换句话说,1988年的模型是不患寡而患不均的模型。其中的 “不患寡” 给很多人带来了误解。


事情在2010年前后悄悄地起了变化。


AIMD模型的目标是不患寡,而患不均,这注定单条TCP的带宽利用率极低,因此HTTP协议一般会采用多条TCP流捆绑的方式来传输Web服务器的数据以增加带宽,然而多TCP连接意味着连接管理的开销会增大,同时数据同步的开销也会增加,这导致了人们倾向于使用单独的连接来完成所有的事情。

然而,又是一个然而,TCP固有的队头拥塞问题导致单独的TCP连接无法很好的进行HTTP流的多路复用,这个难题促进了Google对QUIC协议的设计和发布,同时,QUIC的一些显而易见的优势点也逐步的回移进了TCP(如果可能的话)。

不管怎样,如今确实是倾向于减少TCP连接数量,这便弱化了公平性的约束,如今,提高单条连接的带宽利用率,成了迫在眉睫的硬需求。


如何度量带宽利用率?

我倾向于用一种 综合的效用 来度量,而不仅仅是 把带宽跑满, 倘若如此,一个包发十遍肯定能把带宽跑满,然而此时的利用率高吗?

我倾向于把代价也算进去,最终,我们需要,在带宽尽可能大的同时,保证代价尽可能小。

设GGG为收益,PPP为代价或者成本,那么一个综合效用可以用以下的比值表示:

E=GPE=\dfrac{G}{P}E=PG​

我们的任务是,求出一组约束,使得EEE的值最大,此时带宽的利用率最大。

上面的式子中,请注意PPP由两部分组成:

  • 待服务数据包的排队时延成本;
  • 链路转发节点的空置时间成本;

大致画图如下:

本文以下的讨论,假设链路的处理带宽为常数UUU,处理方式为固定速率处理,处理单位为包粒度而不是字节,那么处理一个包的时间便是1U\dfrac{1}{U}U1​,我们从一种极端情况开始,经由一种一般的情况,最终会得出结论,只有均匀按照每1U\dfrac{1}{U}U1​时间匀速到达的数据包,其EEE值最大,而这种方式就是Pacing!


先看以极端情况下完全突发到达的数据包,即当到达率为λ\lambdaλ时,单位时间内所有的λ\lambdaλ个数据包同时到达。

我们知道,单位时间内系统可以处理UUU个数据包,是为服务率为UUU,然而当λ\lambdaλ个数据包在1U\dfrac{1}{U}U1​时间同时到达时,必然会有λ−1\lambda-1λ−1个数据包排队,而单位时间的空置时延依然是1−λU1-\dfrac{\lambda}{U}1−Uλ​,因此总代价就是常数。如下图所示:

虽然看样子利用率接近了100%,然而代价确实巨大的!通过计算可知,这种情况下的EEE值并不高。然而这么多年,TCP的AIMD正是工作在这个模型上。

然而,正如我们分析网络数据流看到的那样,情况可能比上面的模型展示的结果更加糟糕,这是为什么?我们来接着分析。

下面我们看一种更加一般,更加符合真实环境的情况,即泊松到达的情况。这里将会揭示一个关于 100%利用率的神话永不可达 的事实:

至于说泊松到达的情况下,这张图为什么长这个样子,我就不推导了,从排队论的公式简单理解作图就能得到。注意这里的事实,最佳利用率而不是最大利用率,为什么?

从图上可以看出,如果我们在泊松到达的情况下想逼近收益墙附近的最大100%利用率,代价将是无法承受的,我们看到队列长度将趋向无穷大,这是根本无法处理的情况!

这背后的原因其实非常简单,即在泊松到达到达的情况下,单位时间到达的数据包会有概率性的大于μ\muμ,此时就将付出排队延时的代价,而同样会有概率性的小于μ\muμ,此时便要付出空置的代价,而不管是排队还是空置,对于服务方而言,都是成本,不幸的是,这两种成本是叠加而非抵消的关系!它们对数据包到达的影响效果仅仅是在数值意义上使得其到达均值为到达率λ\lambdaλ!

这便是100%利用率永不可达的神话!

这个故事不断在我们生活中上演,这也是为什么运维们很怕CPU利用率达到100%的原因,100%并不意味着系统利用率高,而是意味着系统卡死!

同样,我们的工作看上去永远也做不完,因为你永远不知道接下来会发生什么,只要你没有空闲的时候,那么就意味着你将永远没有空闲的时候。你仔细想想,是不是这个道理。


如何解决这个问题呢?

破除泊松到达模式即可,取而代之,我们要适配固定的服务速率,即带宽μ\muμ,如果我们能完全按照每1μ\dfrac{1}{\mu}μ1​的时间发送一个数据包,那岂不是意味着 既不用排队,也不会空置 了吗?这才是真正的100%的利用率!

是的,这就是Pacing!

完全按照瓶颈带宽来空置发送的速率,使其和服务速率完全相匹配!这就是提高带宽利用率的最佳方法。上图也是TCP BBR的理论基础。


然而,说起来容易做起来难,首先,端到端的TCP如何知道带宽到底是多少?你又要说测量是不是?测量结果具有一个RTT的滞后性。因此你测得的结果永远都是以前的结果而不是现在的结果,由于网络情况存在随机性,更无法预测未来的情景,于是乎,完全按照瓶颈带宽来发送数据是不可能的,我们意识到一旦不可能实现这一点,就意味着会出现随机的排队或者资源空置,这无可避免!

其次,Pacing的方法增加了TCP端到端实现的复杂性,破坏了TCP完美的 自时钟。这个倒是有几句话可以说说。

事实上TCP的AIMD在设计之初就将Pacing的希望寄托于其ACK自时钟了。因为当时的设计者们相信,完美的 雅各布森管道 会把突发出去的数据包整成Pacing的方式到达对端,进而针对这些数据包ACK也会是Pacing的方式到达发送端,从而驱动下一轮的数据以Pacing的方式发送。

以上这个过程详见《TCP/IP详解(卷1)》。

然而事实证明,TCP的雅各布森管道并不完美,很少有网络能把突发的TCP数据整成Pacing的,最终,TCP便背上了突发协议的骂名。那么,雅各布森管道为什么不完美?有以下原因:

  • 网络上存在多个TCP流而不是一个,新流的出现和旧流的消失不可预知;
  • ACK的反向路径与数据包正向路径不对称导致形成的Pacing序列被破坏;
  • ACK本身的丢失会导致突发;
  • 一些路由器为了限制包量会根据TCP的积累应答机制将多个连续ACK聚合,造成突发;

总之,网络链路太复杂,这使得依赖自时钟形成Pacing是不现实的,那么就不得不自己去算Pacing Rate了,而这个结果又是滞后的,或者说我们采集到的信息仅仅够算一个所谓的均值,这些信息远远不足以指导Pacing发送。

不管怎么样,我们依然会选择Pacing的方式来发送数据,至少在没有新的有别于AIMD的全新数学模型出现之前吧。

如此一来,只要我们选择了Pacing,那么就必然要在TCP发送端内置一套数据采集和计算引擎,这是AIMD模型所不需要的。


其实,很早以前就曾出现过一些争论,比如关于完全速率控制的Pacing Rate发送和完全ACK自时钟驱动的发送之间的争论,非常类似于中断和轮询之间的争论,最终,我们现在使用的Pacing发送,比如BBR的Pacing方式,事实上是融合了两者:

  • 用ACK来驱动Pacing Rate的计算;
  • 基于Pacing Rate来平滑发送数据。

总之,提高带宽的利用率的方法已经从捆绑多条TCP连接的方式进化到了提高单条TCP连接的带宽利用率。理论上证明Pacing的方法是最好的,但是如何精确计算Pacing却成了新的问题。

那么怎么办?

提高带宽利用率!为什么要Pacing?相关推荐

  1. 1载波把32个信道按_OFDM技术:相比FDM提高频带利用率,子载波间隔可以随意选取吗?...

    OFDM技术作为4/5G物理层重要技术之一,为什么可以克服传统FDM频率利用率低的缺点?OFDM的的子载波间隔可以随意选取吗?OFDM信号如何实现? 本文将主要围绕上述3个问题展开. 图1 图中4GL ...

  2. 蓝汛ChinaCache打破传输瓶颈,提高宽带利用率

    现如今,市面上大部分的数据传输软件均基于TCP协议进行运转,TCP协议由于其控制数据流量速率的机制,导致其吞吐量随着时延及丢包率的增加而变得更加明显,使得带宽利用率低,无法适应大文件远距离的传输需求: ...

  3. 生产管理车间提高劳动利用率

    生产管理请添加链接描述车间提高劳动利用率包括两个方面,一是提高直接劳动利用率,二是提高间接劳动利用率.提高直接劳动利用率的关键在于一人负责多台机器,这就要求对操作工进行交叉培训,交叉培训的目的是使生产 ...

  4. RaySync 传输协议的有效带宽利用率分析介绍

    最近在评论区收到不少朋友反应[RaySync FTP]文件传输的效果挺好,谢谢大家的鼓励.也有部分熟悉技术的同学希望介绍下原理,有部分同学咨询RaySync传输协议会不会是通过超量发包来达到快速传输, ...

  5. python视频处理加速的库_VPF:适用于 Python 的开源视频处理框架,加速视频任务、提高 GPU 利用率...

    原标题:VPF:适用于 Python 的开源视频处理框架,加速视频任务.提高 GPU 利用率 雷锋网 AI 开发者按:近日,NVIDIA 开源了适用于 Python 的视频处理框架「VideoProc ...

  6. 中水处理设备可提高水资源利用率说明

    中水处理设备又可在生物池内维持高浓度的微生物量,工艺剩余污泥少,极有效地去除氨氮,出水悬浮物和浊度接近于零,中水回用设备出水中细菌和病毒被大幅度去除,能耗低,占地面积小.膜生物反应器用于污水和废水处理 ...

  7. 服务器物理内存利用率,服务器提高物理内存利用率

    服务器提高物理内存利用率 内容精选 换一换 本文档专供需要对Yarn进行应用开发的用户使用.本指南主要适用于具备Java开发经验的开发人员.Yarn是一个分布式的资源管理系统,用于提高分布式的集群环境 ...

  8. 香侬科技Service Streamer:加速深度学习Web服务、极大提高GPU利用率。| 百万人学AI评选

    2020 无疑是特殊的一年,而 AI 在开年的这场"战疫"中表现出了惊人的力量.站在"新十年"的起点上,CSDN[百万人学AI]评选活动正式启动.本届评选活动在 ...

  9. 流越多,带宽利用率越低?

    多条流共享同一瓶颈链路时,涉及到并发调度问题. 调度在微观上就是查找,调度本身会带来开销.视角放远一点,我们仅当开销是个黑盒,不问细节,看看怎么回事. 类比进程调度,多进程分时运行,想象中时间被所有进 ...

最新文章

  1. MikuMikuShaders
  2. RISC-V评估系列
  3. Avalonia跨平台入门第十五篇之ListBox聊天窗口
  4. 知识主题间先序关系挖掘
  5. java nio 客户端_Java网络编程:Netty框架学习(二)---Java NIO,实现简单的服务端客户端消息传输...
  6. 30G 超大数据文件,如何用一周时间导入生产数据库?
  7. keil5调试如何选择晶振_有源晶振的负载电容重要吗?
  8. sql server,mysql,oracle 获取上一月时间
  9. 根据ip高精度查地址网址
  10. 洛克菲勒:一部西方石油工业的传奇史
  11. 图片选择器ImagePicker
  12. 对接京东联盟,签名无效
  13. 怎么用python学习网站开发_2018年最好用的5个python网站开发框架
  14. DP之Warshall算法和Floyd算法
  15. 揭秘APP软件开发者百万富翁之路:造程序的工厂
  16. 知名云计算厂商云宏加入龙蜥社区,共同打造信息安全坚实“地基”
  17. 单元格等于计算机日期,《excel表格怎样自动填写日期》 Excel单元格中自动获取当前日期与时间...
  18. 【读书笔记《凤凰架构》- 构架可靠的大型分布式系统.周志明】(一)
  19. win7安装node版本最高只支持13.14.0
  20. 图解数据中心冷热电三联供原理

热门文章

  1. android多个悬浮窗口的实现,android实现桌面移动悬浮窗口
  2. html在线预览ppt excel,JavaScript实现Word、Excel、PPT在线预览
  3. 如何确定SAP系统的NetWeaver版本、ERP或S/4HANA的版本
  4. 【Swing】JTextArea文本域组件
  5. 王者荣耀7月4号服务器维护,王者荣耀7月4日更新了什么 7月4日更新维护公告
  6. delphi 两行代码实现合并多张图片生成mp4视频
  7. STM32 之三 标准外设版USB驱动库详解(架构+文件+函数+使用说明+示例程序)
  8. 检索 COM 类工厂中 CLSID 为 ???的组件时失败,原因是出现以下错误: 80080005。
  9. python制作微信小程序_python搭建微信小程序
  10. php取FBOX数据,如何实现如下功能