宽带限速的实现方式概述

带宽管理是一种非常复杂的事情，有很多种算法，也有很多种策略。
我们先看看策略。

现在的设备一般采取的Policy为：
（1）对incoming的数据包进行带宽限制（limit bandwidth）
（2）对outgoing的数据包进行带宽管理

1. 带宽限制
对带宽进行限制一般是采用基于Token的方式来进行的，简单的说就是token bucket，Panabit就是采用这种方式的。当Panabit收到一个数据包后，如果这个数据包
匹配到一个限速类的策略，这个策略的参数就是“数据通道”，Panabit会检查该数据通道剩余的Token是否足够允许这个数据包通过，如果够，就Pass，否则就Drop。
Token是通过一个高速的Timer定时增加的，增加的速率就是该数据通道的带宽。
这种方式的一个好处是，不需要对数据包进行排队，因此数据包不会被“Hold”住，所以减少了对内存的占用。同时，由于不排队，因此减少了数据包的延迟，这在高速
网络中是很重要的。

2. 带宽管理
带宽管理一般是针对Outgoing数据包而言的，简单的说，就是将要发送出去的数据包放到一个队列中，然后由数据包scheduler来将数据包发送出去。Scheduler何时
将什么样的数据包发送出去是由排队策略决定的。有很多种方式，但是比较常用的有：
--WFQ（Weight Fail Queue）
--基于Token

WFQ：给每个队列一个权值，这些队列会共享固定的带宽，如果某个队列比较空闲，其它队列可以超额使用这部分空闲的带宽，但是一旦该队列需要时，它会马上获得
应用的那部分带宽。
Token：同带宽限制一样。

记得这个眼睛吗

关于观看索引的改变

最近发现了一件事看cnbeta订阅的时候内容已经不是主要的了。
评论才是我最爱看的东西。里边充斥着各种吵架谩骂。

其实我很讨厌人为的将技术性的东西分成不同的流派，很搞笑的一件事情。
那里充满了一些无所事事的人。说实话留意信息的人都不会每天跑到那里去看什么评论，我都是通过Google Raeder订阅来看一下概要就完事。保证我不至于处在火星状态。


在这里要感谢那些给cnbeta投递的人还有cnbeta的编辑们。你们在给他家做最新的it信息的索引，但是有一些人就是白吃。自己做不出来的东西就在那里肆无忌惮的谩骂着。

说实话那个留言因该像三表一样处理改名叫黑猩猩，看信息的人是不会留言的。只有黑猩猩才会去关心那种东西。

就GFW问题起诉中国电信！

国内终于有人要就 长城防火墙计划（GFW） 问题跟中国电信打官司了。

此案将于5月29日（周二）上午9：00开庭。地点是上海浦东新区丁香路611号。

详情见《互联网管制不当，中国电信遭起诉》

党的喉舌们估计都不会报道此事，我们地下传播好了


是该支持下。

星空很美丽不是吗？

别看这个题目哦。其实我很久没看到过星星了。城市里是没有星星的，它只属于我们的童年。下一代人的童年里估计已经没有星星了。我看过姨父家里有个不错的天文望远镜，但是北京的天空是不容许他用天文望远镜的。呵呵

手头的第一个活

第一次给人做个东西。一个B2C的系统，接手后就有些后悔了。一个多商户的B2C系统一般都需要20000左右的年费。而我给人做一个才2000块钱。=_=!哎，真郁闷。

对自己的一次小挑战

懒惰的本性又开始显示了出来。毕业设计一直拖到了现在。

下周就要打印论文了现在还没有写^_^，最有意思的还是已经写好的程序已经被自己否定掉了。
重新构建的内核（只有一个架构而已）还没做任何的功能实现。与其说是用一套成熟的技术去做毕业设计不如说是现学一个比较标准化的技术重新开发一样。自己突然感觉是不是太自大了，突然去学习两个标准化技术然后在一个星期内去完成这些东西，还要附带一个带功能说明的论文。

一开始以为只要写好代码说明就行了。现在看来不是的还要介绍所用到的技术，为什么用到。难道我就写上一行“因为这是标准，我对新的技术感兴趣”显然这样做非常的不现实毕竟论文还是要8000字的。