波仔
📡 第二章 彻底理解L2交换机
📄 一句话概括

三种转发方式，差的不只是速度，是「什么时候做决定」。 直通在收到地址时就决定，存储转发在收完最后一字节才决定。

📝 本节和前面几节的关系

上一节讲帧长什么样，这一节讲交换机怎么处理它。 02.02.02 讲这三种方式的来历，这一节把它们放到不同帧长与速率下比一比。

一、决定的时机不同

直通：读到目的 MAC（第 6 字节）就能查表，立刻开始往外发。这一帧后面还有没有错，它不管。 无碎片：先收满 64 字节。这个长度保证不会转发碰撞碎片，但 CRC 错误照样会漏过去。 存储转发：整帧收完、算 CRC、比对，全对才转发。

所以三者的差别本质是「用多少延迟换多少正确性」。这不是技术优劣，是一个设计取舍。

二、换帧长结论就变

直通的延迟与帧长无关：恒定的「读 14 字节」时间，千兆上 0.11 微秒。

存储转发的延迟与帧长成正比：64 字节 0.51 微秒，1518 字节 12.14 微秒。差了 24 倍。

所以「直通更快」这个说法只在长帧下成立。64 字节短帧时两者是同一量级； 1518 字节长帧时差 100 多倍。

三、实际设备怎么选

绝大多数设备默认存储转发，而且不提供直通选项。原因很简单：便宜、安全。

提供直通的设备通常三种模式都支持，可以按端口配。 比如「接服务器的口用直通、接终端的口用存储转发」。

判断设备有没有阻塞比选转发方式更重要：一台「有阻塞」的交换机， 转发方式再快也没用——瓶颈在背板。

四、动手 Demo：同一做法下帧长变长，延迟怎么涨

这段按千兆口算，五个帧长过三种转发方式。重点看直通那一列是常数，存储转发那一列随帧长线性涨。

for sz in sizes:
    t_cut = 14 * 8 / 1000e6 * 1e6
    t_frag = min(64, sz) * 8 / 1000e6 * 1e6
    t_sf = sz * 8 / 1000e6 * 1e6
    T([u"%d 字节" % sz, u"%.2f 微秒" % t_cut,
       u"%.2f 微秒" % t_frag, u"%.2f 微秒" % t_sf], [0, 0, 1, 1])

实跑输出：

--------------------------------------------------------------------
三种转发方式，换个帧长结论就变
--------------------------------------------------------------------
**上一节比的是「同一帧长下三种做法」。这一节换个维度：同一做法下，帧长变长会怎样。**

  帧长          直通 14 字节     无碎片 64 字节     存储转发 整帧
  -------------------------------------------------------------------
  64 字节       0.11 微秒        0.51 微秒          0.51 微秒
  128 字节      0.11 微秒        0.51 微秒          1.02 微秒
  512 字节      0.11 微秒        0.51 微秒          4.10 微秒
  1024 字节     0.11 微秒        0.51 微秒          8.19 微秒
  1518 字节     0.11 微秒        0.51 微秒          12.14 微秒

**这张表按千兆口算。**看清一件事：
**直通的延迟与帧长无关（恒定 0.11 微秒），存储转发的延迟与帧长成正比。**

**所以「直通更快」这个说法只在长帧下成立。**64 字节短帧时，存储转发只要 0.51 微秒，
跟直通的 0.11 微秒是同一个量级；
1518 字节长帧时，存储转发要 12.14 微秒，直通还是 0.11 微秒，差了 100 多倍。

**这也解释了为什么高性能交易场景偏爱直通**：金融行情这类流量全是小包，
但要的是「恒定低延迟」而不是「平均低延迟」；
而大文件传输场景里直通几乎没优势，反而白担一个「可能转发坏帧」的风险。

**还有一条实践中的坑**：直通要求「出端口和入端口速率相同」。
10G 口进、1G 口出时，缓存必然堆积，
只能退回存储转发——**所以很多设备写「支持直通」但只限同速率端口之间。**

第一列全是 0.11 微秒——这就是「与帧长无关」的意思。 第四列从 0.51 涨到 12.14，涨了 24 倍——这就是「成正比」。

中间那一列要注意：64 字节以下时它等于存储转发（因为要收满 64），64 字节以上它就固定了。 它是「存储转发」与「直通」的一个折中档。

最后一行 1518 字节的 12.14 微秒，这个数字在实际中会更大——因为还有查表、排队、总线仲裁的时间。 规格书上的「转发延迟」通常指的就是这整条路径。

30 秒实验

  1. 查一台交换机的「转发延迟」参数，看它写多少微秒。
  2. 想一想你的业务里最大帧是多少字节（MTU 多少）。
  3. 抓一个 1518 字节的包，数一下它从进到出过了多久。

常见误区

  1. 以为直通永远快 100 倍。短帧时差不多。
  2. 以为存储转发没用。它是今天的默认。
  3. 以为转发延迟是固定值。随帧长与排队情况变化。
自测三问（点开对答案） 1. 三种转发方式各在什么时候做决定？ —— 直通读到目的 MAC、无碎片收满 64 字节、存储转发收完整帧并校验。 2. 为什么直通的延迟与帧长无关？ —— 它只需读固定 14 字节的帧头就开始转发。 3. 1518 字节帧在千兆口上，存储转发要多久？ —— 约 12.14 微秒，是 64 字节帧的 24 倍。

下一节：坏帧多的时候设备会自己换策略——自适应交换。

相关笔记