net.ipv4.tcp_tw_recycle 废弃后的 SO_REUSEADDR 与端口复用风险

tcp_tw_recycle 已被 linux 4.12+ 内核彻底移除，启用会报错；SO_REUSEADDR 仅允许服务端端口复用，不解决客户端端口耗尽；tcp_tw_reuse=1 需满足时间戳、SYN 时间戳递增等条件才生效，且不适用于服务端 accept 场景。

tcp_tw_recycle 已被彻底移除，别再试图启用它

Linux 4.12+ 内核已完全删除 net.ipv4.tcp_tw_recycle 参数，`sysctl -w net.ipv4.tcp_tw_recycle=1` 不仅无效，还会报错 Invalid argument。这不是配置没生效，而是内核源码里连定义都删了。它被废弃的主因是：在 NAT 环境下（包括家用路由器、云厂商 SLB、K8s Service），开启后会直接导致大量连接被拒绝——因为不同客户端时间戳不可比，内核误判为“旧包重放”而丢弃 SYN。哪怕你只在内网用，只要上游有任意一层 NAT 或代理清除了 TCP 时间戳（现实中极常见），tcp_tw_recycle 就等于自毁式开关。

SO_REUSEADDR 是服务端重启的刚需，但不解决客户端端口耗尽

SO_REUSEADDR 的作用非常具体：允许监听套接字（bind() + listen()）在端口处于 TIME_WAIT 时立即复用。它不改变任何连接状态，也不加速回收，只是绕过内核对“端口是否可用”的默认检查。

• ✅ 正确用法：服务端程序启动前，必须调用 setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on))
• ✅ 验证是否生效：用 ss -lnt | grep :8080，若输出行末带 u 标记（如 u 在 State 列右侧），说明已启用
• ❌ 它对客户端 connect() 无直接帮助：客户端临时端口耗尽（Cannot assign requested address）需靠 tcp_tw_reuse=1 + 时间戳校验，而非 SO_REUSEADDR
• ⚠️ 注意：多个进程绑定同一端口时，SO_REUSEADDR 允许“地址不同则可共存”，比如 127.0.0.1:8080 和 192.168.1.10:8080 同时监听；但若都绑 0.0.0.0:8080，仍只允许一个成功（除非还设了 SO_EXCLUSIVEADDRUSE 或使用 IP_FREEBIND）

tcp_tw_reuse=1 为什么常被误认为“失效”

tcp_tw_reuse=1 只在满足全部条件时才触发复用：时间戳开启（tcp_timestamps=1，默认开）、客户端主动发起连接、新 SYN 的时间戳 > 对应 TIME_WAIT 连接最后收到包的时间戳、且间隔 > 1 秒。它**完全不适用于服务端 accept() 新连接的场景**。

• 常见误判：服务端看到大量 TIME_WAIT，就以为 tcp_tw_reuse 没起作用 —— 实际上它本就不该管服务端的监听套接字
• 典型失效链：nginx 作为反向代理，后端服务用固定源端口（如 proxy_bind 10.0.0.5:54321）→ 所有请求四元组高度重复 → tcp_tw_reuse 因无法通过 PAWS 校验而跳过复用
• 验证方式：停服务 → ss -tan state time-wait | wc -l 记初始值 → 加 SO_REUSEADDR 后重启服务 → 快速并发请求 → 再查 TIME_WAIT 增速是否明显放缓（注意：不是看绝对值，是看单位时间增量）

golang/python/java 中 SO_REUSEADDR 的典型陷阱

很多语言封装层默认不设 SO_REUSEADDR，尤其在快速迭代开发中容易忽略。golang 的 net.Listen("tcp", ":8080") 默认不启用；Python 的 socket.bind() 前需手动 setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)；Java 的 ServerSocket 要调用 setReuseAddress(true)。

• Go 示例（关键两行不能少）：

  ln, err := net.Listen("tcp", ":8080") if err != nil {     log.Fatal(err) } // 必须在 Listen 后、Accept 前设置 if tcpLn, ok := ln.(*net.TCPListener); ok {     if err := tcpLn.SetDeadline(time.Now().Add(30 * time.Second)); err != nil {         // 实际只需 SetKeepAlive 或直接操作底层 fd     }     // 更稳妥：用 &net.ListenConfig{Control: ...} 自定义 socket 选项 }

• 最容易被忽略的点：容器环境（docker/K8s）中，服务重启时若未清理旧进程残留 socket，SO_REUSEADDR 也救不了 —— 先 ss -tuln | grep :8080 确认端口真没人占着
• 风险提示：windows 下 SO_REUSEADDR 允许“完全相同四元组”的复用（与 Linux 语义不同），跨平台代码务必注意兼容性

真正卡住高并发服务的，往往不是参数调得不够激进，而是没分清「谁在复用」「复用什么」「复用条件是否满足」。TIME_WAIT 本身不是 bug，它是 TCP 可靠性的守门人；我们做的所有优化，都是在协议约束内找更稳更快的开门方式。