企业官网建设流程全解析

先说个让我印象很深的场景：我调测过一套TSN的测试床，802.1AS时间同步、802.1Qbv门控调度全部正常，但一到压力测试就翻车，端到端时延抖动从微秒级直接飙到几十毫秒。排查了两天，最后定位到是一台从站设备在某个周期里多发了几个报文。就这么点流量，把交换机的出口队列挤爆了，所有为控制类流量预留的时隙全部错乱。从那以后我对TSN的理解就多了一层：**TSN的确定性不是靠"大家都很守规矩"来保证的，而是必须在入口就把不守规矩的流量挡在门外。**而802.1Qci（Per-Stream Filtering and Policing，每流过滤与监管）干的就是这件事——它是TSN里专门管"入口秩序"的协议，和802.1Qbv的"出口编排"正好是一对。

这篇文章是TSN协议深度解析系列的第四弹。前面聊过时间同步、调度和帧抢占，这一篇重点拆802.1Qci：它到底过滤什么、门控列表怎么工作、流计限速的原理是什么、和Qbv怎么配合，以及我实际部署时踩过的坑和调试方法。内容按5个部分展开，适合已经入门TSN、正在做方案设计或协议栈开发的工程师，也适合刚接触TSN但不清楚"为什么有了Qbv还不够"的朋友。

1. 为什么TSN最怕"不守规矩"的流量：确定性的前提是入口可控

TSN的核心价值是确定性，但这个确定性并不是凭空来的。为了让大家看懂802.1Qci存在的必要性，先聊清楚一个逻辑：TSN凭什么确定？

1.1 TSN的确定性依赖一个被默认的假设

TSN能做到微秒级甚至亚微秒级的确定性传输，靠的是三件事的紧密配合：全网时间同步（802.1AS）、发送窗口编排（802.1Qbv）、以及流量准入和剔除机制（802.1Qci，还有802.1CB、802.1Qbu等）。

802.1AS把所有节点的时钟对齐到一个纳秒级的时间基准上。802.1Qbv则基于这个统一时间基准，在每个出口端口上编排一张Gate Control List（门控列表），规定哪个优先级队列在哪个时间段开门放行。只要全网节点都严格按照这张表发送和转发，那么一个从端到端的帧，从进入到离开网络，所有经历的排队时延都是确定的，因为每个转发节点在哪个时间片转发哪个队列，都是提前算好、写在硬件里的。

**但这里面藏着一个被默认的假设：每个节点都会在预期的时间，发送预期的帧长和帧数量。**如果某个节点不按约定来，比如多发了帧、扩大了突发量、甚至某个VLAN ID的流量突然暴涨，那么交换机端口的入口流量总和就会超出Qbv调度表所预留的带宽容量。多余的数据帧要么进不了出口队列，要么在队列中挤占其他关键帧的位置。不管哪种情况，延迟和抖动都会不可控地恶化。

1.2 "不守规矩"的流量从哪来？不止是攻击

很多人把802.1Qci理解成防火墙，其实不准确。我更愿意把它比作门口的门禁——它不仅防坏人，也管"超量"的好人。

正常情况下，网络里产生异常流量有三个来源：

• 节点故障：从站设备软件跑飞，循环发送逻辑出错，把本来20ms周期变成了2ms，甚至持续狂发。这类问题在工业现场特别常见，尤其在多厂商设备混用的场景里，总有一台设备的协议栈实现不完善。
• 配置错误：人为配错VLAN、配错流ID，导致一个流的流量跑到了另一个流对应的队列里；或者某个测试设备忘关了，一直在发广播报文。
• 拒绝服务或恶意攻击：虽然TSN大多跑在受控的工业内网，但也不是绝对封闭。一旦某个网口被接入恶意设备，定向打流、广播风暴都能淹没整个确定性调度机制。

这里要纠正一个常见误区：很多人以为TSN的网络风暴主要靠交换机背板带宽解决——"带宽足够大不就得了？"实际上，TSN对延迟的硬性要求决定了交换机内部缓冲是"小而快"的，不可能像普通数据中心交换机那样堆几十兆的缓冲。普通交换机允许爆缓存，多等几毫秒没事；TSN交换机做不到，它只能尽量通过调度保证关键帧不间断地转发。所以入口侧的把关，就变成刚性需求。

