网站开启gzip,广州市网站建设分站价格,网站建设概算,网络服务提供者是谁卸载一切到网卡#xff0c;解放 cpu#xff0c;兜售自己的设想#xff1a;功能越来越多#xff0c;吞吐越来越大的网卡。万物皆关联#xff0c;吞吐越大的网卡反而更闯祸。范雅各布森的大历史视野不是每个工程师都具备的#xff0c;更何况经理们。 事实是#xff0c;网…卸载一切到网卡解放 cpu兜售自己的设想功能越来越多吞吐越来越大的网卡。万物皆关联吞吐越大的网卡反而更闯祸。范雅各布森的大历史视野不是每个工程师都具备的更何况经理们。 事实是网卡发送得太快而不是太慢了因此需要让网卡更慢而不是更快一些。在报文之间塞入哪怕再小的 time slice 都好过突发。但这是为什么建议阅读Evolving from AFAP: Teaching NICs about time 人们很明确下面的话 IP’s AFAP model is embodied in our current NIC API – we tell the NIC what to send but not when to send it. I believe that our ability to build future high efficiency networks depends critically on evolving the NIC API to cover both ‘what’ ‘when’. I’ll try to explain why and how, at least in Linux, the evolution could be easy. 但人们并不真的践行。后面会提到即使有了 edt 以及类似的东西经理们依然倾向于为报文附着一个更早的时间戳错的不是网卡应该具有的机制而是人们使用这种机制的认知。 由于交换网络星形拓扑的本质交换容量一般高出主机网卡一个数量级主机并没有加速网络的动机因为端到端时延几乎就是准光速时延交换机配备一些少量 buffer 吸收突发。主机流量畅通无阻更快的网卡只会导致交换机排队徒增时延资源够用不卷网卡。 随主机性能的发展应用对带宽的需求也增加但无论如何交换机总能相对于主机网卡保持至少 10x 的增速网卡 100mbps交换机 1gbps网卡 1gpbs交换机 10gbps如此而已。交换机设备商总能拉开接入带宽和交换带宽数量级的差异这背后起作用的是摩尔定律。 直到有一天摩尔定律曲线开始往下弯折主机网卡性能逐渐追平交换机主机当高楼带宽看作绿地越来越高的容积率让网卡陷入内卷。前面我在分析 bbr 从 buffer 挤占带宽时描述过带宽挤占的动力学不再赘述简单说就是你努力制造更快的网卡只能至多保持住固定带宽的比例但如果你什么都不做你所能用的带宽将越来越小。 但另一条路才是正确的自律也就是 pacing。 核心交换容量虽不能再跟随摩尔定律的节奏但却还可通过并行化而负担更大交换容量至少目前而言应对应用的需求并不在话下。和摩尔定律时代唯一不同的是交换机和网卡不再有数量级的差异比如网卡 25gbps交换机普遍只有 100gbps 而不是 250gbps。 此情况下较小 buffer 的网络已不符合现状了如今需要更大的 buffer 应对突发而更大的 buffer 的时延副作用很明显因此大 buffer 是另一个问题而不是方案。 若要使应用流量达到以前畅通无阻的效果办法就是主机主动感知和测量(虽然不会准但能算个大概)瓶颈带宽然后基于此带宽主动自律这便是 pacing。 在这个大历史框架下我们发现这自然而然就是 rate-based 拥塞控制算法的背景而 google 正是在这个 2010 年代研发并部署了 bbr一切都不是空穴来风。 再看如何做到 pacingpacing 得以平滑部署的功劳要归于 tcp/ip 的简洁。tcp/ip 来自于做减法而不是加法。 tcp/ip 最大的特点是对周边不做任何假设和限制ip 尽力而为而 tcp 提供可靠性虽然事后来看可靠性也并非必须。总之在当时那个年代tcp/ip 最大化了通用最小化了约束这支撑它平稳度过摩尔定律曲线开始向下弯折的拐点。 设计 tcp/ip 时让它比看起来更好非常容易做出某种假设和限制将事情复杂化几乎是当代经理每天都在做的事随着时过境迁一些外部条件发生改变导致某些假设不合时宜要把其中一些限制去掉时就很难甚至不可能了因此 tcp/ip 的简洁性非常重要它没有规定如何发送报文的细节这给了 pacing 被引入的空间。 仅就 linux tcp 而言pacing 至少经历了三种方案一开始借用 fq-qdisc后来 bbr 在 tcp 逻辑内部实现了 internal pacing再后来有了 edt(earliest departure time)而 dpdk 版的 tcp pacing 更灵活。 对拥塞控制而言做 pacing 就完了而拥塞控制与流量控制是分开作用的前者负责从网卡发出到网卡接收到的传输区间但绝不是从离开 tcp 层就开始起作用了我们发现引入 edt 后对 small queue 的依赖自然也降低了这个和引入 tcp rack 对 tlper 的依赖降低一样。 在 pacing instead of burst 这个大原则指导下一切都往时间戳靠就对了因为需要基于时间做出更精确的控制以支撑 pacing与 tcp rack 基于时间戳做丢包检测同理edt 基于时间戳做发送也是正确的(google swift 用时间戳做更精确的标记也是为支撑更精确的计算)。 edt 的思想很简单传输层控制逻辑根据采集到的数据计算出 pacing rate为每一个待发送报文贴上一个时间戳网卡基于该时间戳安排报文的实际发送这消除了网卡发送报文时的计算和调度带来的误差和抖动发送逻辑只需要查看一下报文上的时间戳即可。 从 edt 的 earliest 修饰看出作为一个不仅限于 tcp 的通用逻辑它规定 “最早发送时间” 而不是 “最迟发送时间”edt 是往里收着的它并不倾向于 “以尽可能快的速率发送”相反它限制 “最快速率不能超过 x”。 即使一个主机中塞入了 10000000000 个连接如果它们果真采用正确的方式测量和计算而不是冒进计算结果也会合理均分瓶颈带宽。 但这一次在对细节的理解上经理们可能又错了。按照上一段的解释如果每个连接都倾向于正确计算 delivery rate网卡在一个时间轮上按照报文 edt 发送总速率一定不会超过网络的瓶颈带宽在后摩尔定律时代虽然网卡追平了交换机但不是越大越好。 但如果经理获得了一个更好的网卡(称经卡)一定会用光它。经理一定会塞入更多的报文大多数经理并不知道 edt更不用谈传输逻辑正确计算速率他们用 blind flood 方式测试网卡而不是在现网测试有效吞吐。更难以理喻的是他们宁可接受发送 100 个报文让交换机扔掉 50 个也不愿意只发送 50 个。如果交换机因此升级到可支撑 100 个报文经卡则会发送 150 个宁愿用重传报文打满带宽。至于公平性恶意假设是你忽略公平性而获益让我做公平性肯定在骗我。 反 pacing反收敛导致资源浪费每发送一个注定被丢弃的报文都是电能在做无用功每排查一例因此导致的丢包和重传问题(绝不是故障但很多人不清楚丢包和重传不是故障)都在无效消耗工人精力可能还有公司的钱。内卷思维在经理心里是一贯的。 pacing 迎着大历史背景而生要迎合 pacing 不是试图绕开它这是获得最佳能效的唯一方式这是历史决定的。 值得担心的不是它有多复杂相反它很简单。值得担心的是人们在内心里的 “慢了就会输” 的笃念就像在路上即使没急事也不允许有车在自己前面一样。如果只能发送 10 个报文经理们总倾向于发送 11 个如果 100gbps 网卡刚跑到 60gbps经理们会尝试让它跑到 70gbps至于好几跳以后的那个交换机的情况谁在乎。 “慢了就会输” 是人们内心笃定的这可能是人们讨厌等待却又喜欢排队的原因。大家都已经在排队了我还等什么呢pacing 和错峰是不被接受的凭什么是我错峰到人后人们宁可挤作一团也不想主动收敛。这可能是我们国家人太多的缘故这导致我们国家的人普遍有 “宁愿挤作一团”“不甘人后”“慢了就会输” 的笃念这些笃念影响着我们做的每一件事我们会把这些笃念注入到我们设计的一切以致很多人把 “取消 pacing激进发送数据” 作为自己面试或晋升的亮点而对方也会觉得 “我艹牛逼” … 本文以范雅各布森的大历史视角分析一下 pacing 的故事。 浙江温州皮鞋湿下雨进水不会胖。