mirror of
https://github.com/wangyu-/UDPspeeder.git
synced 2025-01-18 22:09:35 +08:00
qMerge branch 'master' of https://github.com/wangyu-/UDPspeeder
This commit is contained in:
commit
1ca82311ec
14
README.md
14
README.md
@ -9,13 +9,18 @@ or
|
||||
|
||||
![image_vpn](/images/en/udpspeeder+openvpn3.PNG)
|
||||
|
||||
[简体中文](/doc/README.zh-cn.md)
|
||||
[简体中文](/doc/README.zh-cn.md)(内容更丰富)
|
||||
|
||||
###### Note
|
||||
You can use udp2raw with UDPspeeder together to bypass UDP firewalls.
|
||||
udp2raw:https://github.com/wangyu-/udp2raw-tunnel
|
||||
|
||||
|
||||
# Efficacy
|
||||
tested on a link with 100ms latency and 10% packet loss at both direction
|
||||
|
||||
### Ping Packet Loss
|
||||
![](/images/en/ping_compare3.PNG)
|
||||
![](/images/en/ping_compare_mode1.png)
|
||||
|
||||
### SCP Copy Speed
|
||||
![](/images/en/scp_compare2.PNG)
|
||||
@ -27,7 +32,7 @@ For Windows and MacOS You can run UDPspeeder inside [this](https://github.com/wa
|
||||
|
||||
# How does it work
|
||||
|
||||
UDPspeeder uses FEC(Forward Error Correction) to improve your connection's quality,at the cost of addtional bandwidth.The algorithm for FEC is called Reed-Solomon.
|
||||
UDPspeeder uses FEC(Forward Error Correction) to reduce packet loss rate,at the cost of addtional bandwidth.The algorithm for FEC is called Reed-Solomon.
|
||||
|
||||
![image0](/images/en/fec.PNG)
|
||||
|
||||
@ -68,6 +73,9 @@ Now connecting to UDP port 3333 at the client side is equivalent to connecting t
|
||||
`-f20:10` means sending 10 redundant packets for every 20 original packets.
|
||||
|
||||
`-k` enables simple XOR encryption to confuse DPI(Deep Packet Inspection)
|
||||
|
||||
To run stably,pay attention to MTU.
|
||||
|
||||
# Advanced Topic
|
||||
### Full Options
|
||||
```
|
||||
|
@ -19,7 +19,7 @@
|
||||
#### 原理简介
|
||||
主要原理是通过冗余数据来对抗网络的丢包,发送冗余数据的方式支持FEC(Forward Error Correction)和多倍发包,其中FEC算法是Reed-Solomon。
|
||||
|
||||
对于FEC方式的原理图:
|
||||
FEC方式的原理图:
|
||||
|
||||
![image0](/images/en/fec.PNG)
|
||||
|
||||
@ -43,6 +43,9 @@ Linux主机,可以是桌面版,可以是android手机/平板,可以是open
|
||||
|
||||
android版需要通过terminal运行。
|
||||
|
||||
###### 注意
|
||||
在使用虚拟机时,建议手动指定桥接到哪个网卡,不要设置成自动。否则可能会桥接到错误的网卡。
|
||||
|
||||
### 安装
|
||||
下载编译好的二进制文件,解压到本地和服务器的任意目录。
|
||||
|
||||
@ -51,11 +54,11 @@ https://github.com/wangyu-/UDPspeeder/releases
|
||||
### 运行
|
||||
假设你有一个server,ip为44.55.66.77,有一个服务监听在udp 7777端口。 假设你需要加速本地到44.55.66.77:7777的流量。
|
||||
```
|
||||
在client端运行:
|
||||
./speederv2 -c -l0.0.0.0:3333 -r44.55.66.77:4096 -f20:10 -k "passwd"
|
||||
|
||||
在server端运行:
|
||||
./speederv2 -s -l0.0.0.0:4096 -r127.0.0.1:7777 -f20:10 -k "passwd"
|
||||
|
||||
在client端运行:
|
||||
./speederv2 -c -l0.0.0.0:3333 -r44.55.66.77:4096 -f20:10 -k "passwd"
|
||||
```
|
||||
|
||||
现在client和server之间建立起了tunnel。想要连接44.55.66.77:7777,只需要连接 127.0.0.1:3333。来回的所有的udp流量会被加速。
|
||||
@ -119,40 +122,48 @@ log and help options:
|
||||
|
||||
```
|
||||
### 包发送选项,两端设置可以不同。 只影响本地包发送。
|
||||
##### -f 选项
|
||||
##### `-f` 选项
|
||||
设置fec参数,影响数据的冗余度。
|
||||
##### --timeout 选项
|
||||
##### `--timeout` 选项
|
||||
指定fec编码器在编码时候最多可以引入多大的延迟。越高fec越有效率,加速游戏时调低可以降低延迟。
|
||||
|
||||
##### --mode 选项
|
||||
##### `--mode` 选项 和 `--mtu`选项
|
||||
fec编码器的工作模式。对于mode 0,编码器会积攒一定数量的packet,然后把他们合并再切成等长的片段(切分长度由--mtu指定)。对于mode 1,编码器不会做任何切分,而是会把packet按最大长度对齐,fec冗余包的长度为对齐后的长度(最大长度)。
|
||||
|
||||
mode 0更省流量,在丢包率正常的情况下效果和mode 1是一样的;mode 1延迟更低,在极高丢包的情况下表现更好。
|
||||
|
||||
mode 0使用起来可以不用关注mtu,因为fec编码器会帮你把包切分到合理的大小。用mode 1时必须合理设置上层应用的mtu。
|
||||
mode 0使用起来可以不用关注mtu,因为fec编码器会帮你把包切分到合理的大小;用mode 1时必须合理设置上层应用的mtu。mode 0模式中--mtu选项决定切分的片段的长度,mode 1模式中--mtu选项只起检查作用,如果超过了--mtu指定的值,数据包会被丢弃。
|
||||
|
||||
mode 0模式的流量消耗基本完全透明。mode 1因为涉及到数据按最大长度对齐,所以流量消耗不是完全可预期。不过就实际使用来看,mode 1消耗的额外流量不多。
|
||||
|
||||
##### --report 选项
|
||||
mode 0模式数据包一般不会乱序,除非网络本身有严重乱序;mode 1模式被恢复的数据包可能会乱序,不过UDP本来就允许乱序,对绝大多数应用没有影响。mode 0模式反而可以纠正一些乱序情况。
|
||||
|
||||
##### `--report` 选项
|
||||
数据发送和接受报告。开启后可以根据此数据推测出包速和丢包率等特征。
|
||||
|
||||
##### -j 选项
|
||||
为原始数据的发送,增加一个延迟抖动值。这样上层应用计算出来的RTT方差会更大,以等待后续冗余包的到达,不至于发生在冗余包到达之前就触发重传的尴尬。配合-t选项使用。正常情况下跨国网络本身的延迟抖动就很大。可以不用设-j
|
||||
##### `-i` 选项
|
||||
指定一个时间窗口,长度为n毫秒。同一个fec分组的数据在发送时候会被均匀分散到这n毫秒中。可以对抗突发性的丢包。默认值是0,因为这个功能需要用到时钟,在某些虚拟机里时钟不稳定,可能会导致个别包出现非常大的延迟,所以默认关掉了。这个功能很有用,默认参数效果不理想时可以尝试打开。
|
||||
|
||||
##### -i 选项
|
||||
指定一个时间窗口,长度为n毫秒。同一个fec分组的数据在发送时候会被均匀分散到这n毫秒中。可以对抗突发性的丢包。
|
||||
##### `-j` 选项
|
||||
为原始数据的发送,增加一个延迟抖动值。这样上层应用计算出来的RTT方差会更大,以等待后续冗余包的到达,不至于发生在冗余包到达之前就触发重传的尴尬。配合-t选项使用。正常情况下跨国网络本身的延迟抖动就很大,可以不用设-j。这个功能也需要时钟,默认关掉了,不过一般情况应该不需要这个功能。
|
||||
|
||||
##### --random-drop 选项
|
||||
随机丢包。模拟恶劣的网络环境时使用。
|
||||
##### `--random-drop` 选项
|
||||
随机丢包。模拟恶劣的网络环境时使用。如果你的网络现在没有多大丢包,但是你想测试一下高丢包环境下各种FEC参数的表现,可以开这个选项。
|
||||
|
||||
##### -k选项
|
||||
##### `-k`选项
|
||||
指定一个字符串,server/client间所有收发的包都会被异或,改变协议特征,防止UDPspeeder的协议被运营商针对。
|
||||
|
||||
##### `--disable-obscure`
|
||||
UDPspeeder默认情况下会对每个发出的数据包随机填充和异或一些字节(4~32字节),这样通过抓包难以发现你发了冗余数据,防止VPS被封。这个功能只是为了小心谨慎,即使你关掉这个功能,基本上也没问题,关掉可以省一些带宽和CPU。
|
||||
|
||||
##### `-q,--queue-len`
|
||||
编码器在做FEC前最多积攒多少个数据包,只对mode 0有效。除非是使用下文`V2版如何多倍发包`里面提到的用法,不建议改动。
|
||||
|
||||
# 使用经验
|
||||
|
||||
### 在FEC和多倍发包之间如何选择
|
||||
|
||||
对于游戏,游戏的流量本身不大,延迟很重要,多倍发包是最有效的解决方案,多倍发包不会引入额外的延迟。
|
||||
对于游戏,游戏的流量本身不大,延迟很重要,多倍发包是最佳解决方案,多倍发包不会引入额外的延迟。FEC编码器需要先积攒一些数据,才可以做FEC,延迟无法避免;对于多倍发包,没有这个问题,所以没有延迟。
|
||||
|
||||
对于其他日常应用(延迟要求一般),在合理配置的情况下,FEC的效果肯定好过多倍发包。不过需要根据网络的最大丢包来配置FEC参数,才能有稳定的效果。如果配置不当,对于--mode 1可能会完全没有效果;对于--mode 0,可能效果会比不用UDPspeeder还差。
|
||||
|
||||
@ -169,6 +180,8 @@ mode 0模式的流量消耗基本完全透明。mode 1因为涉及到数据按
|
||||
./speederv2 -c -l0.0.0.0:3333 -r44.55.66.77:4096 -f1:1 -k "passwd" --mode 0 -q1
|
||||
```
|
||||
|
||||
使用了`--mode 0 -q1`以后,`--timeout`选项不起作用,所以不用调。
|
||||
|
||||
如果你只需要多倍发包,可以直接用回V1版,V1版配置更简单,占用内存更小,而且经过了几个月的考验,很稳定。
|
||||
|
||||
### 根据网络丢包合理设置FEC参数
|
||||
@ -189,6 +202,31 @@ FEC算法很吃CPU,初次使用建议关注UDPspeeder的CPU占用。如果CPU被
|
||||
|
||||
另外,fec分组大小不宜过大,否则不但很耗CPU,还有其他副作用,建议x+y<50。
|
||||
|
||||
### 为什么使用之后效果反而变差了?
|
||||
|
||||
有可能是你用了mode 0参数,而又没调好参数。
|
||||
|
||||
如果你没有使用mode 0,而确实效果变差了,那很可能是因为你的运营商对UDP有限制。一般看视频和下载都是TCP流量,而用UDPspeeder中转后流量变成了UDP流量,如果运营商对UDP做了限制,就可能导致效果比不用还差。用udp2raw可以解决,udp2raw: https://github.com/wangyu-/udp2raw-tunnel
|
||||
|
||||
|
||||
### UDPspeeder和BBR/锐速配合
|
||||
|
||||
UDPspeeder和BBR/锐速可以配合使用,UDPspeeder工作在IP层负责降低丢包率,BBR/锐速工作在TCP层负责优化拥塞和重传。这种情况下,可以调低UDPspeeder的冗余度,能把丢包率降低到5%以内就可以了,剩下的交给BBR/锐速解决,这样预计可以节省一些流量。如果是UDPspeeder跟Linux默认的Cubic一起用,最少也要把丢包率降低到1%以下才能流畅使用TCP。
|
||||
|
||||
对下文的`UDPspeeder + openvpn`和`UDPspeeder + openvpn + $***`方法有效。不过有一点区别,具体见下文。
|
||||
|
||||
### UDPspeeder和Kcptun配合
|
||||
|
||||
UDPspeeder和Kcptun配合,UDPspeeder和Kcptun可以并联也可以串联。
|
||||
|
||||
并联的情况下,让kcptun负责加速TCP,UDPspeeder负责加速UDP。见下文的`UDPspeeder + kcptun + $*** 同时加速tcp和udp流量`。
|
||||
|
||||
串联的情况。UDPspeeder的FEC跟Kcptun自带的相比:可以对两个方向设置不通的FEC参数、有一个更省流量的mode 0模式、可以调整的FEC参数多一些;但是UDPspeeder本身不优化拥塞和重传算法。所以UDPspeeder和Kcptun也可以配合使用,结合两者的优点。
|
||||
|
||||
串联时可以关掉Kcptun的FEC,让UDPspeeder接管FEC功能。这样UDPspeeder工作在UDP层负责降低丢包率,Kcptun工作在应用层用kcp算法负责优化拥塞和重传,能起到和`UDPspeeder+BBR/锐速`类似的效果。
|
||||
|
||||
如果发Issue问Kcptun+UDPspeeder相关的问题,一定要说明是并联还是串联。
|
||||
|
||||
# 应用
|
||||
|
||||
#### UDPspeeder + openvpn加速任何流量
|
||||
@ -196,19 +234,23 @@ FEC算法很吃CPU,初次使用建议关注UDPspeeder的CPU占用。如果CPU被
|
||||
|
||||
具体配置见,[UDPspeeder + openvpn config guide](/doc/udpspeeder_openvpn.md).
|
||||
|
||||
可以和BBR/锐速叠加,不过BBR/锐速部署在VPS上只对从本地到VPS的流量有效,对从本地到第三方服务器的流量无效。
|
||||
|
||||
需要在服务端开启ipforward和NAT。在客户端改路由表(可以手动修改,也可以由OpenVPN的redirect-gateway选项自动加好)。
|
||||
|
||||
#### UDPspeeder + kcptun/finalspeed + $*** 同时加速tcp和udp流量
|
||||
如果你需要用加速的tcp看视频和下载文件,这样效果比UDPspeeder+vpn方案更好(在没有BBR的情况下)。
|
||||
![image0](/images/cn/speeder_kcptun.PNG)
|
||||
|
||||
#### UDPspeeder + openvpn + $*** 混合方案
|
||||
也是我正在用的方案。优点是可以随时在vpn和$\*\*\*方案间快速切换。
|
||||
实际部署起来比图中看起来的还要简单。不需要改路由表,需要做的只是用openvpn的ip访问$*** server。
|
||||
实际部署起来比图中看起来的还要简单。不需要改路由表,不需要写iptables规则和开启NAT,需要做的只是用openvpn分配的ip访问$*** server。
|
||||
|
||||
![image0](/images/cn/speeder_vpn_s.PNG)
|
||||
|
||||
(也可以把图中的$*** server换成其他的socks5 server,这样连$*** client也不需要了)
|
||||
(也可以把图中的$*** server换成其他的socks5 server,这样就不需要$*** client了)
|
||||
|
||||
另外,这种方案加速TCP时效果可以和BBR叠加,UDPspeeder用来改善丢包率,BBR负责重传,是不错的组合。
|
||||
可以和BBR/锐速叠加,BBR/锐速只要部署在VPS上就有效。
|
||||
|
||||
# 编译教程
|
||||
暂时先参考udp2raw的这篇教程,几乎一样的过程。
|
||||
|
@ -1,12 +1,14 @@
|
||||
|
||||
# UDPspeeder + openvpn config guide
|
||||
![image_vpn](/images/en/udpspeeder+openvpn.PNG)
|
||||
![image_vpn](/images/en/udpspeeder+openvpn3.PNG)
|
||||
|
||||
# UDPspeeder command
|
||||
|
||||
#### run at server side
|
||||
```
|
||||
./speederv2 -s -l0.0.0.0:8855 -r 127.0.0.1:7777 -f20:10
|
||||
```
|
||||
|
||||
#### run at client side
|
||||
assume server ip is 45.66.77.88
|
||||
```
|
||||
@ -84,3 +86,17 @@ sndbuf 2000000 ##### important
|
||||
rcvbuf 2000000 ##### important
|
||||
txqueuelen 4000 ##### suggested
|
||||
```
|
||||
|
||||
##### Note:
|
||||
If you use the `redirect-gateway` option of OpenVPN,you may need to add a route exception for your remote server ip at client side.Otherwise OpenVPN may hijack UDPspeeder 's traffic.
|
||||
|
||||
For example,depend on your network environment,the command may looks like:
|
||||
```
|
||||
ip route add 44.55.66.77 via 44.55.66.1
|
||||
```
|
||||
or
|
||||
|
||||
```
|
||||
ip route add 44.55.66.77 dev XXX
|
||||
```
|
||||
(run at client side)
|
||||
|
BIN
images/en/ping_compare_mode1.png
Normal file
BIN
images/en/ping_compare_mode1.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 1.1 MiB |
Loading…
x
Reference in New Issue
Block a user