Go 的 net.Conn 默认不实现拥塞控制，该逻辑由内核 TCP 协议栈完成；Go 程序仅通过系统调用封装收发数据，拥塞算法（如 BBR、CUBIC）需在操作系统层配置，如 Linux 的 /proc/sys/net/ipv4/tcp_congestion_control。
Go 的 net.Conn 默认不实现拥塞控制
Go 标准库的 net.Conn（比如 tcpConn）本身不内置任何拥塞控制逻辑——它只做系统调用的封装，真正的拥塞控制由内核 TCP 协议栈完成。你写的 Go 程序发包快慢、重传策略、窗口调整，99% 由 Linux/FreeBSD 内核决定，不是 Go runtime 控制的。
这意味着：别指望通过改 Go 代码里的某个参数就能“开启 BBR”或“切换 CUBIC”，那些得在操作系统层配置。
- Go 应用能影响的，主要是如何使用连接（如写缓冲区大小、是否启用
SetWriteBuffer）、何时读/写、是否复用连接 - 真正调拥塞算法，得看
/proc/sys/net/ipv4/tcp_congestion_control（Linux）或sysctl net.inet.tcp.cc.algorithm（macOS/BSD） -
net/http默认用Keep-Alive，但空闲连接超时由http.Server.IdleTimeout控制，和拥塞无关
哪些 Go 参数实际影响网络吞吐表现
虽然不碰拥塞算法，但几个 net.Conn 和 http.Server 的设置会显著改变你的连接行为，间接影响内核对连接的判断（比如被判定为“突发流”还是“稳态流”）。
-
conn.SetWriteBuffer(n)和conn.SetReadBuffer(n)：设太小会导致频繁系统调用；设太大可能让内核延迟 ACK 或触发 Nagle，尤其小包场景下反而降低响应速度 -
http.Server.ReadTimeout/WriteTimeout已废弃，应改用ReadHeaderTimeout+IdleTimeout，否则可能在 TLS 握手阶段就误杀连接 -
http.Transport.MaxIdleConnsPerHost设为 0 表示不限，但实际受内核net.ipv4.ip_local_port_range和net.ipv4.tcp_fin_timeout限制，盲目调高会导致 TIME_WAIT 爆满 - 用
context.WithTimeout包裹http.Do是必须的，否则 DNS 解析卡住或服务端不回包时 goroutine 会永久挂起
常见错误：把 SetNoDelay(true) 当成“加速”开关
TCP_NODELAY 关闭 Nagle 算法，确实能减少小包延迟，但它不是万能加速器——反而可能加重网络负担。
立即学习“go语言免费学习笔记（深入）”；
- HTTP/1.1 短连接下开
SetNoDelay(true)有意义（避免等待 ACK 合并小包） - HTTP/2 或长连接 RPC 场景下，如果业务本身已批量攒包（比如 protobuf 编码后一次写入），再开
SetNoDelay会产生更多小 TCP 段，增加丢包概率和 ACK 压力 - 某些云厂商的负载均衡器（如 AWS ALB）对小包更敏感，开启后可能触发额外限速或连接中断
- 验证是否生效：抓包看 TCP flag 是否有
[PUSH]，而不是只看 Go 代码里有没有那行调用
调试时最容易忽略的底层信号
Go 程序跑得慢，很多人盯着 pprof 看 CPU，但网络问题往往藏在内核指标里，且 Go runtime 不暴露这些。
-
ss -i查单个连接的retrans、rcv_space、cwnd（实际拥塞窗口），比看 Go 日志直观得多 -
cat /proc/net/snmp | grep -i "RetransSegs"看全局重传量突增，可能是网关丢包或对方接收窗口长期为 0 - Go 的
runtime.ReadMemStats里没有网络缓冲区统计，net.Conn的读写缓冲区用量无法直接观测，得靠lsof -p PID -n配合/proc/PID/fd/下的 socket inode 反查 - 容器环境里，
docker stats显示的网络 I/O 是 host 网桥层数据，和容器内进程看到的send()/recv()并不一一对应
调优不是改完几个 Go 参数就结束的事，关键路径上的每个环节——从应用 write() 到内核 sk_buff 分配，再到网卡 ring buffer，都可能卡住。最常被跳过的，是确认当前连接到底走的是哪个拥塞算法、cwnd 多大、有没有持续丢包。
