基于管道共享的流控策略（2）

上一篇，我们提到了流量通道的基本分类和配置原则，这一篇我们来讲讲上行和下行控制的关系。

我最早先接触到的宽带流控是来自上海贝尔的阿尔卡特宽带大猫白皮书，那里面对ADSL的不对称原理做了比较通俗的表述。他们认为ADSL技术之所以能够成功应用，主要是对网页访问流量在客户下行，上行的流量是微小的。他们给上行流量的定义是，发出网页请求和回应下载标识，其他的流量都在下行。对于那个以网页为主的时代来说确实是这样的，因为P2P那时候还出于萌芽阶段，PHP和JSP等动态网页还没有大规模流行，不像今天打开一个网页需要与后台进行大量的互动信息传输。互动信息是需要从用户端发送大量的信息和应答的，虽然看起来流量不是很大，但是对实时性要求很高。就好像我们在打电话，这一端说句话而另一端迟迟没有答复，那么这次对话我想也就没有进行下去的可能了。但是点播歌曲的时候只要选歌然后静静听就可以了，不需要互动过程。好吧，我想我说清楚了。

由于现在访问网页需要进行大量的互动，所以对上行的实时性要求就很严格了。教科书上告诉我们说带宽大于峰值2.5倍的时候传输延迟最接近于0，我理解就是把带宽设置为数据流量的2.5倍时基本上不会有延迟。可是怎么样来确定流量有多大呢？确定了流量又是否能保证带宽一定是流量的2.5倍呢？通过不断的实验，我发现当上行和下行带宽比例达到2.5:1时基本上可以满足这个条件设定。也就是说，假定我们为某用户设定的下载带宽为1Mbps，那么他的上行带宽就应该是2.5Mbps。现在我们来总结一下，上行与下行的关系公式为：

上行带宽=下行峰值带宽*2.5倍

为每个人都设置独享的上行带宽显然不切实际，上行带宽是可以共享的。这个共享值是多大呢？按照以太网共享带宽的可用公式反推得到：

最大客户数=峰值带宽/0.37

举例说明：

一条2Mbps的光纤宽带，如果保证每个用户都有1M体验，那么最大可以保证【（1/0.37）*2】/0.37=14.6个人。如果保证每个用户512K体验，一定会有人说是29个人。实际上，应该是213个人，因为这是呈几何级数增长的。当然，213个人不会在同一时间点发出访问请求，以太网会为这些请求进行排序。