net.Conn 复用比频繁新建更关键，因新建连接会触发大量 TCP 三次握手、TIME_WAIT 占用及文件描述符耗尽，容器默认 ulimit 仅 1024，易导致 “too many open files” 错误。
为什么 net.Conn 复用比频繁新建更关键
Go 程序在容器中与外部服务（如 Redis、MySQL、HTTP API）通信时，若每次请求都新建 net.Conn，会触发大量 TCP 三次握手 + TIME_WAIT 占用 + 文件描述符消耗。容器默认 ulimit 通常只有 1024，极易触发 "too many open files" 错误。
实操建议：
- HTTP 客户端必须复用
http.Transport，禁用DisableKeepAlives: true（默认是 false，但常被误设） - 自定义
http.Transport时，显式设置MaxIdleConns和MaxIdleConnsPerHost，例如设为100而非 0 或 2 - 使用
database/sql时，调用db.SetMaxOpenConns(50)和db.SetMaxIdleConns(20)，避免连接池过小导致排队，或过大挤占宿主机资源
如何让 Go 程序感知 Docker 的网络命名空间限制
容器内 Go 程序无法直接修改 /proc/sys/net/ipv4/tcp_tw_reuse，但可通过 syscall.SetsockoptInt32 在 socket 级别启用 SO_REUSEADDR 和 SO_KEEPALIVE，绕过内核参数依赖。
常见错误现象：容器重启后连接延迟升高、偶发 "connect: cannot assign requested address" —— 很可能是未开启端口复用。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 在
net.Listen或net.Dial后，对底层conn.(*net.TCPConn)调用SetKeepAlive和SetKeepAlivePeriod - 若使用
http.Server，通过srv.ConnContext或自定义Listener注入 socket 选项 - 避免在容器启动脚本里盲目写
sysctl -w net.ipv4.tcp_tw_reuse=1：Docker 默认不挂载/proc/sys为可写，且该设置对单个 socket 无效
golang.org/x/net/http2 在容器中启用的隐性代价
启用 HTTP/2 后，Go 默认复用 TCP 连接并多路复用，看似提升吞吐，但在高并发短连接场景（如 sidecar 模式调用 Istio 服务），反而因流控和帧缓冲积累引发延迟毛刺。
性能影响：
- HTTP/2 连接建立耗时比 HTTP/1.1 高约 10%～15%，尤其在 TLS 握手阶段
- 容器内存受限时，
http2.maxFrameSize缓冲区可能放大 RSS 占用 - Docker bridge 网络下，某些内核版本（如 4.15 之前）对 HTTP/2 的 ACK 合并不友好，增加小包数量
实操建议：
- 仅对明确支持 HTTP/2 且长连接稳定的下游服务启用，例如 gRPC 后端；对 Nginx / Envoy 等反向代理，优先走 HTTP/1.1 + keep-alive
- 禁用方式不是删掉 import，而是设置
http.DefaultTransport.(*http.Transport).TLSNextProto = map[string]func(authority string, c *tls.Conn) http.RoundTripper{} - 用
curl -v --http1.1 https://...对比验证实际协商协议，别只信 Header
容器 DNS 解析慢？别只改 /etc/resolv.conf
Go 的 net.Resolver 默认使用系统解析器（goos == "linux" 时走 getaddrinfo），但容器内 /etc/resolv.conf 若含多个 nameserver 或超时配置不当，会导致 net.LookupIP 平均耗时飙升至秒级。
根本原因：Go 不支持 resolv.conf 中的 options timeout:1 attempts:2，且默认并发查询所有 nameserver，失败后才 fallback。
实操建议：
- 构建镜像时用
RUN echo "options timeout:1 attempts:2" >> /etc/resolv.conf—— 无效，Go 忽略它 - 正确做法：创建自定义
net.Resolver，设置PreferGo: true并指定DNSServerTimeout，例如：
resolver := &net.Resolver{
PreferGo: true,
Dial: func(ctx context.Context, network, addr string) (net.Conn, error) {
d := net.Dialer{Timeout: time.Second}
return d.DialContext(ctx, network, "10.96.0.10:53") // 直连 CoreDNS IP
},
}
注意：硬编码 DNS IP 比 host.docker.internal 更可靠，后者在非 Docker Desktop 环境可能不可用。
网络栈优化没有银弹，容器里最常被忽略的是连接生命周期管理——不是调大某个 sysctl，而是让 Go 代码自己管好 fd、复用连接、控制解析路径。一旦在 pprof 里看到大量 runtime.netpoll 阻塞或 net.(*Resolver).lookupIP 耗时，问题八成不在网络层，而在 Go 的配置姿势上。