1.3 Qbv管"出"，Qci管"入"，两者缺一不可

802.1Qbv解决的问题是：一个输出端口上的多个队列，在一个时间循环里应该在哪些时隙打开、哪些时隙关闭。它面向的是出口方向。

但Qbv有一个前提盲区：它假设"进入端口的数据量是可控的"。如果入口一下子涌入一堆优先级很高的帧，这些帧会填满对应的入口侧缓冲，然后向出口队列流动。假设某个流的正常带宽是10Mbps，结果业务异常发到了50Mbps，那么Qbv即使把门控编排得很完美，也挡不住这些多余帧造成的拥塞。因为Qbv只在出口侧工作，它面对的是已经进入交换机内部的数据帧。

802.1Qci正是补这个缺口的：**它在端口入口方向，对进入的每个流做逐流的过滤、门控和限速。**帧还没进交换核心，就先按帧特征做一次"安检"。该挡的挡，该限的限，该打标记的打标记。这样进入交换矩阵的流量就是"预期内"的，Qbv的调度表才能真正生效。

所以理解802.1Qci的正确姿势是：它不是取代Qbv，而是让Qbv更可靠。一个是"入口守卫"，一个是"出口红绿灯"。没有Qci的TSN网络，就像没有安检口的车站——车票和站台安排再合理，一旦有人涌进站台，全乱。

在具体拆解802.1Qci协议机制之前，先给一个三句话的速览，帮大家建立整体印象：

• 802.1Qci也叫PSFP（Per-Stream Filtering and Policing），工作在端口入口方向，对数据帧按流进行过滤和监管。
• 它把每类流量映射到一个流过滤器，通过门控（Gate）+ 流计（Flow Meter）控制帧的放行/丢弃/标记。
• 它通过一张周期循环的门控列表实现时间窗口控制，通过令牌桶机制实现带宽限制，既能防"不该来的帧"，也能管"来太猛的帧"。

下面展开核心机制。

2. 802.1Qci核心机制：流过滤器、门控、流计三者如何配合

802.1Qci整套机制可以概括成三个核心组件：流过滤器实例（Stream Filter Instance，SFI）、流门控实例（Stream Gate Instance，SGI）、流计实例（Flow Meter Instance，FMI）。三者是一种串联关系：数据帧先匹配流过滤器，过滤器指向一个门控和一个流计，门控决定这段时间放不放行，流计决定放行后的帧是"正常帧"还是"超量帧"。

2.1 流怎么被识别和匹配？从流ID到流过滤器

802.1Qci里的"每流过滤"，关键在于"怎么筛"。一个流过滤器对应一个流，这个流是用一组帧特征来识别的。Draft标准和最终标准里，流识别的方式经历了演化，在最终802.1Qci-2018里，最核心的匹配字段包括：

把这些匹配规则配置到硬件表项之后，每来一个帧，交换芯片就在入口侧查一遍规则表，命中的帧交给对应的流过滤器处理。为了提高性能和可配置性，Qci还可以通过Stream Handle（流句柄）来做二级映射：帧匹配到流ID后，再映射到一个更宽松的"流句柄"，这个句柄指向真正的处理策略。这样一来，多个相似流可以共享同一套过滤策略，节省硬件资源。

有个非常容易混淆的概念：流ID（Stream ID）不是VLAN ID。Stream ID是一个更大范围内的全局标识，VLAN ID只是它的一部分。在单交换机简化的实现里，确实可以拿VLAN ID等映射成Stream ID，但这只是简化做法；在跨桥接网络时，一个TSN流可能穿越多个桥，每个桥都得能识别出这个流，所以Stream ID的标准定义更接近"基于目的MAC+VID"的组合。实际落地的时候，交换芯片厂商都会做自己的流匹配查表引擎，比如基于精确匹配的Hash表或者TCAM。

2.2 流门控：一张周期循环的开关时间表

流门控（Stream Gate）是Qci里最有意思的一部分。它并不是一个简单的开/关开关，而是一张周期循环的时间表，这张表叫做Gate Control List（门控列表）。

