解决什么问题
TSN 解决的不是“网络能不能通”，而是“关键流量能不能在可接受边界内持续到达”。这句话里有三个关键词：关键流量、边界、持续。
关键流量不是所有流量，而是控制闭环、传感器上报、同步音视频、车载控制消息等对时间敏感的流。边界不是平均值，而是最坏情况延迟、抖动范围、丢包或故障恢复时间。持续意味着这个结论不能只在一次演示里成立，而要能在背景流量、设备负载和故障扰动下仍然被解释。
普通以太网没有错。它的优势是开放、便宜、吞吐高、生态成熟。但它默认提供的是 best effort 服务，不会天然为某条流承诺“最晚什么时候到”。当工业现场、车载网络或专业音视频系统希望把多类业务放进同一张以太网时，问题就出现了：普通流量可以等，关键流量不能无限等；普通业务可以追求吞吐，关键业务更在意节拍稳定。
背景与直觉
你可以把网络看成一组共享资源：链路时间、交换机队列、缓存、端口调度机会和故障恢复路径。普通以太网让这些资源按局部规则竞争，TSN 则试图在关键流量上提前规划这些资源。
这也是为什么 TSN 总是由一组能力构成。仅靠优先级不够，因为高优先级仍可能等待已经发送的大帧。仅靠时间同步不够，因为有了共同时间还需要知道什么时候放行哪个队列。仅靠冗余不够，因为复制两份不代表两份都会准时。每个能力只解决问题空间的一部分。
怎么解决
TSN 的解法可以抽象成四步。
第一步是识别关键流量，知道要保护哪条流，周期、帧长、截止时间和路径是什么。没有这个输入，后面的调度、整形和验证都会缺少对象。
第二步是控制竞争，让关键流量在队列、带宽或时间窗口上获得明确资源。这里会用到 traffic class、CBS、Qbv、帧抢占等能力。
第三步是处理失败，让链路或设备故障不至于立刻打断关键业务。FRER 这类机制解决的是连续性，但它也会增加带宽和调度复杂度。
第四步是验证证据，用抓包、时间戳、配置快照和统计结果证明设计真的成立。没有证据，确定性只是设计意图。
| 问题 | TSN 需要补上的东西 | 后续章节 |
|---|---|---|
| 关键帧什么时候发 | 共同时间和时间窗口 | 802.1AS, 802.1Qbv |
| 关键帧和普通帧怎么竞争 | 队列、整形、抢占 | 802.1Q, CBS, 802.1Qbu |
| 配置如何跨路径一致 | 流级配置和 admission | 802.1Qcc |
| 故障时是否连续 | 复制、路径多样性、消除 | 802.1CB / FRER |
| 结论如何证明 | 测量、分析、报告 | 验证章节 |
带来了什么新问题
一旦你要求边界，就必须付出代价。调度需要准确的流量描述；窗口需要消耗链路利用率；冗余会增加带宽占用；集中配置会增加系统复杂度；验证需要更严格的测试方法。TSN 的工程难点不是某个开关怎么打开，而是多个能力组合后是否仍然一致。
所以学习 TSN 时不要只问“标准支持什么功能”，还要问“这个功能把不确定性转移到了哪里”。很多机制把运行时的不确定性转移成配置时的复杂性，这正是后续高级主题会继续研究调度算法、资源分配和验证方法的原因。
检查点
- 给定一个 1ms 周期控制流，你需要向应用或设备侧追问哪些字段，才能开始讨论 TSN 保护？
- 为什么“这条流平均 80us 到达”不能证明它满足 200us deadline？