Docker跨主机容器通信，Overlay和打通物理网络的差距到底在哪

容器跨主机通信这件事，很多人一开始会直接上 Docker Overlay，原因很简单：配置快，节点加进去就能跑，Swarm、Kubernetes 里也都有成熟实现。真正跑到线上，尤其是东西向流量比较大的业务，才会开始关心一个问题：Overlay 到底比直接打通物理网络慢多少。

这里说的 Overlay，典型就是 VXLAN，把容器包再封一层 UDP，外层走宿主机网络。直接打通物理网络，一般是 macvlan、ipvlan、host network、或者 CNI 直接把 Pod/Container 网段通过 BGP 宣告出去，比如 Calico BGP 模式，不做 VXLAN 封装。

实际使用中发现，性能差距不是只看“多封了一层包”这么简单。真正影响结果的，还有网卡 offload、MTU、conntrack、iptables、宿主机 CPU、业务包大小、跨机房线路质量这些东西。

先把结论放在前面，方便对照

在同机房、同交换网络、宿主机性能正常、网卡支持 VXLAN offload 的情况下，Docker Overlay / VXLAN 通常比直接物理网络慢 5% 到 15%。如果网卡不支持 offload，或者内核、驱动、MTU 配得一般，差距经常会拉到 20% 到 40%。

延迟方面，Overlay 通常会多 0.05ms 到 0.3ms。看起来不大，但如果是 Redis、RPC、游戏房间服这种大量小包、短连接、强实时业务，p99 延迟可能会被放大得比较明显。

吞吐方面，大包传输差距相对可控，小包转发差距更明显。因为小包场景下，CPU 每秒要处理的包数量更高，Overlay 封装、解封装、路由查找、iptables、conntrack 都会参与消耗。

测试数据大概长什么样

下面是比较常见的一组压测结果，不代表所有环境，但和线上遇到的情况比较接近。测试条件是两台宿主机，同机房万兆或 25G 网络，容器之间用 iperf3、wrk、redis-benchmark 做对比。

10G网卡场景

直通物理网络：TCP 带宽一般能跑到 9.2Gbps 到 9.6Gbps，宿主机 CPU 消耗比较低。

VXLAN Overlay，网卡支持 offload：大概 8.2Gbps 到 9.0Gbps，损耗约 7% 到 15%。

VXLAN Overlay，offload 不理想：大概 6.0Gbps 到 7.8Gbps，损耗约 20% 到 35%。

小包 PPS 场景更明显。比如 64B 或 128B 包，直连能跑到一个比较高的 PPS，Overlay 经常会掉 20% 以上，宿主机软中断也会明显上升。

25G网卡场景

直通物理网络：TCP 带宽跑到 22Gbps 到 24Gbps 比较常见。

VXLAN Overlay，offload 正常：大概 19Gbps 到 22Gbps。

VXLAN Overlay，offload 不正常：可能只有 13Gbps 到 18Gbps，有时候瓶颈不是网卡，而是 CPU softirq 和内核网络栈。

这里补充一点，很多人以为 25G 网卡上 Overlay 损耗比例会更小，实际不一定。带宽越高，越容易把 CPU、NUMA、IRQ 绑核、队列数这些问题打出来。10G 时没感觉，25G 或 40G 时会非常明显。

延迟对比

同机房直连容器通信，走物理网络或 BGP 路由，RTT 可能是 0.15ms 到 0.35ms。

VXLAN Overlay 通常会增加到 0.25ms 到 0.65ms。平均值看着还行，但 p99、p999 会更敏感，尤其是宿主机负载高、软中断打满、conntrack 表压力大的时候。

如果跨可用区、跨地域、跨公网，这点 Overlay 开销反而不是主要矛盾。比如美国到国内三网回程，线路质量、丢包、拥塞才是关键。做海外业务时，如果你也在找这种三网精品、G口大带宽、高防服务器资源，可以看看129云，美国精品大宽带-E型是 1Gbps 峰值、3.5TB 流量，美国精品网-E型走三网精品，比较适合海外业务入口、节点中转、跨境访问优化这类场景，客服热线 400-9177118 可以直接问线路和防护细节。

