net.ipv4.tcp_tw_reuse 在高并发短连接场景下不能乱开，因其仅对客户端新连接有效且依赖tcp_timestamps，NAT环境下易失效；应优先扩端口范围、调短fin_timeout，并配平somaxconn与应用backlog。
为什么 net.ipv4.tcp_tw_reuse 在高并发下不能乱开
在短连接密集的场景（比如 HTTP API 网关、微服务调用），大量连接快速建立又关闭，容易堆积 TIME_WAIT 状态。有人直接启用 net.ipv4.tcp_tw_reuse = 1 想复用端口，结果出现偶发连接失败或重传异常——这不是参数没生效，而是它依赖时间戳（tcp_timestamps）且只对「客户端」行为有效。
-
tcp_tw_reuse仅允许把处于TIME_WAIT的本地端口，重新用于**向外发起的新连接**（即本机作为 client），对 server 端监听无影响 - 必须同时开启
net.ipv4.tcp_timestamps = 1，否则内核会忽略tw_reuse - 若后端服务部署在 NAT 后（如容器集群经 kube-proxy），时间戳可能被中间设备篡改或丢弃，导致复用失败甚至 RST
- 更稳妥的做法是：优先调大
net.ipv4.ip_local_port_range（例如"1024 65535"），再配合net.ipv4.tcp_fin_timeout缩短TIME_WAIT持续时间（注意不能低于 30 秒，避免丢 ACK）
net.core.somaxconn 和应用层 listen() 的 backlog 要配平
Linux 内核维护两个队列：SYN 半连接队列（net.ipv4.tcp_max_syn_backlog）和全连接队列（net.core.somaxconn）。当应用调用 listen(fd, backlog) 时，实际生效的是 min(backlog, somaxconn)。如果只改内核参数却不改代码里的 backlog 值，等于白调。
- 查看当前全连接队列上限：
cat /proc/sys/net/core/somaxconn（默认常为 128） - Nginx 默认
listen ... backlog=511，但若somaxconn是 128，则真正可用仍是 128 - Go 的
net.Listen("tcp", addr)默认不设 backlog，等价于 128；需显式用net.ListenConfig{Control: ...}或启动前调sysctl -w net.core.somaxconn=4096 - 队列溢出表现：客户端 connect() 随机超时、服务端
ss -s显示embryonic或failed计数上升
HTTP 长连接别只靠 keepalive_timeout，还得管住 tcp_keepalive_*
Web 服务设了 keepalive_timeout 75（Nginx）或 http.Server.IdleTimeout = 75 * time.Second（Go），只是应用层空闲阈值。底层 TCP 连接若被中间防火墙静默回收（常见于云厂商 SLB、企业出口网关），应用层根本收不到 FIN，只能靠内核级保活探测兜底。
-
net.ipv4.tcp_keepalive_time：连接空闲多久后开始发 keepalive 包（默认 7200 秒，太长！建议调至 600） -
net.ipv4.tcp_keepalive_intvl：两次探测间隔（建议 60） -
net.ipv4.tcp_keepalive_probes：连续失败几次后断连（建议 3） - 这些参数对所有 TCP 连接生效，不是 per-socket；若业务有低频长链（如 IoT 心跳），需单独在 socket 上 setsockopt(
TCP_KEEPIDLE/TCP_KEEPINTVL/TCP_KEEPCNT) 覆盖全局值
UDP 场景下 net.core.rmem_max 不够会导致静默丢包
UDP 没有重传机制，接收缓冲区溢出时内核直接丢包，且不通知用户态。监控上表现为 netstat -su 中 packet receive errors 或 rcvbuferrors 持续增长，但应用日志里查不到错误——因为 recvfrom() 返回 -1 且 errno 是 EAGAIN 或 ENOMEM，而很多框架忽略了这个分支。
- 先看当前限制：
cat /proc/sys/net/core/rmem_max（常见默认值 212992 字节 ≈ 208KB） - 单个 UDP socket 接收缓冲区上限受此值约束，即使你调
setsockopt(fd, SOL_SOCKET, SO_RCVBUF, &size, sizeof(size))也超不过它 - 突发流量（如 DNS 放大攻击、实时音视频数据洪峰）极易打满缓冲区；建议根据单包大小 × 预估并发包数 × 安全系数（如 2~3）反推所需值，例如：1500B × 1000pps × 3 ≈ 4.5MB → 设
rmem_max = 4608000 - 调整后需确认应用是否显式设置了
SO_RCVBUF，否则仍用系统默认初始值（通常远小于 max）
sysctl -w net.core.rmem_max=4608000 sysctl -w net.core.rmem_default=4608000
真正的瓶颈往往不在协议栈最外层，而在参数之间的隐式耦合——比如开了 tcp_tw_reuse 却忘了开时间戳，或者调大了 somaxconn 却没改应用 listen 的 backlog 参数。这些地方不报错，只悄悄降级。
