Bandwhich 带宽溯源

问题场景：当带宽异常时我们真正需要什么

在网络运维中，带宽突然飙升是最令人头疼的故障类型之一。当监控系统报警「出站流量激增」时，管理员往往面临一个困境：知道带宽被占用了，但不知道具体是哪个进程在传输数据，也不知道数据流向了哪个远端主机。传统工具如 iftop 或 nethogs 只能提供部分信息，要么无法关联进程，要么无法展示完整的连接路径。这种信息断层会导致故障排查方向错误——比如误判为 DDoS 攻击，而实际可能是某个备份任务失控。

核心能力：bandwhich 如何帮我们定位

bandwhich 的核心价值在于它同时关联了进程、连接和远端主机三个维度。它通过抓取网络接口的数据包，解析出每条连接对应的本地进程 PID 和进程名，同时显示远端 IP 和端口。这种关联能力让管理员能快速回答三个关键问题：

• 哪个进程在消耗带宽？（比如 java 进程还是 rsync 任务）
• 数据流向了哪里？（具体远端 IP 和端口）
• 当前连接的速率和累计流量是多少？

操作流程非常直接：

1. 在目标服务器上运行 bandwhich（需要 root 权限）
2. 工具会实时显示当前所有网络连接的带宽使用情况
3. 按 p 键可按进程名聚合显示，按 h 键按远端主机聚合
4. 通过 Tab 键切换不同的显示视图（进程/连接/主机）

适用边界与注意事项

这个技能的有效范围需要明确：

• 仅适用于当前主机：bandwhich 只能监控运行它的那台机器的网络流量，无法跨主机追踪。如果带宽异常涉及多台服务器，需要在每台机器上分别运行。
• 无法解析加密流量：对于 HTTPS、SSH 等加密协议，只能看到端口和 IP，无法得知具体传输内容。但连接层面的带宽统计依然有效。
• 高权限依赖：抓取网络包需要 root 权限，且每次运行都需要提权。在自动化脚本中使用时需要注意安全策略。
• 实时性与历史记录：工具显示的是实时数据，不保留历史记录。如果问题已经过去，无法回溯分析。

典型适用场景：

• 故障发生时，快速确认带宽是否被某个异常进程占用
• 排查异常出站连接，确认是否与已知业务系统通信
• 在应用部署后，验证新版本的网络行为是否符合预期

不适用的情况：

• 需要长期流量分析（应使用 vnstat 或 Prometheus 等工具）
• 需要分析应用层协议内容（需结合 tcpdump 或 Wireshark）
• 跨多台服务器的流量追踪（需分布式监控系统）