netstat不直接测量带宽或cpu内存负载，但可通过recv-q/send-q队列长度、-s协议统计（如重传率＞2%）、连接状态分布（established/time_wait/close_wait）及进程关联（-tunlp）间接判断网络吞吐瓶颈与系统负载倾向。
netstat 本身不直接测量带宽或吞吐量（如 Mbps），也不能实时反映 CPU 或内存负载，但它能通过连接状态、队列长度、协议统计等间接指标，辅助判断网络层的吞吐压力与系统负载倾向。关键在于结合多个参数交叉观察，而非依赖单一输出。
看 Recv-Q 和 Send-Q 判断瞬时吞吐瓶颈
在 netstat -an 输出中，每行的第三、四列分别是 Recv-Q（接收队列字节数）和 Send-Q（发送队列字节数）：
- 正常情况下两者应为 0；若持续非零（尤其 > 10KB），说明应用层读取太慢（Recv-Q 高）或网卡/对端接收能力不足（Send-Q 高），数据在内核缓冲区堆积
- 高 Send-Q 常见于突发大流量 + 小窗口 + 网络延迟场景，可能预示拥塞或对端处理迟滞
- 可配合 netstat -i 查看对应网卡的 TX-ERR、RX-OVERFLOW，确认是否因硬件或驱动导致丢包/溢出
用 -s 统计分析协议层异常信号
netstat -s 输出的协议统计是识别隐性负载的重要依据：
- 关注 TCP Segments Retransmitted：重传率 > 2% 通常表明链路不稳定或中间设备丢包，会显著降低有效吞吐
- 检查 TCP Failed Connection Attempts 和 Connection Resets：大量失败连接可能源于服务过载、防火墙拦截或 SYN Flood 攻击
- 对比 Segments Received 与 Segments Delivered：若差值大且伴随 Received Packets Discarded 上升，说明内核已因资源紧张（如内存不足）主动丢包
结合 -c 实时观察连接状态分布变化
运行 netstat -antc（持续刷新 TCP 连接），重点关注状态数量趋势：
- ESTABLISHED 数量长期高位 → 应用连接数接近上限，可能需调优连接池或排查长连接泄漏
- TIME_WAIT 突增且不回落 → 可能是短连接高频释放，结合 /proc/sys/net/ipv4/tcp_fin_timeout 和 tcp_tw_reuse 判断是否需内核调参
- CLOSE_WAIT 持续累积 → 表明本地应用未正确关闭 socket，属于程序级资源泄漏，会耗尽文件描述符
定位高负载进程与端口关联
要确认是哪个进程拖慢网络响应，必须加权限查进程上下文：
- 执行 sudo netstat -tunlp，查看监听端口对应的 PID/程序名，确认是否预期服务（如 nginx、java）
- 对高 Recv-Q 或 Send-Q 的连接，用 sudo lsof -i :端口号 或 ss -tunp | grep :端口 辅助验证进程行为
- 若发现陌生 PID 或无名进程（显示为“-”），需进一步用 ps -p PID -o pid,ppid,cmd 追溯源头，防范恶意连接