门控列表的每个条目由两部分组成：一个门控操作（Open/Close/Set）和一个时间间隔。整个列表循环执行，执行周期与TSN的控制周期对齐。

举一个具体例子。假设一个工业控制场景，控制周期是10ms，我们需要在一个循环里让流A只在第2ms到第4ms之间放行。那么门控列表可以这样定义：

循环执行下来，在第0-1ms之间门是开的，1-3ms门是关的，3-9ms门是开的，9-10ms门是关闭的。做完这10ms的循环，从头再来。这样一来，在第1-3ms这个窗口到达的帧，一律被丢弃，无论它是谁、优先级多高。

这就是Qci和普通ACL（访问控制列表）最大的区别：ACL是"静态规则"，而Qci是"时间敏感规则"。ACL只根据帧头内容来判定放行与否，Qci除了看帧头内容，还要看"当前时间点允许不允许你过"。这也是它作为TSN协议族成员的根本原因——它把时间维度引入了流量过滤。

门控列表配置几个容易注意的点：

• 时间精度：条目里的时间间隔通常以纳秒（ns）为单位，上限取决于硬件定时器的位数。一般配置粒度到1024ns的整数倍就够了。
• 周期对齐：门控循环的起点必须和802.1AS时间同步后的循环周期对齐（通常和Qbv的周期周期保持一致），否则你设想好的窗口和你实际放行窗口会错位，出现"该开的时候没开，该关的时候没关"的情况。
• 最小间隔：硬件实现的流门控通常有最小时间间隔要求（比如32ns或者1024ns），配置时不能把间隔设得太短。短于最小间隔的门控条目，交换芯片不一定能准确执行。

2.3 流计：三色令牌桶的限速逻辑

流门控管"时间窗口"，流计管"速率和突发量"——这两个维度缺一不可。流计的核心实现就是工业界非常成熟的令牌桶算法，在802.1Q里的具体形式是定义一个带宽配置文件（Bandwidth Profile），由4个关键参数决定行为：

可以把它类比成一张公交卡：CIR就是每个月固定充值的钱，CBS就是卡里允许积攒的最高余额；EIR是允许你透支的额度，EBS就是透支的上限。正常范围内，怎么刷都行；超出承诺额度但还在透支额度内，卡被标记为"需人工审核"；超出透支额度，直接拒绝上车。

流计给帧做三色标记（Color）：

• 绿色（Green）：帧在CIR和CBS范围内，可以直接放行，且保留其优先级不变。
• 黄色（Yellow）：帧超过了承诺速率，但还在EIR和EBS范围内。这时帧可以放行，但会被打上"低优先级"的标记，后续如果遇到拥塞，这类帧最先被丢弃。
• 红色（Red）：帧超出上述所有额度，直接丢弃。

你可能会问：这不就是SRTCM（单速率三色标记）或TRTCM（双速率三色标记）吗？对，Qci的流计本质上就是SRTCM/TRTCM在TSN场景下的实例化，区别在于它的标记结果会联动后面的帧淘汰策略，三色标记决定了一帧进入交换矩阵后享受什么待遇。

这里有个细节值得多说一句：流计不仅可以用于限速，也可以用于"突发控制"。因为TSN里很多控制流是周期性突发的（比如一个周期内一次性发送多个帧），CBS的大小决定了你能否容忍这个突发。如果CBS配置过小，正常周期性的突发帧会被误判为超量帧，导致正常业务的帧被丢弃或降级——这是我实际配置中最常遇到的问题之一，后面避坑章节再细说。

2.4 帧淘汰策略：不止是"丢"和"不丢"

Qci对一帧完整处理流程是：流过滤器匹配 → 流门控检查时间窗口 → 流计检查速率 → 最后按策略执行。这个"最后按策略执行"也很讲究，标准里定义了不止一种动作：

在很多人印象里，不匹配门控的帧必然被丢弃。但实际上，标准允许配置成"Observe"模式——帧照样过，同时累计异常计数。这在调试和部署初期非常有用：你不需要一上来就"动刀杀帧"，可以先观测异常流量是不是真的存在、有多大、什么时间出现，确认无误后再切到Discard模式。我在实验室做验证时经常用这套流程：先Observe，再Discard，能极大降低上线时的风险。

