提高带宽利用率！为什么要Pacing？

1986年的TCP拥塞崩溃事件让AIMD模型在1988年后出来应对时局，从此以后互联网协议的设计者和实现者聚焦于如何让网络不拥塞。

毫无疑问，这里最重要的是公平性，而非效率。不管是慢启动，加性增窗，乘性减窗，还是后来的Vegas算法的主动退让，其目标都在于保证多条流经过共享链路时能公平共享带宽。这种机制的目标不是让单条流跑得更快。

换句话说，1988年的模型是不患寡而患不均的模型。其中的 “不患寡” 给很多人带来了误解。

事情在2010年前后悄悄地起了变化。

AIMD模型的目标是不患寡，而患不均，这注定单条TCP的带宽利用率极低，因此HTTP协议一般会采用多条TCP流捆绑的方式来传输Web服务器的数据以增加带宽，然而多TCP连接意味着连接管理的开销会增大，同时数据同步的开销也会增加，这导致了人们倾向于使用单独的连接来完成所有的事情。

然而，又是一个然而，TCP固有的队头拥塞问题导致单独的TCP连接无法很好的进行HTTP流的多路复用，这个难题促进了Google对QUIC协议的设计和发布，同时，QUIC的一些显而易见的优势点也逐步的回移进了TCP(如果可能的话)。

不管怎样，如今确实是倾向于减少TCP连接数量，这便弱化了公平性的约束，如今，提高单条连接的带宽利用率，成了迫在眉睫的硬需求。

如何度量带宽利用率？

我倾向于用一种 综合的效用 来度量，而不仅仅是 把带宽跑满， 倘若如此，一个包发十遍肯定能把带宽跑满，然而此时的利用率高吗？

我倾向于把代价也算进去，最终，我们需要，在带宽尽可能大的同时，保证代价尽可能小。

设G GG为收益ÿ