高峰期访问延迟偏高，多数情况下不是带宽买小了，而是瞬时流量把调度队列冲乱，先把入口整形、业务分级和CDN卸载做扎实，通常比直接扩容专线见效更快。
晚高峰的卡顿很像十字路口堵车车道没少，但信号灯配时没跟上，带宽调度就是给流量重新画车道、设优先级，很多团队一看到延迟升高就申请加带宽，结果高峰期依然慢,钱却多花了一截。
高峰期网站访问慢怎么解决？先把带宽调度提到扩容前面
高峰期网站访问慢怎么解决，关键不是让总带宽变大，而是让关键流量先走，多数情况下，入口带宽只跑到七成上下，但用户已经感觉明显卡顿,问题出在队列堆积和低价值流量挤占了同一出口。
访问延迟高是什么原因？先分清队列堆积和链路拥塞
访问延迟高是什么原因，很多人第一反应是带宽不够,其实要拆成两个层面看。
- 队列堆积：服务器网卡发送队列塞满，数据包在本地排队等待出站，此时带宽可能还没跑满，但应用响应已经变慢，可执行
tc -s qdisc show dev eth0查看 backlog 是否持续升高。 - 链路拥塞：本地出口到用户之间的运营商链路出现丢包或时延抖动，可用
mtr -rwzbc 100 目标地址连续追踪，观察中间跳的 Loss% 是否增大。 - 连接池阻塞：某个慢 SQL 或慢 API 拖住应用线程，Nginx 侧开始出现 502 或 504，此时加带宽不会改善,需要先定位慢请求。
业内专家指出，链路延迟与队列延迟要分开处理，否则很容易误判为带宽不足,导致扩容后问题依旧。
带宽调度和CDN哪个好？先看流量构成再决定
带宽调度和CDN哪个好，不能简单二选一,两者解决的不是同一层问题。
| 流量场景 | 优先带宽调度 | 优先CDN |
|---|---|---|
| 动态API、下单、支付回调 | 适合 | 不适合 |
| 静态图片、视频、安装包 | 可配合本地缓存 | 适合 |
| 大文件上传 | 适合做限速与排队 | 不适合 |
| 用户地域分散 | 受专线质量制约 | 适合 |
行业共识认为，CDN负责把静态流量挡在源站之外，带宽调度负责把进入源站的动态流量排好优先级，两者配合,高峰期源站压力会明显下降。
企业专线带宽价格一般多少？调度比扩容更省钱
企业专线带宽价格一般多少没有统一标价，不同地域、运营商、带宽档位相差很大，北京、上海、广州的独享专线通常按M/月计费，百兆以下单价较高，百兆以上单价逐步降低，共享带宽便宜一些,但高峰期无法保证延迟。
北京服务器带宽调度方案：先切分南北向流量还是先切业务？
北京服务器带宽调度方案里，先切业务优先级通常比先切地域更重要，北京机房成本高，专线价格也贵，直接加带宽的预算压力不小，用调度削峰，可以把月度95计费峰值降下来,成本反而更可控。
95计费取月度每5分钟带宽平均值的较高部分计费，只要高峰期的几个尖峰被削掉，账单就会明显下降,具体做法:
- 把大文件下载、图片缩放等非实时任务放到低优先级队列。
- 对API接口做令牌桶限速,避免突发重试把峰值拉高。
- 静态资源尽量走CDN回源收敛,减少源站出口压力。
可落地的带宽调度配置：从网卡到应用层
出口队列整形：给流量分车道
在支持 tc 的 Linux 主机上，可以用 HTB 队列把出口流量分成不同优先级，以下配置假设出口物理带宽为 100mbit：
tc qdisc add dev eth0 root handle 1: htb default 20 tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit ceil 100mbit tc class add dev eth0 parent 1:1 classid 1:10 htb rate 30mbit ceil 80mbit prio 0 tc class add dev eth0 parent 1:1 classid 1:20 htb rate 20mbit ceil 50mbit prio 1
prio 0 给支付回调、登录、实时API；prio 1 给普通页面；prio 2 给静态文件和大文件下载,这样高峰期关键流量不会排在静态资源后面。
Nginx限速与缓存：从应用层减少无效出站
在 Nginx 里可以做两件事：限制单个来源的请求速率,给静态资源设置长缓存。
limit_req_zone $binary_remote_addr zone=api:10m rate=50r/s;
location /api/ {
limit_req zone=api burst=100 nodelay;
}
burst=100 nodelay 允许短时突发，超过后立即返回 503,避免单个客户端把队列占满。
静态资源配置：
location ~ .(jpg|png|css|js|webp|woff2)$ {
expires 365d;
add_header Cache-Control "public, immutable";
}
这样同一用户后续请求直接命中浏览器缓存，不再反复回源,高峰期出口压力会下降一截。
监测与调参：盯住三个指标
- 网卡队列长度：
watch -n 1 'tc -s qdisc show dev eth0'，观察 backlog 是否持续大于零。 - 连接队列溢出：
netstat -s | grep -i overflow,多次采样看溢出次数是否增长。 - 应用响应分位数：从 Nginx 日志提取
$request_time，重点看 P95、P99 是否在高峰期突然抬高。
根据这三个指标调整 HTB 的 rate 和 ceil,而不是凭感觉加带宽。
Q&A
高峰期访问延迟偏高怎么快速定位是带宽问题还是应用问题？
先用 mtr 看链路中间跳的丢包情况，再执行 tc -s qdisc show dev eth0 看本机队列，如果链路丢包但本地队列低，说明是上游拥塞；如果本地队列高但链路正常,说明是应用排队或出口调度问题。
带宽调度策略有哪些适合中小站点？
中小站点优先用 Nginx 限速、静态资源长缓存、CDN 卸载静态流量，如果用户集中在几个地域，再加 DNS 分线路解析，不需要上复杂 BGP 调度。
高峰期网站访问慢用CDN还是升级带宽？
先看静态资源占比和用户分布，静态资源多且用户分散，CDN命中后源站压力会明显下降；动态接口慢则需要优化应用层缓存与连接池，升级带宽只是暂时缓解,无法解决慢查询与串行阻塞。
高峰期访问延迟偏高，通常是队列、链路、应用三层叠加的结果，先把调度做好，再考虑扩容,才能把钱花在降低峰值而不是堆总量上。