峰值带宽200M：3个地方在偷吃你的速度

带宽这块最容易出现的误会，就是把账面够用当成跑起来够快。峰值带宽 200M 的机器，放一个几百 KB 的页面，用户那头照样转圈等，这种事碰上过不止一次。慢的地方往往不在管道粗细，而在这条路上有三个地方一直在偷偷分流。下面挨个扒开说。

峰值带宽 200M 管的是管道粗细，不管水怎么流

这句话得展开一下。带宽说的是单位时间里能过多少数据，200M 是理论上限。可网页加载不是一桶水往里倒，它是几百个小文件排队往外送：HTML、样式、几个脚本、字体、一堆图。管道再粗，队伍排乱了照样慢。所以先别急着怪带宽不够，先看队是怎么排的。

第一个漏斗：连接数一卡，带宽就闲着

小文件一多，真正拖时间的是往返延迟和并发数。浏览器对同一个域名同时发起的请求有上限，通常就是个位数；服务器那边如果还开着单连接限速（nginx 里的 limit_rate 就是干这个的），单个连接更是被摁住。两头一夹，标称的 200M 只跑出很小一截，面板上的曲线平得像没业务。改法不复杂：合并资源、开 HTTP/2 或者分几个域名做分片、把 limit_rate 这类配置翻出来核对一遍。别小看这几个参数，调完的差别肉眼能看出来。

第二个漏斗：机器上的自己人在抢流量

这条最阴。同一台机器上跑的东西太多了——半夜定时备份把整站打包、数据库主从同步、日志往远端推、监控 agent 时不时回传，再加上站长自己挂的采集脚本和爬虫。平时它们不吭声，一跑起来就跟访客抢同一块网卡。表现出来就是整点一到网站就卡，或者白天正常晚上慢。查起来不难，把网卡流量曲线跟业务访问曲线摆一块儿对，对不上就是内部在吃。CDN 回源也是同一个道理：缓存没命中，每个访客都变成一次回源，本来分给一个人的量要分给几十个人。缓存命中率这个数，值得天天瞄一眼。

第三个漏斗：客户端和前端那头，你管不着但能减重

用户家里的网、手机信号、运营商到机房那段路，都不归你管。你能管的是自己发出去的东西有多重。图片没压、首屏先拉三个用不上的脚本、字体文件几百 KB 全量加载、压缩没开——这些毛病凑一起，带宽再宽也白搭。还有个常被冤枉的情况：单个大文件走单线程下载，速度天然上不去，这时候看到下载才几兆就断定带宽虚标，属于错怪人。前端优化没什么花活，把资源逐个称重，能砍的砍，能延后的延后。

口径这件事得说清：峰值、保底、共享

下单时页面上写的峰值带宽，实际是不是独享，得看合同和产品细则。有的产品是共享带宽池，邻居白天跑满，你就跟着挤；有的标峰值，超了限速不断线；还有的带宽给足，但 CPU 核数、连接数上限、磁盘 IO 是按最低档配的，短板根本不在带宽上。看到 200M 先别激动，把「峰值」「保底」「突发」这几个词后面的注释从头读一遍，拿不准就以服务商页面说明或者工单回复为准。

重的东西挪出去，通常比加带宽划算

静态资源——图片、视频、字体、安装包——全堆在源站，是很多小站的通病。把它们丢到对象存储或者 CDN 上，源站只负责出 HTML 和接口，带宽压力立刻就散了。注意两件事：一是回源要配好缓存规则，TTL 别设太短，不然 CDN 等于摆设；二是跨域资源、证书、防盗链这些细节得跟着调，不然页面会出莫名其妙的错。挪完再测一次，多半能省下一笔升级套餐的钱。

排查顺序别搞反，先看数再动钱

顺序一反，最容易花冤枉钱。我的走法是：先看服务商控制台的带宽曲线，峰值有没有贴着上限跑；没贴到，问题就不在带宽。然后登机器用 iftop、nload 这类工具看一眼，公网口流量和业务曲线对不对得上，有没有别的东西在偷跑。接着抓一次真实访问的瀑布图，看时间花在等响应还是花在传数据上：等响应多，往数据库和程序逻辑上找；传数据多，才是资源和带宽的事。最后才去怀疑用户的网络。四步走完，八成就定位到具体哪一处了。

实在一头雾水，还有个笨办法：把定时任务列表和回源日志翻一遍。内部偷跑和缓存不命中这两件事，多半在这两份东西里露马脚。

带宽是租来的，浪费掉的流量才是自己的。下次觉得慢，按上面三处对着看一遍，能改的先改，别急着掏钱升套餐——很多所谓的带宽不够，只是没人去关掉那个半夜打包的脚本。