netstat 不直接统计吞吐量，但可通过 recv-q/send-q、重传率、连接状态分布及网卡错误等间接指标定位吞吐瓶颈环节。

netstat 本身不直接统计吞吐量（如 Mbps 或 MB/s），它不测量带宽、不采样流量速率，也不提供字节计数随时间变化的差值。但它能通过多个间接指标，帮助你**定位吞吐瓶颈所在环节**，判断是应用层、协议栈、网卡驱动还是对端限制了数据流动——这才是运维中真正需要的“吞吐分析”。

看 Recv-Q 和 Send-Q 判断瞬时数据堆积点

运行 netstat -tan，关注每行第三列（Recv-Q）和第四列（Send-Q）：

• Recv-Q 持续 > 10KB：说明本地应用读取太慢，数据卡在内核接收缓冲区，是应用处理能力不足的信号
• Send-Q 持续 > 10KB：说明本地发不出去，可能因为对端接收窗口小、网络延迟高、或本机网卡/驱动发送受阻
• 两者都高：常见于突发流量 + 小 TCP 窗口 + 高 RTT 场景，TCP 流控已起作用，实际吞吐被压制

用 netstat -s 查重传与丢包，识别链路级吞吐衰减

执行 netstat -s | grep -A 5 -B 5 "TCP.*retransmit\|failed\|reset"，重点关注：

linux-performance-analyzer

Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。

下载

• TCP Segments Retransmitted：重传率超过 2%（用 Segments Retransmitted / Segments Sent 计算），说明链路不稳定或中间设备丢包，有效吞吐大幅下降
• Failed connection attempts：持续增长表示 SYN 被拒，可能是全连接队列满（ss -lnt 中 Listen 处 Send-Q 非零）、SYN Flood 或防火墙拦截
• Connection resets received：大量 RST 可能源于对端异常关闭、应用崩溃或健康检查失败

观察连接状态分布，识别资源型吞吐瓶颈

用 netstat -ant | awk '{print $6}' | sort | uniq -c | sort -nr 统计各状态数量：

• ESTABLISHED 过多且长期高位：连接数逼近 ulimit -n 或 net.core.somaxconn，新连接被拒绝，吞吐无法横向扩展
• CLOSE_WAIT 持续累积：本地应用未调用 close()，socket 不释放，耗尽文件描述符，后续连接失败
• TIME_WAIT 短期激增后回落正常：高频短连接释放的表现；若长期不降，可能需调小 tcp_fin_timeout 或启用 tcp_tw_reuse

结合 netstat -i 看网卡底层错误，排除硬件级吞吐限制

运行 netstat -i，重点检查对应业务网卡的：

• RX-OVR / TX-OVR：覆盖错误上升，常见于老旧网卡缓冲区溢出，表明收发能力已达物理极限
• RX-ERR / TX-ERR：持续增长指向驱动异常、网卡故障或 MTU 不匹配
• RX-DRP：因内核 socket 缓冲区满被丢弃，可调大 net.core.rmem_default 或排查应用读取延迟