周末闲聊TCP加速和拥塞控制

Posted dog250

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了周末闲聊TCP加速和拥塞控制相关的知识,希望对你有一定的参考价值。

本文主要说四个主题。开始之前有两句话:

  • TCP加速不是拥塞控制,写一个拥塞控制算法不能加速,相反,好的拥塞控制算法是在必要时减速的,所以不要在拥塞控制算法里多增加几个cwnd。
  • 若做TCP加速,不要盯着均值和中位数,不要田忌赛马,唯一要做的事就是照顾慢速连接,将慢速连接识别出来,对剩余的连接,什么也别做。

聊聊做TCP加速还有没有前途。

2012年,TCP加速意义明显。稍微一改便立竿见影,经理和用户有目共睹,经理和用户结果导向,结果就是能感受观测的效果,比如原来下载文件要1分钟,现在只要半分钟,经理不在乎所用的技术,用户甚至不知道什么是TCP。

简单易改的原因在于粗放型方案以破坏公平性换取单连接传输性能。对大多数网络状况本良好的连接,激进传输非常有效,最终均值,中位数提升,但P99提升并不大,问题在于弱网传输很难优化,而破坏公平性加剧了这份差异。

到2022年,TCP加速在各个公司仍在进行。但经理和用户再看不到期待的效果,空留研发自嗨。2012年开始过去了9年,这9年间大家基本追平,从2分追到9.6分,从3分追到9.5分,从3分追到9.7分。但继续从9.5分进击到9.8分,这效果便只剩研发可感知了,经理看不见,用户不在乎。

下载时间从5分钟缩短到3分钟,用户兴奋,继续缩短到2.6分钟,用户仍愿买单,继续缩短到2.5分钟,用户便很难感知,继续缩短到2.47分钟,经理便怀疑你摸鱼划水了。最终,前面就是一堵墙。

事已如此,TCP加速实在挖了一个深坑。最优和最差之间的差距更大。好的不能继续再好,差的很难被优化。

粗放型的加速方案很容易提升80%+连接的传输性能,但无力处理不到20%的尾巴。由于已经加速了大多数本无需加速的连接,剩余慢速连接劣势便越加明显。问题不再是让快的更快,而是让慢的赶上,这比加速良好连接更难,粗放型方案统统失效。

由于粗放型算法不注重公平性收敛,结果就是越来越不公平。谁来拯救慢速连接,不是没人做,而是很难。我想如今业内都纷纷遇到这个问题了吧。

再聊聊拥塞预测。

拥塞不可预测,只能感知,但感知时已经晚了,拥塞可能已结束。最近看卡洛罗韦利的书,“此时是相对的”是相对论精髓。TCP以准光速联络时空中两点,颇似地球和比邻星通信。你永远无法知道发生拥塞的远方“此时”的情形,你感知到的拥塞事件对你甚至不在偏序列,拥塞事件对你既不在过去,也不在未来,它是一个“延展的现在”事件,它甚至与你无干。

几近末路,幸运的是,现实不似你所见。

人们把拥塞难题归咎于网络波动,但波动并非无章可循。周一我画了一幅悲图:

为此文,我细化了些:

画出你自己的圈。很不幸,绝大多数普通人都如我日复一日大循环里小循环。将所有这些人的圈加在一起,颇似一个傅立叶变换,多个频率的周期合为一个新频率的周期。

虽悲哀,但现实。地铁上每天固定时间固定座位就是那几个人,吃完饭遛弯儿,今天在固定时间固定拐角遇见的人明天此时此地大概率还会遇见,偶遇是谎言。

固定街区固定时间会拥堵,长期生活在一个地方的人知道哪里在什么时间会堵车并能绕开。背后依据即这些叠加的圈圈。

网络拥塞亦如是,固定的人在固定时间刷固定App,经理的会议固定在每周五晚上十一点半,此些产生固定流量。理解这个,拥塞即可预测,实属拿昨天的此时预测今天的未来,我们相信,循环一直在继续。

聊聊现实中的拥塞控制算法。

无论CUBIC,BBR,还是自研算法,现实表现都不拉胯,看似狠狠驳斥了拥塞不可预测,但并不是。

算法并未预测拥塞,其有效性来自拥塞的持续。当算法感知到拥塞并作出反应,当反应力到达拥塞点,拥塞依然持续,便没有扑空,算法命中,产生效力。若出现非持续突发拥塞,任何不依赖外部数据的封闭算法均将失效。

封闭算法控制的是“从过去持续到未来的拥塞”,拥塞发生在过去,算法反应力在未来控制持续的拥塞。换句话说,拥塞具有惯性,但惯性不一定都强劲,典型的incast拥塞惯性极弱,任何端到端算法均无能为力。拥塞持续越久,RTT越小,封闭拥塞控制算法越容易生效。

若参照外部数据,算法将更易实施。举例言之,双十一前,淘宝服务器及网络均扩容,以应对即将的大流量。为什么能预测大流量,因为去年如此,今年便亦如此了。将此精细化,便是一个好算法,背后依据是,流量并不随机,你要识别到规律。

一个好的模型,喂给的数据总来自于过去。

最后,聊下为什么要应对拥塞。

拥塞后果为何?后果只有延时。丢包只是现象,会触发重传,而重传会带来额外延时,若拥塞尚未丢包,则排队延时也是徒增,故拥塞只导致延时。

BDP越小,对拥塞越敏感,拆开讲,带宽越小,RTT越小,拥塞排队延时,重传延时占比越大。

BDP越大,算法一旦采取动作,越难恢复如初。拆开讲,带宽越大,恢复越慢,RTT越大,拥塞感知与反馈周期越久。

拥塞要不得。但又无法控制,怎么办?绕路呗。但端到端算法亦无法控制路由,又怎么办?还是要问经理。

对于拥塞控制,没必要长篇大论,不懂的人,写一百万字他也不懂,懂的人,几个字就懂了,所以长篇大论的都在pr。并且,pr之人完全都是藏着掖着,时刻提防他者,他们不可能把自己所想的实际公开,这是他们的唯一,这也是他们的庸俗。我不知道我是不是他们中的一员,希望不是。

浙江温州皮鞋湿,下雨进水不会胖。

以上是关于周末闲聊TCP加速和拥塞控制的主要内容,如果未能解决你的问题,请参考以下文章

独立双(N)拥塞窗口的TCP单边加速思想

让人很容易误解的TCP拥塞控制算法

让人非常easy误解的TCP拥塞控制算法

在Wireshark的tcptrace图中看清TCP拥塞控制算法的细节(CUBIC/BBR算法为例)

CentOS7.5 配置BBR加速

TCP拥塞控制