互联网拥塞控制实践

TCP 及 QUIC 端到端拥塞控制是无解的，因为独立的端掌握的信息不足以使其作精确判断。精确的拥塞控制需要全局视角，但全局视角不可得。

空间上，对于特定端，无法获得俯视全局的视角。获得全局视角需要网络的操作权限，除了运营商，几乎没人可获得此权限。运营商可部署 SDN，但用户不能。

换个维度，从时间维度入手。

任何网络行为说到底都是人的行为(尚未进入 AI 时代)，人的行为是符合心智模型的。比如：

• 凌晨到早上，使用网络的人少，如有，则大概率长连接，看剧或玩游戏。
• 周五周六凌晨网络流量会大，第二天不用上班，可追剧追比赛，玩游戏。
• 南方夏季午后普遍午休，如有流量，长连接下载居多，短连接突发很少。
• 早高峰非开车通勤的人们看电子书，看剧，突发流量少，晚高峰同理。
• 晚上 10 点后刷短视频的居多…
• …

给定足够久的时间段，采集足够的数据，一定会总结出以上规律。

我用交通作例。在自己生活的城市，你开车上下班，你肯定知道哪条路在什么时间段拥堵，什么时间段畅通，你会根据这认知安排出行，所以道路虽堵，但也不至于堵上一小时，第一天上班除外，因为第一天没有任何道路信息。

此思路用来指导互联网拥塞控制完全可行。

• 突发流量大的时段，RTT 可信度低，需保守传输。
• 突发流量小的时代，RTT 作为拥塞信号可信度高。
• 深夜里大可激进些传输，但端到端不要跨越 6 个以上时区。
• 重大节日，赛事，演唱会直播，尽可能拼命抢带宽，大概率有用。
• 下午三四点钟做大文件传输。
• …

只要数据足够，精度度就会继续提升。

好的拥塞控制算法，说到底需要足够的信息注入，同样传输一个文件，凌晨的传输效率一定比晚高峰高，没什么理论，这是人生物钟决定的。

端到端实时采集的信息拥有无法突破的上限，这个上限不由算法盲猜能力决定，它是固有的。

说实话，端到端实时采集并不是实时的，它至少滞后半个 RTT，即使上帝也不足以确定曾经发生的事件会延续到将来，基于滞后的反馈信息做决断，合理但不精确。

近年来，各互联网厂商纷纷卷起 DC 网络传输，如代表性的 HPCC。说到底这些算法无一例外都在利用额外注入的信息，需要让交换机反馈信息，就要修改交换机。没有端到端的算法可以原地完成这些。

BBR 将主机提供的信息运用到极致，该能力为 BBR 提供了更精确的信息，如 us 级时间戳，ns 级高精度时钟，但在主机外，BBR 依然一无所知。

是时候让人类心智模型起作用了。今天是周末，此刻是凌晨三点，我要传输一个 10 TB 的文件，我要不要手工增加 cwnd 实现超发呢？

真正的程序员大概率看不起这个，认为它太简单，要么认为它过于依赖数据，但真的有用的就是高尚的。

它并不简单。该理念背后需要足够的大数据作支撑，需要一个合理的评价体系做支撑。

数据引导过程，经理决定导向，别靠冥想也别靠算法啦。

没地方全局设计，就花时间观察规律，效果是一样的。我认为我表达清楚了。

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