QoS三件套：管制、调度、呼叫接纳，一次讲透网络流量管理

做网络或者做音视频传输的，多少都碰到过这几个词：管制、调度、呼叫接纳。我在项目里也经常被问“这三个不都是控制流量的吗，为什么还要分别记”。看起来都是QoS里的术语，但它们管的事完全不一样，拿一个替换另一个，配置上不出错才怪。这篇文章我按自己的理解把这三个概念拆开讲透，如果还能帮你应付掉一次技术面试，或者说让你在客户现场少改两版配置，那就更值了。

先说结论：服务质量这件事，本质是网络带宽、时延、抖动、丢包这四样资源不够用的时候，由谁来决定“谁受影响、受多大影响”。管制管的是流量入口，调度管的是拥塞之后的排队秩序，呼叫接纳管的是新会话进来之前有没有能力接。下面逐个拆。

1. 先理思路：QoS是组合拳，三个词管的是三个环节

1.1 网络为什么会拥塞，QoS到底解决什么问题

很多人一提QoS就想到“限速”，这其实是把结果当成了原因。网络之所以需要QoS，是因为交换机、路由器、无线控制器这些设备的转发能力不是无限的，出接口在单位时间内能送出去的帧/包是有上限的。当多路流量同时涌向同一个出口，比如公司出口带宽只有200M，但视频会议、文件下载、数据库备份、办公流量同时都要走，出接口队列就会堆积，丢包和时延上升。

这和高速收费站一个道理。车道数量固定，车多了就得排队，谁先过、谁等待、谁被劝返，必须有规则。QoS干的事就是制定这套规则，而不是凭空增加带宽。所以理解QoS，要先理解“资源有限，规则决定谁先获得资源”。

1.2 三个名词在整条链路上的位置

我习惯用一条数据流的生命周期来记这三个概念。流量从用户终端发出来，经过接入层、汇聚层、核心层，最后从出口到对端或者公网。在这条链路上：

• 流量刚进设备的时候，设备要先检查它符不符合购买或规划的速率约定。这是管制的活。
• 流量在设备内部转发，到了出接口准备往外走，发现队列里已经有其他流量在排队。谁排前面、谁排后面、每个队列给多少带宽，这是调度的活。
• 如果这是一路新的语音通话或者视频会议，它还没开始传数据，先要问一句：从源到目的地的路径上，带宽够不够支撑这一路不卡顿？这个预先审批，是呼叫接纳的活。

三个环节位置不一样，做事的方式也不一样。管制和数据包的字节流打交道，调度和数据包的排队顺序打交道，呼叫接纳和“会话”这个抽象概念打交道。

1.3 它们分别回答的三个问题

把三个名词翻译成问题，区别就清晰了：

• 管制回答：流量是否遵守签约速率？违规了怎么办？
• 调度回答：当多个队列都想用出口带宽时，谁的优先级高、谁分多少比例？
• 呼叫接纳回答：在既定资源条件下，新的呼叫或业务流该不该准入、准入了会不会拖垮原有的？

这三个问题互相关联，但答案不能互相替代。只做呼叫接纳，不配置调度，即使呼叫被批准了，数据在拥塞时也可能排不上队。只做调度，不配置管制，谁都往队列里塞优先级高的流量，队列权重再合理也会溢出。我在实际项目里确实见过只按照优先级给全线流量打高标准，结果出口拥塞时所有包都是最高优先级，调度策略形同虚设。

2. 管制：进门的流量，得按约定速度来

2.1 管制的本质：约定速率与违规处理

管制，英文对应Policing，常见名字有流量监管、流量限制。它做的事非常直白：流量进设备的时候，设备按一个约定的速率来测量它，超过约定速率的部分要么丢弃，要么标记成低优先级，允许它继续走但后续处理时优先丢它。管制不缓存、不等待，当场处理。

举现实场景。公司买了300M办公带宽，但某个业务系统所在的服务器网段每天把带宽跑满。这时在接入这个网段的交换机入方向配一个管制策略：承诺速率CIR 100Mbps，超出部分标记为低优先级。这个策略一旦生效，该网段的流量到了100M就往下降级，再怎么冲也冲不进高端队列。

管制的“狠”就在这：它不接受排队，超了就处理你。这个特性决定了它特别适合用在入口和边缘，防止某条无人管的流量把整条链路拖垮。

2.2 令牌桶与三色标记

