IDC网络传输优化随想录
Posted dog250
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了IDC网络传输优化随想录相关的知识,希望对你有一定的参考价值。
在IDC内部,如果你还遵循传统为广域网而生的拥塞控制逻辑做事,那就错了。当然,我下面说的也不一定都对。
正确的做法就好像我之前说的一种情况的反例,那种情况是,让你优化长肥链路传输,你却在优化spinlock。IDC的情况相反,把前面的例子反过来说,把spinlock换成ECN(可扩展)就对了。但这就够了吗?
广域网传输优化只能基于RTT为周期,你有足够的时间利用足够的资源去做运算,但IDC内部这么做不太现实,在IDC内部,任何误判的代价都会被放大,一个5us的延时除了做重传之外几乎做不了任何事,再靠盲猜,靠复杂计算积累学习就比较扯了。
如果盲猜不行,那怎么做行?不是有ECN吗?
ECN可以通告拥塞,但无法控制调度,怎么还需要调度?
无论你将IDC网络看作是PCIe,还是把主板总线看作是CLOS变体,其实都是一回事,两者也变得越来越无法区分。不把IDC网络看成是网络和把主机内部看作网络是一回事,既然大家对主机优化积累了这么多经验,就把IDC网络看成是一个主机的内部好了,用资源调度的思路去优化它就好了。说白了就是仲裁流能不能通过,就像调度task那样去调度流。
既然可以将task迁移到另一个CPU上,显然也就可以将流量迁移到另一个交换机。
我在上周的文章里说了,DCTCP应该优待突发短流而惩罚长流,这并没有问题,事实上这是唯一的措施,因为如果不这样,怎么做都是错:
- 突发短流和长流均不惩罚?这就是常规cc的做法,那就任由其丢包吧。
- 惩罚突发短流?已经拥塞了,突发短流得不到服务,长流半天才能恢复。
- 突发短流和长流双双惩罚?任何流都会受到影响,服务受损。
所谓的惩罚长流并未影响任何流的延迟,相反,正因为同时惩罚了所有流但相对狠地惩罚了长流,才保证了所有流的延迟均不增加。
但相对狠地惩罚长流只是事情的一个方面,为了缓解拥塞,毕竟长流来日方长,暂时的损失可以被时间稀释。但事情还有另一方面。如果长流也是FCT敏感的呢?任何吞吐的损失都会带来FCT的延期,又当如何?得让长流的数据包告诉交换机才是,这就需要在端主机对数据包进行分类打标。
那么这个时候惩罚谁呢?换一条不拥塞的路径即可,这就是所谓流量调度的意义。
总的来讲,把IDC网络看作是一个整体的资源池就好了,剩下的就是最大化这个资源池的利用率了。这个思路和MPTCP有些像,但我觉得MPTCP在广域网上效果不一定好,但在IDC网络不妨一试。
以上都是拥塞控制,传输优化还有另一面,流量控制。
TCP不好做并行传输,因为要保序,一旦有空洞窗口就憋住了。有人想过这个问题吗?
针对小内存主机,长肥管道,TCP只能做串行,因为哪怕一个空洞,至少一个BDP的数据憋住,所以在早期,即便是SACK都不现实。假设TCP可以忽略序列号的连续发送,将很消耗内存。另一方面,补充这个空洞无论如何至少也要到一个RTT,30ms量级的RTT内并行传输产生新的空洞的概率很大,最终传输将崩溃。
对于IDC网络这种超短超肥管道,事情起了变化。10us量级的RTT几乎和协议栈处理时延属于同级,协议栈的重排序和重传可以同步进行,一系列传输行为将流水线化:
- 发送端:发送,重传
- 接收端:排序,反馈
即便有空洞,窗口也不必憋住,因为传输和重传是并行的,传输只管传输,重传只管重传,保序操作在接收端完全和TCP解耦,它可以作为一个独立的逻辑存在,比如有些流不需要保序。
其实,只要不要求流式,TCP的什么问题都解决了,把重排序加一个层次来做。但比较悲哀的是,大部分问题都是工程问题,而不是算法问题。如何保证兼容性,是最大的问题。
最后不妨说说性能优化的边际效益递减。
第一个找到关键热点并将其优化掉的,收益会很大,这个人肯定会获得丰厚的奖励。大家纷纷模仿,但却陷入了内卷,几乎没什么拿得出手的产出。
一个系统不可能存在多个独立热点,即便有多个,也是相关联的,符合幂律分布,抽掉第一个,后面的都不是问题。
拥塞控制领域,CUBIC是一个创举,和之前Reno/BIC相比,是个飞跃,之后的那些算法都很拉胯,直到2016年BBR的出现,又是个飞跃,再往后所有针对BBR的优化同样拉胯。无论是CUBIC还是BBR,事后看,都很简单,但为什么大家都没想到?反而等这些都出来后,纷纷挑毛病,觉得这里可以改,那里可以调,这就是走火入魔。
性能优化最关键的那一步其实不难,大家都没想到恰恰因为大家都希望优化一个已有系统,而不是去做一个新需求。Google意识到网络带宽利用率不高,定位了Bufferbloat根因,就开发了BBR。如果包括Neal在内的Google人把一天天的时间花在优化CUBIC上,那几乎也同样拉胯。
所以还是要系统看问题,而不是只盯着某些点挑毛病找bug拿大奖,真正的大奖都藏在系统,且一般只有一个。
不知不觉,近年来做优化的越来越多,做功能的越来越少,有时Demo还没出来就开始考虑优化,有时都没有找到关键热点就开始考虑优化…如果我说很多人都在优化用不到的东西,那这句话必然是忠告。
考虑一个做了点手脚的骰子,1点那面重一点,大概1.2/6的概率吧,有个人凭肉眼发现了这个骰子不公平,在押注时押1点稍微多一点,赢了不少钱就走了,其余人一拥而上,有的allin了1点,有的买来了精密仪器去测量算计这个骰子,企图发现更加确定性的事实…结果,大家总体上是血亏的,即便是微赢的那些专家,扣掉买设备的钱,也不剩多少了。我们要学第一个人,去发现并解决关键问题,而不是去优化已经被发现的关键问题。
有人会问我自己扯这么多,有做过什么拿得出手的作品吗?事实上是没有的,我也不是唯作品论者。
但我是做过的,在BBR之前,我曾经做过Westwood和Vegas的结合,差一点就改成了BBR,效果比CUBIC好很多,我赢在考虑到了实时测量bandwidth,并监控RTT的增加,主动probe后再次测量监控,抛弃AIMD做主动收敛,这就是BBR的思路,我相信我已经找到了关键点,但我输在了编码能力太差,没能写出Delivery rate的测量代码,直接借用了Westwood的实现,所以效果不如预期。我的目的是希望具有良好编程技术的人可以读懂这篇文章。
浙江温州皮鞋湿,下雨进水不会胖。
以上是关于IDC网络传输优化随想录的主要内容,如果未能解决你的问题,请参考以下文章