以为载波监听拖累了实时性？以太网实时性差的真正原因在这里

大家好，我是bug菌~

最近跟同事聊到为什么现在的以太网还是够不上实时以太网呢？其中有个同事说了下主要是因为载波监听机制，导致发送的以太网数据存在碰撞，于是我又想了想，不对呀，现在不都是用交换机吗？交换机都是直接转发的，也没有什么碰撞呀，于是探究了一下。

1. 载波监听那些事儿

首先我们来聊一下什么是网络中的载波监听机制，其实全称也叫 “载波监听多路访问/冲突检测” ，别说真的挺长的，英文缩写为: CSMA/CD。

CSMA/CD 其实是以太网的核心媒体访问控制协议，它就是用来解决: 当多个设备共享同一根线缆（或集线器）时，如何协调发送，以及发生冲突后如何恢复。

它的工作流程总结下来就是: 先听后说，边听边说；冲突则停，随机重传。

先载波监听，检测线路上是否有其他设备在发送，空闲了才发送；由于存在发送延时和信号传播存在延迟，两台设备可能几乎同时开始发送，导致信号在线路上叠加、破坏，这就是冲突。冲突发生后，等待一段随机时间后重新尝试发送，当然这中间还有一些退避算法，避免反复碰撞死锁。

载波监听只能防止自己撞别人，不能防止别人撞自己。 这就是著名的 “暴露站问题” ：你听着没声音开始发，但如果远处另一个节点也在同一时刻听着没声音开始发，信号传播到中间时还是会撞上。

2. 交换机如何消灭冲突

其实 CSMA/CD 主要在集线器的半双工时代做贡献。当我们进入廉价的交换机时代，交换机从两个层面优化了这个过程：

首先，交换机每个端口都是一个独立的冲突域。不像集线器会把信号复制给所有端口，交换机解析帧里的目标 MAC 地址，只向对应端口转发。这就好比把“大群对讲机”拆成了“交换机居中，每个人跟交换机之间是一根专线”。端口 A 给端口 B 发数据时，端口 C 和 D 完全不受影响，多个端口对可以同时通信，互不干扰。

其次，交换机端口通常工作在全双工模式，而且有缓存。物理上收发分开：网线里的发送线对和接收线对是独立的，设备可以在发的同时也收，不需要像对讲机那样“按下去就聋了”。缓存代替冲突解决：如果多个端口同时要向同一个目标端口发数据，交换机会把后来的帧暂时缓存起来，排队转发。数据不会在介质上撞成一团，只是多等一会儿。

于是，既没有信号碰撞，也不需要在发之前侦听信道有没有人，更不用“发中检测冲突”。于是，CSMA/CD 的两大任务—— “先听后说”和“碰撞检测” ——全都不需要了。协议虽然还在，但实际物理层上已经不用它了。

可能你会问，如果我不用交换机，两根网线直连会不会触发 CSMA/CD？在现代网卡直连即使没有交换机的情况下，通常不会触发载波监听（CSMA/CD），因为链路会工作在全双工模式。载波监听只在半双工模式下才会激活。 而且全双工交换式以太网中网卡不再需要靠载波监听来避免冲突，但载波监听电路仍然工作，解决的是“物理链路是否可用”，而不是冲突。

3. 那为什么还不是实时网络？

既然交换机把路径都拉顺了，为什么现在的以太网还是不能成为实时以太网呢？

交换机的本质是“存储-转发”，遇到多个入口同时想往同一个出口发帧，就会排队。就是这一排队，实时性就没了。

比如说你在交换机端口1，想给端口8发一个控制指令帧，只有一帧，非常小，你觉的应该很快就能够到达目的地。可是刚巧，与此同时，端口2、端口3正在往端口8发满带宽的巨型文件——它们先到达输出队列。

你的小指令帧就只能乖乖排在后面，等前面的帧发完。而这个等待时间，取决于当时其他端口的流量，而那些流量可能是突发的、不可预测的；队列可能深可能浅，有的还有优先级，但标准以太网的优先级只是“尽力而为”，不能给你硬性保障。

于是：这一帧的延迟是不可预知的，时大时小，最坏情况可能是几十甚至上百毫秒。对工业运动控制等场景来说，这已经失效了——它要的是“每 1ms 必达，抖动小于 1μs”。

当然如果你的场景是小数据、局域网、低负载 + UDP，经过合理的实时性调优（实时内核、核隔离、中断绑定等），也不是不可以实现可靠的 1 ms 周期通信。

总的来说，在没有任何改造的标准交换式以太网下，那确实很难达到硬实时。所以才有了 TSN 及各种工业实时以太网协议。

• 标准的 TSN（时间敏感网络）：在标准以太网上增加时间同步(802.1AS)、门控调度(802.1Qbv)、帧抢占(802.1Qbu)、流预留(802.1Qav)等，把排队变得可预测且可调度。
• 大名鼎鼎的 EtherCAT：虽然物理层用标准以太网，但数据帧处理机制完全改变，从站“飞速”读取/插入数据，根本没有传统交换机的存储转发排队。
• 西门子的 PROFINET IRT：在交换周期中划分实时通道和开放通道，对实时帧用 TDMA 方式调度，确保没有排队干扰。

好了，今天就跟大家分享这么多了，如果你觉得有所收获，一定记得点个赞~