要理解管制，绕不开令牌桶。令牌桶可以理解成一个水桶，桶里装的是令牌，每一个字节要发出去，都得先拿一枚令牌。设备以CIR速率持续往桶里放令牌，桶的容量是CBS（承诺突发尺寸）。流量到达时，有令牌就拿令牌放行，桶里没令牌了超出的部分就按违规处理。

但工业实现里光“放行/丢弃”两档不够用，所以演化出了三色标记。最典型的是单速率三色标记srTCM和双速率三色标记trTCM。

单速率三色（RFC 2697）维护一个承诺速率CIR和一个承诺突发CBS，再加一个超突发尺寸EBS。流量先看桶里的C令牌够不够：够则标为绿色；不够则看E令牌，够则标为黄色；连E令牌都不够，标为红色。绿色直接放行，红色立刻丢弃，黄色呢？打上低优先级标记放行，等到了拥塞节点再有调度策略时优先丢它。

双速率三色（RFC 2698）则维护两个令牌桶：一个按CIR填充的承诺桶，一个按PIR（峰值速率）填充的峰值桶。流量先测峰值桶，超出PIR直接标红；没超PIR，再看承诺桶，超了CIR但没超PIR标黄，在CIR内的标绿。PIR通常配得比CIR高，允许流量有突发。

实际配管制策略的时候，很多人纠结CBS和EBS/PBS参数填多少。这里给个经验值：如果流量平滑，CBS可以小一些；如果业务本身就是突发的，比如网页浏览、数据库查询，CBS至少要能容纳几十毫秒到几百毫秒的突发量。拿100Mbps的CIR举例，如果希望允许约100ms的突发，CBS大概需要100Mbps乘0.1秒再除以8，约1.25MB，也就是1,250,000字节级别，换算成突发字节数差不多1,250,000。具体值按厂商设备不同取整即可。

2.3 管制和流量整形，别老搞混

管制和整形在中文里听起来差不多，实际天差地别。整形，英文Shaping，也有令牌桶，但超出速率的流量不会当场丢弃，而是放进一个缓冲区排队，等令牌足够了再慢慢发出去。管制是当场决定处理，整形是缓一缓再发。

两者的代价正好相反。整形因为缓存了流量，丢包少，对TCP流量尤其友好，但会引入额外时延和抖动，不适合对时延敏感的场景；管制几乎不增加时延，但丢包干脆，TCP遇到丢包会触发拥塞控制，导致吞吐下降。

所以在工程上有个不成文的习惯：入方向用管制，防止外部流量把设备打爆；出方向用整形，比如链路出口带宽小于接口速率时，用整形把发送速率平滑到和链路匹配。管制管入口，整形管出口，不是一个东西。

2.4 一段可参考的入口管制配置

以常见企业级设备的配置风格为例，限制某个内网网段总带宽不超过100M，超出的包标记为低优先级DSCP CS1：

traffic classifier limit if-match acl 3001 traffic behavior mark-down car cir 100000 pir 150000 remark dscp cs1 traffic policy ingress-policy classifier limit behavior mark-down

interface GigabitEthernet0/0/1 traffic-policy ingress-policy inbound

这段配置的意思是：在接口入方向做管制，承诺速率100Mbps，峰值速率150Mbps，超过承诺速率到峰值之间的流量被标记为CS1。后续策略只要丢低优先级，CS1就是首选对象。

配置里最容易犯的错：把CIR配得超过了物理链路速率。入接口带宽1G，你配CIR 800M没问题；出接口只有100M，你却往里压了500M的承诺速率，那这个管制策略就是尸体，永远不生效。配置前先确认方向，再确认物理速率。

3. 调度：拥塞时，先发谁由队列规则决定

3.1 从FIFO到分级队列

调度说的是数据包在出接口排队时的发送顺序。设备出接口只有一个，同一时刻只能发一个包，多个包要出去就得排队。最简单的排队就是先到先发，FIFO。这种模式听起来公平，实际上对业务毫无区分度：一秒钟的下载突发，就能把后面所有语音包的顺序拖后几十毫秒，而语音超过150毫秒的单向时延，人耳就能感知到卡顿。

所以有了分级队列，把流量分成若干个队列，每个队列有自己的发送优先级或带宽权重。配置上常用的做法是按DSCP或优先级来分类：EF（加速转发）进低时延队列，AF类进保障带宽队列，BE（尽力而为）进默认队列。

3.2 常见的调度算法对比

我把常见算法的逻辑用一个表理一下，这样面试或者选型的时候可以直接对着看：

