Docker 核心技术：深入理解网络模式 (Bridge, Host, None, Container)

Docker 的网络模式是其核心功能之一，直接决定了容器如何与宿主机、其他容器、外部网络通信。Docker 提供了四种内置网络模式（基于 Linux 网络命名空间和 veth pair 等内核技术），这些模式在 2025–2026 年生产环境中仍是最主流的（尽管 Swarm / Kubernetes 等扩展了它们）。下面按原理 → 对比 → 实战顺序拆解，帮助你从“知道名字”到“能优化生产环境”。

核心对比表（2026 年最实用速查）

模式	隔离级别	宿主机端口映射	与宿主机网络关系	容器间通信（默认）	性能开销	典型场景（优先级排序）	缺点 / 注意事项
Bridge	高（独立命名空间）	需要（-p）	通过 docker0 桥接（NAT）	是（同网络下）	中	★★★★★ 默认模式，Web 服务、数据库、多容器应用	NAT 导致性能小损，端口冲突需手动管理
Host	低（共享宿主机）	无需	完全共享宿主机网络栈	是（直接宿主机）	低	★★★★☆ 高性能需求，如监控、游戏服务器、基准测试	端口冲突风险高，隔离差，不适合多租户
None	极高（无网络）	无	无网络接口，完全隔离	否	零	★★★☆☆ 安全沙箱、离线计算、测试隔离	无网络，无法通信，除非手动加 loopback
Container	中（共享其他容器）	视目标容器	与目标容器共享网络命名空间	是（与目标容器）	低	★★★★☆ Pod 风格、多进程容器、调试代理	依赖目标容器生命周期，端口易冲突

原理基础：所有模式都基于 Linux 网络命名空间（network namespace）。Docker 用 ip netns 命令管理（但 Docker CLI 封装了）。Bridge 用 veth pair 连接容器与桥；Host/None/Container 直接复用/禁用/共享 ns。

1. Bridge 模式（默认、最常用）

底层逻辑：

• Docker 创建 docker0 桥（默认 172.17.0.0/16 子网）。
• 每个容器分配一个 veth pair：一端在容器 ns（eth0），一端连桥。
• 容器间通信走桥；出外网走 NAT（iptables MASQUERADE）。
• 端口映射：宿主机端口 → 容器端口（DNAT）。

Linux 视角查看：

# 查看桥
ip link show docker0
brctl show docker0   # 如有 brctl 工具

# 容器网络（需进容器或用 nsenter）
docker run -d --name test-bridge busybox sleep 3600
docker inspect -f '{{json .NetworkSettings.Networks }}' test-bridge | jq

生产实践：

• 优点：隔离好，易扩展多网络（docker network create mynet --driver bridge）。
• 缺点：NAT 导致 traceroute 复杂，性能比 Host 低 5–10%。
• 2026 年优化：用 Calico / Flannel 替换默认桥，在 K8s 中常见。

2. Host 模式（性能王者）

底层逻辑：

• 容器直接用宿主机的网络 ns，无隔离、无桥、无 NAT。
• 容器看到宿主机的 eth0 / lo 等接口，IP/端口与宿主机共享。
• 通信：容器像宿主机进程一样，直接用宿主机 IP。

示例：

docker run -d --name test-host --network host busybox sleep 3600
# 容器内：ip addr show   # 与宿主机一模一样

生产实践：

• 优点：零网络开销，适合 Prometheus / Node Exporter 等监控容器。
• 缺点：端口冲突（容器 80 占宿主机 80），不适合暴露服务。
• 注意：Windows / Mac Docker 不支持（因 VM 架构）。

3. None 模式（极致隔离）

底层逻辑：

• 容器 ns 中无任何接口（除了 lo），完全无网络。
• 手动加网络需用 ip link add 等，但 Docker 不鼓励。
• 用途：纯计算任务，或安全要求高的沙箱。

示例：

docker run -d --name test-none --network none busybox sleep 3600
# 容器内：ip addr   # 只看到 lo (127.0.0.1)

生产实践：

• 优点：最大安全，无网络攻击面。
• 缺点：实际很少用，除非结合 volume / pipe 传输数据。
• 扩展：用 --cap-add=NET_ADMIN 加权限，手动配置接口。

4. Container 模式（共享网络）

底层逻辑：

• 新容器加入现有容器的 ns，共享 IP/端口/接口。
• 像 K8s Pod：多个容器共享网络，但文件系统/进程隔离。
• 底层：--network container:目标容器名。

示例：

# 先跑一个主容器
docker run -d --name main-container busybox sleep 3600

# 共享它的网络
docker run -d --name shared-container --network container:main-container busybox sleep 3600

# 检查：两个容器 ip addr 相同

生产实践：

• 优点：低开销，适合 sidecar（如 Envoy 代理 + 业务容器）。
• 缺点：主容器死，共享容器网络断；端口冲突需协调。
• 2026 年常见：Helm Chart 中的多容器 Pod 模拟。

生产环境优化要点（避免踩坑）

1. 端口冲突解决：Bridge 用 -p 宿主机端口:容器端口；Host/Container 靠容器内配置不同端口。
2. 性能调优：Host/Container 优先高吞吐场景；Bridge 用 --mtu 9000（jumbo frame）提速。
3. 安全：Bridge 默认隔离好；Host/None 视需求加 SELinux/AppArmor。
4. 多网络：docker network create -d bridge --subnet 10.0.0.0/16 mynet → --network mynet 指定。
5. 调试工具：docker network inspect bridge / nsenter -t $(docker inspect -f '{{.State.Pid}}' 容器) -n ip addr。
6. 2026 年趋势：在云原生中，CNI（如 Cilium eBPF 模式）逐步取代内置桥，提供更细粒度控制。

掌握这些后，你能轻松 debug 90% 的 Docker 网络问题，如“容器 ping 不通外网”（查 iptables / route）。

你当前用的是哪个模式最困惑？

• Bridge 的 NAT 细节？
• Host vs Bridge 性能 benchmark？
• Container 模式在 K8s 中的对应？
• 自定义网络的实战脚本？
• 还是 IPv6 / Macvlan 扩展？

告诉我具体场景，我可以给你更针对性的代码或故障排查流程。