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 模拟。
生产环境优化要点（避免踩坑）
- 端口冲突解决：Bridge 用
-p 宿主机端口:容器端口；Host/Container 靠容器内配置不同端口。 - 性能调优：Host/Container 优先高吞吐场景；Bridge 用
--mtu 9000（jumbo frame）提速。 - 安全：Bridge 默认隔离好；Host/None 视需求加 SELinux/AppArmor。
- 多网络：
docker network create -d bridge --subnet 10.0.0.0/16 mynet→--network mynet指定。 - 调试工具：
docker network inspect bridge/nsenter -t $(docker inspect -f '{{.State.Pid}}' 容器) -n ip addr。 - 2026 年趋势：在云原生中，CNI（如 Cilium eBPF 模式）逐步取代内置桥，提供更细粒度控制。
掌握这些后，你能轻松 debug 90% 的 Docker 网络问题，如“容器 ping 不通外网”（查 iptables / route）。
你当前用的是哪个模式最困惑？
- Bridge 的 NAT 细节？
- Host vs Bridge 性能 benchmark？
- Container 模式在 K8s 中的对应？
- 自定义网络的实战脚本？
- 还是 IPv6 / Macvlan 扩展？
告诉我具体场景，我可以给你更针对性的代码或故障排查流程。
