运维大神教你如何用iftop和ss命令结合排查带宽占用高的进程

361 阅读3分钟

image.png

一、场景背景

当服务器突发带宽占用过高时,需快速定位异常流量来源。本文通过 iftop(实时流量监控)和 ss(套接字状态分析)的协作,提供一套高效排查流程。


二、工具简介

1. iftop:实时网络流量分析

  • 功能:按连接(IP+端口)监控接口带宽,显示发送/接收流量及峰值,支持过滤和自定义视图。
  • 特点:无需复杂配置,交互界面动态更新,实时反馈流量源头。

2. ss(socket statistics):进程级连接追踪

  • 功能:查询当前网络连接状态(TCP/UDP),可按IP、端口或进程ID过滤,直接关联具体进程。
  • 特点:比 netstat 更高效,支持直接显示进程名和PID。

三、排查步骤

步骤1:iftop 定位高流量连接

sudo iftop -nN -i eth0  
  • 参数说明
    • -n: 直接显示IP而非域名(避免DNS延迟)。
    • -N: 直接显示端口号而非服务名。
    • -i eth0: 指定网卡(如公网接口)。

界面关键信息

  • 中间列表:展示当前活跃连接的源/目标IP+端口发送/接收流量(单位为bit,注意转换为字节需除以8)。
  • 峰值流量:底部显示总流量(如 TX Cum: 1.5GB)及实时速率。

操作技巧

  • s/d 隐藏本地/远程主机名,明确流量方向。
  • P 暂停流量统计,筛选关键连接。
  • l 输入IP或端口,过滤特定流量(例如 l 10.0.0.1 检查该IP的连接)。

步骤2:ss 关联进程
场景:发现某IP(如 10.0.0.5)或端口(如 8080)占用带宽过高。

方法1:通过目标IP定位进程

sudo ss -tp src 10.0.0.5  # 查找源IP为10.0.0.5的TCP连接  
sudo ss -tp dst 10.0.0.5  # 查找目标IP为10.0.0.5的TCP连接  

方法2:通过端口定位进程

sudo ss -tp 'sport = :8080'  # 查询本地监听8080端口的连接  
sudo ss -tp 'dport = :5432'  # 查询连接到远程5432端口的连接  
  • 关键字段pid/program name 直接显示进程ID及名称。

步骤3:综合分析案例
假设通过 iftop 发现 => 10.0.0.5:80 持续占用10Mbps上行带宽:

  1. 执行 ss -tp dst 10.0.0.5: tcp ESTAB 0 0 192.168.1.10:41020 10.0.0.5:80 users:(("nginx",pid=1234,fd=6))
  2. 确认 PID 1234 对应 nginx 进程,进一步检查配置或终止进程:
    ps -p 1234 -o command  # 查看命令行参数  
    kill -STOP 1234       # 暂停进程验证带宽变化  
    

四、进阶技巧

1. 组合参数精准过滤

# 监控内网192.168.1.0/24网段流量  
sudo iftop -F 192.168.1.0/24 -nN -i eth0  

# ss筛选 established 状态的特定端口连接  
sudo ss -tp 'status established ( src :80 or dst :443 )'  

2. 日志化记录与分析

# 将iftop输出存档(需配合 `screen` 或 `nohup`)  
nohup sudo iftop -nN -i eth0 -t >> /var/log/iftop.log &  

# 解析日志提取Top N流量连接  
awk '{print $1, $2, $3}' /var/log/iftop.log | sort -nrk 3 | head -n 10 

五、对比其他工具

工具优势适用场景
iftop实时流量监控,视觉化界面快速定位IP/端口流量异常
ss进程级连接细节关联端口与进程,精准杀指定连接
nethogs进程级带宽分组直接显示各进程总带宽消耗

六、常见问题

Q1:iftop 显示单位如何转换?

  • 输出单位为bit/s(如 10Mbit),转为 MB/s 需除以8,即 10 → 1.25MB

Q2:ss 无法显示进程名?

  • 确保内核支持 proc 文件系统进程信息,或检查权限(需 sudo)。

七、总结

iftop + ss 的组合提供了从流量源头到进程定位的完整闭环,尤其适合动态排查突发流量问题。通过上述方法,可快速响应带宽占用异常,避免服务中断。对于更复杂的进程级监控需求,可进一步使用 nethogs 作为补充。