|
|
发表于 2007-7-6 09:18:39
|
显示全部楼层
cFos/cFosSpeed
文章来源 [發現]cFos cFosSpeed 有效增強 P2P 流量效率的工具 (Rev 2 校正說明).htm (79.77 KB)
cFos/cFosSpeed提供一种新的上传流量「封包重新排序」的功能，称之为「Traffic Shaping」.
就 TCP 封包交换的过程, 先说明一下:
(1) TCP 采取交握式封包传送机制, 传送端必须等待接收端的 ACK (认知) 封包传回后, 才会继续传送下一个封包. 也就是说如果, 传送端一直等不到接收端的 ACK 封包时, (1a) 他会一直等待到传回 ACK 为止, 这段时间他不会传送任何新的封包 (1b) 超过时间后, 他会切断与接收端的通信.
(2) 为此, 现有 ADSL 多半建议使用者将 TCP 封包长度仅可能开到最大, 目的是减少 ACK 交握讯号的次数. 然而这么做会有个副作用, 就是在全速上传时, 排队在后面的 ACK 封包, 会因为前一个封包上传占据大量时间, 无法「及时」传送给「传送端」, 造成 (1a) or (1b) 的状况.
(3) 如果将 TCP 封包长度减少, 则单位时间内 ACK 交握次数增加, 「或许」可以减轻因为全速上传造成的排队中, ACK 封包的延迟「机率」, 但仍然因为较多的 Overhead (封包本身的控制区块所占用的频宽), 也没有占多少便宜.
(4) 整理 (2) and (3) 可发现, 问题都出在 ACK 交握的时间点是否能在「传送端」等待时间之内, 这是因为 Windows 内建的 TCPIP 驱动器, 没有「封包优先权」的设计, 造成「上传满档压死下载」的奇特现象.
这张图就是在说没有收到「接收端」ACK 封包时, 「传送端」停止下一个封包输出. 左边是「接收端」, 右边是「传送端」. 红色小方块是传送端等待输出的封包, , 正在传送的绿色是「ACK 封包」, 由于 TCP 交握机制的运作, 收到一个红色小方块时, 就必须传一个绿色小方块对方, 告诉他我已经确实的收到了, 接下来才能再传一个红色小方块过来.
x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x
那么启动 Traffic Shaping 以后的结果是什么?
很明显的发现, 绿色的小方块 (ACK 封包) 可以「插队」在蓝色小方块之间, 而且插队的位置, 是在下一个要传送封包的预备位置, 也就是说, 封包之间产生了「优先权」的机制. 所以红色小方块 (下载) 可以不受蓝色小方块 (上传) 的影响, 继续的输出数据给接收端. 对于 P2P 来说, 这正是最迫切需要的功能.
如此一来, 即便上传达到满档, 依然可以保持不断的下载, 也就是说「上传与下载之间的关系, 不再互相牵制, 上传满档压死下载是历史名词」; 至少笔者试用几周来, 约有 95% 的时间, 看到上传与下载各自满档的状况, 在过去这是不可能的, 只要上传达到满档, 接下来下载就准备阵亡, 现在有了 Traffic Shaping 这种机制, 此情形已经看不见了.
================================
下面这张图是没有收到「接收端」ACK 封包时, 「传送端」停止下一个封包输出
(左边是你家的计算机, 右边是 Server)
下面没有使用CFos 的封包图(ACK封包被延迟送出)
下面是使用CFos 之后的封包流量图(ACK封包插队立刻送出)
[ 本帖最后由 BiscuiT 于 2007-7-6 09:26 编辑 ] |
|
发表于 2007-7-6 10:19:11
