简单看一个图：
它不是互联网本身，但这是典型网络的必要组件，它决定了 flow 如何从从一边流向另一边：一条 flow 经过交换节点通过 NIC 被导入一条链路前在 buffer 中排队。
现如今大多数工程师的工作都在折腾那个单独的盒子，少部分人关注 flow 和盒子的相互作用。
整体来看，flow 随接入终端(确切说应该是 app)的增加指数级增加(规模为 n 的网络增加一个节点，理论上增加 n 条 flow)，这意味着 NIC 带宽即使不能随着终端接入速度同步增长，至少它也应该足够快地升级，尽力满足快速增长的带宽需求，否则 buffer 则要大增，而 buffer 只能提供传输假象，无限增加的时延揭穿了这假象。
因此，我们合理假设，NIC 带宽在快速增加，而 buffer 则相对保持稳定。
这意味着交换节点 buffer 排空速度越来越快，但与此同时，flow 的 rtt 却至多保持不变(传播时延)，还会稍微增加(排队时延)。拥塞表现在 buffer 排队，经典端到端拥塞控制需要将 buffer 排队这件事反馈到端，它固有滞后，拥塞信号的准确性取决于两点：
- buffer 排空速度，越慢越好。
- 信号反馈速度，越快越好。
打个比方，如果 buffer 在拥塞信号出发不久就迅速排空，那么这个信号就失效了，另一方面，即使 buffer 排空速度不变，信号反馈的速度很慢，这个信号的滞后性又严重了。
但若要取得好的传输体验，buffer 排空速度应该越快越好才对，拥塞本身和拥塞控制是矛盾的。想要更精确控制，就要慢一点，为了控制而控制。
so？经典拥塞控制将越来越失效。
事件持续时间和该事件的反馈时间的比值是核心，该比值越大，信息越精确，该比值越小，随机性越高。典型的例子是 CSMA/CD 和交换机，前者场景下该比值很小，引入随机就够，别的什么都别做，就像猜硬币，盲猜 50% 就 OK，任何启发只能削弱准确性，而后者场景下该比值非常大，便可以采用精确调度的方式。
另一个例子是足球和射击，足球速度慢，和球员奔跑速度在同一量级，球在飞行时，球员有足够时间重新布局位置，对足球比赛更多的是在宏观统计上的控制，而不存在针对某人，某坐标的精确控制，而射击则是另一个极端是射击，由于子弹速度远大于被射物体的移动速度，所以采用梭哈方式就更浪费，因为信息准确，可信度高。
现如今的互联网越来越像足球比赛，而不是射击。
…
至于数据中心，按以上原则倾向于启发精确控制，数据中心拥塞控制模型和广域网很不同，它更依赖精确信息，这就是为什么 google swift 好的原因，而广域网拥塞控制，足够模糊的 cubic 就够了。bbr 是另一种企图，它希望在模糊的环境做精确控制，也只有 google 自己的 B4 可以满足它了。
有点悲观，但只针对传统的，经典的拥塞控制领域，未来的另一条路完全是另一个方式，谁先发现谁抢跑。
…
和本文结合(联合，而不是反驳)的是另一个观点，随着带宽增加，app-limited 将越发可能，资源丰富时资源匮乏时的控制方式是根本不同的，早在农业时代，动力是稀缺的，人们倾向于节省动力，发展是收敛的，到了工业时代，动力是丰富的，人们倾向于不在乎甚至浪费动力，发展是粗旷野蛮的，就这个意思。
本文启发自昨天中午发的一个朋友圈：
皮鞋没有蹬上，露着白袜子。
浙江温州皮鞋湿，下雨进水不会胖。
