交换机端口上设一个速率上限，超出之后有两种处理方式，这就是限速（policing）与整形（shaping）的分界。
限速在入口或出口对报文计量，超出承诺速率的直接丢弃，或者降一个优先级再转发。它不占缓存，动作在微秒级完成，行为干脆。缺点是丢包是硬丢，TCP 会因此重传，视频会因此花屏。
整形在出口把报文先放进队列，按令牌桶给出的速率匀速取出。超出速率的报文不是被丢掉，而是晚一点发。它需要缓存，也会引入时延，但不会因为瞬时突发就丢包。
| 维度 | 限速 Policing | 整形 Shaping |
|---|---|---|
| 超出速率的报文 | 丢弃或降优先级 | 进队列等待 |
| 占用缓存 | 不占 | 占用，深度由 CBS 决定 |
| 引入时延 | 几乎为零 | 队列深度 ÷ 出口速率 |
| 对 TCP 的影响 | 触发重传、窗口收缩 | 平滑，重传少 |
| 典型位置 | 入口（防超额接入） | 出口（匹配下游带宽） |
| 适用场景 | 防用户超用、防攻击流量 | 上联带宽小于接入带宽 |
一句话的区分：限速管"你不许发这么多"，整形管"你发慢一点"。 前者是准入，后者是适配。
整形靠令牌桶实现。桶里按承诺信息速率（CIR）持续注入令牌，每个字节消耗一个令牌，桶空了就排队。三个参数决定它到底怎么表现：
CIR（Committed Information Rate）：长期平均速率，单位 bit/s。整形后的输出速率不会超过它。
CBS（Committed Burst Size）：桶的容量，单位字节。决定能容忍多长的突发。
EBS / PBS：超额突发容量，配合双速三色算法（RFC 2698 的 trTCM）使用，决定超出 CIR 但低于峰值速率的那部分报文是标记为黄色还是直接丢弃。
CBS 的取值有一个直接算式：
CBS（字节）= CIR（bit/s）× 容忍突发时长（s）÷ 8
这个式子说明一件事：CBS 不是越大越好，它等价于"你允许业务连续突发多久"。 允许 100 ms 和允许 20 ms，桶容量差 5 倍，丢包表现完全不同。
QoS 的打标、队列调度解决的是"谁先走"，整形解决的是"走多快"。工业网里后者被低估，是因为错配往往藏在拓扑里。
第一种，接入千兆、上联百兆。 8+4 口千兆工业交换机很常见，但现场往往只用其中一个口接到百兆无线网桥或运营商专线。24 个千兆口同时来流量，上联只有 100 Mbps，不整形就是队列溢出，溢出的部分随机丢。
第二种，有线接无线回传。 无线链路的有效带宽随信号质量波动，标称 300 Mbps 的链路在干扰下可能只剩 40 Mbps。交换机侧若按标称值配队列，实际链路一恶化就丢包；整形把出口速率压到链路能稳定承载的水平，反而更稳。
第三种，多路视频挤一条窄链路。 单路 1080p 摄像头平均 4 Mbps，但 I 帧瞬间能到 8–10 Mbps，且多路摄像头的 I 帧可能同时到达。平均带宽算下来够用，瞬时不够用，这是最典型的整形场景。
反过来，纯控制流量不需要整形。Modbus TCP 轮询、PROFINET 的循环数据，报文小而规律，速率远低于链路容量，整形只会给它们增加不必要的排队时延。这类流量要的是优先级，不是限速。
整形把报文放进队列，队列深度直接换算成时延：
排队时延（s）= 队列深度（bit）÷ 出口速率（bit/s）
举例：出口 90 Mbps，队列积压 512 KB，时延 = 512 × 1024 × 8 ÷ 90,000,000 = 0.0466 s，约 46.6 ms。
46.6 ms 对视频会议是可接受的抖动，对运动控制就是灾难。PROFINET 的循环周期常见 1–4 ms，EtherCAT 更低，任何超过周期的排队都意味着控制失效。所以整形参数不能只看"能不能不丢包"，还要看"愿意付多少时延"。
这也是为什么工业交换机上的整形通常要分层：端口级整形控制总出口速率，队列级整形控制每个优先级队列的速率。语音队列可以给小 CBS 保低时延，视频队列给大 CBS 吸收 I 帧，控制队列干脆不做整形、只做严格优先级。
一轮真实的配置计算。
已知：单路摄像头平均码率 4 Mbps，I 帧瞬时 8 Mbps、持续 40 ms；上联无线回传实测稳定带宽 6 Mbps；链路上还有 1 Mbps 的控制流量。
第一步，定 CIR。 视频可用带宽 = 6 − 1 = 5 Mbps。CIR 取 5 Mbps，控制流量走单独队列、不参与整形。
第二步，算突发长度。 一个 I 帧的数据量 = 8 Mbps × 40 ms = 320,000 bit = 40 KB。
第三步，算 CBS。 若容忍突发 100 ms：CBS = 5,000,000 × 0.1 ÷ 8 = 62,500 字节 = 62.5 KB。62.5 KB > 40 KB，一个 I 帧能完整进桶，不丢包。
第四步，验证时延。 最坏情况队列积压 62.5 KB，出口 5 Mbps，时延 = 62,500 × 8 ÷ 5,000,000 = 0.1 s = 100 ms。这是整形的固有代价，正好等于设定的容忍时长。
第五步，反证 CBS 取小了会怎样。 若按 20 ms 容忍配：CBS = 5,000,000 × 0.02 ÷ 8 = 12,500 字节 = 12.5 KB。一个 40 KB 的 I 帧只能装下 12.5 KB，剩下 27.5 KB 被丢，解码端看到的就是花屏或卡顿。这就是"整形配成了限速"的典型症状：明明开了整形，还是丢包。
结论：CIR 5 Mbps、CBS 62.5 KB、端口队列深度不小于 128 KB（留 2 倍余量），视频画面稳定，端到端增加约 100 ms 排队时延。
| 业务类型 | CIR 建议 | CBS 建议 | 队列深度 | 时延代价 |
|---|---|---|---|---|
| 视频监控（H.264/H.265） | 实测均值 × 1.1 | 100–200 ms | ≥ 2 × CBS | 100–200 ms，可接受 |
| 语音 / VoIP | 单路 100 kbps | 20–30 ms | 小 | < 30 ms，必须保 |
| PLC 控制（Modbus/Profinet） | 不整形 | 不整形 | 小 | 只给严格优先级 |
| 办公上网 | 按套餐 | 50 ms | 中等 | 影响小 |
整形管速率，队列调度管顺序，两者是串联关系：报文先按 802.1p 的 8 个优先级（0–7）入队，再由调度算法决定哪个队列先出，最后由整形器控制出口速率。
常见组合是严格优先级（SP）+ 加权轮询（WRR）+ 端口整形：
语音、控制走 SP 队列，永远优先出队，不做整形；
视频走 WRR 的高权重队列，配队列级整形；
办公、下载走低权重队列，端口级整形兜底。
顺序错了会出问题。先整形再调度，等于所有业务被一起压平，优先级失去意义；先调度再整形，高优先级报文能先出，整形只约束总量。配置时确认整形器挂在出口调度之后，这一条在各家设备上的实现差异很大，要看具体型号的转发流程说明。
另外，整形只在出方向有效。入口方向只能限速（丢弃），因为报文还没进队列，没有地方缓存。想控制"用户不要发太多"用入口限速，想控制"上联不要被撑爆"用出口整形。
三段示意，不同平台命令不同，以实际 CLI 为准。
! 示意：端口出口整形，CIR 5 Mbps，CBS 62.5 KB interface gigabitethernet 0/1 qos shape 5000 62500 ! 示意：入口限速，超出丢弃 interface gigabitethernet 0/2 qos police 10000 62500 exceed-action drop
三个常见误配：
其一，CBS 用了默认值。 很多设备默认 CBS 只有几 KB，对视频 I 帧完全不够，表现为"整形开了还丢包"。必须按业务突发量算。
其二，整形配在入口。 入口没有队列可缓，配置能下发但不生效，或者直接退化成限速。
其三，端口整形覆盖了控制流量。 控制报文和视频挤在同一个整形器下，视频的突发会把控制报文一起排队。正确做法是控制流量走独立队列、绕过整形，或给它单独的整形器。
锐应 8+4 口千兆工业交换机支持端口与队列级的 QoS 配置，PoE 型号可选项按项目确认；具体到整形器挂在哪个环节、CBS 的取值范围，要按型号的软件说明核对，不同芯片平台的实现差别不小。端口与供电侧的配合可参考 工业交换机方案，PON 侧多业务带宽的分配逻辑见 PON 方案。
限速在超出时丢包，整形在超出时排队。如果下游链路只是"平均带宽不够"，限速会让突发全部丢失；整形能把突发摊到后面几百毫秒发完，业务不中断。判断方法：看丢包是否集中在突发时刻，若是，用整形；若长期超载，整形也救不了，只能扩带宽。
按业务的最大突发量算，不要凭经验。算式是 CBS = CIR × 容忍时长 ÷ 8。视频按一个 I 帧的字节数校验，语音按 20–30 ms 校验，控制流量不整形。算出来的值再用"队列深度 ÷ CIR"换算成时延，确认这个时延业务能接受。
会，如果控制报文和视频共用同一个整形器。控制流量应该走严格优先级队列并且绕过整形，只受端口物理速率约束。工业现场配错这一条的比例不低，表现为"网络不丢包，但 PLC 响应偶尔超时"。
严格说不能。入口的报文还没进队列，没有缓存位置，只能计量后丢弃或降优先级，这就是限速。部分平台提供"入口整形"的说法，实际是把报文先缓存再处理，效果接近但时延特性不同，要按设备说明确认。
不是。微突发是现象（毫秒级的瞬时流量尖峰），整形是应对手段之一。另一个手段是加大队列缓存，让微突发被吸收而不丢包。两者区别在于：缓存只是"存下来等空闲发"，整形是"主动控制发送节奏"，后者更可控，前者更简单。
整形存在的理由只有一个：下游带宽装不下上游的瞬时输出，而业务又经不起丢包。工业现场几乎每个视频项目都会遇到这件事，只是很多人用"加带宽"绕过去了，直到链路换成无线、或者成本压不下来。真要靠软件解决，就得把 CIR、CBS、队列深度三个数一起算，并且接受它换来的那几十到几百毫秒时延。算不出来就配，结果通常是整形配成了限速，白忙一场。设备侧的端口与 QoS 能力见 关于锐应。
