如何解决宿主机到Docker容器网络吞吐量极低的问题

你观测到的性能问题不是Docker容器本身的通用缺陷，完全是macOS、Windows平台下Docker Desktop的特殊架构导致的：
这两个非Linux平台上的Docker无法直接复用宿主机内核运行容器，必须先启动一个隐藏的轻量级Linux虚拟机，所有容器实际都运行在这个虚拟机内部。你以为的「宿主机到容器的直接通信」，实际流量要经过多层转发：

1. 宿主机协议栈发出数据包
2. 宿主机和虚拟机之间的虚拟网卡/用户态网络代理转发
3. 虚拟机内核的端口映射NAT规则处理
4. 虚拟机内部Docker bridge网络转发
5. veth虚拟网卡对送到容器内

整条路径比Linux原生Docker多了2-3层额外开销，部分环节甚至跑在用户态，没有内核转发的性能优势，远达不到本地环回的转发效率。

两个反常测试结果的具体成因：

• macOS本地环回性能高，是因为本地环回流量直接走macOS原生内核的lo接口，完全不涉及隐藏虚拟机和Docker的网络组件；但Docker Desktop在macOS上长期使用vpnkit做用户态端口转发，所有映射端口的流量都要经过这个用户态进程做包解析、转发，没有内核网络栈的offload加速，早期版本甚至默认做了带宽限速，你测到的350Mbps就是这个实现的典型性能水平。
• Windows 10 Pro本地环回性能本身弱于macOS，但如果你的Docker Desktop用的是WSL2后端，WSL2和宿主机之间的虚拟网络转发是内核态实现的，开销比macOS的vpnkit低，所以最终测出来的宿主机到容器带宽反而比macOS更高。

作为对比，原生Linux环境下部署Docker时，不存在额外的虚拟机层，宿主机到容器的流量由Linux内核netfilter模块直接做DNAT转发，通过veth pair直达容器网络栈，全程不经过物理网卡，性能和本地环回几乎无差异，通常可以跑到几十Gbps的水平，和你测到的macOS本地环回性能相当。

按优化效果从高到低排序：

• 最彻底的方案：如果业务对网络性能要求极高，直接在Linux宿主机上部署Docker，没有额外转发层，默认配置就能跑满内存带宽，不存在你遇到的性能瓶颈。
• macOS环境优化：
  • 升级到最新版Docker Desktop，在设置中开启「New Virtualization Framework」和「新版网络栈」选项，替换掉老旧的vpnkit实现，端口映射带宽可以提升到10Gbps以上。
  • 放弃Docker Desktop，自行通过multipass等工具启动启用virtio半虚拟化网卡的Linux虚拟机运行容器，虚拟网络性能可以比默认Docker Desktop高10-20倍。
• Windows环境优化：
  • 确保Docker Desktop使用WSL2后端，不要用老旧的Hyper-V后端，基础网络性能就能提升30%以上。
  • 在用户目录下的.wslconfig文件中添加networkingMode=mirrored配置，开启WSL2镜像网络模式，省去宿主机到WSL2虚拟机的NAT转发开销，宿主机访问容器的性能可以提升到10Gbps级别，和本地环回的性能差距缩小到10%以内。
• 跨平台通用临时方案：不要通过宿主机localhost加映射端口的方式访问容器，直接进入Docker所在的虚拟机环境（WSL2发行版/ Docker Desktop的Linux虚拟机shell），通过容器的内部IP直接访问，流量全程在虚拟机内核转发，没有跨虚拟机的额外开销，性能接近原生。

注：你测试用的iperf客户端命令存在参数遗漏，缺少指定服务端地址的参数，正确的客户端命令应为iperf -c 127.0.0.1 -p 8020，但由于你两组对照测试使用了相同的命令参数，测试结果的对比是有效的，不影响问题结论。

内容的提问来源于stack exchange，提问作者j3141592653589793238