Linux无现成命令直接计算进程网络吞吐占物理带宽百分比，需先确认真实可用带宽（非标称值）、用nethogs获取进程级实时速率（单位校准为MB/s），再人工换算，但该比值因协议开销、丢包、容器虚拟化等限制仅具模糊参考价值。
Linux 没有直接提供「进程网络吞吐占物理带宽百分比」的现成命令——因为物理带宽（如网卡标称速率 1 Gbps）是静态上限，而进程吞吐是动态值，二者需人工比对；更关键的是，nethogs、iftop 等工具输出的都是实际流量（bytes/sec），不是占比。真要算这个比，得先确认物理带宽真实值，再抓进程级实时速率，最后做除法。
查网卡真实物理带宽（不是标称值）
别信厂商贴纸或 ethtool eth0 显示的 “Speed: 1000Mb/s”——它只反映协商速率，不等于当前链路可用带宽。实际瓶颈可能在交换机端口、云厂商限速、QoS 策略或双工模式 mismatch。
-
ethtool eth0 | grep -i "speed\|duplex"：确认协商结果，但注意：全双工下 TX/RX 可同时跑满，总吞吐 ≠ 单向速率 ×2 sudo ethtool -S eth0 | grep -i "tx\|rx" | grep -E "(errors|dropped|overrun)"</li> <li>若 <code>rx_over_errors
或tx_fifo_errors持续增长，说明物理层已饱和或丢包，此时测出的“进程吞吐”实际已被截断，不能直接除以标称带宽- 云服务器（AWS/Aliyun）必须查控制台：实例规格文档里写的“网络性能”才是真实上限（如 c5.2xlarge 是 “Up to 10 Gbps”，但突发带宽≠持续带宽）
取进程实时网络吞吐（用 nethogs）
nethogs 是唯一能按进程输出瞬时速率的工具，但它默认单位是 KB/s，且数值是滚动平均（非严格瞬时），直接用于比值计算前必须校准。
- 启动时加
-d 1设为 1 秒刷新：sudo nethogs -d 1 eth0，避免默认 2 秒平均掩盖峰值 - 按
m切到KB/s模式（不是kb/s），因为kb/s是千比特，KB/s是千字节——物理带宽单位通常是 Mbps（兆比特每秒），换算时必须统一：1 MB/s = 8 Mbps - 按
s排序看发送速率，r看接收速率；界面顶部显示的TOTAL是当前所有进程之和，可粗略对标网卡总吞吐（但会漏内核协议栈开销） - 若看到某进程显示
0.0 KB/s却实际在传数据，大概率是该进程使用了SOCK_STREAM但未触发 TCP ACK 流量（如小包堆积），此时应结合ss -i查rcv_ssthresh和unacked字段
手动计算占比并识别陷阱
假设 nethogs 显示 chrome 占用 12.4 MB/s，网卡标称 1 Gbps（即 125 MB/s），表面看是 9.9%——但这毫无意义，因为：
- 物理带宽 ≠ 可用带宽：如果
ethtool -S eth0显示tx_dropped: 321，说明已有丢包，真实可用带宽已低于 125 MB/s - 进程吞吐含协议开销：TCP/IP 头部、TLS 加密填充、重传包都计入
nethogs的 bytes，但不增加有效载荷，所以 12.4 MB/s 应用层数据可能对应 14+ MB/s 线路层流量 - 多进程共享同一连接：
nethogs按 PID 归因，但 Chrome 多进程模型下，renderer进程发包最终走的是主进程的 socket，你看到的可能是主线程 PID，而非真实工作线程 - 容器环境完全失效：Docker/Podman 默认用 veth-pair，
nethogs在宿主机上监控eth0时，只能看到 bridge 转发后的流量，无法映射回容器内 PID
真正有用的判断方式，不是算百分比，而是盯住两个信号：一是 nethogs TOTAL 是否持续接近 ethtool 报告的协商速率 × 0.8（留 20% 余量防抖动）；二是 ifconfig eth0 的 TX errors 和 RX dropped 是否为 0。只要这两个成立，再看哪个进程吃掉大部分 TOTAL，就足够定位问题——至于“占带宽百分之几”，只是个模糊参考，别当真。
