低延迟场景下应优先选host模式，实测容器间延迟可压至1–3ms；bridge模式因veth、网桥、NAT等环节叠加导致8–12ms延迟；macvlan是需独立IP时的折中选择；overlay和none模式均不适用于低延迟需求。
低延迟场景下，网络模式选错会直接让容器通信多出 8–12ms 延迟，甚至翻倍。关键不是“哪个更好”，而是“哪个更匹配你的部署边界和安全要求”——host 模式在单机高敏服务中几乎是默认答案，但不能一概而论。
看延迟来源：bridge 模式为什么慢
Bridge 是 Docker 默认模式，但它走的是完整虚拟网络路径：容器 → veth pair → docker0 网桥 → NAT → 物理网卡。实测各环节加起来贡献约 8–12ms 延迟，其中 NAT 转换、网桥转发、veth 驱动各占 1–5ms。如果你的应用对端到端延迟敏感（比如实时音视频处理、高频交易中间件、边缘传感器聚合），这部分开销无法忽略。
- 容器间通信走 bridge，默认需跨网桥+地址转换
- 对外访问必须经过 iptables 规则和 SNAT，增加内核处理跳数
- 无法绕过宿主机的 conntrack 表，高并发时易成瓶颈
host 模式：单机低延迟的首选方案
容器直接复用宿主机网络命名空间，不创建独立网卡、不走网桥、不触发 NAT。实测可将容器间延迟压到 1–3ms，带宽也接近物理网卡极限。适合数据库代理、API 网关、时序数据写入器等对吞吐和响应时间双敏感的服务。
- 启动时加 --network host 即可启用，零配置改动
- 端口无需映射（-p 参数失效），容器内监听 80 就等于宿主机 80
- 注意：多个容器若监听同一端口会冲突，需提前协调端口分配
macvlan：需要独立 IP 又要低延迟的折中选择
当业务要求容器拥有真实局域网 IP（比如对接已有 DHCP 或 ACL 策略），又不能接受 bridge 的延迟，macvlan 是更可控的替代方案。它为容器绑定物理网卡子接口，跳过网桥和 NAT，延迟接近 host 模式，同时保留网络层隔离。
- 需宿主机网卡支持混杂模式（通常默认开启）
- 创建命令示例：docker network create -d macvlan --subnet=192.168.1.0/24 --gateway=192.168.1.1 -o parent=eth0 my_macvlan
- 容器获得同网段真实 IP，防火墙、交换机策略可直接作用于容器
别踩坑：overlay 和 none 模式不适合低延迟场景
Overlay 专为 Swarm 跨主机设计，封装/解封装 VXLAN 包带来额外 10ms+ 延迟，带宽损耗明显，只应在分布式调度不可替代时使用。None 模式完全无网络栈，连 localhost 都不通，仅用于离线计算类容器，和低延迟目标背道而驰。
- 边缘计算节点若只有单机部署，强行用 overlay 属于过度设计
- none 模式下想调试网络？得靠 nsenter 进入命名空间手动配，效率极低
- 真正需要隔离又低延迟的，优先考虑 macvlan + 网络策略，而非 none
