路由器小包转发能力探讨

我也不知道，据说软路由的弱项就是小包转发弱

小包转发相当于电脑处理器的 IPC 性能，你要对比总得有对比的标准吧。你跑大包有啥意义，J1900 RK3328 这种垃圾不也能跑千兆大包。

另外现在的 ARM A53x4 2.0G 性能已经不输部分 Intel ATOM 和菜羊了，加上 ASIC 和 NPU 加速，人家处理网络任务都不需要占用 CPU ，剩下的性能跑科学等服务是不是比同等级的 x86 更强更省电？

@geekvcn 你说的这些我都知道，但本帖的主要目的是想讨论一下路由器小包转发能力对大多数的家庭用户有多重要？是不是大多数的家庭用户可以不那么需要在意小包转发能力。

软路由发展已经到头了，没任何意义，除非搞搞 AIO ，搞个家庭中心服务器资源共享顺便跑个软路由。最新的 MTK 高通 博通 路由 SOC 已经全都可以上双 2.5G 以上，都带 ASIC 网络加速单元，性能都是 4xA53 1.5G 以上，都带 AES 硬件加速。也就是跑网络+无线+科学+DDNS+去广告等大多数人所需的功能都绰绰有余了。x86 软路由还有任何意义？ br-lan 软桥接当高功耗交换机用？

包转发就是网络最重要的性能指标，你说家庭用户重不重要，家庭用户用的不是网络吗？以前是在垃圾硬路由处理器和 x86 的高性能通用计算面前没得选，只能被动接受小包低一些，功耗高一些，再说家用环境低的小包也够用，只是跑不满小包线速。现在有的选了，硬路由通用计算部分都 4xA53 了

@geekvcn 高通 wifi7 平台集成 6 Port Integrated Ethernet Switch:4 x 2.5 GE + 5 GE + 10 GE
估计今年或者明年有厂商的旗舰产品会用到

https://www.qualcomm.com/content/dam/qcomm-martech/dm-assets/documents/Networking-Pro-1620-product-brief_87-PW325-1.pdf

acwifi 站长的这篇文章里有统计 https://www.acwifi.net/18930.html

低功耗 x86 在没跑到小包线速的情况下 CPU 占用已经普遍 50%以上，功耗 10W 以上，这时候现在的硬路由就几瓦功耗就能跑满线速了，通用计算部分 4xA53 甚至没占用。

总结下就是以前家用硬路由 SOC 通用计算部分弱鸡，家用小包需求也不高，所以不得不接受 x86 软路由的部分缺点。现在硬路由通用计算部分也不弱了，讨论这个没啥意义了，因为同样的价格和功能你能选到跑满线速火接近线速的产品了，为啥要选更弱的。

你不如把问题改成 软路由和硬路由你更偏向哪个，或者说低功耗和高功耗你更倾向哪个

@geekvcn 你说的基本都对，但也不是完全没有讨论的意义吧。比如有些人已经买了软路由，或者有闲置，那我要不要继续用？要不要废物利用？这个时候，是不是要考虑一下自身环境对小包的需求到底是怎样的。

@huangya 这是高端线，价格一般人接受不了，肯定选 x86 顺便 AIO 。今年得看双 2.5G 的 7986 系列，不出意外会成为新爆款

@huangya 软路由小包没你想的那么弱到极点，所以家用当然够用，缺点还是一样，更低的小包转发率更高的功耗，但是优点也很明显，更高的灵活性，容易搭配不同的内存硬盘，更多的 IO 接口意味着更高的扩展，能跑各种各样的系统环境。但是单纯的当家庭主网关，x86 软路由的时代将结束了。

不考虑这个问题，只考虑和电网交朋友

我来直接求助个问题吧,跑 pcdn 主要考验小包转发还是大包?

x86 软路由,如果是 j4125 n5105 这种的话,一般也就 10w 功耗吧(当然如果是 all in one 那种加了一堆硬盘的另算),全天跑满一年下来应该还不到 100 度电

