回到楼主的问题，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 为最高优先级，来实现无损网络。

随便列一下，

网关的问题：
1. 网关出 Bug 、被打爆 所有服务全无
2. 网关在逻辑增加了一跳路径，降低稳定性
3. 网关不是单纯的网关，如果是 DNS+VIP 的方式访问网关，那在网络层也需要 L4 接入，L4LB 是 ecmp 发布的路由，扩缩容时会损失部分连接（除非做了 session 同步，这个坑更多），所以在物理层面实际上增加了两跳
4. 为了避免 3 中 L4LB 带来的缺陷，需要采用服务发现去发现网关实例，那为啥不直接发现下游实例呢？

优势：
1. 服务治理（含风控等所有通用功能）好做，功能迭代在网关上

综上：
1. 入口服务使用网关做接入，内部 RPC 调用上 ServiceMesh

@WithLin 原因比较多，比如 Cilium 功能太多，而大部分功能在内网是不需要的，比如 NetworkPolicy 、非 VxLAN 隧道支持
Cilium 为了适配各种场景、各种 kernel 版本，使得它的复杂度很高，而我们的场景要小很多；同时还有一些场景是 Cilium 不支持的，比如多个物理网卡
一些额外的功能，比如 Pod 内多网卡，社区方案只能用 multus ，而 multus 需要通过 crd 来存储数据；历史原因 Pod 的 IP 需要 BGP 发布到 Underlay ，所以需要额外的 IPAM
Cilium 能支持的规模也太小，因为大量使用了 apiserver 的 api ，基本上集群规模到 2k 左右就到头了；同理太多的功能判断也导致数据面的性能没有做到最好

维护 Cilium 的难度不亚于参考 Cilium 的方案重写一个，大部分思想还是从 Cilium 来的，只是代码是重写的，以及抄了 Cilium 部分 ebpf 片段。