4、带宽规划与QoS策略：带宽计算方法、业务优先级分类、QoS队列机制（LLQ、CBWFQ）、限速与整形
带宽规划这事儿，说白了就是「把钱花在刀刃上」。我见过太多企业，专线带宽买得挺贵，结果视频会议卡成PPT，ERP系统慢得像蜗牛。问题出在哪？不是带宽不够，是没规划好。
今天咱们就聊聊，怎么科学地算带宽，怎么给业务排优先级，以及QoS那点事儿。
4.1 带宽计算方法：别拍脑袋，要算清楚
很多人问我：「老王，我们公司100人，买多少带宽合适？」我的回答永远是：先算，再买。
带宽计算的核心公式其实很简单：总带宽 = 并发用户数 × 每用户平均流量 × 冗余系数。但这里有个坑——「每用户平均流量」怎么定？
我习惯把业务分成三类来估算：
| 业务类型 | 典型应用 | 每用户带宽建议 | 备注 |
|---|---|---|---|
| 办公类 | 邮件、OA、网页浏览 | 200-500 Kbps | 突发流量小，可压缩 |
| 协作类 | 视频会议、VoIP、远程桌面 | 1-2 Mbps | 对延迟敏感，需保障 |
| 数据类 | ERP、数据库、文件传输 | 500 Kbps - 5 Mbps | 突发流量大，需缓冲 |
举个例子：一家50人的公司，20人同时开视频会议（每人1.5Mbps），30人做日常办公（每人300Kbps）。那么总带宽 = 20×1.5 + 30×0.3 = 30 + 9 = 39 Mbps。再留个20%的冗余，大概50 Mbps就够了。
4.2 业务优先级分类：谁先走，谁排队？
带宽算好了，但所有业务都挤在一起抢资源，照样卡。这时候就需要给业务排个优先级。
我个人习惯把业务分成四个等级：
- 实时交互类（最高优先级）：视频会议、VoIP、远程桌面。这类业务对延迟和抖动极其敏感，延迟超过150ms，体验就崩了。
- 关键业务类（高优先级）：ERP、数据库、OA系统。公司命脉，不能断，但可以容忍少量延迟。
- 普通办公类（中优先级）：邮件、网页浏览、文件共享。可以等一等，但不能完全不管。
- 非关键类（低优先级）：软件更新、大文件下载、视频流媒体。说白了，这些业务可以「靠边站」。
为什么要这么分？你想想看，视频会议卡了，老板当场发飙；但软件更新慢了点，没人会注意到。这就是优先级的意义。
4.3 QoS队列机制：LLQ与CBWFQ
优先级分好了，怎么让路由器听话？这就得靠QoS队列机制了。我重点讲两个：LLQ和CBWFQ。
4.3.1 CBWFQ：公平但不绝对
CBWFQ（基于类的加权公平队列）是QoS的基石。它的逻辑是：给每个业务类分配一个带宽权重，然后按权重公平分配剩余带宽。
举个例子：你给视频会议类分配了30%的带宽，给ERP类分配了40%，剩下的30%给其他业务。当网络拥塞时，CBWFQ会保证每个类至少拿到自己那份带宽。
但CBWFQ有个问题——它不保证延迟。如果视频会议类突然有大量流量，它可能会排队，导致延迟飙升。这时候就需要LLQ了。
4.3.2 LLQ：给实时业务开绿灯
LLQ（低延迟队列）说白了就是在CBWFQ的基础上，加了一个「优先通道」。实时业务（比如VoIP）的数据包进来后，直接插队到最前面，优先发送。
我习惯这样配置：
class-map match-any REALTIME
match ip dscp ef
!
policy-map QOS_POLICY
class REALTIME
priority 1000 ! 保证1Mbps，超出部分丢弃
class CRITICAL
bandwidth 4000 ! 保证4Mbps
class NORMAL
bandwidth 3000 ! 保证3Mbps
class DEFAULT
fair-queue
!
interface GigabitEthernet0/0
service-policy output QOS_POLICY注意看，priority命令就是LLQ的核心。它告诉路由器：这个类的数据包，必须优先发送，哪怕其他队列饿死。
4.4 限速与整形：管住「野蛮生长」的流量
队列机制解决的是拥塞时的调度问题，但有些业务天生「野蛮生长」——比如P2P下载、视频流媒体。它们会拼命抢占带宽，把其他业务挤死。这时候就需要限速和整形。
4.4.1 限速：简单粗暴
限速（Policing）就是直接丢弃超出限制的流量。比如你给下载业务限速5Mbps，超过的部分直接丢包。
优点是配置简单，缺点是丢包会导致TCP重传，反而增加网络负担。
4.4.2 整形：温柔一刀
整形（Shaping）则温柔得多。它把超出限制的流量缓存起来，等带宽空闲了再发。比如你给下载业务整形到5Mbps，超过的流量会排队等待，不会丢包。
我一般这样用：
policy-map SHAPE_POLICY
class DOWNLOAD
shape average 5000000 ! 整形到5Mbps
service-policy QOS_POLICY
!
interface GigabitEthernet0/0
service-policy output SHAPE_POLICY注意，整形通常用在出口方向，而且需要配合队列机制一起用。否则整形后的流量还是可能拥塞。
4.5 一张图看懂带宽规划与QoS
说了这么多，我画张图帮你理清思路：
这张图把整个流程串起来了：先算带宽，再分优先级，然后用QoS队列保障实时业务，最后用限速/整形管住非关键流量。每一步都环环相扣。
4.6 实战避坑指南
最后，分享几个我踩过的坑：
- 别迷信「带宽越大越好」：我曾经帮一家客户从100M升级到500M，结果视频会议还是卡。后来发现是QoS没配，大带宽反而让P2P下载更疯狂了。
- LLQ的priority带宽要留余量：我习惯只分配总带宽的20-30%给LLQ，剩下的给CBWFQ。这样即使实时流量突发，也不会饿死其他业务。
- 限速和整形别混用：同一个接口上，既做限速又做整形，会导致流量行为不可预测。我一般出口用整形，入口用限速。
- 别忘了监控：QoS配完不是终点。我每周都会看一次接口的队列统计，看看有没有丢包、有没有队列溢出。发现问题及时调整。
嗯，带宽规划与QoS策略，说白了就是「算清楚、分好类、配好队、管住野流量」。做到这四点，你的远程办公专线基本就稳了。
公众号:蓝海资料掘金营，微信deep3321