2.5 一次完整的流处理过程示例

把上面的机制串起来走一遍：假设端口GE1/0/1配置了流过滤器SFI_100，它映射到的门控条目允许时间段是0-1ms和3-9ms，映射到的流计参数是CIR=10Mbps、CBS=1000Bytes。

• 在0-2ms之间，到达一个属于流100的帧：门控现在处于Open状态，帧通过门控；流计检查到帧在CIR配额内，打绿色标记，放行。
• 在2-4ms之间，帧再到达一个流100的帧：此时门控处于Close状态，直接丢弃，流计都不需要检查。
• 在5ms时，突然来了比平时量大得多的流100帧：门控是Open的，但流计发现超过了CIR，如果还有EIR余量，打黄色标记后放行，同时把帧的优先级降级；如果连EIR也超了，直接丢。

所以，**门控负责"这段时间让不让你过"，流计负责"过了之后按什么状态进网络"。**两个工具配合，一个控时机，一个控数量。

3. 落地配置：为什么用Netconf/YANG，而不是传统CLI？

协议原理搞清楚之后，下一步就是实操。802.1Qci的配置和传统交换机的ACL配置很不一样，最大的区别就是：**它几乎无法用一行show命令搞定，而是必须通过结构化数据模型来下发。**这就要提到TSN里绕不开的Netconf和YANG的组合。

3.1 Qci为什么离不开Netconf

TSN的协议配置有个共同特点：大量参数是互相作用的结构化数据。一个流过滤器需要同时引用门控实例、流计实例、匹配规则、淘汰策略，中间还有一堆枚举和引用关系。如果用CLI一条一条敲，不仅效率低，容易出错，而且很难做批量下发和审计。

Netconf协议的作用，就是用类似"数据库操作"的方式来管理网络设备。TSN标准组织（IEEE 802.1）为Qci定义了标准的YANG数据模型（ieee802-dot1q-psfp），设备厂商基于这个模型实现配置能力。Netconf提供四种核心操作：get（读取配置和状态）、edit-config（修改配置）、copy-config（整体替换配置）、delete-config（删除配置）。配合YANG模型，管理员可以像操作数据库一样精确管理Qci的各个表项。

简单理解：**CLI是"人往设备里写命令"，Netconf/YANG是"程序往设备里写数据结构"。**TSN这种动辄几十个流、每个流又带门控和流计的场景，结构化下发是唯一可行方案。

注意一点：Netconf传输层的默认端口是830（使用IETF标准分配），实际设备也支持自定义端口。配置Qci前，建议先用简单的hello报文握手测试设备是否支持对应YANG模型，通常厂商文档里会写清楚"支持IEEE 802.1 Qci YANG模型"。

3.2 一个完整的Qci配置示例

下面用一个简化的配置示例来说明。假设场景是：端口GE1/0/1，流A（Stream ID=100）需要限制在10Mbps以内，门控列表允许0ms-1ms和3ms-9ms放行，超量帧打黄色标记但不丢弃。

使用Netconf的edit-config操作下发（省略传输层细节，只展示配置内容核心结构）：

<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <psfp xmlns="urn:ieee:std:802.1Q:yang:ieee802-dot1q-psfp"> <stream-filters> <stream-filter-id>100</stream-filter-id> <stream-handle-ref>SF_100</stream-handle-ref> <gate> <gate-id>1</gate-id> </gate> <flow-meter-ref>FM_100</flow-meter-ref> </stream-filters> <stream-gate-instances> <gate-id>1</gate-id> <gate-enable>true</gate-enable> <gate-control-list> <gate-control-entry> <gate-operations>open</gate-operations> <time-interval>1000000</time-interval> </gate-control-entry> <gate-control-entry> <gate-operations>close</gate-operations> <time-interval>2000000</time-interval> </gate-control-entry> <gate-control-entry> <gate-operations>open</gate-operations> <time-interval>6000000</time-interval> </gate-control-entry> <gate-control-entry> <gate-operations>close</gate-operations> <time-interval>1000000</time-interval> </gate-control-entry> </gate-control-list> </stream-gate-instances> <flow-meters> <flow-meter-id>100</flow-meter-id> <committed-information-rate>10000000</committed-information-rate> <committed-burst-size>1000</committed-burst-size> <excess-information-rate>2000000</excess-information-rate> <excess-burst-size>500</excess-burst-size> <color-aware>false</color-aware> </flow-meters> <flow-classifier> <stream-id>100</stream-id> <destination-mac>00:11:22:33:44:55</destination-mac> <vlan-id>100</vlan-id> <priority>5</priority> </flow-classifier> </psfp> </config>

