datocp
48 天前
从 qos 的角度来看 icmp 和 tcp tcping/udp 分属于不同的流量类型，
qos 往往解决的是流量和延迟 2 个问题，并发是一个忽有忽没的问题
对于 linux tc 我的方法是
将 20%上行用于高优先级流量包括 icmp
将 60%上行用于所有无法区分的假定为 p2p 流量
根据以前电话拔话宽带的观察 60 ％的上行会获得满速下行，此时延迟极低
当达到 80%的上行时下行开始下降，延迟开始变高
在这个 60/80 的结论下，qos 一下变得非常简单，把 hfsc 的延迟理解简单化。
将一根宽带分为
20/80 两个分组
高优级的流量在 20%那组，怎么也不可能在 20%的总流量以超过 80%的比例通过，游戏可以小于 19ms
低优先级的 p2p 流量在 80%那组，总是在 80%的总流量以接近 100%的比例抢夺通过延迟可以接近 600ms
再辅以下行流量
高速下载高优先级通过但只能使用 60%下行
无下载低优先级通过但能使用 100%下行
这样在 1 根 100mbps 宽带带 280+ip 在线，可以无视任何 p2p 的存在，延迟依然有保障，每个 ip 都有机会获得 100%的带宽。当然移动专线最高并发最高见过接近 50000 。
至于家用宽带，像以前 8mbps 大概在 1200 个并发。单机还想保证正常，用 iptables limit 来压抑，即能保证流量，又能抑制并发。