Update README.zh-cn.md

doc/README.zh-cn.md

@@ -145,20 +145,12 @@ log and help options:
 指定fec编码器在编码时候最多可以引入多大的延迟。越高fec越有效率，加速游戏时调低可以降低延迟。
 
 #####  `--mode` 选项 和 `--mtu`选项
-`--mode` 选项决定fec编码器的工作模式。对于`mode 0`，编码器会积攒一定数量的packet，然后把他们合并再切成等长的片段（切分长度由--mtu指定）。对于`mode 1`，编码器不会做任何切分，而是会把packet按最大长度对齐，fec冗余包的长度为对齐后的长度（最大长度）。
 
-`mode 0`更省流量，在丢包率正常的情况下效果和mode 1是一样的；`mode 1`延迟更低，在极高丢包的情况下表现更好。
+简单来说`--mode 0`更省流量，没有mtu问题；`--mode 1`可以稍微降低一点延迟，需要考虑mtu；另外还有个`--mode 0 -q1`模式，多倍发包专用，没有延迟，也没有mtu问题，适合游戏。
 
-`mode 0`使用起来可以不用关注mtu，因为fec编码器会帮你把包切分到合理的大小；用`mode 1`时必须合理设置上层应用的mtu。`mode 0`模式中`--mtu`选项决定切分的片段的长度，`mode 1`模式中`--mtu`选项只起检查作用，如果超过了`--mtu`指定的值，数据包会仍然会被尝试发送，但是log里会报warning。
+见：https://github.com/wangyu-/UDPspeeder/wiki/mode和mtu选项
 
-`mode 0`模式的流量消耗基本完全透明。`mode 1`因为涉及到数据按最大长度对齐，所以流量消耗不是完全可预期。<del>不过就实际使用来看，`mode 1`消耗的额外流量不多。</del> `mode 1`一般会比`mode 0`多消耗零点几倍的流量，对于在意流量的人，推荐用`mode 0`。
+对于新手，建议不要纠结这些参数的具体含义，就用我在`使用经验`里推荐的设置，不要乱改参数，尤其是不要改`--mtu`。
-
-`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的情况下编码器会丧失切分数据包的能力，是不推荐的用法。
 
 ##### `--report`  选项
 数据发送和接受报告。开启后可以根据此数据推测出包速和丢包率等特征。