这个配置里，CIR=10000000（bit/s，即10Mbps），CBS=1000字节，EIR=2000000（bit/s，即2Mbps），EBS=500字节。这些参数的具体含义前面已经讲过了，就不重复。

有几个配置时的细节值得强调：

• time-interval的单位是纳秒，所以我上面写的1000000代表1ms。不同厂家的YANG模型可能对单位有不同的约定，配之前一定要确认，否则门控窗口会完全错位。我见过有人把单位搞混，把1ms写成了1000000us，导致整个门控列表周期直接缩短了1000倍。
• color-aware参数决定流计是否参考帧自带的服务等级颜色。如果设为true，那么帧必须已经携带IEEE 802.1ad里的DEI等颜色信息，流计会基于这个颜色做三色标记；如果设为false，流计只看自身的令牌桶状态做三色标记。绝大多数工业场景下，TSN流都是干净帧，不需要颜色感知，建议设为false，逻辑更清晰。
• gate-enable必须置true，否则门控列表不生效，相当于Qci被旁路了。这个配置项在有的厂商实现里默认是false，特别容易漏。

3.3 配置验证和状态查看

配置下发后，光看no error回车没用，需要验证流量是否真的被过滤了。Netconf提供了状态数据的获取能力：

<get xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <filter> <psfp-state xmlns="urn:ieee:std:802.1Q:yang:ieee802-dot1q-psfp"> <stream-filters> <stream-filter-id>100</stream-filter-id> <gate-drop-count></gate-drop-count> <flow-meter-pass-count></flow-meter-pass-count> <flow-meter-yellow-count></flow-meter-yellow-count> <flow-meter-red-count></flow-meter-red-count> </stream-filters> </psfp-state> </filter> </get>

这些计数器在调试阶段非常有用。我强烈建议大家在测试环境里把每个流过滤器的计数器摸清楚：gate-drop-count表示被门控丢弃的帧数，flow-meter-red-count表示被流计判红丢弃的帧数。通过对比这两个值，能快速判断当前是门控窗口的问题还是流计参数的问题。很多工程师配置完Qci后一测流量不对，就直接怀疑Qci没生效，其实先看一眼计数器就能缩小问题范围。

此外，TSN交换芯片的Netconf实现绝大多数都支持通过订阅通知（create-subscription）来接收告警，比如流计发生超限、门控丢弃过多时会上报一个notification事件。我实测下来，这个机制对运维监控特别有用。配合Prometheus等监控平台，甚至可以把Qci的drop计数做成面板，实时观察全网哪些端口、哪些流在被限流。

3.4 基于Linux tc的模拟验证

如果没有专业TSN交换机，想验证Qci的过滤逻辑也不是没有办法。Linux的tc工具（traffic control）虽然不能完整实现802.1Qci，但可以用类似机制模拟核心逻辑，至少能让你验证"入口限速+门控丢弃"这套思路。

我常用一个简化的模拟方法：用psfp相关的qdisc插件（部分Open Source项目实现了简化版PSFP），或者直接用tbf（token bucket filter）限速器模拟流计的部分行为，再用prio或etf（Earliest TxTime First）插件模拟门控窗口。命令类似：

# 在入口方向创建一个tbf限速器，限制为10Mbps，突发量为1000字节 tc qdisc add dev eth0 handle 1: root tbf rate 10mbit burst 1000 latency 10ms # 用netem模拟门控：在指定时间窗口丢弃50%的包（粗糙模拟） tc qdisc add dev eth0 parent 1:1 handle 2: netem loss 50% # 用iperf生成突发流量，观察限速效果 iperf3 -c 192.168.1.2 -u -b 50M -t 5

