github/wangyu-UDPspeeder
1
0
Fork 0
mirror of https://github.com/wangyu-/UDPspeeder.git synced 2025-01-31 20:29:37 +08:00
Code Issues Packages Projects Releases Wiki Activity

Update README.zh-cn.md

Browse Source
This commit is contained in:
wangyu- 2017-11-11 14:29:46 -08:00 committed by GitHub
parent eb7406e6f3
commit 9152fef474
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 2 additions and 89 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

91
doc/README.zh-cn.md
View File

@ -188,97 +188,10 @@ echo queue-len 100 > fifo.file
echo mode 0 > fifo.file
```
可以动态改变fec编码器参数。可以从程序的log里看到command是否发送成功。
# 使用经验
见：
### 在FEC和多倍发包之间如何选择
对于游戏，游戏的流量本身不大，延迟很重要，多倍发包是最佳解决方案，多倍发包不会引入额外的延迟。FEC编码器需要先积攒一些数据，才可以做FEC，延迟无法避免；对于多倍发包，没有这个问题，所以没有延迟。
对于其他日常应用（延迟要求一般），在合理配置的情况下，FEC的效果肯定好过多倍发包。不过需要根据网络的最大丢包来配置FEC参数，才能有稳定的效果。如果配置不当，对于--mode 1可能会完全没有效果；对于--mode 0，可能效果会比不用UDPspeeder还差。
对于游戏以外的应用，推荐使用FEC。但是，如果FEC版的默认参数在你那边效果很差，而你又不会调，可以先用多倍发包。
### V2版如何多倍发包
只要在设置-f参数时把x设置为1，fec算法就退化为多倍发包了。例如-f1:1，表示2倍发包，-f1:2表示3倍发包，以此类推。另外建议加上"--mode 1"参数，防止fec编码器试图积攒和合并数据，获得最低的延迟。
2倍发包的完整参数：
```
./speederv2 -s -l0.0.0.0:4096 -r127.0.0.1:7777 -f1:1 -k "passwd" --mode 1
./speederv2 -c -l0.0.0.0:3333 -r44.55.66.77:4096 -f1:1 -k "passwd" --mode 1
```
使用了`--mode 1`以后，`--timeout`选项不起作用，所以不用调。
如果你只需要多倍发包，可以直接用回V1版，V1版配置更简单，占用内存更小，而且经过了几个月的考验，很稳定。
提醒：多倍发包只对游戏有意义，因为不会引入额外延迟。 FEC参数`-f20:10`用1.5倍的流量就可以达到好几倍发包的效果。 所以不要用多倍发包来看视频和下载，害人又害己。
### `-f`参数和丢包的关系；是否发包倍数越多效果就越好？
比如`-f20:10`,表示对每20个原始包发送10个冗余包,流量消耗1.5倍。这样，只要30个包中有20个到达，数据就可以被完全恢复。
比如`-f1:2`,表示对每1个原始包发送2个冗余包，也就是3倍发包，流量消耗3倍。这样，只要3个包中有1个包到达，数据就可以被完全恢复。
1.5倍流量的效果是否差于3倍流量呢？ 要做简单的概率计算就可以知道，一般情况下`30个包中有20个到达`的概率远高于`3个包中有1个包到达`的概率。比如在丢包率10%的情况下，`30个包中有20个到达`的概率是 99.99% ，而3个包中有1到达的概率只有99.9%, 所以在这个例子中1.5倍流量的效果远好于3倍流量（丢包率低10倍）。所以不要迷信于多倍发包，并不是消耗的流量倍数更多效果就一定更好。多倍发包的意义基本只在于可以省几毫秒的延迟，只对游戏有用。 对于下载和看视频，FEC不但更省流量，效果也更好。
### 根据网络丢包合理设置FEC参数
默认的FEC参数为-f20:10，对每20个包，额外发送10个冗余包，也就是1.5倍发包。已经可以适应绝大多数的网络情况了，对于10%的网络丢包，可以降低到0.01%以下；对于20%的网络丢包，可以降低到2.5%。
如果你的网络丢包很低，比如在3%以下，可以尝试调低参数。比如-f20:5，也就是1.2倍发包，这个参数已经足够把3%的丢包降低到0.01%以下了。
如果网络丢包超过20%，需要把-f20:10调大。
如果你实在不会配，那么也可以用回V1版。
### 如何测试网络本身的丢包率
比如你配置好了OpenVPN+UDPspeeder，但是不知道网络本身的丢包情况。你可以在两边为UDPspeeder加上`--disable-fec`选项，这样FEC就被关闭了。透过这条VPN连接来ping，就可以测出网络本身的丢包率。
###### NOTE1
直接ping的结果不准，因为直接ping走的是icmp流量。通过VPN连接来ping才能真实反映出UDP的丢包情况。
###### NOTE2
不要用iperf3来测UDP, 有BUG，结果很离谱。
### 根据CPU处理能力来调整FEC参数
FEC算法很吃CPU，初次使用建议关注UDPspeeder的CPU占用。如果CPU被打满，可以在冗余度不变的情况下把FEC分组大小调小，否则的话效果可能很差。
比如-f20:10和-f10:5，都是1.5倍的冗余度，而-f20:10的FEC分组大小是30个包，-f10:5的FEC分组大小是15个包。-f20:10更费CPU，但是在一般情况下效果更稳定。把分组调小可以节省CPU。
另外，fec分组大小不宜过大，否则不但很耗CPU，还有其他副作用，建议x+y<50。
### 改变FEC参数而不断线
`--fifo`选项可以在运行时改变FEC参数，无需重启程序，也不会断线。如果你在使用过程中发现网络丢包突然变高，可以动态地把冗余度调大；反之也一样，如果网络变好了，把冗余度调小节省流量。一切都是无缝进行，不会断线，也不会因为改FEC参数导致额外的丢包。
### 为什么使用之后效果反而变差了？
有可能是你用了`--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相关的问题，一定要说明是并联还是串联。
https://github.com/wangyu-/UDPspeeder/wiki/使用经验
# 应用