路由器小包转发能力探讨

@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 秒有讲

<amp-youtube data-videoid="OdCeoQ2dYxE" layout="responsive" width="480" height="270"></amp-youtube>

@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 。