-
Notifications
You must be signed in to change notification settings - Fork 833
使用经验
因为V1版需要考虑MTU问题，建议新手用V2版。下文里除了有特殊说明，讲的都是V2版。
推荐给新手的参数/设置：
https://github.com/wangyu-/UDPspeeder/wiki/推荐设置
建议新手用--mode 0模式，可以避免MTU问题。
（不但不会引入新的MTU问题，反而可能帮你解决一些本来存在的MTU问题。比如可以解决PS4的「您所使用的路由器可能不支援IP碎片封包」提示）
在mode 0模式下，-f x:y参数里的x需要>=2（如果设置成x=1，FEC会退化为纯粹的多倍发包，并且丧失对数据包分片的能力，仍然可以工作，但是不建议新手使用)。x>=2是重要的注意事项，一定要注意。
如果你用了mode 1模式，需要考虑MTU。
默认的FEC参数为-f20:10，对每20个包，额外发送10个冗余包，也就是1.5倍发包（1.5倍冗余度）。已经可以适应绝大多数的网络情况了，对于10%的网络丢包，可以降低到0.01%以下；对于20%的网络丢包，可以降低到2.5%。
如果你的网络丢包很低，比如在2%以下，可以尝试调低参数。比如-f20:4，也就是1.2倍发包，这个参数已经足够把2%的丢包降低到0.01%以下了。
如果网络丢包超过20%，需要把-f20:10调大。
另外，对于--mode 0模式，建议冗余度不要低于1.2，也不要用-fx:1这种参数，否则效果可能很差；--mode 1模式无特殊要求，即使是用-f40:1也可以（1.03倍冗余度）。
比如-f20:10,表示对每20个原始包发送10个冗余包,流量消耗1.5倍。这样，只要30个包中有20个到达，数据就可以被完全恢复。
比如-f1:2,表示对每1个原始包发送2个冗余包，也就是3倍发包，流量消耗3倍。这样，只要3个包中有1个包到达，数据就可以被完全恢复。
-20:10的1.5倍流量的效果是否差于-f1:2的3倍流量呢？ 只要做简单的概率计算就可以知道，一般情况下30个包中有20个到达的概率远高于3个包中有1个包到达的概率。比如在丢包率10%的情况下，30个包中有20个到达的概率是 99.99% ，而3个包中有1到达的概率只有99.9%, 所以在这个例子中1.5倍流量的效果远好于3倍流量（丢包率低10倍）。所以不要迷信于多倍发包，并不是消耗的流量倍数更多效果就一定更好。多倍发包的意义基本只在于可以省几毫秒的延迟，只对游戏有用。 对于下载和看视频，FEC不但更省流量，效果也更好。
比如你配置好了UDPspeeder+OpenVPN，想测试网络本身的丢包情况。有两种方法：
可以在两边为UDPspeeder加上--disable-fec选项，这样FEC就被关闭了。透过这条VPN连接来ping，就可以测出网络本身的丢包率。
不透过VPN直接ping的结果不准，因为直接ping走的是icmp流量。通过VPN连接来ping才能真实反映出UDP的丢包情况。
在两边为UDPspeeder加上--report 10选项，这样结合client端和server端的输出，可以算出网络本身的丢包率。
client端的 client-->server:(original......)(fec:xxx pkt:aaa byte)，里面的xxx表示从client到server发送了xxx个数据包。
server端的 client-->server:(original......)(fec:yyy pkt:bbb byte)，里面的yyy表示server收到了client发来的yyy个数据包。
对比一下xxx和yyy，就可以算出client-->server方向的丢包率。 server-->client方向的数据同理。
以上方法计算出的丢包率是网络本身的丢包率。如果你用original那一列的数据计算，计算结果是被FEC纠正以后的丢包率。
https://github.com/wangyu-/UDPspeeder/wiki/UDP丢包率和延迟测试
不要3.2版以下的iperf3来测UDP, 有BUG，结果很离谱。
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。
--fifo选项可以在运行时改变FEC参数，无需重启程序，也不会断线。如果你在使用过程中发现网络丢包突然变高，可以动态地把冗余度调大；反之也一样，如果网络变好了，把冗余度调小节省流量。一切都是无缝进行，不会断线，也不会因为改FEC参数导致额外的丢包。
有可能是你用了--mode 0参数，而又没调好参数。（如果你的网络丢的包比FEC额外发的包还多，那mode 0模式就无法恢复出数据了）
如果你使用的是UDPspeeder+VPN的方式，如果你的参数没问题，而确实效果变差了，那很可能是因为你的运营商对UDP有限制。一般看视频和下载都是TCP流量，而用UDPspeeder+VPN中转后流量变成了UDP流量，如果运营商对UDP做了限制，就可能导致效果比不用还差。用udp2raw可以解决。
UDPspeeder和BBR/锐速可以配合使用，UDPspeeder工作在IP层负责降低丢包率，BBR/锐速工作在TCP层负责优化拥塞和重传。这种情况下，可以调低UDPspeeder的冗余度，能把丢包率降低到5%以内就可以了，剩下的交给BBR/锐速解决，这样预计可以节省一些流量。如果是UDPspeeder跟Linux默认的Cubic一起用，最少也要把丢包率降低到1%以下才能流畅使用TCP。
UDPspeeder和Kcptun配合，UDPspeeder和Kcptun可以并联也可以串联。
并联的情况下，让kcptun负责加速TCP，UDPspeeder负责加速UDP。README.md里的UDPspeeder + kcptun + $*** 同时加速tcp和udp流量。
串联的情况。可以关掉Kcptun的FEC，让UDPspeeder接管FEC功能。这样UDPspeeder工作在UDP层负责降低丢包率，Kcptun工作在应用层用kcp算法负责优化拥塞和重传。这种用法收益不大，不建议新手使用，直接用kcptun自带的FEC就可以了。
有些运营商会对udp流量做限制，具体现象包括：1.udp使用一段时间后突然断流，要过几分钟才能恢复 2.udp被限制到了非常低的速率（比如几百kb），UDPspeeder、kcptun、VPN等udp程序无论怎么调参数，速度都很低。
udp2raw是专门为应对这种情况开发的，udp2raw可以把udp流量伪装成tcp，防止udp被运营商限速或断流。即使发生断流，udp2raw会检测到这种情况并自动帮你重连，不需要手动干预。
推荐UDPspeeder和udp2raw一起使用。连接方式:
UDPspeeder client---->udp2raw client--------------->udp2raw server---->UDPspeeder server
https://github.com/wangyu-/UDPspeeder/wiki/UDPspeeder和udp2raw串联加速OpenVPN
https://github.com/wangyu-/UDPspeeder/wiki/FAQ
(koolshare版梅林)udpspeederV2+udp2raw串联加速简明教程
https://github.com/wangyu-/UDPspeeder/wiki/koolshare版梅林固件UDPspeeder和udp2raw串联的完整设置