-
Notifications
You must be signed in to change notification settings - Fork 833
mode和mtu选项
--mode 选项决定fec编码器的工作模式。对于mode 0，编码器会积攒一定数量的packet，然后把它们合并再切成等长的片段（切分长度由--mtu指定）。对于mode 1，编码器不会做任何切分，而是会把packet按最大长度对齐，fec冗余包的长度为对齐后的长度（最大长度）。
mode 0更省流量，在丢包率正常的情况下效果和mode 1是一样的；mode 1延迟更低一点点，在极高丢包的情况下表现更好一点点。因为后面会提到的mtu问题，不推荐使用mode 1。
mode 0使用起来可以不用关注mtu，因为fec编码器会帮你把包切分到合理的大小；用mode 1时必须合理设置上层应用的mtu。mode 0模式中--mtu选项决定切分的片段的长度，mode 1模式中--mtu选项只起检查作用，如果超过了--mtu指定的值，数据包会仍然会被尝试发送，但是log里会报warning。
mode 0模式的流量消耗基本完全透明。mode 1因为涉及到数据按最大长度对齐，所以流量消耗不是完全可预期。不过就实际使用来看， mode 1消耗的额外流量不多。mode 1一般会比mode 0多消耗零点几倍的流量，对于在意流量的人，推荐用mode 0。
mode 0模式数据包一般不会乱序，除非网络本身有严重乱序；mode 1模式被恢复的数据包可能会乱序，不过UDP本来就允许乱序，对绝大多数应用没有影响。mode 0模式反而可以纠正一些乱序情况。
mode 0模式允许你发送的数据包大小超过物理接口的MTU而几乎不引起效率损失（而普通的ip分片做不到这点），目前最高支持到2000字节，2000字节已经可以应对任何应用了，因为一般网络的MTU只有1400多。之所以支持到2000字节是为了省程序内部开的静态buff(静态buff避免malloc提高性能)，如果你是开发者，通过重新编译，支持到UDP协议的极限(65507字节)也没问题。
对于mode 0模式，为了达到不用关注mtu的效果，-f x:y里的x必须>=2。 mode 0模式中，x=1的情况下编码器会丧失切分数据包的能力，是不推荐的用法。
mode 0还有个特殊用法--mode 0 -q1，可以用来多倍发包，而不会引入任何延迟(延迟比--mode 1还低)。后文的使用经验中会提到。
如果你使用的是--mode 1模式，那么你需要为UDPspeeder加速的应用设置好MTU(不是在UDPspeeder中，是在被加速的应用中)，建议设置为1200。
如果被加速的应用不能调整MTU，而你又确实遇到了MTU问题，那就只能使用--mode 0模式了。
--mode 1曾经是UDPspeeder的默认模式，现在默认模式已经改成--mode 0。