上面PQ有个“饿死”问题：高优先级队列持续有包，低优先级队列永远轮不到。LLQ解决这个问题的办法是对PQ队列也设置一个带宽上限，超过上限的实时流量也会被延后或丢弃，其他队列至少能拿到剩余带宽。

3.3 实操重点：如何配出“语音优先”

在实际组网里，“语音优先”往往意味着两件事：一是语音流量的单跳时延要可控，二是语音会话占用的带宽能保证。这两件事在调度侧靠同一套配置完成。

以同时支持PQ和CBWFQ的设备为例，典型思路是这样一个出接口策略：

• 语音流量（DSCP EF）进一个严格优先级队列，使用LLQ方式，保证最多128kbps，且优先发送。
• 视频会议流量（DSCP AF41）进保障队列，分到2M带宽。
• 普通办公流量（DSCP AF21、BE）进其他队列，按权重分配剩余带宽。

命令风格长这样：

traffic classifier voice if-match dscp ef traffic classifier video if-match dscp af41 traffic behavior voice-queue queue low-latency bandwidth 128 traffic behavior video-queue queue af bandwidth 2048 traffic policy out-policy classifier voice behavior voice-queue classifier video behavior video-queue

interface GigabitEthernet0/0/0 traffic-policy out-policy outbound

这么做的好处是语音包进入LLQ后，优先级保障一直从出接口持续到对端，时延相对可控。视频和流媒体大包分流到AF队列，不会因为数据队列里的长队列而挤掉语音。

3.4 调度里的关键权衡：时延、公平和丢包

调度策略表面上是在排先后，本质上是在三个指标之间做权衡：时延、公平、丢包。不存在一种调度算法三个都最好。PQ时延最优，公认最不“公平”；WFQ公平最好，但对时延没有硬保证；LLQ折中，可配置性最强，但如果LLQ带宽占总带宽比例太大，剩下的业务带宽还是会被挤到接近零。

这个比例怎么算，有一个简单经验：链路总带宽里分配给LLQ的带宽不建议超过50%，语音和视频混跑的环境里，LLQ分配超过70%基本会把数据流量饿到不可用。即便是全高清视频会议，单路多边形的码率也就2M上下，给LLQ预留足够的但相对克制的余量就行。

还有一点要记住：调度只在拥塞时起作用。链路空闲时，所有流量都秒发，调度规则根本不会触发。很多人在测试环境里验证QoS，发两个小流，一看没差别就以为配置错了，其实是没制造拥塞。真要验证，请同时打满多条大流，让出口队列真的堆起来，再测目标流的时延和抖动，效果才看得出来。

4. 呼叫接纳：会话还没开始，就决定它能不能进

4.1 名字有点“老”，但逻辑到今天还在用

呼叫接纳控制，英文是Call Admission Control，通信圈喜欢简称CAC。它问的问题和管制、调度都不一样：一个实时会话要想在这个网络上开始传输，网络还有能力接待它吗？如果有，就放行；如果没有，与其让新呼叫进来后和旧呼叫一起卡顿，还不如直接拒绝新的呼叫，或者把它路由到备用路径。

这个概念来自传统电话网时代。程控交换机时代有个概念叫“电路”，每条通话占一个固定时隙，交换机能处理的并发呼叫数量有限，所以要有一个机制，在呼叫进来的时候判断资源够不够。这一套逻辑延伸到IP网络上依然适用，而且更复杂，因为IP网络没有固定电路，所有流量在一个共享管道里，你很难精准预知某一路新呼叫到底会消耗多少带宽、途经哪些节点。

4.2 三种实现方向：呼叫数、预留、测量

按实现机制，CAC大致分三类，简单记就是按个数管、按预留管、按测量管。

基于呼叫数的CAC最朴素，直接限制并发会话数量。比如一个分公司只允许同时存在10路语音通话，超过10路时新呼叫直接拒绝或转忙音。这种方式实现成本低，但不精确，因为每路呼叫的编码格式、包间隔不一样，真正消耗的带宽差别很大，同样是语音，G.711一条流占用80kbps上下，G.729只要不到30kbps，按个数限制必然有浪费或超卖。

基于资源预留的CAC是另一类代表，最典型的是RSVP。应用在呼叫前通过信令沿路径去请求资源，每个节点查看自己有没有足够的可用带宽，如果整条路径都答应预留，呼叫才能建立。这个方案可靠，但代价是设备要维护大量会话状态，大型网络扩展性差，所以实际落地时通常只在带宽瓶颈明显的WAN链路两侧启用，而不是全网开启。