配合tc -s qdisc show dev eth0查看drop计数，就能直观看到流量被限制的效果。这个验证方法虽然不能完全复现802.1Qci的时序逻辑，但用来理解Qci的工作维度、参数敏感度，完全够用。

4. 802.1Qci在TSN整体架构中的正确位置：与Qbv和802.1CB的协同关系

前面提到过"Qci是入口守卫"，但要真正用好它，还需要看清楚它在整个TSN协议族里的位置，尤其和Qbv、802.1CB之间是怎么协同工作的。

4.1 协同定位：Qci在端口入口，Qbv在端口出口

在每一台TSN交换机的每个端口上，数据帧的完整路径大致是：

端口入口 → 802.1Qci（入端口过滤、门控、限速） → 交换矩阵（FDB查表/转发） → 出口队列 → 802.1Qbv（出端口门控调度） → 物理线路

Qci管的是"什么流量可以进入交换核心"，Qbv管的是"进入交换核心的流量在哪个时间片从出口发送"。两者不是在竞争，而是在分工。如果入口不管控，突发流量可能直接挤爆交换矩阵的内部FIFO或共享缓冲，这时候Qbv再怎么编排出口调度，也无济于事——因为关键帧可能已经在内部缓冲里排队排超时了。

4.2 802.1Qci如何保障802.1Qbv的调度精度

Qbv的调度表是静态配置的，它假设每个出口队列在每个时间片内只有"预期内"的流量需要发送。这个"预期内"不仅指流量的总带宽不超过链路带宽，更重要的是每个时间片内，需要通过该出口发送的流量总量不超过该时间片能发出的帧数。

如果缺乏Qci的入口限制，一旦某个流突然超量，其超量帧就会被交换机放到对应优先级的队列里。如果Qbv正好为这个队列安排了发送时隙，超量帧会占用宝贵的发送时隙；如果该队列门控是关闭的，超量帧就只能在队列里堆积，直到下一个周期开门时全部释放，造成时延尖峰和抖动。而有了Qci，在入口处就把超量部分丢弃或降级，Qbv调度的"输入环境"就是理想的。

这里有一个配置上的关键技巧：**Qci的门控周期必须与Qbv的周期保持一致，且相位对齐。**因为Qci和Qbv是两个不同的门控机制，如果它们的周期不一致（比如Qci是10ms循环，Qbv是8ms循环），那么两者之间很容易出现"Qci放行的帧在Qbv的关闭窗口"的情况——也就是Qci过了，Qbv关了，结果帧还是出不去。实际上，很多TSN交换芯片的实现中，Qci的gate control list和Qbv的gate control list是共享同一个周期计时器的，但有些芯片的实现比较独立，需要人为配置保证。我见过因为周期不一致导致吞吐量忽高忽低的案例，排查起来非常隐蔽。

4.3 与802.1CB帧复制消除的配合

TSN网络里，可靠性依赖于冗余，802.1CB（FRER，Frame Replication and Elimination for Reliability）负责把帧复制成多份走不同路径，再在接收端消除重复帧。FRER的工作方式是对帧序列号（Sequence Number）做连续性检查。

Qci对FRER的价值有两层：

• 第一层，防止异常流量污染序列号空间。如果一个端口收到了一个不受控的流，其数量和速率超过预期，这个流产生的帧序号序列就会在接收端的FRER逻辑中造成混乱，导致正常的冗余帧被误判为"序号跳跃"，丢失有效帧。
• 第二层，Qci的每流过滤会按照流ID识别帧，让FRER只需要处理合法的流实例。这样FRER的序列号匹配表不会被无效帧占据，查表效率和判定准确性都有保障。

在实施上，如果一个TSN网络同时部署了Qci和802.1CB，要注意流ID的定义必须在两者间保持一致。否则Qci认为这是一个流，CB认为那是另一个流，两者各管各的，会出现Qci已经丢弃了某些帧，但CB还在等待这些帧的序列号到达，产生误报。类似问题在跨厂商设备对接时特别容易发生，建议在方案设计阶段就统一流ID和Stream Handle的映射关系。

