程序员做网络 – buffer 越大越好吗_dog250的博客-CSDN博客

周三下班路上发了一则朋友圈：

声明：我并不针对虚拟网络，在我看来，虚拟网络不属于网络范畴，而属于主机范畴，虚拟网络并不是真正的网络，虚拟网络只是一种资源管理和资源复用的手段。

周六又有些思考：

为 infiniband 而哭泣… 但如今 chatgpt 风靡一时，虽不知六个月以后会怎样，但至少 “高带宽，低延迟” 成了必须，“尽力而为” 或多或少成了人们必须优化的东西，如果一个系统被设计成尽力而为，就注定会被优化，提供就业岗位，这就是卷材。

The juaner who believed juanism had juaned himself to the juanable juanage or juanization itself.

重看《楚汉传奇》，趁宫廷剧情不喜欢，写篇文章，胡乱写写。

网络的限制永远只有一个，就是带宽资源而不是算法，算法只在瓶颈带宽收敛比 >= 1 时才作为仲裁者被引入。收敛比 > 1，算法关注公平性，收敛比 = 1，算法关注带宽利用率，收敛比 < 1 无需算法。提高带宽才是正道。

算法在传输和计算上的意义完全不同，后面会细说，但要先举例，比如 1 + 2 + 3 = ? 这个计算问题无论硬件发展到何等高尚，都是避不开的，但类似拥塞控制，AQM，大 buffer 此类计算，随着带宽资源的日益丰盈，将不再需要，至少会越发简化。

再一个例子，高速公路非常干净，仅双向封闭 4 车道，只有慢速道路才花哨，红绿灯，隔离带，慢车道，人行道，绿化带，岗楼，斑马线，待转区…

先从大 buffer 谈起吧。

交换需要配置多大的 buffer，这是一个老问题。buffer 越大越好吗？回答也是直截了当，并不是。比如，过大的 buffer 将延迟 sender 早早知道拥塞这件事。

TCP 端到端拥塞控制依靠反馈来做决策，一定要让 sender 尽早知道所发送的事件。RED AQM 是一个好东西，它随机丢几个包，然后放过去一批，好让被放过去的这批快速将丢包这件事反馈给 sender，对于 TCP 就是靠 dupacks 来通知 sender。如果是尾丢，丢包这件事只能等待 sender 端 timeout 方可感知，如果是大 buffer 的尾丢，这个 timeout 时间将非常久。

大 buffer 的影响：

• 影响时延抖动幅度，buffer 越大，抖动服务越大，最大 RTT 越大，RTO 越大。
• 影响 sender 敏感度，buffer 越大，sender 对信号的反馈越迟钝。
• 影响延迟敏感类应用的 QoE，buffer 越大，总会有流侵占 buffer 而造成 HoL blocking。
• …

但人们普遍追求大 buffer，来自两个明显的原因：

• 人们将丢包看作亏损，但没人知道到底有多少带宽可用，而 buffer 提供了带宽还没满的假象。
• 人们在意实体物料，设备商需要加载更多硬件以获得更多利润，广告效应偏向大 buffer 料足。

设备上宣传并提供更大 buffer 的设备，用户拼命用尽这些大 buffer，这又是一个 Windows + Intel = Wintel 环。有利益，就能圈钱，引入符合摩尔定律的物件儿，类 Wintel 环就能起转。

但大 buffer 只提供了无损假象，等到 sender 意识到丢包时，buffer 已经排满，除了不可避免丢包，延时也变得不可接受。

就像喝酒，人体提供了一个小 buffer，在喝不到 250ml 白酒时就给人醉意，喝到 500ml 几乎断片没法继续喝，这是在保护人体，如果提供一个大 buffer，当人们喝完 2L 白酒才意识到醉意时，身体已经受到了大伤害。

不仅喝酒，人体几乎全是小 buffer，吃饭，喝水，娱乐，性爱，让 burst 不能持久，没人觉得这是亏损。

高尚的做法是 sender 适配带宽，而不是适配 buffer。如果带宽 100Mbps，一共 2 条流，每条流就以 50Mbps 发送。当然，没有任何 sender 知道有多少流共享多大带宽，cc 的目标就是在没有这些信息的情况下，收敛到公平共享带宽。

传统的 AIMD cc 就是适配 buffer 的算法，有多大 buffer 它们能用满多大，而新样式的 BBR 则声称在保持 RTT 最小的情况下适配最大带宽，但两者都是 Capacity-Seeking 算法，这种算法都有用尽一切 buffer 的倾向，即使 BBR 在规避使用 buffer 的现实效果上做得也不够好-如果不是很糟糕的话。

但还有一类应用，自己来做带宽适配，如 BBR 文档中的介绍：… interactive applications (e.g., Web pages, remote procedure calls, video chunks) often have natural silences or low-rate periods… 所谓 app-limited，应用程序根据自身需要和现实，自行配置一个够用，合理的带宽，不再 Capacity-Seeking，如果背景流量过多，它们会重新选择一个更小的但依然可用的带宽重新适配。

buffer 本是用来吸收统计突发(参考分组交换网统计复用原理)的，顺便用来为端到端拥塞控制提供丢包信号或延时信号，端侧根据这些信号调整姿势，这种顺便的通知用途当然不能因为 buffer 过大而延迟太久，除非有 ECN，INT 等额外带内或带外机制通知，否则 buffer 过大只能带来更大的亏损。

如果你抱怨小 buffer 会丢包，那是因为你发得太多，如果想通过配置更大的 buffer 来避免丢包，实际上只是掩耳盗铃，假象只延缓了丢包，而这种假象也不免费，代价是额外延时。就像酒一样，花钱遭罪，只为换一点妄想。

最后说说 RDMA 场景下的 PFC 反压。以下跟题目关系不大，以后我自己找估计都不一定能找到。

