低延迟与大流量

与大多数程序一样，流量大的时候，很难同时保持低延迟。除非引入 QoS 机制，识别数据包并针对某些程序发出的数据调整发送次序（也就是优先级）。引入QoS机制会增加程序的复杂程度，还不如主动分成两条通道简单快捷。

低延迟

对于需要低延迟、而数据量不大的情况，请使用 KCPTube 的 fast 模式，并根据丢包率、对于延迟的敏感度选择 fast1~6。

• 若丢包率低（低于 3%），选择 fast5 或 fast6 通常已经足够。
• 若丢包率中等（假如是 4% ~ 9%），可以选择 fast3 或 fast4。可以接受一点点延迟波动的话，可以选 fast5 或 fast6。
• 若丢包率比较高（高于 10%），并且可以接受稍微一点延迟波动，那么 fast3 或 fast4 仍然可以用。实在想减少延迟波动，那么 fast1 和 fast2 都是最佳选择。
• 不介意任何流量浪费，只追求低延迟、低波动，那就选 fast1 或 fast2 吧。

通常来说，fast 的偶数模式表现会比较好。除非丢包时总是突然来那么几下连续丢包，那这个时候选 fast 的奇数模式或许能稍微把丢失的包快一点点补回去。

大流量

对于数据量大的情况，请使用 KCPTube 的 regular 模式。同样的，应当根据丢包率选择 regular1~5。

• 若丢包率低于 8%，选择 regular3 ~ regular5 都可以，此时浪费的流量比较少。
  • 区别是，regular5 的延迟比 regular4 多十几毫秒，而 regular4 的延迟又比 regular3 更大。
  • 延迟较大的选项，传输时的反应会比较慢，不过浪费的流量相对更少。
• 若丢包率高于 10%，但低于 12%，选择 regular3~5 仍然可行，但可能会偶尔出现不稳定的情况。
• 若丢包率高于 12%，此时 regular3~5 会极不稳定。此时请选择 regular1 或 regular2。

既要……又要……

如果确实想一条通道内既要低延迟，又要大流量，那也不是不行，请确保大流量传输的时候不使用“延迟敏感”的程序，例如联机游戏。玩游戏（以及其他“延迟敏感”的程序）时，不要下载大文件。

这个时候，regular1 或 regular2 是相对适合的折衷选择。

附加说明

KCPTube 并未提供 FEC（前向纠错），全靠 KCP 自己的重传功能。主要是为了避免 FEC 可能会带来的延迟。

所以在高丢包率（大于 15%）的环境下，KCPTube 无法保证大流量的传输速度，也无法保证一定能压低延迟波动。