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-15 20:28:48 -08:00 committed by GitHub
parent e50292bd4a
commit d05bcfc2f8
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -145,17 +145,17 @@ log and help options:
指定fec编码器在编码时候最多可以引入多大的延迟。越高fec越有效率，加速游戏时调低可以降低延迟。 指定fec编码器在编码时候最多可以引入多大的延迟。越高fec越有效率，加速游戏时调低可以降低延迟。
##### `--mode` 选项 和 `--mtu`选项 ##### `--mode` 选项 和 `--mtu`选项
`--mode` 选项决定fec编码器的工作模式。对于mode 0，编码器会积攒一定数量的packet，然后把他们合并再切成等长的片段（切分长度由--mtu指定）。对于mode 1，编码器不会做任何切分，而是会把packet按最大长度对齐，fec冗余包的长度为对齐后的长度（最大长度）。 `--mode` 选项决定fec编码器的工作模式。对于`mode 0`，编码器会积攒一定数量的packet，然后把他们合并再切成等长的片段（切分长度由--mtu指定）。对于`mode 1`，编码器不会做任何切分，而是会把packet按最大长度对齐，fec冗余包的长度为对齐后的长度（最大长度）。
mode 0更省流量，在丢包率正常的情况下效果和mode 1是一样的；mode 1延迟更低，在极高丢包的情况下表现更好。 `mode 0`更省流量，在丢包率正常的情况下效果和mode 1是一样的；`mode 1`延迟更低，在极高丢包的情况下表现更好。
mode 0使用起来可以不用关注mtu，因为fec编码器会帮你把包切分到合理的大小；用mode 1时必须合理设置上层应用的mtu。mode 0模式中--mtu选项决定切分的片段的长度，mode 1模式中--mtu选项只起检查作用，如果超过了--mtu指定的值，数据包会仍然会被尝试发送，但是log里会报warning。 `mode 0`使用起来可以不用关注mtu，因为fec编码器会帮你把包切分到合理的大小；用`mode 1`时必须合理设置上层应用的mtu。`mode 0`模式中`--mtu`选项决定切分的片段的长度，`mode 1`模式中`--mtu`选项只起检查作用，如果超过了`--mtu`指定的值，数据包会仍然会被尝试发送，但是log里会报warning。
mode 0模式的流量消耗基本完全透明。mode 1因为涉及到数据按最大长度对齐，所以流量消耗不是完全可预期。<del>不过就实际使用来看，mode 1消耗的额外流量不多。</del> mode 1一般会比mode 0多消耗零点几倍的流量，对于在意流量的人，推荐用mode 0。 `mode 0`模式的流量消耗基本完全透明。`mode 1`因为涉及到数据按最大长度对齐，所以流量消耗不是完全可预期。<del>不过就实际使用来看，`mode 1`消耗的额外流量不多。</del> `mode 1`一般会比`mode 0`多消耗零点几倍的流量，对于在意流量的人，推荐用`mode 0`。
mode 0模式数据包一般不会乱序，除非网络本身有严重乱序；mode 1模式被恢复的数据包可能会乱序，不过UDP本来就允许乱序，对绝大多数应用没有影响。mode 0模式反而可以纠正一些乱序情况。 `mode 0`模式数据包一般不会乱序，除非网络本身有严重乱序；`mode 1`模式被恢复的数据包可能会乱序，不过UDP本来就允许乱序，对绝大多数应用没有影响。`mode 0`模式反而可以纠正一些乱序情况。
mode 0模式允许你发送的数据包大小超过物理接口的MTU而几乎不引起性能损失（而普通的ip分片做不到这点），目前最高支持到2000字节，2000字节已经可以应对任何应用了，因为一般网络的MTU只有1400多。之所以支持到2000字节是为了省程序内部开的静态buff(静态buff避免malloc提高性能)，如果你是开发者，通过重新编译，支持到UDP协议的极限( `mode 0`模式允许你发送的数据包大小超过物理接口的MTU而几乎不引起性能损失（而普通的ip分片做不到这点），目前最高支持到2000字节，2000字节已经可以应对任何应用了，因为一般网络的MTU只有1400多。之所以支持到2000字节是为了省程序内部开的静态buff(静态buff避免malloc提高性能)，如果你是开发者，通过重新编译，支持到UDP协议的极限(
65507字节)也没问题。 65507字节)也没问题。
##### `--report`  选项 ##### `--report`  选项