如果这样就想和电网交朋友的话,会被嫌弃的吧

@jiangyang123
大包，一般都是视频文件

@jiangyang123 省电耗电是相对的

@geekvcn #15 这就不要在意了,少开一天空调就省出来了

小包转发在游戏方面影响较大吧

@erfesq 但是家里小包即使游戏也不会有多少 bps ，小包转发率主要还是企业，商场公网的网关需要关心的指标。

我一朋友，天天说软路由小包垃圾，我也就笑笑，不说啥。

家用不需要在意小包转发，用的频率最高的也就游戏，但游戏那点数据量九牛一毛。
你看看是不是 99%家庭用户都是下载？

我的软路由，3 个人玩王者完全没问题，简单说就是，软路由处理个游戏的小包完全不在话下。
那个说软路由没用的人，说话太片面，玩软路由就是喜欢灵活，可以装 x86 上的各种软件，不单单是追求大带宽

@jiangyang123 实测 3150 和 3160(两部机器都做过软路由)在满载的时候是 7-8W ，用电流表和电压表测出来的。挂载了一个 2.5 机械硬盘和 msataSSD

软路由 nas 98%的人用不上
剩下的大多当爱好玩，不记成本收益，开心就好

可以看洋葱哥的测试视频， ，用数据说话。

@geekvcn 软桥接可以做透明防火墙，BROUTE 了解一下。用一台单独的设备当网桥，接入之后自动 intercept 所有流量，移除自动恢复。不需要修改任何网络拓扑和客户端配置，不进行额外 nat ，完全兼容双栈。
当然这个设备用 arm 也很好，但如果只有一台设备要开虚拟机的话，还是得 x86 。

家用不需要在意小包转发是否能达到满速

关注小包转发更像是买新电脑必须要跑个分似的，可以直观的显示出设备处理性能

100 万分的电脑和 70 万分的电脑，玩扫雷都是 1 帧

这个小包不适合我来讨论。我也不知道小包是啥玩意。。。说说我认识中的小包

对于 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 的概念回答了延迟问题，而不是小包。

小包转发性能是网络设备的基础指标，包括 pps/时延 /乱序等等
实际使用中，随着各种功能的叠加（比如 NAT/QoS 等等），转发表的大小（ 100 条路由 vs10w 条路由），实际的转发性能还会有一定下降
接入路由器不需要这么高转发，但是汇聚路由器 /核心路由器是必要参考值

DPDK @ TNSR
x86 还有挖掘空间？

来学习学习。。。
个人感觉家用上，小包的量一般不会太高。毕竟家用设备数量算是智能家居那种最多也就内网有 50 多个 IP 已经算是很硬核玩家了。上网所产生的小数据包在家用应该不会太多，除非是企业几百上千设备。基本同意楼上所说的，这个指标在汇聚和核心处才更有价值。 看了下 ROS 可能是玩家玩得最多的 RB750gr3 64byte 小包 fast path 情况下速度都能跑到 500 多 mbps ，家用实际上这种量应该是足够了

对于普通用户来说，包转发率的确不是这么重要，基本上不是太垃圾的路由器都有硬件转发，性能是足够用的。一般像上网 BT 这种应用也是以大包为主。

小包线速对于 IDC 机房或者运营商可能意义会更大，因为 DDoS 攻击流量什么的可能会有很多小包，用最低的带宽给路由设备制造最大的负载。

AMS-IX 有个包大小的统计，应该对互联网上的数据大小分布具有一定的代表性： https://stats.ams-ix.net/sflow/index.html

绝大多数的数据包都是在 64-127 字节和 > 1024 字节这个区间。

小包应用场景： 端口扫描

