@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 是我看错了，你这个无法被访问，就是商家物理网络配置的问题

ip route get 1.1.1.1
看 src ip 就是你 default 路由指定的 IP ，如果不指定，那就用这个 IP 。要想把多个 IP 用起来，除了 IP 配在接口上，还需要应用程序显式指定源 IP

ipvs 性能、扩展性、易用性是最好的。所有用户态代理（ nginx 之类），在这个场景性能都差很多


ipvsadm -A -t 1.0.0.1:1111 -s rr
ipvsadm -a -t 1.0.0.1:1111 -r 2.0.0.1:2222 -m -w 1
ipvsadm -a -t 1.0.0.1:1111 -r 2.0.0.2:2222 -m -w 1

@kera0a 看来这照片铁假了

连接数，实际上这个值采集的是 conntrack 的值
conntrack -L | wc -l
没经过 conntrack 的连接，是统计不出来的，比如在 filter 表把局域网连接 NOTRACK 了，那局域网的连接不会被统计到里面

@WithLin 多网卡的场景非常小，目前只有 RDMA 场景需要按 GPU 的 NUMA 数量分配 VF 的场景有。IPAM 就是一个中心化 IPAM

你填了是你填了，运营商认不认那就是另外一会事了。
不过内网 TOS 还是可以用的，一般都是和物理网络约定几个值就行。典型就是 RoCE 使用一个 dscp ，全网都配置这个 dscp 为最高优先级，来实现无损网络。