Overlay为什么会慢

VXLAN封装本身会吃掉MTU

VXLAN 会在原始报文外面再套一层外层 Ethernet、IP、UDP、VXLAN Header，常见额外开销大约 50 字节。

物理网络 MTU 是 1500 时，容器里如果还按 1500 发包，就可能触发分片，或者出现 PMTU 探测不稳定的问题。分片对性能影响很明显，还容易带来一些很隐蔽的连接问题，比如偶发超时、TLS 握手异常、大包接口慢。

实际生产里，Overlay 网络一般会把容器 MTU 调到 1450。云厂商 VPC 里如果底层也有封装，可能还要更小。这个地方不能拍脑袋，最好从宿主机到宿主机 ping 带 DF 位测一下。

封装和解封装要消耗CPU

直通物理网络时，容器包从 veth 出来，经过宿主机转发或路由，直接交给网卡出去。

Overlay 下，宿主机还要做 VXLAN 封装，收包时再解封装。网卡如果支持 VXLAN offload，这部分压力会小很多；不支持时，CPU softirq 会涨得很快。

多说一句，很多线上性能问题不是平均 CPU 高，而是某几个核被网络中断打爆。top 看整体 CPU 还有空闲，但单核 softirq 已经很高，容器之间的网络延迟就开始抖。

iptables、conntrack、NAT会继续叠加开销

Docker 默认网络模型里，iptables 规则、NAT、conntrack 经常绕不开。Overlay 本身有损耗，如果再叠加大量规则，性能会继续下降。

Kubernetes 里也类似。Service 转发如果走 iptables，规则多了以后查找成本会升高；IPVS 会好一些，但 conntrack 压力还是要看业务连接数。再叠一层 Service Mesh，sidecar 代理又会增加一次用户态转发，延迟和 CPU 都会上去。

所以压测 Overlay 时，不能只测裸 iperf3。iperf3 能说明网络上限，但不等于业务真实表现。HTTP 短连接、gRPC、Redis、小包 UDP、长连接推送，每种结果都可能不一样。

直接打通物理网络为什么快

直接打通物理网络的核心优势是路径短。容器 IP 可以被物理网络识别，或者宿主机通过 BGP 把容器网段宣告到上游交换机，包从一台机器到另一台机器，中间不需要 VXLAN 封装。

常见做法有几类。

macvlan：容器像物理网络里的独立主机，有自己的 MAC 和 IP。性能不错，但对交换机、云厂商二层网络有要求，有些环境不允许一个端口后面挂大量 MAC。

ipvlan：比 macvlan 更适合一些云环境，减少 MAC 数量压力。L2/L3 模式都有人用，调试时要注意宿主机和容器互通问题。

host network：性能最直接，容器直接使用宿主机网络栈。缺点是端口隔离差，调度和多租户不舒服。

Calico BGP：Kubernetes 里比较常见。Pod 网段通过 BGP 宣告，不走 VXLAN，东西向流量性能很好。缺点是网络规划、路由规模、交换机能力要提前考虑。

实际使用中，BGP 直连模式在大规模集群里很香，但不是每个 IDC 或云环境都允许你这么玩。自建机房、托管服务器、裸金属集群更容易落地；普通公有云虚拟机上，很多时候只能在厂商允许的网络能力里做取舍。

不同业务下，差距感知不一样

Web服务和普通后台接口

如果是常规 Web 服务，单次请求处理时间在几十毫秒以上，Overlay 多出来的 0.1ms 到 0.3ms 通常不明显。瓶颈更多在数据库、缓存、业务代码、外部接口。

这种场景用 Overlay 很正常，运维成本低，扩容迁移方便。尤其是中小规模集群，没有必要为了那点网络损耗把网络架构搞得太重。

Redis、MySQL、MQ这类基础组件