基于测量的CAC更灵活，对会话开始前和进行中都做探测。具备这种能力的设备持续监测出口带宽占用率、时延、丢包率，当新呼叫到来时，通过当前资源余量决定是否放行，会话进行中如果质量下降，还能主动掐断或重定向。缺点是测量本身有滞后，瞬时突发可能测量不到，所以缓存窗长要调得合理。

4.3 语音/视频会议里的CAC落地

现代企业组网里，CAC最常出现在语音网关、视频会议MCU、SBC（会话边界控制器）这些网关上。举例，一个分布式视频会议系统，每个分会场通过一根20M专线汇聚到总部。如果同时开3路1080p视频会议，每路占8M，线路余量还剩一些，第4路呼叫进来时为了保证已有的3路不卡顿，SBC按策略直接把第4路路由到备份链路，或者干脆拒绝并提示稍后重试。

这种场景下，CAC策略一般是这么设计的：

1. 先明确单路业务模型，比如单路语音80kbps、单路1080p视频8M。
2. 再统计链路最大可用带宽，并保留安全余量，通常保留20%给非实时流量，只把80%作为实时可分配带宽。
3. 最后按会话数或按总带宽设置上限，新会话进来先算账，账不够就采取措施。

这里的核心是“安全余量”不能没有。我在项目里见过一个反面案例，管视频的管理员把20M专线的实时带宽可分配值设成18M，满算满配，结果视频码率一波动，加上链路底层开销，把专线跑满，所有会议一起卡。后来留了20%余量，反而稳定了。

4.4 CAC和管制、调度到底怎么分工

CAC和另两个不是同一个维度的工作，这里必须说清：管制和调度是对已经存在的流量做处理，CAC是对还没建立的会话做决策。CAC更像“事前审批”，管制是“事中稽查”，调度是“事中排队”。

但这三者又互相依赖。CAC计算的时候，必须先知道网络在调度侧给实时流量预留了多少带宽，不然CAC批得合不合理无从谈起。而调度侧如果已经通过CAC预留了带宽，调度策略里必须能在物理上保证这部分带宽，否则CAC批了也白批。

举个具体的：某设备的语音调度策略里，LLQ带宽设了5M，那么CAC在算接纳上限时，就应该以这5M为可分配基数，而不是拿总带宽来算。如果CAC按总带宽的30%批准呼叫，调度却只给实时流量留了20%，呼叫建立后数据在LLQ里排队，该卡还是卡。先调调度，再配CAC，这个顺序别反。

5. 串起来看：一个语音会话从呼叫到传输的完整路径

5.1 时间线拆解

把前面三部分串成一个完整场景，理解马上就会立体起来。假设有一条50M的企业专线，总部和分部各有一台语音网关，内部话机通过IP网络通话。一个用户拿起话机拨号，流程大致是这样的：

1. 话机发呼叫信令到语音网关，网关向对端发起呼叫。
2. 对端和路径上的CAC模块或SBC先做接纳判断，查询当前实时流量带宽利用率，估算本次呼叫需要多少带宽。若带宽充足，呼叫建立；若不充足，直接返回忙音或引导到备用线路。
3. 呼叫建立后，语音流按约定编码格式产生RTP包，DSCP被标记为EF。
4. 数据包进入第一个接入设备，入接口的管制策略开始检查速率：呼叫带宽在CIR范围内，包标记为绿色正常通过；如果终端/网关出流量异常，比如由于病毒或放音异常导致突发流量过大，管制会在入口处理掉或降级。
5. 语音包在网络内逐跳转发，到达每个出接口时，调度策略让EF队列的语音包优先发送。拥塞期间，语音包的排队时延被压到极低，而文件下载的包在后面排队。
6. 整个会话过程中，如果某一段链路的实时占用率持续走高，CAC模块还会拒绝后续的新呼叫，保证正在通话的这条路不被打扰。

这个过程里，管制可能在多个节点入口同时存在，调度在每个出接口都存在，CAC只在网络边界或会话管理节点存在。三者各管一段，合在一起用户才感受不到卡顿。

5.2 为什么只做其中一环不够

我见过不少组网只做了调度，觉得只要语音优先级高就万事大吉。结果呢，外部接入的某路流量在入口也被打成了高优先级，调度器一视同仁，语音一样被挤。这就是缺少管制的后果。

反过来，有个分支只做了管制，把每路语音呼叫限制在100kbps以内，但没做调度。链路拥塞时，语音包和数据包一起在FIFO里排队，发送顺序完全不可控，时延指标照样不达标。这就是缺少调度的后果。