小包是非常常见的且重要的，数量上能达到 50%+，例如 DNS ，DHCP ，TCP 的握手和挥手，TLS 的握手，游戏包等都是小包。
如果你只是像要一个稳定的环境而非折腾，建议还是硬路由好，AIO 这种随便一个故障把家里搞断网被骂又不是没有。

@li02 #22 主要是要一个透明代理 跑一下 v2ray 跟 iptables 要是硬件路由支持这个就好了

@geekvcn #4 老哥 你推荐的一个硬件路由呗，我只要求跑一下 iptables 的 ipset 以及 v2ray 的透明代理，因为我现在的软路由，安装了一个 chnRoute 的功能，国内外自动分流，如果有合适的硬件路由 能跑得足够快，可以推荐一下

@geekvcn #4 主要我是 iptables 的重度用户，我有好几个上游网络需要 iptables 做 路由规则的定义

用交换机能避免小包问题吗？

@veSir 不能

@465456 虚拟机 WAN LAN 口都直通网口 数据都用交换机交换都避免不了？

@bosonx 小包的转发能力是指路由器拨号后的 nat 转发

https://www.acwifi.net/13527.html 选对好的 CPU 和网卡，小包的转发能力都可以接近硬路由

@465456
我的软路由 CPU I9900 网卡 X550T2 ，X710DA4 都是直通的，而且都是用万兆交换机交换数据，不用虚拟网卡，应该可以吧，没测试过。。

根据 youtube 洋葱的测试，sfe 对小包转发提升很明显.

说软路由没意义就太夸张了，硬件路由如果刷三方固件（ OpenWRT 没支持几个设备的硬件转发），或者进用户态一样是软转发的，尤其是大家现在这种用法，科学、Qos 、去广告啥的一起上，全部都妥妥的是软转发。

X86 我最喜欢的一点倒是通用性，驱动开源，硬件随意搭配，能上最新的内核，系统随意挑；从低性能到高性能都有对应的硬件选择，后续升级线路都很清晰。

对于购买硬件路由来说，就没有通用性和选择的余地了，也完全没有扩展性。对应的系统选择范围非常窄，自行编译固件又非常麻烦，还有奇奇怪怪的 BUG ，比较难折腾满意。（尤其是赠送的 WiFi6 无线，不要想省点钱还不行）

至于电费差距嘛，可能确实有，但是也就那小 5W ，一年下来其实也没几个钱，比起软路由，硬件路由器的溢价都可以用好几年了，更别说后续的升级剩下的钱。

