高并发下linux默认tcp参数易成瓶颈，必须调优队列长度、time_wait行为、缓冲区和拥塞算法；不调则连接丢弃、端口耗尽、吞吐卡在30%。
直接结论：高并发或短连接密集型服务（如API网关、微服务调用）下，Linux默认TCP参数极易成为瓶颈，必须调整队列长度、TIME_WAIT行为、缓冲区和拥塞算法——不改，连接丢弃、端口耗尽、吞吐卡在30%都是常态。
为什么ss -s显示“listen overflows”却没报错？
这是半连接队列（SYN queue）或全连接队列（accept queue）溢出的典型信号，但内核默认静默丢弃连接，客户端收不到RST，只感知为“连接超时”或“第一次请求失败”。根本原因是net.ipv4.tcp_max_syn_backlog和net.core.somaxconn太小，而应用层listen()的backlog参数又受其限制。
- 先查溢出：
netstat -s | grep -i "listen drops\|SYNs to LISTEN"，非零即说明已丢包 - 临时调大：
sudo sysctl -w net.ipv4.tcp_max_syn_backlog=65535和sudo sysctl -w net.core.somaxconn=65535 - 必须同步改应用：Nginx需设
listen 80 backlog=65535；Go程序net.Listen("tcp", ":8080")要传&net.ListenConfig{KeepAlive: 30 * time.Second, Control: func(fd uintptr) { syscall.SetsockoptInt32(int(fd), syscall.SOL_SOCKET, syscall.SO_BACKLOG, 65535) }} - 持久化写入
/etc/sysctl.d/99-queue.conf，再sudo sysctl --system
TIME_WAIT太多导致“Cannot assign requested address”怎么办？
短连接服务（比如每秒上千次HTTP调用）下，主动关闭方（通常是客户端或反向代理）大量进入TIME_WAIT，60秒内端口不可复用，net.ipv4.ip_local_port_range（默认32768–65535）很快耗尽。关键点：tcp_tw_reuse只对客户端有效，且依赖tcp_timestamps；tcp_tw_recycle在NAT环境下绝对禁用（已从4.12+内核移除）。
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
- 启用复用：
sudo sysctl -w net.ipv4.tcp_tw_reuse=1+sudo sysctl -w net.ipv4.tcp_timestamps=1 - 缩短等待时间（仅限客户端）：
sudo sysctl -w net.ipv4.tcp_fin_timeout=30（服务端慎用） - 限制总量防OOM：
sudo sysctl -w net.ipv4.tcp_max_tw_buckets=2000000（超出后内核强制回收） - 检查当前数量：
ss -tan state time-wait | wc -l，对比net.ipv4.tcp_max_tw_buckets值
吞吐上不去，带宽利用率始终低于50%？
常见于跨机房、高RTT链路（如中美专线），本质是TCP窗口被net.core.rmem_max和net.core.wmem_max卡死，无法撑满带宽延迟积（BDP）。例如10Gbps + 50ms RTT，理论BDP ≈ 62.5MB，但默认rmem_max才256KB，窗口永远打不开。
- 先估算BDP：
带宽(Bps) × RTT(s)，单位换算成字节 - 调上限：
sudo sysctl -w net.core.rmem_max=16777216（16MB）、net.core.wmem_max=16777216 - 开自动调优：
sudo sysctl -w net.ipv4.tcp_rmem="4096 131072 16777216"、net.ipv4.tcp_wmem="4096 131072 16777216"（min/default/max） - 验证是否生效：
ss -i看单连接rcv_space和cwnd是否接近你设的max值
BBR比CUBIC快，但开了就断连？
BBR需要内核4.9+且未被禁用，但更常见的问题是：某些中间设备（尤其是老旧防火墙、运营商NAT）不兼容BBR的探测包节奏，导致握手失败或重传激增。别一上来就切BBR，先确认路径支持。
- 查当前算法：
sysctl net.ipv4.tcp_congestion_control - 临时切换：
sudo sysctl -w net.ipv4.tcp_congestion_control=bbr（不是bbr2，后者需5.4+） - 必须加载模块：
lsmod | grep bbr，若无输出则sudo modprobe tcp_bbr，并写入/etc/modules - 监控效果：
ss -i中看bbr字段是否出现，cat /proc/net/bbr_info查实际带宽估计 - 回滚条件：如果
ss -s里重传率（retransmits）飙升或连接建立失败增多，立刻切回cubic
所有改动都得配合监控看效果，光调参数不看ss -s、netstat -s、ss -i，等于蒙眼调优。最易忽略的是应用层backlog与内核队列的匹配，以及tcp_tw_reuse对服务端完全无效这个事实——很多人在负载均衡器上配了tw_reuse却指望后端服务受益，结果白忙活。
