当性能变慢时，先别急着加带宽，按“客户端-链路-服务器”的顺序做归因排查，多数情况下能在10分钟内定位是带宽瓶颈还是应用代码问题。
带宽被占满怎么排查：先分清是“不够用”还是“没用好”
很多团队遇到网页打开慢、视频卡顿、接口超时，第一反应是“带宽又不够了”，但行业共识认为，相当一部分性能问题并非物理带宽不足，而是连接数耗尽、丢包重传或单线程限速导致的，如果直接升级带宽套餐，钱花了，问题还在。
用排除法锁定大方向
开始抓包之前,先回答三个问题，这三个答案能帮你节省至少一半的排查时间。
- 是所有用户都慢，还是某个区域/某个运营商慢？ 如果是特定区域慢，问题大概率出在跨网链路或CDN节点，而不是源站带宽。
- 是全天候慢，还是特定时段慢？ 如果是晚高峰8点到11点慢，可能是带宽跑满；如果是凌晨3点也慢，那就要怀疑应用层逻辑。
- 是页面加载慢，还是接口响应慢？ 页面慢可能是前端资源太大，接口慢可能是数据库查询时间过长，这两种情况跟带宽的关系都不大。
两条命令快速确认带宽水位
登录服务器,用以下命令看实时流量，这是排查的第一步，也是最直接的一步。
- iftop：按IP和端口显示实时流量，一眼就能看出谁在“大口吃肉”。
- nload：用图表形式展示总流入/流出带宽，适合先看整体水位。
操作路径：SSH登录服务器 → 执行 iftop 或 nload → 观察是否持续达到或接近你购买的带宽上限（比如100Mbps的带宽，流量冲到95Mbps以上且持续不降）。
如果流量常年贴近上限,那确实是带宽过小，如果流量只有30Mbps，但服务已经卡死，带宽就不是主要矛盾，请继续往下排查。
带宽监控工具有哪些：从服务器侧到全局流量分析
当确认流量没有跑满,但性能仍然很差时，需要引入更细致的工具链，区分是出方向（上行）还是入方向（下行）的问题。
服务器侧：看清每个进程的连接
用 nethogs 按进程查看流量占用，这是定位“谁在偷偷跑流量”的最高效手段，常见的意外情况包括：
- 服务器被植入挖矿程序,持续对外发送数据。
- 日志同步Agent异常重试,反复上传大文件。
- 备份任务集中在业务高峰期执行。
操作路径：执行 nethogs → 按M键按流量排序 → 记录异常进程PID → 用 lsof -p PID 查看该进程打开的端口和文件。
下表是几种常见进程流量异常的判断特征：
| 进程类型 | 典型流量特征 | 首要怀疑方向 |
|---|---|---|
| Web服务器（Nginx/Apache） | 流量平稳，与PV曲线正相关 | 是否被CC攻击或爬虫抓取 |
| 数据库进程 | 流量脉动式突增 | 是否有全表扫描或慢查询 |
| 未知二进制文件 | 流量持续高位且无规律 | 是否被植入恶意程序 |
链路侧：用tcpdump抓包看重传
如果服务器侧一切正常,问题可能出在链路质量。网络丢包会导致TCP协议疯狂重传，表面上带宽占满，实际上传输的有效数据极少。
抓包命令：
tcpdump -i eth0 tcp port 80 -w /tmp/capture.pcap
用Wireshark打开抓包文件,重点看两点：
- TCP Retransmission（重传）占比：如果重传比例超过5%，链路质量堪忧。
- TCP Window Full（窗口满）：如果频繁出现，说明接收方处理不过来，是应用性能问题，不是带宽问题。
业内专家指出：重传率升高时，应用响应时间会成倍增加，但带宽监控图上却看不出异常，这是最容易被误判的场景之一。
服务器带宽跑满原因：被忽视的“小包攻击”与半开连接
另一种典型情况是：带宽确实被占满了，但一看流量构成，全是不足100字节的小包，这属于典型的连接型消耗，而非传输型消耗。
小包如何“塞满”带宽
一个64字节的空包,在以太网上实际占用约84字节（加上帧间隙和 preamble），当设备处理能力达到每秒百万级PPS（包转发率）时，即便总带宽只有10Mbps，CPU也已经满负荷运转，此时有效吞吐趋近于零，用户感知就是“慢死”。
快速判断方法
- 执行
sar -n DEV 1 100，观察rxpck/s（每秒收包数）。 - PPS 数值异常高（比如单核超过 30万），但带宽使用率只有 20%，这就是 PPS 瓶颈。
- 执行
netstat -s | grep -i listen，查看半连接队列溢出次数，如果溢出计数持续增长，说明有大量连接只握手不发数据，占满了连接表。
对这类问题,调大带宽没有意义，反而会增加成本，正确做法是限制单IP连接数、启用SYN Cookie防护、调优内核参数（如 net.core.netdev_max_backlog）。
带宽和延迟哪个影响大：不同业务场景的归因权重
这句话容易被误解,所以展开说。带宽决定你能同时搬多少块砖，延迟决定你搬一块砖要多久。 对多数Web应用，延迟的影响远大于带宽。
适合归因到带宽的场景
- 文件传输类：上传下载速度直接取决于带宽，延迟再低也没用。
- 视频会议类：需要持续的双向高码率流，带宽不足会直接导致画面模糊或卡顿。
- 数据库主从同步：binlog复制量超过带宽上限，从库延迟会越来越大。
适合归因到延迟的场景
- API接口调用：一次请求只有几十KB的数据量，带宽几乎不构成约束，但每增加10ms延迟，用户体验就会明显变差。
- 网页首屏渲染：受TCP慢启动机制影响，页面越小，延迟占比越重，一个1MB的页面，在50ms延迟下加载约需1秒；在200ms延迟下可能需4秒以上。
排查建议：如果性能问题表现为“每次请求慢”，而不是“并发一大就慢”，优先排查DNS解析时间、SSL握手时间、路由跳数，而不是带宽。
带宽归因排查顺序的实操清单
把完整排查流程整理成清单,方便你在故障时按顺序执行。
- 查水位：用
nload看当前带宽占用，对比购买带宽上限。 - 查进程：用
nethogs找出流量占用大户，确认是否为合法业务。 - 查连接：用
ss -s查看连接总数和TIME_WAIT状态，判断是否连接耗尽。 - 查丢包：用
ping -f连续发送大包，观察丢包率；用traceroute定位丢包节点。 - 查重传：用
tcpdump抓包，统计重传比例。 - 查小包：用
sar -n DEV看PPS指标，排除小包攻击。 - 查应用：用
top看CPU/内存占用，排除应用自身瓶颈。
两个典型误判场景的纠偏
- 误判一：图片加载慢，加了带宽后没改善，实际原因是图片没做压缩，单张图3MB，但页面只有几个用户访问，正确做法是压缩图片和开启CDN，而非加带宽。
- 误判二：视频播放卡顿，加了带宽后明显好转，这是少数加带宽能解决的情况，但更优解是转码为自适应码率，减小高峰期带宽压力。
带宽排查常见疑问解答
为什么带宽没跑满，网速还是很慢？
带宽没跑满但网速慢,通常指向三个方向：一是DNS解析耗时过长，每次访问都在解析上浪费几百毫秒；二是TCP三次握手和TLS协商耗时过多，尤其在高延迟链路上；三是服务器自身处理能力受限，比如单核CPU跑满或磁盘IO等待过高，建议先用 curl -w 查看各阶段耗时分布，定位时间消耗在哪一环。
租用云服务器时带宽怎么选才够用？
选带宽要看两个维度：峰值带宽和月度流量包。峰值带宽决定突发能力，流量包决定长期成本。 以视频网站为例，如果一个用户看1080P视频需要4Mbps带宽，同时在线100人，就需要约400Mbps的峰值带宽，但如果只是企业内部OA系统，50Mbps带宽已足够支撑数百人日常操作，采购前建议做一个压测，用真实业务流量模拟高峰期的带宽需求。
CDN能彻底解决源站带宽压力吗？
CDN能吸收大部分静态资源的请求,但解决不了所有问题，CDN对动态API请求、POST请求、WebSocket长连接无能为力，这些流量仍会直接打到源站，如果业务中动态请求占比高，CDN能缓解的带宽压力相对有限，此时更应关注应用层的接口缓存和数据库查询优化，口径上，CDN适合“读多写少、资源可缓存”的场景，不适合“实时交互、数据强一致”的场景。