TCP 与 bufferbloat
说到既能降低成本,又能降低时延,总觉得这在 pr,兜售自己或卖东西。毕竟哪有这么好的事,鱼与熊掌兼得。可事实上是人们对 buffer 的理解错了才导致了这种天上掉馅饼的事发生。
人们总觉得 buffer 越大越好,buffer 越大设备越贵,真实情况是 buffer 越大越糟糕,如果按这个思路,应该是 buffer 越小设备越贵,所以你若想获得低时延,就要花更多的钱买小 buffer 的设备,这依然是一笔需要权衡轻重的买卖。
可无奈 buffer 是一样东西,它是实实在在的实物,是一种普通非稀有容器,哪有越小越贵的道理,但其实不能将 buffer 理解成容器,而要理解成调节剂,比如盐,味精等调味品,放一点刚刚好,越多越糟糕:
人们对好的东西支付,以上图为导向,携带 100GB buffer 的交换机肯定没有携带 100MB buffer 的交换机贵。
看个标准 TCP(std TCP) 的经典锯齿:
为 100% 利用有效带宽,std TCP 需要 “即使执行 MD(multiplicative-decrease) 将 cwnd 折半后依然恰好填满有效带宽”,即 Wmax = 2 * BDP,因此,buffer 的建议大小为 BDP。
如果 buffer 不足 BDP,就会出现带宽不能有效利用的情况:
但如果有 2 条流,第 2 条流的 cwnd 就可以补上图示中的阴影,隐约可见,流数量越多,阴影越容易弥补。另一方面,随着弥补阴影变得容易,阴影更能容忍继续扩大,而阴影的扩大意味着 buffer 减小。
进一步,设流数量为 N,N 不需无穷大,只需数值上等于 BDP 并随机异步散列,buffer 可趋向 0 仍保证带宽 100% 利用。研究表明,实际需要的 buffer 与根号 N 成反比:Bsize = 2 * BDP / N^0.5。我曾经写过一篇分析:buffer 的平方反比律。
N 越大,所需 buffer 越小,虽有悖于直觉,但也可以理解,背后的动力学是 “交互的代价”or 收益。N 越大,总带宽利用率越不受单流行为影响,整体上趋于互补。
下面是一个例子。
设 BDP = 6,单流场景,cwnd 序列为:6,7,8,9,10,11,12,buffer 大小为 12。现考虑 2 条流公平收敛后的场景,每一条流的 cwnd 序列均为:3,4,5,6。
- 如果两条流同步,那么 cwnd1 + cwnd2 序列为:6,8,10,12,此时所需 buffer 仍然为 12。
- 如果两条流相位差 1,cwnd 和序列为:7,9,11,9,所需 buffer 为 11,但有 1 单位 buffer 无法清空。
- 如果两条流相位差 2,cwnd 和序列为:8,10,8,10,所需 buffer 为 10,有 2 单位 buffer 无法清空。
后面两种情况,均可既满足带宽被 100% 利用,又减少 buffer。若固定最大相差,在实数域上移动相位,就是一个抽样过程,按中心极限定理,N 越大,概率分布曲线会越高越瘦收敛于均值,瘦意味着方差小,无需照顾小概率事件,buffer 用量减少。
但填满带宽和单流吞吐是两回事。小 buffer 虽足以 N 条流一起填满总带宽,但 N 流交互的代价是单流丢包间隔缩短,丢包增加。
一般而言,交互即 capacity-seeking,所以代价来自 capacity-seeking,假设存在非 capacity-seeking 机制控制 sender 恰好分享 1 / N 带宽份额,便完美高效并完美公平,由于没有足够控制信息,这几乎不可能,因此 capacity-seeking 固有开销(这是普遍管理开销)必须接受。
当 N 很大时,要么选择高丢包高重传,要么选择大 buffer 但同时大排队时延。显然选择后者不高尚,如果频繁丢包,说明链路过载,AIMD 锯齿波只是以一种并不完美 capacity-seeking 方式保证收敛,但远非唯一方式,甚至 capacity-seeking 本身都不是唯一的带宽高效共享的方式。
L4S(Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service) 提供了一种新思路。在传统端到端视角,舍弃大 buffer 而开发更优的 cc 更智能地 capacity-seeking 相比部署大 buffer 更正确(buffer 就像盐,缺了不行,但稍微多一点就会出大问题),比如 CUBIC 和 BBR 相比 std TCP 就是很好的优化。
Internet 核心并没有选择大 buffer。如上所述,早期 Bsize = BDP 的结论被证明 在 N 很大时是不必要的,这大大降低了核心路由器对 buffer 的依赖,因为在 Internet 核心,N 一定很大。
以 100Gbps 带宽为例,早期核心路由器需覆盖 RTT 上界接近 200ms 的 BDP,需要部署大小为 2.5GB 的 buffer,但在新理论下,当 N = 10000(可能不止),只需要约 25MB 的 buffer 即可。
此外,在数据中心,另一番景象依然不允许部署大 buffer。
数据中心低时延是刚需,超高带宽是固有属性,超高带宽将灵敏响应的责任甩给了主机和交换机,100Gbps+ 带宽容不得半点抖动,留给 cc 以及 queue 的决策时间非常短,同时由于数据中心高频微突发,N 也不会小,综上,数据中心不能部署大 buffer(大概只有 3MB~10MB)。
Internet 核心和数据中心之外,还有网络边缘接入点这第三个场地,这也是最难搞的地方。经过这地方的流量没有足够大的 N,连选择的机会都没有,buffer 太小既高丢包又低带宽利用率,buffer 太大就会 bufferbloat。
要排除对 buffer 的侵占(有多少 buffer 会用多少),几乎所有的 AIMD capacity-seeking 这种对 buffer 强依赖的算法均不适合。
application-limited 流量无 capacity-seeking,但 application-limited 流量无法抗 burst:
所以知道 BBR 为什么要在 ProbeRTT 维持 4 个 inflight 以清空 queue 了吧,很多以百分比或盲目增加个常数(显然是嫌 4 太小了)来魔改 ProbeRTT inflight 的,歪曲了本意,基本算扯淡,但 BBR2 为流共存已经做了很大修改,它其实算混合算法,并不是真的 BBR。
但 inflight = 4 确实会带来应用抖动,增加应用 buffer 可缓解,但既然增加应用层 buffer 可容忍时延换不抖动,转发节点 bufferbloat 带来的时延为何就不可原谅呢,总之很难搞。或许 CUBIC 停留在 Wmax 更久一点,并用 pacing 缓解 burst 更好一些。
电脑内存越大越好,但交换机 buffer 可不是这样。认为交换机 buffer 越大越好的肯定是接触电脑多于网络,接近微软 PC 时代的人,程序员居多。
buffer 作为调节剂,用来平滑统计突发(可能还有更基本的存储转发用途,但这依然需要少量 buffer),而不是像电脑里那样暂存计算中间结果或平滑快慢设备的。网络是通路,不需要停留,小 buffer 溢出说明过载了,要降载荷而不是加 buffer。
buffer 到底大了好还是小了好是一个与 “golang 和 rust 哪个更好” 截然不同的问题,即便 rust 再时兴,看不惯用不上的依然不会用,但 buffer 大了好还是小了好是一个很明确的问题,难点在于很难解释 “为什么 buffer 不能太大”,不管如何解释,都会被怀疑,“难道大 buffer 不丢包不好吗?”,很少人会去真心面对链路过载问题,很少人能接受 “慢点发送”,似乎每个人都希望将数据尽快发送出去,于是越大越好的 buffer 承载了所有希望。
浙江温州皮鞋湿,下雨进水不会胖。
TCP 与 bufferbloat相关推荐
- 深夜聊聊Bufferbloat以及TCP BBR
这篇文章的写作动机来源于知乎上的一个问题,有人问既然Bufferbloat是个问题,为什么路由器的缓存还要设计那么大.起初,我也是觉得缓存越大越好,这个就像人们拼命比拼谁的电脑内存大一样,因为在一般人 ...
- 漫谈TCP bufferbloat的根源-Jacobson管道
在前面的文章中,我经常提到bufferbloat,关于这个词的解释,我几乎都是明嘲暗讽地把锅甩到Reno/CUBIC这类基于AIMD的算法身上,声称它们是 buffer友好的 ,必须填充buffer的 ...
- 从流量控制算法谈网络优化-TCP核心原理理解
hi,大家好,又是新的一周,周末在朋友圈读到一篇网络优化的文章,感觉文章比较接地气,有实验测试,有数据分析,想分享给大家,让我们再次加强对TCP以及网络优化的理解. 作者简介 费良宏,AWS Prin ...
- TCP 拥塞控制详解
作者:engleliu,腾讯 PCG 开发工程师 本文主要介绍 TCP 拥塞控制算法,内容多来自网上各个大佬的博客及<TCP/IP 详解>一书,在此基础上进行梳理总结,与大家分享.因水平有 ...
- 漫谈TCP新算法Elastic-TCP
自适应的CCA(Congestion Control Algorithm)给人一种简洁明快的感觉. Elastic-TCP是一种新近的算法,比BBR还新,但比BBR简洁多了,可以从Wiki上了解其大概 ...
- 令人躁动一时且令人不安的TCP BBR算法
虽然我在这个周六(2016/12/17)荒废了一天而毫无意义的加班,我依然要在次日把上一周的点滴记录下来.以下在2016/12/18下午19时之前的文章,全属周六通宵之作. 可以说,这个周末过得比较水 ...
- 从TCP拥塞本质看BBR算法及其收敛性(附CUBIC的改进/NCL机制)
本文试图给出一些与BBR算法相关但却是其之外的东西. 1.TCP拥塞的本质 注意,我并没有把题目定义成网络拥塞的本质,不然又要扯泊松到达和排队论了.事实上,TCP拥塞的本质要好理解的多!TCP拥塞绝大 ...
- 骨干网络演化释义以及TCP BBR的部署环境问题
昨天本应该去公司加班的,但我由于不在本地而没去享受这奢华的周末盛宴.不过我要一路上远程值守,有问题要上,这是必须的.无聊的时候,没有问题制造问题也要上?这是贱.所以,在没有问题的时候,我写下一些简单的 ...
- QVegas-一个升级版的TCP Vegas拥塞算法
拥塞避免带来了很多疑惑,本文解开这个疑惑并给出一个实实在在但却很简陋的算法. 其实在基于丢包的拥塞算法中,拥塞避免的过程总是伴随着AI和MD的,不能光说AI而忽略MD. ...
最新文章
- c语言ctype中替换查找字符,c – std :: ctype是否总是按“C”语言环境对字符进行分类?...
- fastDFS同步问题讨论
- python定义符号常量_python注释、变量、常量的学习
- python零基础知识_python 零基础 基本知识
- erlang安装报错
- Linux命令——set 和 unset
- 【控制】反馈控制入门,PID控制
- 创作短视频怎么去除素材水印?
- BOM Routing (2009-08-31 23:46:00)
- 【Python百日进阶-Web开发-Feffery】Day315 - fac导航4:AntdDropdown下拉菜单
- 安卓抓jdwskey
- wod我的博客开通了
- 蒙特卡洛树搜索(The monte carlo search tree)
- GitHub中已开源项目汇总
- 一个敬谦基督徒的生活
- Stereo Vision-based Semantic 3D Object and Ego-motion Tracking for Autonomous Driving
- plm服务器 硬件性能,如何对PLM系统进行性能诊断与调优?
- 硬盘分区文件格式变成RAW,点击就显示未格式化解决方法(小莫)
- Android解锁图案共有多少种?
- Matlab函数trainingOptions参数解析
热门文章
- 2021-08-09校网比赛D题
- 浏览器的四大内核:Trident,Gecko,Webkit,Blink
- Win11应用更新在哪里 Win11怎么更新应用
- Spring的IOC创建对象的方式和代码基本解释为什么要有ioc的思维以及Ioc容器和spring依赖注入的解释
- Indie 音乐类型扫盲
- python+pytest接口自动化(5)-requests发送post请求
- 移植u-boot-2012.04.01到JZ2440(二:分析启动流程)
- 今年slam方向的同学秋招进展如何?
- 计算机组成原理EMAR啥意思,计算机组成原理考研补习.ppt
- CakePHP中文教程4