RoCEv2 需要一个承诺不丢包的无损网络，一旦丢包，端侧只能 GBN。端侧不实现 SACK 的缘由是它太消耗计算资源，而 RDMA 的目标就是将计算资源留给计算而不是传输，因此只能提供无损网络，而 PFC 反压则是无损网络的一种手段。但 PFC 反压需要大 buffer，会引入不可预期的延时，造成严重抖动。

一种思路是将 SACK offloading 到网卡，由专门的硬件实现做 SACK 从而解除对 PFC 反压无损网络的依赖。不管怎样，只是转移了问题，从无损网络中移除了延时成本，却将复杂性转移到了网卡，而这一切都是为了节省计算成本，看起来任何成本都没有节省，成本是守恒的。

未来虽然有 offloading 的倾向，但节省了 CPU，不还是要买网卡么。如果什么都不做，那就付出时间等待吧。但所有这些成本，都不如摊到更快更新的网络转发硬件上，在网络领域，并不存在软件跟不上硬件这回事。

所有人都卷错了方向。

成本不应该花在大 buffer 下的 PFC 反压，也不该兑换计算资源，更不是去实现 SACK offloading。如果中间的光纤被经理的皮鞋踩几下，是不是要实现更复杂的 SACK 或提供更智能的 retransmit 机制呢？另一方面，如果光纤晶莹通透柔滑，交换机可承载 100Tbps 带宽，甚至不需要任何 SACK 和 retransmit 机制，仅保留 RTO + GBN 即可。

换句话说，成本应该花在线路和带宽上。

遗憾的是，人们把很多精力和钱财花在了生产和购买大 buffer，如何分配利用这些大 buffer，以及如何实现复杂的传输控制机制上。换句话说，人们把钱花在了容错上，而不是如何更正确。更正确就更简单，有了高品质的光纤和高带宽的交换机，其它成本就都省了，而高品质光纤和高带宽交换机无疑不便宜，但这钱才是真值得花的。

具体来讲，换一根更贵的光纤，换一台带宽更大的交换机，单位时间可发出更多数据的交换机，买带宽而不要买 buffer，这笔钱就花得值，成本远低于雇佣互联网卷客所支付的工资。做一个极端的假设，购买并部署一套钻石设备(超高带宽，超纯光纤)，即可开除所有领工资做传输优化的卷客。

网络是需要尽快离开的地方，任何阻碍数据快速离开网络的措施都是作恶。网络应该很简单而不该更复杂，延时分三块，传播延时，排队延时，处理延时，先引入大 buffer 增加排队延时，再引入大 buffer 的管理算法增加处理延时，劣质线缆误码丢包增加重传延时，这是罪恶。

总之，错误少了，容错方案就少了，错误没了，容错方案就不需要了，大 buffer(而不是 buffer 本身，只要统计复用都需要 buffer，具体参见 排队论) 作为容错方案而不被需要。

把问题上升一下再看文初的那则朋友圈。

绝大多数程序员并不懂网络，程序员并不理解网络本质上不该做什么。程序员关注主机侧，将代码部署在主机运行，所以他们也希望将代码部署在网络，程序员并不理解网络侧运行的代码越少越好。

CPU 参与计算，核心不是 CPU 本身而是算法，再好再贵的 CPU，算法都可极大影响执行效率，至少你有能力故意写一个拖沓的算法。

网络则相反，网络不需要算法，只提供一条干净的通道。你无法阻滞光纤上的一束光，想延迟光信号，不得不靠延长传输距离的土法，你甚至无法让电脉冲在 buffer 里长驻留，它们在出口总是以带宽为速率往外泄露。

直言之，网络需要的就是昂贵的高品质光纤和高品质高带宽交换机(or 路由器)。

把 CPU 那套摆指令的玩法搬到网络，将报文摆来摆去，只损无益。

网络对报文只有 FIFO 一种合理摆法，如果确实有多种队列调度算法，只能说带宽不够大，不得不做取舍才要引入算法，换句话说，这些算法不是让传输更快，而是为不得已的牺牲做决策，这个取舍决策影响所有报文，不做取舍，全部慢，做取舍，部分稍慢，部分极慢。说白了就是带宽资源不足导致的不得已，痛点是提高带宽，而取舍决策本身，但凡取舍，都不应该，用付给写算法工人的工资买更好的设备才是高尚的。

转回现实，网络越来越堵，干线上功能越来越多，主机功能被虚拟化潮流转移到网络。近在眼前的东西向 HOOK，NFV，远在天边的 DPI，xFW，这些 “虚假网络技术” 在事实上将从 DCI 到 Internet 的整个网络变成了弱网。

最后，虽然不针对虚拟网络，虽然虚拟网络的存在无可厚非，但它确实拖慢了网络传输，幸亏它还有些足够交换损失的收益，比如它确实提高了资源利用率。

什么是真正的网络技术，我们程序员经常挂在嘴边的都不是真网络技术，DPDK，XDP，SmartNIC，零拷贝，中断，Socket，epoll，OVS 以及所有包含 “深入理解”，“Linux 网络” 等关键词的书目录里包含的技术，所有旨在依靠以上这些技术栈提高网络性能的，全都叫错了名字。以上这些技术几乎没有一个可以走出一台装有 Linux 内核的主机，换句话说，它们叫主机网络技术。真正的网络技术会将数据面交给高速硬件和光纤，控制面保留路由协议维持联通性，诸如 AQM，令牌桶，Firewall，NAT 尚存争议。有多少人把 “读过 Linux 内核协议栈源码”，“精通数据包在 Linux 内核的接收流程” 当作懂网络的标准，若果真如此，手里有个锤子，便到处都是钉子了。都多少年了，还是 10 年前的老话题。

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