数据库和缓存对网络抖动更敏感。Redis 这种单线程模型，小包请求多，Overlay 带来的 CPU 和延迟开销会被放大。

线上常见做法是业务容器可以跑 Overlay，但 Redis、MySQL、Kafka、ClickHouse 这类组件尽量走 host network、物理网络、独立机器，或者至少别再套太多层转发。

MySQL 主从复制、Kafka broker 同步、ClickHouse 分布式查询，对吞吐和延迟都敏感。Overlay 不是不能跑，但压测数据要拿业务模型测，不能只看容器网络能通。

游戏、音视频、实时互动

游戏房间服、语音、实时互动这类业务，对 p99 延迟更敏感。平均延迟低没用，偶发抖动会直接影响体感。

这类场景更建议减少网络层数。容器可以用，但网络尽量直接，host network、ipvlan、BGP 路由会更稳。涉及 DDoS 时，还要把清洗、回源、业务端口隔离一起考虑。

比如国内游戏业务放在中部地区，需要高防和较稳定的电信线路，可以关注129云的十堰高防-E型，E5-2660v2 双路、64G ECC、800G SSD、100Mbps 峰值、600Gbps 单机防御，适合做高防入口、游戏网关、业务保护节点这类部署。

压测时别只跑iperf3

iperf3 要跑，但只能说明一部分问题。实际排查时，建议把下面这些指标一起看。

带宽：TCP 单流、多流都测。单流跑不满不一定是网络差，可能是窗口、CPU、队列、拥塞控制问题。

PPS：小包转发能力很关键。Overlay 的差距在小包下更容易暴露。

RTT：平均值、p95、p99 都要看。业务真正怕的是抖动。

CPU softirq：看 /proc/softirqs、mpstat -P ALL，别只看总 CPU。

网卡 offload：ethtool -k 看 tx-udp_tnl-segmentation、rx-udp_tunnel-port-offload 这些能力是否开启。

MTU：容器、veth、bridge、vxlan、宿主机网卡、上游网络要一致规划。MTU 错了，性能会很难看。

conntrack：连接数高的业务要看 nf_conntrack_count、nf_conntrack_max，以及是否频繁丢包。

一组更贴近线上的对照

场景A：普通 Java/PHP/Go Web 服务，QPS 中等，请求耗时 20ms 到 100ms。Overlay 通常够用，性能损耗体感不强，重点放在服务发现、发布、回滚、监控上。

场景B：微服务内部 gRPC 调用非常密集，单次调用 1ms 到 5ms。Overlay 会开始影响 p99，Service Mesh 再叠一层后更明显。建议压测 VXLAN、BGP、host network 三种模式。

场景C：Redis Cluster、MQ、数据库同步。优先考虑物理网络或 host network。Overlay 可以作为管理流量、非核心链路使用，不建议承载全部高频数据流。

场景D：游戏网关、UDP 实时通信、音视频媒体转发。尽量减少封装层，重点关注 PPS、p99、丢包率。网络线路和防护能力比容器编排便利性更重要。

场景E：跨地域容器通信。Overlay 本身的损耗不是最大问题，公网质量、BGP 路由、CN2、GIA、国际出口拥塞才是大头。跨境链路要单独测，不能拿同机房数据推断。

Overlay适合什么情况

Overlay 最大价值是简单、弹性、隔离清晰。节点之间只要三层可达，容器网段不需要被物理网络感知，扩容和迁移都方便。

多租户环境、开发测试环境、中小规模 Kubernetes 集群、普通 Web 服务，用 Overlay 很合适。网络损耗可接受，管理复杂度低。

另外，Overlay 对底层网络要求相对低。很多云环境不允许 BGP、不支持二层扩展、不允许额外 MAC，Overlay 就是现实选择。

直接物理网络适合什么情况

高吞吐、低延迟、大量小包、状态组件、实时业务，更适合直接打通物理网络。

