Linux 目前没有现成命令可以直接计算“某个进程的网络吞吐量占物理带宽的百分比”。本质原因并不复杂：物理带宽例如网卡标称的 1 Gbps，属于固定的理论上限；而进程网络吞吐是实时波动的动态数值，两者天然需要手动比对。更重要的是，nethogs、iftop 这类工具通常给出的都是实际流量速率，也就是 bytes/sec，而不是已经换算好的带宽占比。如果确实想算出这个比例，基本步骤绕不开：先确认网卡真实可用带宽，再获取进程级实时网络速率，最后手动换算。
Linux 并没有现成工具，能直接告诉你“某个进程当前网络吞吐到底占了物理带宽的多少百分比”。原因很简单：物理带宽，比如网卡标称的 1 Gbps，本质上是一个静态上限；而进程吞吐则是持续变化的实时值，这两者本来就需要人工对照分析。更关键的是，nethogs、iftop 这类网络监控工具输出的通常都是实际流量数据，也就是 bytes/sec，并不是直接计算好的占比值。真正要得出这个比例，步骤基本固定：先确认物理带宽的真实可用值，再抓取进程级实时速率，最后自己做除法换算。
查看网卡真实物理带宽（不是标称值）
不要只看厂商标注或 ethtool eth0 显示的 “Speed: 1000Mb/s”——它只能说明链路协商速率，并不等于当前实际可用带宽。真正的瓶颈可能出现在交换机端口、云服务商限速、QoS 策略，或者双工模式不匹配等环节。
ethtool eth0 | grep -i "speed|duplex"：用于确认协商结果，但要注意：在全双工模式下，TX/RX 可以同时跑满，总吞吐并不等于单向速率简单乘以 2sudo ethtool -S eth0 | grep -i "tx|rx" | grep -E "(errors|dropped|overrun)"
- 如果
rx_over_errors 或tx_fifo_errors持续增长，说明物理层可能已经饱和或正在发生丢包，这时测得的“进程吞吐”实际上已经被截断，不能直接拿去除以标称带宽 - 云服务器（如 AWS、阿里云）还必须查看控制台或实例规格说明：文档里标注的“网络性能”才更接近真实上限（例如 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，通常就能较准确地定位问题。至于“到底占了物理带宽的百分之几”，归根结底只能算一个相对模糊的参考值，不适合过度解读。
