有谁知道锐速的加速原理？

[Yifan Gao]

今天发现一个有趣的软件锐速，可以加速单线程链接。网上有人说可以加速数倍，我怀着将信将疑的心态尝试了一下，将其安装在DigitalOcean上。

100mb文件下载速度（DO新加坡节点->科大教育网）

运行前：wget单线程 2MB/s

运行后：wget单线程 15MB/s

大家有没有什么看法？

-- 
Yifan Gao

[Allan Lu]

http://v2ex.com/t/116480

Soli Deo gloria.

Allan Lu
Email: al...@ream.at
梦.:如此短暂: http://d.ream.at

--
-- 来自USTC LUG
请使用gmail订阅，不要灌水。
更多信息more info：http://groups.google.com/group/ustc_lug?hl=en?hl=en

---
You received this message because you are subscribed to the Google Groups "USTC_LUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ustc_lug+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Bojie Li]

不要使用此类软件，它会破坏与你共享网络链路者的公平性。TCP 是有拥塞控制的，也就是它感受到网络拥塞的时候就会减慢发送速率。在 Internet 上感受到拥塞的方法有两种，一是丢包（假定丢包都是拥塞导致的），二是往返延迟（RTT）增大。如果把拥塞控制去掉（例如像某些下载软件一样采用 UDP + 丢包重传），自然能挤掉链路上其他的 TCP 流，表现出很快的下载速度。

锐速宣称是基于 Zeta TCP，它是有拥塞控制的，不过会把其他常见的 TCP 实现（如经典的 TCP Reno，Windows Vista+ 的 CTCP，Linux/BSD 的 Cubic TCP）挤掉，也就是不公平。由于 Internet 不可能在一夜间更换 TCP 实现，任何会导致不公平的 TCP 拥塞控制算法都不能大规模使用。

至于 Wikipedia Zeta TCP 词条宣称的 “不论对方是 Zeta TCP 还是其他 TCP 都能加速”，事实上是任何有实用价值的 TCP 改进算法的必要条件（总不能要求客户端和服务器同时升级系统吧）。词条中的 Congestion Avoidance 提出把基于丢包的和基于往返延迟的拥塞控制相结合，这也不是什么新思路，事实上 Windows Vista 至今的 Compound TCP 就是这样做的，这里的关键是“结合”的细节。词条中还提到 Loss Detection，也就是早些发现丢包的可能并予以重传，算法细节没有公布，但似乎比较拙劣，事实上 RFC 5827 已经定义了新的丢包检测与重传算法，并由 Google 实现在了 Linux 3.5 中。

设计快速的 TCP 拥塞控制算法不难，难点是要与常见的 TCP 实现保证公平。感兴趣的可以看我老板的回忆文章：

http://blog.sina.com.cn/s/blog_4caedc7a0100gd8f.html

像 Zeta TCP 这样的适用于小规模的部署，所有机器都要部署 Zeta TCP。如果你只是想尽快下载，不在乎别人抱怨，那就用 UDP + 应用层丢包重传吧。

2014-06-25 22:22 GMT+08:00 Yifan Gao <ylgao...@gmail.com>:

--

[Ding ZhiGang]

好啊，今天freeshell上wget美国的DO只有10K左右是不是就是被你的锐速害的啊。。。

---------

Ding ZhiGang

--

[Bojie Li]

2014-06-25 23:36 GMT+08:00 Ding ZhiGang <dingz...@gmail.com>:

好啊，今天freeshell上wget美国的DO只有10K左右是不是就是被你的锐速害的啊。。。

@Yifan Gao 你是在哪里做的实验？今天 LUG 服务器流量正常。

傍晚期间学校移动出口几乎被占满了，因此访问国外网络速度缓慢。移动出口高峰期经常会这样，不一定是锐速导致的。

[Yifan Gao]

我在科大云上做的实验，使用的是教育网出口，实验共持续了8秒。

-- 
Yifan Gao

开启 2014年6月26日 at 上午12:27:51, Bojie Li (boj...@gmail.com) 写:

[Ding ZhiGang]

是不是有其他什么原因？现在freeshell感觉不是很正常啊。