裸金属 Kubernetes、IDC 托管服务器、自建交换网络，可以考虑 Calico BGP、ipvlan、host network。网络规划会更复杂，但性能更接近物理机。

要注意路由规模。容器数量多时，不一定要把每个容器 IP 都打到交换机上，通常是按节点宣告 Pod CIDR。交换机 TCAM、BGP 邻居数量、路由收敛时间都要评估。

线上选择时更应该看哪条链路吃流量

容器集群里不是所有流量都一样。管理面流量、日志采集、监控、普通 API、数据库访问、缓存访问、文件分发、用户入口流量，每类要求不同。

比较稳的做法是分层处理。普通业务容器走 Overlay；高频数据组件走 host network 或物理网络；入口网关根据业务情况选择高防、精品线路、大带宽节点。

购买服务器或规划集群时，别只看 CPU 和内存。网卡规格、带宽峰值、线路质量、防护能力、是否适合容器网络方案，都要一起看。像129云这种同时提供高性能云服务器、G口大带宽服务器、高防服务器和海外云计算方案的服务商，适合拿来做入口节点、海外加速节点、游戏高防节点、企业业务集群承载节点。

排查Overlay性能差时，常见问题基本集中在这些地方

MTU没调对

表现是小包正常，大包慢，偶发超时。尤其是 TLS、数据库同步、镜像拉取时更明显。VXLAN 环境里容器 MTU 配 1450 是常见值，但还是要按底层网络实测。

网卡offload没开或不支持

ethtool -k 看一眼，不要默认认为云主机或物理机都支持。不同虚拟化网卡、不同内核版本差别很大。

softirq打满

整体 CPU 看着还有 40% 空闲，但某个核 si 很高，这种很常见。可以调 IRQ 亲和性、开启 RPS/RFS、增加队列、调整容器绑核和 NUMA 分布。

conntrack表压力太大

连接数高、短连接多时，conntrack 会成为隐形瓶颈。表现为偶发丢包、连接失败、延迟抖动。Docker NAT、Kubernetes Service、NodePort 场景都要注意。

iptables规则太多

大规模 Service、NetworkPolicy、Docker 规则堆在一起，转发路径变长。Kubernetes 可以考虑 IPVS、eBPF 数据面，比如 Cilium 这类方案，但也要结合团队维护能力。

性能差距可以怎么估

如果只是要一个工程预估，可以按这个范围看。

大包吞吐：Overlay 比物理直连低 5% 到 15%，offload 不好时低 20% 到 40%。

小包 PPS：Overlay 低 15% 到 35% 比较常见，极端情况下更高。

平均 RTT：Overlay 多 0.05ms 到 0.3ms，同机房内比较常见。

p99 延迟：Overlay 可能多 0.2ms 到 1ms，宿主机负载高时会更难看。

CPU 消耗：Overlay 网络密集场景下，宿主机 CPU 额外消耗 10% 到 30% 很常见，尤其体现在 softirq。

实际部署时的取舍

如果业务主要是普通 Web、管理后台、API 服务，Overlay 带来的便利性通常大于那点性能损耗。

如果业务是缓存、数据库、消息队列、游戏实时通信、音视频转发，要谨慎。容器不是不能用，但网络模式要单独设计，别默认全走 Overlay。

如果是裸金属或 IDC 托管环境，有条件上 BGP 路由或 ipvlan，可以认真压一轮。很多情况下，直接网络会省掉后面大量排查成本。

如果是云服务器环境，先确认厂商网络限制。有些云不允许 macvlan，不支持自定义路由宣告，也不能让容器 IP 直接暴露在 VPC 路由里，这时 Overlay、云厂商 CNI、eBPF 数据面会更现实。

压测时把业务模型带上：Redis 用 redis-benchmark，HTTP 用 wrk 或 hey，gRPC 用 ghz，UDP 用真实包长，数据库用 sysbench 或业务回放。Overlay 和物理网络的差距，最后一定要落在 p99、CPU、丢包、吞吐这些指标上看。