先确认带宽是否真跑满：用ethtool查网卡速率，sar -n DEV看txkB/s并换算为Mbps，iperf3多流测试吞吐，iftop与nethogs两级追踪进程，检查中断分布、连接队列溢出及TCP缓冲区与拥塞算法匹配业务特征。
先确认是不是真跑满了
别急着调参，先看清楚带宽到底有没有被吃光。很多“跑满”其实是错觉：比如 iftop 显示某 IP 占了 900Mbps，但网卡实际是 10Gbps，那根本没瓶颈；又或者 iperf3 -c 测出来只有 200Mbps，却看到 txkB/s 在 sar -n DEV 1 5 里飙到 120MB/s（≈960Mbps），这时得核对单位——sar 输出是 KB/s，不是 Kbit/s。
- 查网卡理论速率：
ethtool eth0 | grep Speed，确认是 1G/10G/25G - 看实时出向流量：
sar -n DEV 1 5 | grep eth0，盯txkB/s，换算成 Mbps（×8÷1000） - 测真实吞吐：服务端跑
iperf3 -s -B 10.0.0.10，客户端用iperf3 -c 10.0.0.10 -P 8 -t 30，多流才能暴露调度问题
定位流量来源：从 IP 到进程的两级追踪
带宽被谁用了？不能只靠 iftop 看个 IP 就封，得闭环到具体进程。常见陷阱是：看到大量 192.168.1.5:443 流量，以为是 HTTPS 服务，结果 nethogs eth0 一跑，发现是某个 Python 脚本在后台轮询 API，根本不是 Web 服务器本身。
-
iftop -i eth0 -P：按连接排序，暂停（P键）记下高流量端口 -
nethogs -d 2 eth0：直接显示进程名+PID+实时速率，支持按流量排序（↑/↓） - 若
nethogs不可用或权限受限，用ss -tunlp | grep :PORT反查端口归属进程
排除内核与协议栈层面的隐形损耗
流量确实来自合法进程，但带宽还是上不去？很可能是内核“自己卡住了”。比如 /proc/interrupts 里 eth0-TxRx-0 中断全挤在 CPU0 上，其他核空转；或者 netstat -s | grep "listen drops" 输出非零，说明 SYN 包在进内核前就被丢弃了——这和应用层代码无关，是 net.core.somaxconn 或网卡 Ring Buffer 太小导致的。
- 查中断分布：
watch -n1 'cat /proc/interrupts | grep eth0'，观察各 CPU 列数值是否严重不均 - 调大接收缓冲：
ethtool -G eth0 rx 4096 tx 4096（需驱动支持，部分虚拟网卡不生效） - 检查连接队列溢出：
netstat -s | grep -i "listen.*drops\|retransmit"，值持续增长就要调net.core.somaxconn和net.ipv4.tcp_max_syn_backlog
别让 TCP 参数成为带宽天花板
1Gbps 网络 + 30ms RTT，BDP ≈ 3.75MB，但默认 net.ipv4.tcp_rmem 最大才 4MB，表面够用，实际因窗口缩放未稳定启用或应用未设 SO_RCVBUF，真实接收窗口可能卡在 64KB。这时候再怎么加大带宽，单流也跑不满。
- 必须开窗口缩放：
sysctl net.ipv4.tcp_window_scaling=1 - 缓冲区三元组按 BDP 设：
net.ipv4.tcp_rmem = "4096 262144 8388608"（最后值 ≈ BDP × 1.2） - 强制应用使用大缓冲：
echo 'net.core.rmem_max = 8388608' >> /etc/sysctl.conf，否则某些程序会受限于默认 212992 - 拥塞算法换
bbr：sysctl net.ipv4.tcp_congestion_control=bbr，比cubic在丢包波动时更稳
真正难的不是改哪几行 sysctl，而是理解你的业务流量特征：是长连接大文件下载？还是短连接高并发 API？前者要调缓冲区和 TIME_WAIT 复用，后者得压 tcp_fin_timeout 和扩 ip_local_port_range。参数没有通用解，只有匹配场景的解。