另外，其实家用真的很难通过小包打满路由，毕竟 UDP 的 Qos 也这么严重。考虑下复杂规则下的大包转发率会比较好，尤其是用了桥的情况。
1Gbps * 4 的情况下这个问题不是很明显，但是到 10Gbps*2/*4 的这个等级下来，CPU 和内存的整体要求就非常高了。
（当然到了 10GE-100GE ，现在也只能选软路由了）

那么有没有推荐的千元以下的不带 wifi 的硬路由呢？最好带 sfp+口

没有测试过，不过小包很容易把路由器打挂倒是真的

@oovveeaarr 高通 qsdk 就是基于 openwrt ，联发科 openwrt 下主线分支就支持有线硬件转发。到你那不支持了，你用的什么芯片？

@geekvcn qos 和自己写的 iptables 限制连接数，硬件支不支持

@geekvcn 请教个问题，策略路由用上的话，转发还会是硬件转发？

例如基于五元组转发等规则。

@neroxps 是不是硬件转发，只要在 br-lan 上抓一下包，看看能否抓到完整的 tcp 数据流就可以。如果只有３次握手，后续数据交互部分没有，就表示走了硬件转发

@geekvcn 高通的 NSS 并未合并进 Openwrt 主线，Openwrt 的 hardware offload 仅测试过 MTK 的部分 soc 。
这与我说的“OpenWRT 没支持几个设备的硬件转发”有何冲突？大部分的 target 就是不支持。
建议把别人说的话看清楚，不要整天就想搞个大新闻。

@465456 #48
@neroxps #49
这些都是不支持的，只要涉及了 netfilter （包括 nftable/iptables ），基本都可以认定不支持。

@huangya #50 这个其实也有可能抓的到的，我的建议是查一下 nf_conntrack ，一般只有 bypass 了 nf 才能做 hwnat

@oovveeaarr qsdk 知道吗？

@geekvcn #54 openwrt 知道吗？不知道的话可以看看 github.com/openwrt/openwrt

@oovveeaarr 只会用主线只能说你没救了

首先只有包转发率，并没有什么小包转发率。
其次家庭网络关注包转发率没啥意义，又不是核心网骨干网。
太多商家带节奏了，卖软路由的鼓吹千兆科学，卖硬路由的鼓吹包转发率。
其实都是扯淡。

@geekvcn #56 连主线都用不了，可太惨了

@cwbsw 千兆科学很容易，问题是有啥应用呢

@huangya @geekvcn 因为没环境所以想问问 qsdk 这种是不是支持 五元组策略路由这种或者 iptables mangle mark router 那种转发是否也可以硬件加速。

粗略搜索了下好像没找到相关文档。

@oovveeaarr 对的 之前 Mikrotik 文档也是这样说，开启某些防火墙规则后，硬件转发就会关闭。所以我一直对硬件转发不关系，因为我的需求即使设备支持硬件转发我也用不上，但听楼上说 qsdk 这种技术之前没了解过，就想了解下看看是不是有新技术。

@neroxps 策略路由应该是支持的，前面三次握手不加速，qsdk 中 ecm 模块会从前面的 tcp 三次握手中知道往哪个 interface 走。

@neroxps 高通的硬件加速有个 ASIC 单元，QSDK 本质就是一个 openwrt ，只不过加上了高通的部分私有代码和内核模块，其中 NSS 就是最重要的内核模块，对应的内核模块有好几个，分别用来卸载不同的任务，具体支持卸载什么任务和工作流程参考这篇文档 https://people.netfilter.org/pablo/netdev0.1/slides/IPQ806x-Hardware-acceleration_v2.pdf

@neroxps
截图是国内用户，见调试信息，实时速率约 200Mbps ，这个访问状态可以看出硬件加速的特性了。 有策略路由，加解密


小包转发性能，使用体验，体现在打开网页 /微信之类的速度。
之前 i3 软路由，3 万连接数打开微信收信息明显感觉慢。换了“IPQ6018”，当前保持 4.5 万连接数，丝毫没有迟滞的感觉

@luoshengdu 请问一下
１.可以发下你科学上网的配置信息吗？把 server 名称，密码这些敏感信息打码。据我所知，科学上网有两种方式或方向，第一是利用强加密，第二种是混淆，不知道你是使用哪种。
２.你家是不是设备很多很多，4.5 万连接数确实蛮大的

@huangya
1 ，trojan 启用 TLS


2 ，家里缺交换机，买了个京东云鲁班当交换机，又有网心云，所以连接数很高。连接数主要来自于网心云。


总结：从 3 月份换到高通芯片 360v6 的路由器明显感觉网络延迟、响应快了，打开网页，微信收取消息没有延迟；之前软路由在上述网络环境下体验相对差很多，打开微信的菊花要转很久； 两者使用都开启了 sqm qos 限速
软路由配置对比：
esxi 虚拟化，Intel T350 双口网卡（直通 /虚拟化 vmxnet3 都有尝试）、7 代 I3CPU 分配了 4 核心，软路由维持 3~4 万连接数功耗 10-15 瓦；
360v6 的硬路由功耗 6 瓦

原来如此，活动连接还跟这个有关系。 发微信，看视频卡顿的原因终于找到了-_-||

@Smallsun1231 你的连接数更高啊，也是跑 pcdn ？ 210 的 IP ，应该是联通的。

@luoshengdu #68 单纯跑个 PT~

我也是开了网心云，通常 4w 多连接

硬件是 N3160 pve 虚拟 op ，cpu 占用 30 ~ 60%

@luoshengdu 这个 trojan TLS 是不是少了一层加密，比如你的客户端访问 youtube, 本身就用的 https,已经加密了，就可能不会再次加密了。下面这个视频中的 5:30 秒有讲

@luoshengdu CPU 处理不用来，卡卡也正常

@huangya taojan 包头也有加密的

@luoshengdu 包头毕竟是少量数据吧

@huangya trojan 不包含加密，是个轻量传输协议。TLS 除了 SNI 部分是都加密的。你说的部分加密是 xtls ，防火墙已经能识别了。何况高通支持硬件加密，本来就毫无压力

@geekvcn 你说的高通硬件加密是指 ARMv8 cryptography extensions 还是 NSS 带的加密引擎？如果是指 NSS 带的加密引擎，现有的科学软件基本不支持调用它，即使调用了，效率也很低。因为要通过 kernel 去访问它。ARMv8 cryptography extensions 类似与 intel aes-ni, 这个是 cpu 汇编指令级加速，这个有很多软件是已经支持 AR Ｍ v8 了

@geekvcn op mtk 那个硬件 offload 很迷，udp 很多都不走（比如跑 bt 下载或者 iperf3 -u ，无论是 wan 接口还是 cpu 占用都看得出来 udp 没走）。

@bibiisme 主线硬件加速兼容都不行，MTK 主线的无线驱动都不支持硬件加速，建议用别人闭源驱动编译的版本或者 mips 老平台用 padavan

@geekvcn flow offload 的策略太迷，bt 下载表现实在不理想。所以这段时间我扒了 mtk sdk 的过来，udp 的 hwnat 基本正常了（但跑 iperf3 得加个-l 1450 ，否则默认情况 udp 会分片，mtk 的 hwnat 不支持分片的 udp 。当然主线那个加不加-l 跑 iperf3 udp 都没法被 hw offload ）

https://www.right.com.cn/forum/forum.php?mod=viewthread&tid=8235037&page=1#pid17016488 借楼推广下扒的 mtk sdk 的 hwnat 。

@geekvcn
> 人家处理网络任务都不需要占用 CPU ，剩下的性能跑科学等服务是不是比同等级的 x86 更强更省电？

不是很懂，但我总感觉，跑这种服务会需要用到 iptables 这种使得硬件加速全部失效的东西吧，这时候整个内外网部分的转发都会弱于性能较好的软路由

@jecvay 首先别挖坟，其次你最好多查查资料不要想当然的凭你个人的认知水平得出一个错误的结论

@geekvcn
> 主线硬件加速兼容都不行，MTK 主线的无线驱动都不支持硬件加速，建议用别人闭源驱动编译的版本或者 mips 老平台用 padavan

主要是我不信任一些小作坊的第三方固件，有些个人开发者的固件甚至都不开源，里面有没有加料都不清楚，甚至某几个有劣迹厂家的路由官方固件我当 AP 都膈应。
所以我只用主线 OpenWrt ，然而一般硬路由刷了主线 OpenWrt 基本上只能软件转发性能感人，有去扒厂家泄漏 SDK 自己移植的功夫我还不如随便找台 x86 的机器拿 Linux 糊一个软路由（

查 ipq6018 查到这个贴子，x86 软路由配合 dpdk+vpp ，应该比基于内核网络的方式还是优秀不少的。

而即使不支持 dpdk ，在 ipq6018 上，用 vhost net 驱动的 tap ，配合 A53 的 crytpo 指令，单核就可以跑到 600Mbps 的加密处理（ iperf3 tcp ），当然小包确实差一些，大概只能做到 100Mbps@128B iperf3 udp ，不过应该还是不错了。

有结论了吗？