Linux网络吞吐瓶颈通常不在带宽，而在数据路径中的隐性问题；需分层排查：先用iftop/nload/speedtest确认是否真为带宽瓶颈，再通过ip/ethtool/proc/interrupts检查网卡与驱动异常，最后用netstat/ss分析TCP协议栈状态。
Linux网络吞吐量上不去，核心问题往往不在“带宽没买够”，而在于数据从应用到网卡的路径中存在隐性瓶颈。定位关键不是测速，而是分层观察：先确认是不是真被带宽卡住，再逐级排查协议栈、驱动、硬件和链路。
一、确认是否真为带宽瓶颈
别急着调参数，先排除误判：
- 用 iftop -i eth0 实时看当前接口的实时收发速率（单位 MB/s），对比你购买的带宽上限（如 1Gbps ≈ 125MB/s）。若长期接近或打满，才可能是带宽不足；若仅 20MB/s 却感觉卡顿，问题大概率不在带宽本身。
- 用 nload eth0 查看历史峰值与平均值，避免被瞬时抖动误导。
- 运行 speedtest-cli 测试公网上下行——结果远低于标称带宽？说明问题可能在 ISP、中间链路或本地出口策略（如 QoS 限速）。
二、检查网卡与驱动层面异常
即使带宽充足，网卡丢包、缓冲区溢出、校验错误也会大幅拉低有效吞吐：
- 执行 ip -s link show eth0，重点关注 dropped（内核丢弃）、errors（物理层错误）是否持续增长。dropped 高常因 netdev backlog 溢出或软中断处理不过来。
- 运行 ethtool -S eth0，查看 rx/tx_queue_*_drops、rx_missed_errors、tx_aborted_errors。这些值非零且递增，提示驱动兼容性差、中断分配不均或硬件故障。
- 用 cat /proc/interrupts | grep eth0 观察中断是否集中在单个 CPU 核——这会导致软中断瓶颈，需通过 irqbalance 或手动绑定均衡。
三、分析协议栈与连接状态
TCP 性能受队列、重传、窗口等多因素制约，吞吐受限常表现为高延迟、低窗口、频繁重传：
- 查重传率：netstat -s | grep -i "retransmitted"。若 TCPSegsRetrans 占总发送段比例 > 2%，说明网络不稳定或接收端处理慢。
- 看连接队列：ss -lnt 查 listen 队列（Send-Q）是否堆积；ss -ant | awk '{print $1}' | sort | uniq -c | sort -nr 统计各 TCP 状态分布。大量 SYN_RECV 或 TIME_WAIT 可能暴露连接管理问题。
- 检查接收窗口：ss -i 查看具体连接的 rwnd（接收窗口）和 unacked（未确认字节数）。rwnd 长期偏小（如 tcp_window_scaling 或应用未及时读取 socket 缓冲区。
四、验证内网真实带宽能力
公网测速不准内网性能，必须用可控环境实测端到端能力：
- 在目标服务器启动服务端：iperf3 -s -p 5201
- 从另一台同机房机器运行客户端：iperf3 -c
-p 5201 -t 30 -P 4 （-P 4 表示 4 并发流，更贴近真实负载） - 若结果远低于预期（如万兆网卡只跑出 2Gbps），说明问题在本地配置：检查 MTU 是否一致（建议设为 9000 启用 jumbo frame）、是否启用了 LRO/GRO（某些场景反而降低吞吐）、网卡是否工作在全双工模式（ethtool eth0 看 Speed 和 Duplex）。
