优化容器网络缓冲区需匹配场景与资源限制，bridge模式侧重socket缓冲区与conntrack调优，host/macvlan模式可深度配置内核tcp参数如rmem_max、tcp_rmem等，并须避免盲目增大、mtu不匹配及未关闭sack等反模式。
优化网络栈缓冲区容量能显著提升容器间大文件传输速度，但关键不在于“越大越好”，而在于匹配传输场景与底层资源限制。实测表明，盲目增大缓冲区反而可能引发延迟上升、内存压力激增甚至gc停顿，尤其在资源受限的容器环境中。
明确容器网络模式对缓冲区生效的前提
不同网络模式下，缓冲区优化的作用域完全不同：
- bridge 模式：默认启用 NAT，数据需经过 iptables 规则和网桥转发，用户态缓冲区（如应用层 socket 的 SO_RCVBUF/SO_SNDBUF）仍有效，但内核 netfilter 路径会引入额外拷贝；此时优化重点是调高 socket 缓冲区 + 减少 conntrack 压力
- host 模式：容器直接复用宿主机网络栈，所有内核网络参数（如 net.core.rmem_max、net.ipv4.tcp_rmem）完全生效，是最适合深度调优的模式
- macvlan 或 ipvlan 模式：容器拥有独立网络接口，缓冲区策略可按物理网卡级别精细控制，适合高吞吐专用场景
调整内核级 TCP 缓冲区参数（host/macvlan 模式适用）
在宿主机或容器启动时通过 sysctl 设置，影响 TCP 连接的实际收发窗口能力：
- net.core.rmem_max / net.core.wmem_max：设为 4–16 MB（如 2097152），确保单连接能承载高带宽延迟积（BDP）
- net.ipv4.tcp_rmem / net.ipv4.tcp_wmem：采用三元组格式，例如 "4096 524288 8388608"，分别对应最小、默认、最大值；大文件传输建议将默认值设为 512 KB，上限设为 8 MB
- net.ipv4.tcp_window_scaling=1：必须开启，否则窗口无法突破 64 KB 限制
注：若使用 Docker，可通过 --sysctl 参数注入，例如：
docker run --sysctl net.core.rmem_max=2097152 --sysctl net.ipv4.tcp_rmem="4096 524288 8388608" ...
应用层 socket 缓冲区显式配置（通用）
无论何种网络模式，应用代码中设置 socket 选项都是最直接有效的手段：
- Java：创建 Socket 后调用 socket.setReceiveBufferSize(8388608) 和 socket.setSendBufferSize(8388608)
- Go：使用 SetReadBuffer() / SetWriteBuffer()，推荐值 1–4 MB
- Python：用 setsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF, 8388608)
注意：该值不能超过内核 rmem_max/wmem_max 上限，否则会被静默截断。
避免常见反模式
以下做法在容器环境下已被多次验证会拖慢大文件传输：
- 将缓冲区设为 100 MB 以上：超出 L3 缓存，触发频繁 TLB miss 和页表遍历开销
- 在 bridge 模式下仅调大 socket 缓冲区却不调大 conntrack 表项（net.netfilter.nf_conntrack_max），导致连接被丢弃
- 忽略 MTU 匹配：容器网络 MTU 若小于物理链路（如 veth 默认 1500 vs 主机网卡 9000），分片会严重降低吞吐
- 未关闭 TCP SACK 或时间戳：在高丢包率容器网络中，这些特性反而增加处理开销
不复杂但容易忽略。
