在快速 TCP RX 情况下的 QoS about kcptun HOT 3 CLOSED

这一问题在 kcptun server 也是可能出现的，只要满足 TCP rx 快于 kcp tx 即可能出现。

在 kcptun 内部的实现修改前的替代方案是使用多个 kcptun 进程，并使用 iptables 等负载均衡将 TCP 连接分配至多个 kcptun 进程。此时各 kcptun 进程会有不同的 udp sport ，可用 tc sfq 进行 QoS 。

from kcptun.

@yaleh 非常好的分析，这个问题我是这么解决的，对于LAN TO INTERNET来说，要做到绝对的流量均匀，必须要在IP层完成TC，即不能在四层做。 简单的解决方法是，OVPN over KCPTUN，在tun0上做tc，这样虽然ovpn会多一些头部，有效载荷变低，但这是最简单最可靠的解决办法，对于企业应用是非常合适的，虽然这样对于视频这样的大流量传输并不友好。

另外提醒一点，根据LARTC的描述，sfq是不能单独用的，需要配合htb设定来用。这部分我没有深究，因为我的场景已经完全够用。 企业应用的最大问题，就是网盘类应用占用大量的上行带宽，（主要是Amazon S3的上行），这点你可以根据S3的IP范围做iptable过滤，Amazon公布了IP范围的JSON。简单处理下即可。

另外，SNMP的里程碑版本已经发布，稳定快速，建议更新。

from kcptun.

查了下 iptables, hashlimit 应该可以在这一场景下配合 tc 实现降低大流量连接的 prio 。待会儿试一下。

from kcptun.