本质上类似买股票，你买股票亏了钱找交易所赔么？
如果上市了翻了 100 倍你还会在这里发帖吗？
本身就是赌，期权相比股票的风险很大、收益也更大；愿意承担风险就买，不愿意就不买。

iptables-save 检查 iptables 规则，你的这个场景，软中断消耗基本上只有 netfilter 。
如果没啥异常，perf top 看看是在干啥，不知道 openwrt 有 perf 没

关联的两个 iptables action 是 -j CONNMARK --save-mark （把 skb-mark 复制到 ct-mark ），-j CONNMARK --restore-mark （把 ct-mark 复制到 skb-mark ）

因为 linux route 是工作在 L3 的组件，对于 route 系统来说，是 per-packet 处理的，不关注你的连接。如楼上所说，如果你需要让他从哪儿进来从哪儿出去，那就需要在创建 ct 的时候，设置 ct-mark ，在出向的时候把 ct-mark copy 到 skb mark ，再通过 ip rule 配置不同的 skb mark 走不同的接口出来。

Singularity has been EOL'ed, see Apptainer

出门小米 65w ，小巧方便。
问题是玩游戏的时候两三个小时电池就用光了，轻度使用电池不耗电。
充电功率对电池寿命没有影响。

@ryd994 在 L4LB 场景下，如果能测出 nginx 能比 ipvs 更快，我也想学习一下这到底是什么样的条件和场景，无论是 latency 还是 throughput

@ryd994 不知道说的是哪家的防火墙有性能问题。云平台的防火墙的性能，不知道你是指 nfv 版的防火墙，还是普通的安全组。如果是安全组，各家公有云都是在 Host 侧的 dpdk 实现的，本来 Host 的 dpdk 就一定会有 ct ，连接一旦连接之后，都是在快路径匹配五元组转发，不会遍历流表，所以性能上不去是不存在的，至少目前没听说过国内国外那家公有云的安全组会影响影响。ACL 是无状态的，无 ct 的功能更不可能影响性能。唯一可能就是 nfv 的边界防火墙，或者入侵检测，对应阿里云的云防火墙，这种都是 dpdk 实现的 dpi ，如果说有的云厂商初期会选择用 x86 的 server 来用 iptables 做防火墙，那是有可能会有性能问题，不过迟早都会走向 dpdk 。
iptables 已经在云网络绝迹了，如果哪家云还在用 iptables 或者 iptables 类似物做产品，最好别买。

此外有什么“网络加速能力是内核态用不了，而只能用户态能用”，我理解是不存在这样特性的，如果有的话可以贴一下，我也学习一下。
iptables offload 这个事情社区推进很久了，但是 iptables 本身也即将退出历史舞台，而无论是 iptables 还是 nftables ，绝大部分场景都是用来做有状态服务，而有状态服务要做 offload 最难的地方就是要管理 ct ，网卡无法完成 ct offload 的闭环，需要将带 sync 、rst 、fin 等 flag 的报文送到内核来变更 ct 状态，并决定是否插入或删除硬件的 entry ，带来的问题就是对短连接性能影响较大，家用场景因为连接数少（ 16k 以内），所以是没啥问题的。
关于网卡 offload 能力的 feature ，比如可以搜 NETIF_F_TSO ，来看哪些地方和 TSO 有关，理论上有它出现的地方都是在网卡 driver 。

@ryd994 lro 应该已经被 gro 淘汰了，没用过 lro ，这块儿不是很了解。nf 大部分钩子是夹在协议栈和 driver 之间的，协议栈不会去检查 dev 的 features ，所以 nf+协议栈+用户态看到的报文内容是相同。 区别是用户态在收发包的时候需要多一次内存拷贝，所以要实现相同的功能，任何情况下内核态的 iptables 都会比用户态的 nginx 性能要好。
比如都是做 L4 代理，在 rx 收到包之后，首包做完 dnat 后建 ct ，后续报文 nat 表的 hook 直接匹配 ct 就修改报文转发出去了，不会经过协议栈；同一个报文，nginx 是 rx->link->network->protocol->copy 到用户态->nginx 解析->把 data 发送到到 rs 的 socket->copy 到内核态->protocol->network->link->tx 。
另外关于硬件加速这部分，对于 x86 服务器来说，通常情况下只关注 csum offload 、tso 、tls offload ，只有这几个是真正硬件在做的，其他如 gso 、gro 都是纯软件实现。家用路由器的 nat 加速是针对特定场景定制的处理器，具体我不是很清楚它的实现方式，盲猜应该是快慢路径，iptables 处理建联过程，ct 建好后通过 sdk 下发到转发芯片上。
至于说要实现真正的硬件 offload ，目前有且仅有 mellanox 的 cx5 、cx6 的 switchdev sriov+tc flower offload 是在生产环境大规模使用过，当 tc flower 是 in_hw ，那 tcpdump 都看不到报文，全部在 eswitch 处理了（带 ct 的规则除外，ct offload 比较特殊）。

回到楼主的问题，nginx 会二次建联 tcp ，而 iptables 只是对同一条连接做修改。真因为如此，nginx 可以跨协议代理，比如 HTTPS 转 http 、quic 转 http ，而 iptables 是做不到的。综上，看需求，对性能有要求，只是做 L4 的连接修改，那选 iptables ，对性能没要求，那尽量 nginx ，毕竟 L7 的灵活性无敌

@ryd994 tso 是在网卡 driver 收完，送到协议栈之前就完成了，netfilter 阶段看到的就是一个超大的 skb ；同理，出方向只要 dev 的 feature 带 tso ，那一路都会是一个大 skb ，直到真正的网卡驱动，或者中途某个不支持 tso 的 dev 时，才会被 gso 拆分成多个 skb 。你可以随便找个 docker 环境，起一个 bridge 的容器，在 host 侧的 veth 抓包，会发现 tcpdump 看到的都是大包，因为 veth 默认是开启了 tso 。

@wuwu123 我使用的吉列的 5 层刀片那款，加上泡沫，剃胡子比电动的快，也顺滑

不试试手动吗，剃得丝滑

@heliushao88 有私有化部署的方案，国内有几家大公司私有化部署了

@duoduo1x 要看你 host 上是用啥启动的 qemu ，你在 host 上试试 virsh list ，如果能看到 vm 的话，那就 virsh edit ID ，然后找找 virtio-net 部分，如果有现成的 queue=1 ，那就改成你 CPU 数量相等的值，如果没有，那就加一下，具体格式的话，搜一下 qemu virtio net multi queue

@FabricPath virtio net 更正为 vhost net ，手滑

你这 3 个选项，e1000 和 rtl8139 都是 qemu 在 kvm 、非 kvm 下的全虚拟化网卡，为兼容性而生的。
virtio 是你这 3 个选择中最先进的（所有公有云的软件网络方案都是 virtio ）。virtio 是半虚拟化，即使是 kernel 的 virtio net 也比另外两种好得多。
目测你这个是单队列的，单队列只有一个核在处理报文，如果你能修改一下 qemu 的 xml ，增加队列数的话，性能会更好。

outlook 可以托管 gmail ，国内无缝收发邮件

@FabricPath 是我看错了，你这个无法被访问，就是商家物理网络配置的问题