Node#1，这个是Freeshell下的wget结果

================================================================

root@mthk:~# wgethttps://downloads-packages.s3.amazonaws.com/centos-6.5/gitlab-7.0.0_omnibus-1.el6.x86_64.rpm

--2014-06-26 00:10:38--  https://downloads-packages.s3.amazonaws.com/centos-6.5/gitlab-7.0.0_omnibus-1.el6.x86_64.rpm

Resolving downloads-packages.s3.amazonaws.com... failed: Name or service not known.

wget: unable to resolve host address `downloads-packages.s3.amazonaws.com'

root@mthk:~# wget162.243.159.129/gitlab-7.0.0_omnibus-1.el6.x86_64.rpm

--2014-06-26 00:11:00--  http://162.243.159.129/gitlab-7.0.0_omnibus-1.el6.x86_64.rpm

Connecting to 162.243.159.129:80... failed: Connection timed out.

Retrying.

--2014-06-26 00:12:04--  (try: 2)  http://162.243.159.129/gitlab-7.0.0_omnibus-1.el6.x86_64.rpm

Connecting to 162.243.159.129:80...

这个是DO下的wget结果

================================================================

wget https://downloads-packages.s3.amazonaws.com/centos-6.5/gitlab-7.0.0_omnibus-1.el6.x86_64.rpm

--2014-06-26 00:07:14--  https://downloads-packages.s3.amazonaws.com/centos-6.5/gitlab-7.0.0_omnibus-1.el6.x86_64.rpm

Resolving downloads-packages.s3.amazonaws.com... 54.239.36.25

Connecting to downloads-packages.s3.amazonaws.com|54.239.36.25|:443... connected.

HTTP request sent, awaiting response... 200 OK

Length: 286298101 (273M) [application/x-rpm]

Saving to: “gitlab-7.0.0_omnibus-1.el6.x86_64.rpm”

100%[========================================>] 286,298,101 23.6M/s   in 22s

2014-06-26 00:07:37 (12.4 MB/s) - “gitlab-7.0.0_omnibus-1.el6.x86_64.rpm” saved [286298101/286298101]

---------

Ding ZhiGang

[Bojie Li]

那是由于学校移动出口凌晨维护，我切换到电信出口了。电信出口出国丢包率很高，所以不太稳定。移动出口恢复半个小时后，就自动切换回来了（我挂了个脚本）。现在已经在用移动出口了。

[Bojie Li]

现在科大移动出口正在维护（见 BBS ustcnet 版）（吐槽一下，最近几个月维护好几次了），VPN 临时切换到了电信出口，电信出口丢包严重，因此现在网络不是很好。

[Scott Mon]

作为本科生刚学完计算机网络，看完此回复有了一些更深入的理解，受教受教。

[Bojie Li]

2014-06-26 2:21 GMT+08:00 Bojie Li <boj...@gmail.com>:

现在科大移动出口正在维护（见 BBS ustcnet 版）（吐槽一下，最近几个月维护好几次了），VPN 临时切换到了电信出口，电信出口丢包严重，因此现在网络不是很好。

Sorry, 这是一封延迟的邮件……手机 Gmail 不稳定，没想到过了 1 小时竟然发出来了……

[hui zhang]

这个能突破 公网 带宽限制不

在 2014年6月25日星期三UTC+8下午10时22分30秒，Yifan Gao写道：

[Bojie Li]

2014-06-30 17:16 GMT+08:00 hui zhang <fastf...@gmail.com>:

这个能突破 公网 带宽限制不

如果带宽限制是运营商做的，无论用什么通信协议都不能突破。

 

--

[Yifan Gao]

那迅雷光速会员是怎么动态突破带宽的丫？有可能伪造请求吗？

Bojie Li <boj...@gmail.com>于2014年6月30日星期一写道：

--
Yifan Gao(高一凡)

[Thomas Copper]

迅雷什么时候突破过带宽了？

[Yifan Gao]

一年前。http://act.vip.xunlei.com/ebit/2014/msyl/

PS:不是突破物理带宽极限，只是突破运营商限速.

在 2014年7月1日星期二UTC+8下午12时25分46秒，DeepImpact写道：

迅雷什么时候突破过带宽了？

On Jul 1, 2014 12:12 PM, "Yifan Gao" <ylgao...@gmail.com> wrote:

那迅雷光速会员是怎么动态突破带宽的丫？有可能伪造请求吗？

Bojie Li <boj...@gmail.com>于2014年6月30日星期一写道：

2014-06-30 17:16 GMT+08:00 hui zhang <fastf...@gmail.com>:

这个能突破 公网 带宽限制不

如果带宽限制是运营商做的，无论用什么通信协议都不能突破。

 

在 2014年6月25日星期三UTC+8下午10时22分30秒，Yifan Gao写道：

今天发现一个有趣的软件锐速，可以加速单线程链接。网上有人说可以加速数倍，我怀着将信将疑的心态尝试了一下，将其安装在DigitalOcean上。

100mb文件下载速度（DO新加坡节点->科大教育网）

运行前：wget单线程 2MB/s

运行后：wget单线程 15MB/s

大家有没有什么看法？

-- 
Yifan Gao

--
-- 来自USTC LUG
请使用gmail订阅，不要灌水。
更多信息more info：http://groups.google.com/group/ustc_lug?hl=en?hl=en

---
You received this message because you are subscribed to the Google Groups "USTC_LUG" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ustc_lug+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
-- 来自USTC LUG
请使用gmail订阅，不要灌水。
更多信息more info：http://groups.google.com/group/ustc_lug?hl=en?hl=en

---
You received this message because you are subscribed to the Google Groups "USTC_LUG" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ustc_lug+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[hui zhang]

可以的

达到过8MB

在 2014年7月1日星期二UTC+8下午12时25分46秒，DeepImpact写道：

迅雷什么时候突破过带宽了？

On Jul 1, 2014 12:12 PM, "Yifan Gao" <ylgao...@gmail.com> wrote:

那迅雷光速会员是怎么动态突破带宽的丫？有可能伪造请求吗？

Bojie Li <boj...@gmail.com>于2014年6月30日星期一写道：

2014-06-30 17:16 GMT+08:00 hui zhang <fastf...@gmail.com>:

这个能突破 公网 带宽限制不

如果带宽限制是运营商做的，无论用什么通信协议都不能突破。

 

在 2014年6月25日星期三UTC+8下午10时22分30秒，Yifan Gao写道：

今天发现一个有趣的软件锐速，可以加速单线程链接。网上有人说可以加速数倍，我怀着将信将疑的心态尝试了一下，将其安装在DigitalOcean上。

100mb文件下载速度（DO新加坡节点->科大教育网）

运行前：wget单线程 2MB/s

运行后：wget单线程 15MB/s

大家有没有什么看法？

-- 
Yifan Gao

--
-- 来自USTC LUG
请使用gmail订阅，不要灌水。
更多信息more info：http://groups.google.com/group/ustc_lug?hl=en?hl=en

---
You received this message because you are subscribed to the Google Groups "USTC_LUG" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ustc_lug+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
-- 来自USTC LUG
请使用gmail订阅，不要灌水。
更多信息more info：http://groups.google.com/group/ustc_lug?hl=en?hl=en

---
You received this message because you are subscribed to the Google Groups "USTC_LUG" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ustc_lug+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Roy Zhang]

这个应该是迅雷与运营商合作了…

[Bojie Li]

运营商的带宽限制一般是在与公网的接口处，而不是在你接入的交换机上。如果两个同一运营商的用户之间对传，也可以达到很快的速度。像 360 软件中心下载软件就用了 p2p 技术，因此比较快。迅雷光速我没用过，不过不外乎两种方法，一是局域网 p2p，二是迅雷把服务器部署到运营商那里，或者是部署到不限速的内网，或者是跟运营商签协议加入不限速的白名单。

[Yifan Gao]

迅雷光速会员加速的只是高速通道流量，加速前加速后连接的是同一台服务器。

-- 
Yifan Gao

开启 2014年7月1日 at 下午12:48:05, Bojie Li (boj...@gmail.com) 写:

[Bojie Li]

那可能是迅雷的服务器对非光速会员做了限速，光速会员就放开了限速。

[Yifan Gao]

挖个坟。青云新出了一个 App Center，第一批上线的应用中竟然有锐速。

--

Yifan

[汤先锋]

如果对用户有类似运营商的那种限速这种软件应该就没有用了啊

在 2014年6月25日星期三 UTC+8下午11:24:02，Bojie Li写道：

[Felix Yan]

On 05/15/2015 06:37 PM, 汤先锋 wrote:
> 如果对用户有类似运营商的那种限速这种软件应该就没有用了啊
>
> 在 2014年6月25日星期三 UTC+8下午11:24:02，Bojie Li写道：
>>
>> 不要使用此类软件，它会破坏与你共享网络链路者的公平性。TCP 是有拥塞控制的，也就是它感受到网络拥塞的时候就会减慢发送速率。在 Internet
>> 上感受到拥塞的方法有两种，一是丢包（假定丢包都是拥塞导致的），二是往返延迟（RTT）增大。如果把拥塞控制去掉（例如像某些下载软件一样采用 UDP +
>> 丢包重传），自然能挤掉链路上其他的 TCP 流，表现出很快的下载速度。
>>
>> 锐速宣称是基于 Zeta TCP，它是有拥塞控制的，不过会把其他常见的 TCP 实现（如经典的 TCP Reno，Windows Vista+ 的
>> CTCP，Linux/BSD 的 Cubic TCP）挤掉，也就是不公平。由于 Internet 不可能在一夜间更换 TCP 实现，任何会导致不公平的
>> TCP 拥塞控制算法都不能大规模使用。
>>
>> 至于 Wikipedia Zeta TCP 词条宣称的 “不论对方是 Zeta TCP 还是其他 TCP 都能加速”，事实上是任何有实用价值的
>> TCP 改进算法的必要条件（总不能要求客户端和服务器同时升级系统吧）。词条中的 Congestion Avoidance
>> 提出把基于丢包的和基于往返延迟的拥塞控制相结合，这也不是什么新思路，事实上 Windows Vista 至今的 Compound TCP
>> 就是这样做的，这里的关键是“结合”的细节。词条中还提到 Loss
>> Detection，也就是早些发现丢包的可能并予以重传，算法细节没有公布，但似乎比较拙劣，事实上 RFC 5827
>> 已经定义了新的丢包检测与重传算法，并由 Google 实现在了 Linux 3.5 中。
>>
>> 设计快速的 TCP 拥塞控制算法不难，难点是要与常见的 TCP 实现保证公平。感兴趣的可以看我老板的回忆文章：
>> http://blog.sina.com.cn/s/blog_4caedc7a0100gd8f.html
>> 像 Zeta TCP 这样的适用于小规模的部署，所有机器都要部署 Zeta TCP。如果你只是想尽快下载，不在乎别人抱怨，那就用 UDP +
>> 应用层丢包重传吧。

既然已经被挖起来了……

以前我看到一篇论文[1]比较各 TCP 拥塞控制算法，其中 westwood 与其他所有算
法在同一个网络中时都有明显的优势。于是我试着把它启用到我翻墙用的 vps
上，测速有相当明显的提升（相较 hybla 等）。

不过如 Bojie 当时所说的，这同样是一种不公平的做法。所以你可以尝试，但是
不推荐大规模应用……

[1]
http://www.satnac.org.za/proceedings/2012/papers/2.Core_Network_Technologies/15.pdf

--
Regards,
Felix Yan

[Adrian Zhang]

佩服！看了看你老板的博客。打算对我管理的所有Linux主机都部署CTCP。大概2000台规模。

[Bojie Li]

CTCP 就是 Windows vista+ 系统里面标准的 TCP 实现啊，Linux 上也有 CTCP 的实现，不过后来被从内核主线中移除了。你说的 CTCP 是 compound TCP 吧？

[Adrian Zhang]

是的。说的就是compound TCP

You received this message because you are subscribed to a topic in the Google Groups "USTC_LUG" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ustc_lug/Ka-vrTWcSOg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ustc_lug+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Yours sincerely,

Adrian Zhang