ss是现代替代工具，直接通过netlink读取内核数据，速度快、资源占用低，支持bpf过滤、sctp协议及tcp内部状态；netstat已停止维护，依赖解析/proc/net文本文件，性能差、扩展性弱。

netstat 本身不直接支持分析“多路复用网络连接”（如 HTTP/2、HTTP/3 或 QUIC 中的流复用），因为它工作在传输层（TCP/UDP），看到的是内核维护的 socket 连接视图，而非应用层的逻辑流。它无法区分单个 TCP 连接上承载的多个 HTTP 请求或 WebSocket 子通道。但通过合理组合其输出，仍可间接评估底层连接复用效果对服务性能的影响。

识别高复用潜力的连接模式

多路复用依赖于长连接和低连接新建频率。netstat 可帮你确认服务是否按预期维持连接：

• 观察 ESTABLISHED 连接数量是否稳定且远高于 SYN_SENT 或 TIME_WAIT 的瞬时峰值——说明客户端在复用连接，而非频繁建连
• 对比同一服务端口（如 :443）下，Foreign Address 的 IP 数量与总连接数的比例：若连接数远大于客户端 IP 数，大概率存在连接复用
• 检查 Recv-Q / Send-Q 是否持续非零：若队列堆积，可能因复用连接中某一流阻塞导致整条连接吞吐下降

排查复用失效的典型瓶颈

当本应复用的场景却出现大量短连接，往往暴露配置或实现问题：

• TIME_WAIT 过多：执行 netstat -an | grep ':443' | grep TIME_WAIT | wc -l，若数值持续 >5000，说明连接释放过快，客户端或服务端可能禁用了 keep-alive，或设置了过短的 idle timeout
• 监听套接字未启用 SO_REUSEPORT：仅靠 netstat -tlnp | grep :443 看不到该选项，但若单进程监听 + 高并发下出现 accept 队列溢出（可通过 netstat -s | grep -A 2 "Tcp:" 查 failed connection attempts），说明复用连接请求被排队甚至丢弃
• UDP 复用场景（如 QUIC）不可见：netstat 对 UDP 只显示端口绑定，无法反映 QUIC stream 级状态；此时需结合 ss -u -n 和应用层日志交叉验证

结合进程与计时器看真实复用行为

单纯看连接数不够，需确认是哪个进程在管理这些连接：

• 用 netstat -tunlp 查看监听进程，确认是 nginx、envoy 还是自研服务——不同实现对复用的支持策略（如最大 streams 数、流优先级）差异很大
• 加 -o 选项（如 netstat -tno | grep ESTABLISHED）查看每个连接的计时器：若 keepalive timer 正常倒计时，说明连接处于健康复用状态；若 timer 显示 retransmit 或长时间为 0，则可能存在流级拥塞或 peer 异常
• 注意 Recv-Q 值：若某 ESTABLISHED 连接的 Recv-Q 持续 >0，可能是应用层未及时读取数据，导致该连接上的其他流也被阻塞（尤其在单线程处理模型中）

更合适的替代与补充工具

netstat 是基础视角，要深入复用性能，需配合其他手段：

• ss 命令：比 netstat 更快、更少依赖 procfs，ss -tin 可显示 TCP 连接的详细状态（如 retrans、rto、qsize），更适合高频采样
• 应用层指标：HTTP/2 的 streams initiated、streams closed、frames received/sent 等，通常由服务暴露的 /metrics 接口提供
• eBPF 工具：如 bpftrace 跟踪内核 socket 事件，可统计单连接内实际活跃流数，真正穿透复用层