diff --git a/doc/README.zh-cn.md b/doc/README.zh-cn.md
index 5036e0e..75bf41b 100644
--- a/doc/README.zh-cn.md
+++ b/doc/README.zh-cn.md
@@ -145,17 +145,17 @@ log and help options:
指定fec编码器在编码时候最多可以引入多大的延迟。越高fec越有效率，加速游戏时调低可以降低延迟。
##### `--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因为涉及到数据按最大长度对齐，所以流量消耗不是完全可预期。不过就实际使用来看，mode 1消耗的额外流量不多。 mode 1一般会比mode 0多消耗零点几倍的流量，对于在意流量的人，推荐用mode 0。
+`mode 0`模式的流量消耗基本完全透明。`mode 1`因为涉及到数据按最大长度对齐，所以流量消耗不是完全可预期。不过就实际使用来看，`mode 1`消耗的额外流量不多。 `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字节)也没问题。
##### `--report` 选项