没有比Little‘s Law更简单的表述了：
- 系统中物体的平均数量(L)等于物体离开系统的平均速率(
)和每个物体在系统中停留的平均时间(W)的乘积。
网络是一个“需要迅速离开的系统”。对于一个路由器，当buffer被排满时，按照Litttle’s Law：
其中L是buffer容量，即带宽，W则为排队延时。buffer越大，延时越大。
在追求低延时传输的今天，降低延时的有效方法就是减少buffer。
这看似一个自然而然的道理却总是被反其道而行，小buffer的反对者建议传输协议保持矜持，保守填充buffer，但事实却是只要有buffer，无论多大，它总是会被填满。
结果是在传统实物观念，摩尔定律和商业利益的共同驱动下，buffer越做越大，甚至成了高品质的指标。1GB buffer的设备肯定比100MB buffer的设备用料足，卖的贵。
网络本身就是一个buffer，它在时间中延展，该buffer横截面是BltBW，长度延展到RTT(或其一半)。理论上任何静态buffer都没必要。
但按照排队理论，需要一个buffer来暂存统计突发到达，这个buffer的作用仅平滑统计突发，无法增加网络容量。理论上若完全pacing到达，该buffer便可以取消。
任何buffer都会带来额外延时。buffer越大越孬种。
最理想情况是完全pacing，取消所有buffer，最现实的理想情况是buffer大小刚好平滑统计突发。剩下的交给端到端拥塞控制。一个好的(而不是激进定制的)算法可以完美适应小buffer。
无论标准AIMD还是BBR，大buffer除了增加延时，并无益处。buffer是一个贷方，按照借贷模型，出来混早晚要还的。
小buffer有利于拥塞控制，但需所有参与方协作，这是社会学和博弈论范畴，工人们对此一筹莫展，但治不了经理还治不了主机么，工人们可以降低接收端主机协议栈的buffer。
接收端主机协议栈是端到端传输中接近目的地的那一环，减少接收buffer对于降低端到端延时非常有效。但还是要啰嗦几句，Linux系统若降低接收buffer，带宽会下降，因为通告窗口是根据接收buffer算的，这个错误的行为必须订正。
再宽的路也会拥堵，不要建宽路，要建多条窄路。有个很有趣的issue，为什么无论多大的停车场都会被停满，为什么无论多宽的路还是会堵车，为什么无论再大的房间总是空间不够。以前我用排队论分析过，但不得要领，模型也不match。其实并没那么复杂，问题转化为，为什么看见buffer就要填满它？
这要把空间和时间辩证看待才能得到解答。
时间的松弛可以让你把做一件事的节奏放缓，也可以让你保持紧张节奏做更多的事，你选哪一个？
空间的松弛可以让你把一件物品的体积平摊，也可以让你保持原体积吸纳更多物品，你选哪一个？
对于时间，绝大多数人选择放缓节奏，对于空间，绝大多数人选择保持体积吸纳更多物品，说到底就是懒，不想额外做功，但时间的债需要从空间还回来，反之亦然。做最省力的就是了。
听经理的就对了。
为什么空间总是会被填满，无论多大的空间，总是会被填满。这个问题思考了很久，直到联系到了经理才能有个大概的答案。同时联系Little’s Law，联系rcvbuff，有点意思，写篇短文。
浙江温州皮鞋湿，下雨进水不会胖。
