接着昨天的 大历史下的 pacing：why & how 接着说。
程序员以为的 edt(earliest departure time) 背景和动机：
- 单机部署容器越来越多，网络流量需要在不同 pod 间公平分发；
- 多 pod 之间调度流量需要复杂的 qdisc 队列(比如 tbf(token bucket filter))；
- linux qdisc root lock 开销大，cpu 越多，流量越大，竞争越激烈；
- …
于是：
- 多 pod 部署场景充分发挥多 cpu 优势；
- 尝试简化 qdisc 的工作，降低 lock 开销；
- 重要的工作转移到 pod 内部，pod 自行为报文打 timestamp，底层根据该 ts 安排发送；
- time-wheel 设计；
- …
总之还是 linux kernel 数据路径优化老掉牙的那套。这种优化永无止境，自己制造问题，自己解决问题，但问题的本质并不清晰。
在大历史的视角下，一切看起来就不是见招拆招。左右这一切的竟然就是摩尔定律曲线的弯折。
大历史视角下的 edt 背景和动机：
- 摩尔定律曲线趋缓，交换机相对主机网卡不再保持数量级优势；
- 交换带宽吃紧，降低丢包需要更大 buffer，但以更大延迟为代价；
于是：
- 主机以测得实际可用带宽并保持不超过此带宽发送；
- 主机自行 pacing 报文；
- edt 作为代价最低的 pacing 手段，将 timestamp 的计算和基于该 ts 的发送解耦；
- edt 落地。
问题空间和解决方案完整闭环，一切自然而然地发生。
在程序员视角下，edt 只是实现 pacing 的优化，至于为什么 pacing，多数人的理解限于公平调度，端到端降低时延 … 这种理解下，一切不过是策略，既然是策略，乱搞就是难免的，各种反压，偷偷 burst 等方案层出不穷，有了反压必然要大 buffer，都挤进大 buffer 就免不了要解调度谁的问题，你看，问题是自找的，然后自己解决。
在大历史视角下，pacing 自然且必然，做法就简单粗暴，应用程序自行测量实际吞吐(可在任意位置完成)，基于该吞吐为下一个报文算个 ts，网卡在 time-wheel 中根据该 ts 发送。pacing 完全是因为交换机容量不再对主机网卡保持优势，它不是策略而是必须，因此一切额外的措施都是自找麻烦。
bbr 恰好在 2010 年代放出，正是摩尔定律曲线弯折时，合时宜。如果事后倒着想一下为什么摩尔定律会在 2010 年代放缓，和移动互联网的发展不无关系，而后者无论在晶体管集成度还是能耗续航方面都是对摩尔定律最后的考验，正在这种背景下，端追平了网。
而移动互联网则得益于通信技术的发展，通信正是 21 世纪前 10 年的主角。
…
有多少人是从接触一个设计时就被告知 “它就是这样子” 的，又有多少人问过 “它为什么这样？”，百忙之中他们将这个设计现在的样子当作它唯一的形式，没有精力或者能力想象其它的可能性。
我经常跟关系好的朋友讲，“这不是你认为的，这只是别人告诉你的 …”，“你甚至没有去海边看过远处下沉的帆就相信了地球是圆的”，虽然不可能每件事都去实证，但我们至少不能忘记思考。
前面写过一篇文章 数字逻辑不可能涌现出真智能，看到评论后我相信大多数人并没有思考能力，他们(并非评论的全部)甚至已经僵化到不允许别人发表和他们认知不一致的论述，更不指望和他们讨论开放性问题，在他们内心并不允许开放性问题存在，一切必须符合他们自己对自己 “学到的真理” 的认知，而对于科学的本质，他们错误地将其视为真理，他们并不理解科学。他们只是从没有听到过这些 “荒唐” 言论，就笃定这是 “可怕的”，“中式的”，“无知的”，“臆想”，除非我能给出一些 “论据” 或者 “出处”。
我曾写过一些 tcp 接收窗口，序列号，三次握手，timewait 相关的随笔，我几乎从不分析代码，也不翻译 rfc，总有人教我做人，告诉我这纯属无根据臆想，误人子弟，后来我写了些 sack，dsack，reordering，bbr，pacing 相关的随笔和想法，依然没有代码分析和 rfc 翻译，却没人理我了。因为tcp 协议太简单了，但 tcp 拥塞控制很难，懂的人少了。
浙江温州皮鞋湿，下雨进水不会胖。