还有只做接纳控制的，在SBC上把并发呼叫数卡得很死，呼叫是挡住了，但已经准入的流量在网络上没有明确的优先保障，接进了一堆呼叫却照样丢包严重。这种情况发生在网关做了接纳、内部路由器却没做QoS映射的组网里。

所以这三样东西面向同一个目标的不同环节，组合使用是常态，单独使用都是半拉子工程。

5.3 一套小型组网的参考配置组合

下面给一个完整的、可以在小型企业分支复现的配置思路。链路：50M专线。业务：语音+G.711编码，共用若干路视频会议，其余为办公数据。

第1步，分类标记。在接入交换机或网关入方向，把语音RTP包标记为EF，视频会议标记为AF41，一般OA数据保持AF21，其余为BE。这一步很关键，后续所有策略都依赖这一步的分门别类。

第2步，入口管制。对语音和视频分别做CIR保护，防止单点故障或异常拖垮线路。例如语音网关入接口做CIR 5M、PIR 8M的管制，超过PIR直接丢，避免异常放音流量声明为EF后冲进网络。

第3步，出接口调度。在50M专线路由器的出接口配置调度策略，LLQ给语音分配2M，保证队列给视频分配20M，剩余带宽给数据和默认流。这里留给实时业务的带宽总量不超过30M，保证数据业务有基本存活空间。

第4步，呼叫接纳。在语音网关上设置基于测量/呼叫数的CAC，可并发语音呼叫数上限按实时带宽池计算。如果单路G.711约80kbps，预留2M给语音，大约允许20路并发，建议保守点配16~18路，留一点余量。

第5步，监控。在网管系统里看LLQ队列丢弃数、EF流量丢包率和时延，定期回看CAC拒绝的呼叫次数。如果CAC拒绝次数一直很高，代表带宽模型保守了，可以顺次微调；如果队列丢弃数增长说明调度带宽或管制参数不合理，优先查入口管制。

6. 常见问题与排查经验

6.1 管制误伤了正常业务

最常见的坑是CIR配得太小，或者CBS爆发的尺寸设得太低。做数据库备份的流量本身是突发型的，短时间冲到300M，平均速率只有80M。如果管制配了100M的CBS却只够容纳几十毫秒的突发，那每次备份高峰都会触发丢包，业务反馈“慢”。

排查建议分两步：先看设备里CAR/Policing的统计计数，绿色包、黄色包、红色包各自的数量。如果黄色和红色包的数量在平时也不清零，说明峰值突发超过了不少；再看是否已经出现TCP重传增多或业务卡顿的反馈。调参方向是先加大CBS，让它能容纳2-3个业务响应周期的突发，再考虑是否提高CIR。

6.2 调度配置看起来没问题却没生效

遇到过很多次用户把调度策略挂在物理端口上，但流量实际走的却是某个VLAN子接口或隧道接口。策略挂错了位置，自然不生效。要先用命令把所有接口的流量统计打开，对比哪个接口的计数在变化。

还有一个常见原因是隧道封装导致DSCP被改了。某些运营商线路在隧道内外层双标签处理时会把内层DSCP设成默认值，语音包的EF标记被改写成了BE，后面的调度全按普通数据处理。这种情况需要在隧道入方向重新应用QoS策略，对DSCP进行信任或重标记，让隧道内部仍然按EF处理。

6.3 呼叫接纳过严导致呼叫失败

CAC过严的典型症状是新呼叫常常打不通，或者通话建立后只响一声就忙音。排查时先看SBC/网关上的呼叫统计，确认拒绝原因是不是带宽不足或并发数超限。如果是，先检查CAC的带宽池和实际链路带宽差距有多大，余量一般要留20%-30%给波动。如果呼叫成功率很低，试着提高实时可分配带宽百分比；但也别一下提太高，会导致另一个症状——呼叫通了但说话断断续续。CAC的调节要保持呼叫成功率与会话质量两个指标同时盯。

6.4 排查思路速查表

最后整理一张速查表，适合在客户现场照顺序排查：

最后说几句实在话

这三个词之所以经常被放到一起问，不是因为它仨是同一类功能，而是因为一个真正可用的QoS方案，往往要同时用到它们。我这些年做网络项目的体会是：先别急着敲命令，先在纸上把流量路径画出来，标清楚入口、出口和会话边界，再看看三样东西各自该出现在哪。只要这一步想明白了，配置只是照着填参数而已。反过来说，那些现场改来改去最后还是一锅粥的，基本都是在没搞清三个环节分工的时候就动手了。希望这篇对你也有用。