这个小包不适合我来讨论。我也不知道小包是啥玩意。。。说说我认识中的小包
对于 tomato 的 QOS 就是这样的，不是 routeros 里的 iptables length 匹配。说到包转发的硬件能力，曾经接触过 iptables 每包匹配(非 CONNMARK 这种包到连接的转换过程)。在一些低端设备，像 mtk7620 跑 openwrt 的 SQM （ 2016 年版本）每包匹配非常耗 CPU 资源，包括更早的 ddwrt imq 那是直接导致路由死机。。。
从 QOS 的优先级来说显然已经对 tcp 的这些握手的真正小包实现了高优先级出列。
#$TC filter add dev $UDEV parent 1:0 prio 12 protocol arp handle 1 fw classid 1:20 # Arp traffic
$TC filter add dev $UDEV parent 1: prio 13 protocol ip u32 match ip protocol 1 0xff flowid 1:20 #ICMP
#$TC filter add dev $UDEV parent 1: prio 14 protocol ip u32 match ip protocol 6 0xff match u8 0x05 0x0f at 0 match u16 0x0000 0xffc0 at 2 match u8 0x10 0xff at 33 flowid 1:20 #ACK
$TC filter add dev $UDEV parent 1: prio 15 protocol ip u32 match ip protocol 6 0xff match u8 0x05 0x0f at 0 match u16 0x0000 0xffc0 at 2 match u8 0x02 0x02 at 33 flowid 1:20 #SYN
$TC filter add dev $UDEV parent 1: prio 17 protocol ip u32 match ip protocol 6 0xff match u8 0x05 0x0f at 0 match u16 0x0000 0xffc0 at 2 match u8 0x01 0x01 at 33 flowid 1:20 #FIN
$TC filter add dev $UDEV parent 1: prio 19 protocol ip u32 match ip protocol 6 0xff match u8 0x05 0x0f at 0 match u16 0x0000 0xffc0 at 2 match u8 0x04 0x04 at 33 flowid 1:20 #RST
以上就涉及到小包转换像 iptables 这种需要靠 cpu 运算的，以及其它的所谓的硬件转发。但硬件转发往往又没有 iptables 那么好玩。像 mtk7620 使用 openwrt 固件，没有 mtk 官方的驱动，在使用 pppoe 拔号时大概 88mbps,但在专线模式 eth0 接口下它也能在 QOS 状态跑接近 600mbps 的能力。
至于游戏和延迟，应该有公式计算的。最早接触的是，这些公式似乎和 SQM 作者经常提到的公式不一样。。。
http://linux-ip.net/articles/hfsc.en/Assume that all packets to be sent conform to a fixed size of 1500 bytes and all classes are sending at maximum rate. Based on the 1000 kbit link capacity, it takes 12ms (8*1500 byte / 1000000 bit/s = 12ms) to send a packet. The Voice over IP application sends at 100kbit which corresponds to 8 packets per second. In order to meet the guaranteed 100kbit rate for this class, the qdisc must send a packet from this class every 120ms, which would mean a maximum [queuing] delay of 132ms per packet. This example illustrates the relationship between bandwidth and delay.
实际上在 adsl(电话线线路)的测试结果，上行表现为使用当前带宽 60%时拥有极低的延迟，在当前带宽 80%时下行速度还不错延迟也不是很高。超过 80%时就出现下行还不如 80%时，下行流量更差延迟更高。
有了这样的经验认知就可以用 tc class 概念对 1 根带宽切成针对游戏的小水管+针对 P2P 的大水管。只要记得 CS 游戏交互基本不超过 5KB ，那只要给这根小水管 5/0.6=8.33KB 就足以保证游戏延迟。。。
对我来说我只要记得延迟和带宽的关系就可以了，根本不通过公式去计算。当然这种针对有线线路的延迟，似乎到了无线又成了另外一回事。在无线更多的是因为弱信号导致的 AP 呑吐性能的变化，所以对玩游戏的朋友有条件就自己独占一个 AP ，也用不着被人忽攸买什么几千块的游戏路由。。。
通过一个 1:2 分组限制了 P2P 最多只能使用 90%带宽，又能极大的保障高优先级分组游戏的延迟。根据早些年在 135KB 的光纤线路的测试结果。游戏小于 19ms,而其它 P2P 流量接近 600ms 。
##$TC class add dev $UDEV parent 1:1 classid 1:100 htb quantum 1514 rate $((UPLINK*10/100))kbps ceil 1Gbit prio 5
#$TC class add dev $UDEV parent 1:1 classid 1:2 htb rate $((UPLINK*8/10))kbps ceil $((UPLINK*9/10))kbps
#$TC class add dev $UDEV parent 1:1 classid 1:10 htb quantum 1514 rate $((UPLINK*1/10))kbps ceil $((UPLINK))kbps prio 0
#$TC class add dev $UDEV parent 1:1 classid 1:20 htb quantum 1514 rate $((UPLINK*1/10))kbps ceil $((UPLINK))kbps prio 2
#$TC class add dev $UDEV parent 1:2 classid 1:30 htb quantum 1514 rate $((UPLINK*3/100))kbps ceil $((UPLINK*90/100))kbps prio 3
#$TC class add dev $UDEV parent 1:2 classid 1:40 htb quantum 1514 rate $((UPLINK*5/100))kbps ceil $((UPLINK*85/100))kbps prio 4
最后用 QOS 的概念回答了延迟问题，而不是小包。