4.4 与CIP Sync和工业协议的典型联动

在工业领域，TSN最典型的应用场景之一就是EtherNet/IP的CIP Sync。CIP Sync依赖TSN提供微秒级的同步周期，同时在此基础上承载实时控制流量。这种场景下，Qci的典型配置是：

• 对同步相关的时间同步帧，按低速率高优先级配置，门控窗口与同步周期严格对齐；
• 对运动控制帧，按周期大小配置对应的CIR，只允许每个周期内传输一次；
• 对配置诊断类流量，限制总带宽，防止后台扫描操作影响实时流量。

实际项目中，我参与过的自动化生产线网络改造里，TSN交换机上一般会对两条不同业务配置不同的Qci策略：一条是"高速高可靠"的实时控制流，一条是"尽力而为"的参数上传/下载流。后者如果不加Qci，一旦某个设备在启动瞬间同时访问后台服务器，成百上千个数据包同时涌入网络，立刻会挤占前者所需的带宽和时间窗口。配置好Qci后，这种业务突发就被限制在1Mbps以内，对控制流完全无感。

所以，Qci在TSN系统里的定位，核心可以概括为八个字：剔除非预期，保住预期流。

5. 实战避坑指南：那些文档里不会写的坑和调试经验

文章写到最后，分享一些我在实际调测中遇到的坑和积累的经验。这些内容在IEEE标准文本和厂商白皮书里基本看不到，但对真正把Qci用起来非常关键。

5.1 坑一：门控列表的更新与切换，不是即时的

Qci的门控列表是可以动态更新的，但更新后的列表并不会在下一秒立刻生效。标准要求门控列表的激活时间必须与门控相关的控制周期对齐。换句话说，你下发一个新门控列表之后，交换芯片必须等到当前循环的某个特定时间点（通常是一个周期的起始点）才会加载新的列表。

如果一个人忽略了这一点，在下发配置后马上打流测试，很可能会看到两个周期的"旧配置仍然生效"的现象。这不是bug，而是标准里明确的行为。调试时建议主动设置一个激活时间参数（部分YANG模型里有adminGateState、configChangeTime之类的字段），并确保它离当前时刻足够远，让所有设备都有时间在下个周期前完成切换。

还有一点，部分芯片在门控列表切换的瞬间，会有一个极短的窗口内既不执行旧列表也不执行新列表，此时帧可能被丢弃，造成偶发的掉包。如果业务对丢包零容忍，建议在配置变更窗口内暂停测试流量，等列表稳定后再恢复。

5.2 坑二：流计的CBS配置过小导致"误杀"正常流量

这是我踩过最深的坑。配置流计时，大家天然关注CIR，因为"限速"嘛，直接把CIR设成业务带宽就行。但实际上，CBS才是最容易出问题的地方。

TSN里很多控制流是周期性突发的。比如一个周期内，应用层一次性向网络发送了多个帧——这些帧到达交换机的瞬间，瞬时速率可能远高于长期平均速率。CBS就是为这种瞬时突发准备的。如果你把CBS设置成几十个字节，那这些正常突发帧会被流计标记为红色或黄色，然后被丢弃或降级。表面上看是"限速生效"，实际上是在误杀正常业务。

我的经验是：CBS至少要为"一个周期内的最大突发字节数"的两倍，再留20%~30%的余量。比如一个10ms周期内，某个流一次性突发2000字节，CBS可以起步设置为4000~5000字节。留足余量之后，再观察实际流量是否触发黄色标记，逐步收紧，而不是一步到位。这是典型的"先松后紧、逐步逼进"的调优方法。

5.3 坑三：观察模式的强力用途

前面提到过Observe策略，但这里特别想强调它的实战价值。

我在一个项目里给某个TSN交换机配置Qci时，刚开始完全没有头绪：不知道这个流实际会有多大的突发量、什么时间分布。如果直接配一个严格的Discard规则，上线后一旦误杀，整个产线直接停机，风险太高。

我的做法是分两步走：

