>>
原文链接： http://www.prollblog.cn/read.php/242.htm
作者： proll
<<

一款具有很多功能DSL modem和路由器驱动软件,可以充分使用你的ISDN和DSL连接。
程序特点：
高级Traffic Shaping （通信量调整功能）；
用于DSL 调制解调器和路由器；
与通用的 PPPoE 驱动器兼容；
自动识别路由器；
自动校准；
应答游戏以及例如 eMule，Kazaa 等的对等网络；
可自由定义的优先级；  
禁拨高收费电话功能；
通信量计数器及计时器；
防火墙；

时间同步；
最优远程数据通信网连接提高网速；

智能识别不在使用中的连接等!

原理介绍
TCP 封包交换过程

    * TCP 采取交握式封包传送机制，传送端必须等待接收端的 ACK（认知）封包传回后，才会继续传送下一个封包。也就是说如果，传送端一直等不到接收端的 ACK 封包时，它会一直等待到传回 ACK 为止，这段时间不会传送任何新的封包；超过时间后，会切断与接收端的通信。
    * 为此，现有 ADSL 多半建议使用者将 TCP 封包长度尽可能开到最大，目的是减少 ACK 交握讯号的次数。然而这么做会有个副作用，就是在全速上传时，排队在后面的 ACK 封包，会因为前一个封包上传占据大量时间，无法“及时”传送给“传送端”，造成 (1) 的状况。
    * 如果将 TCP 封包长度减少，则单位时间内 ACK 交握次数增加，“或许”可以减轻因为全速上传造成的排队中的 ACK 封包的延迟“机率”，但仍然因为较多的 overhead（封包本身的控制区块所占用的频宽），也没有占多少便宜。
    * 整理 (2) 与 (3) 可发现，问题都出在 ACK 交握的时间点是否能在“传送端”等待时间之内，这是因为 Windows 内建的 TCP/IP 驱动器，没有“封包优先权”的设计，造成“上传满档压死下载”的奇特现象。

cFos / cFosSpeed 的原理 - 关键的 Traffic Shaping

    * 这张图就是在说没有收到“接收端”ACK 封包时，“传送端”停止下一个封包输出。左边是“接收端”、右边是“传送端”、红色小方块是传送端等待输出的封包、正在传送的绿色是“ACK 封包”。由于 TCP 交握机制的运作，收到一个红色小方块时，就必须传一个绿色小方块对方，告诉对方我已经确实的收到了，接下来才能再传一个红色小方块过来。


若无提高 ACK 封包的优先权，在网路上传流量繁忙的时候，因为 ACK 封包延迟送出，而造成下载不顺的情况出现。

那 么启动 Traffic Shaping 以后的结果是什么？很明显的发现，绿色的小方块（ACK 封包）可以“插队”在蓝色小方块（上传封包）之间。而且插队的位置，是在下一个要传送封包的预备位置。也就是说，封包之间产生了“优先权”的机制·所以红 色小方块（下传封包）可以不受蓝色小方块（上传封包）的影响，继续的输出资料给接收端。对于 P2P 来说，这正是最迫切需要的功能。