1. 先用Observe模式观察一周，通过Qci的计数器看每个流的通过率、丢弃率、黄色标记次数。这一周里，后台数据会告诉你：流的最大速率是多少、突发量多大、有没有周期性的尖峰。
2. 根据观察数据计算CIR和CBS，再切换到实际限制模式。同时盯着计数器，确认限制策略生效后，再正式收尾。

**Observe模式等于给了你一双"透视眼"，把网络里看不见的流量行为摸清楚，然后有的放矢地制定策略。**这是我强烈推荐大家使用的部署方式，尤其是生产网络改造的场景。

5.4 坑四：硬件资源有限，流过滤器不是无限多

Qci的流过滤器依赖交换芯片的TCAM或精确匹配表项来存储匹配规则。这类硬件表项在业界是稀缺资源——一款中端TSN交换芯片可能只有几百条Qci规则表项，高端芯片也只有几千条。

所以设计Qci策略时，一定要做好"聚合"。不是每个业务流都要单独建一条流过滤器，可以使用Stream Handle机制将多个行为相似的流映射到同一个处理策略。比如10台设备都属于同一类控制流量，可以合并成一个流句柄，共享同一套门控和流计，这样10条规则占用的硬件表项从10条降到1条。配置优化前的规划远好过配置后的打补丁。

另外，各厂家的计数器资源也是有限的。如果每个流都开启完整的统计计数，后续其他功能（如802.1CB的序列号统计）可能不够用。优先给关键业务流开统计，其他流能用简单的pass/discard就不开计数器。

5.5 Qci与芯片实现：国产厂商的支持情况

聊一下TSN芯片层面的现状。目前国内已经有多家厂商推出了TSN交换芯片和TSN IP核，整体进度比前几年快了不少。

在Qci支持方面，国产芯片的现状可以分两类：一类是完全自主设计，在硬件上已经包含Qci相关的门控、流计逻辑，支持802.1Qci标准流量条目；另一类是基于以太网交换IP核进行二次开发，Qci是作为转发逻辑的一部分实现的，通常支持流过滤和门控，但流计的精度和条目数可能弱于国际头部厂商。总体趋势是好的，国产TSN芯片正在从"支持基本协议"向"全线支持TSN协议族+大规格表现"进化。

如果你在做国产化替代方案，建议重点关注这几项：

• 门控时间精度：是否能到纳秒级执行、时间同步的最小粒度是多少；
• 流计粒度：CIR的最小步进值是否能满足实际低速业务（比如100kbps）；
• 并发流数：同时支持多少个流过滤条目；
• Netconf/YANG支持：是否实现了标准Qci YANG模型，还是私有MIB。

这些参数直接决定了Qci策略能不能按需要配置出来，建议在选型时让芯片厂商提供规格书逐项核对。

5.6 调测Web验证技巧

最后补充一个快速验证Qci是否生效的小技巧：用流量发生器打一个定向流，对比加不加Qci的吞吐量和延迟抖动。

• 先用每分钟Iperf或者专业的流量测试仪，以2倍于CIR的速率打流到被测端口；
• 观察Qci计数器：gate-drop-count和flow-meter-red-count都应该增长；
• 关闭Qci策略，以相同速率再次打流，确认此时流量能完全通过；
• 两次对比，如果数据正常，说明Qci的过滤和限速路径都在正常工作。

如果Qci计数器没有增长，但实际流量已经受影响，那说明问题可能不在Qci，而在Qbv的出口门控——这时候你要去检查出口方向上Qbv门控列表配置，而不是继续在入口方向上查。"入口看Qci计数器，出口看Qbv队列状态"，这是排查TSN流量异常的高效路径。

写了这么多，Qci这套协议的逻辑其实非常清晰：**每一项TSN能力都不是孤立存在的，Qci保护的既是Qbv的调度精度，也是整个网络确定性的底线。**如果让我给正在做TSN方案的人一句实在话，那就是：别急着把Qci的所有参数一步配到位，先用Observe模式看几天数据，理解你的网络里真实的流量行为，再逐步收紧策略——用观察换确定性，这是我在多个项目里验证过的最稳路径。