交换芯片转发模式深度解析：Cut-through与Store-and-forward的工程权衡

聊到交换芯片，不管你研究的是数据中心核心交换机、白盒交换机，还是带交换功能的网卡，绕不开一对老冤家：Cut-through（直通转发）和 Store-and-forward（存储转发）。这俩概念在交换芯片的数据面上，属于“最古老也最重要”的取舍。很多人一听到这两个词，就以为只是延迟大小的问题——直通快，存储慢，选完就完了。但真正在项目里调过芯片、看过转发寄存器、盯过交换机链路的人会告诉你，这里面的门道远不止一个“快”字。

这篇文章我打算从转发原理、芯片内部实现、真实场景选型、常见坑和实操配置几个角度，把一个项目里最容易被忽略，但影响面特别大的“转发模式选择”问题讲透。适合做网络设备、交换机研发、数据中心网络运维，或者研究DPU、智能网卡的朋友参考。哪怕你只是个刚入门做交换机测试的新人，只要把文章里的计算和场景对应起来，也能在选型时说得出“为什么”，而不是只知道“谁快谁慢”。

1. 这题目为什么值得重新翻出来讲一遍

1.1 两个词背后，是整个交换数据面的地基

先别急着对比参数。Cut-through 和 Store-and-forward 这两个模式的本质，不是某个厂商的“独门绝技”，而是一个交换节点在收到帧之后，到底要等多久才开始向出端口发送。这个“等多久”直接决定了交换机需要多少缓冲，决定了它能多大程度容忍坏帧，也决定了它在拥塞时的行为，甚至会影响你整个网络的延迟预算。

很多做网络的人对这两种模式的理解停留在教材层面：Cut-through 是收到帧头就转发，Store-and-forward 是收完整帧再转发。这么说没错，但真实交换芯片里，数据包在芯片内部经过的不只是一根“直通管道”，而是要过解析、查表、切cell、排队、调度这些流水线。芯片里有没有“完整的一个帧”这个概念，跟你从外部看交换机的延迟、丢包行为，经常是两回事。

另外一个关键背景是，现在高速交换芯片和DPU的转发延迟已经做到很低了，动不动就是几百纳秒到一微秒这个量级。在这个量级上，转发模式引起的差异不再是“选哪个都无所谓”的细节，而是可能决定你RoCEv2集群是否拥塞、存储链路是否存在微突发丢包的关键参数。所以才值得把这老生常谈的话题拿出来，认认真真把原理和细节都拆一遍。

1.2 别再被“新旧”误导：两种模式不是淘汰关系，是取舍关系

我遇到过不少刚入行的朋友，以为 Cut-through 是“更先进”的技术，Store-and-forward 是“老掉牙”的实现。这个误解很危险。实际上，几乎所有高端交换芯片在内部设计时都以“缓存并调度”为核心，因为交换芯片本质上是一个多入多出的排队系统。真正无缓冲的纯直通，在现代Crossbar交换芯片里是无法单独存在的。

另一种误解是觉得 Store-and-forward 一定更可靠，所以平时无脑选它就行。可一旦你面对的是AI训练集群这种延迟敏感场景，Store-and-forward 引入的固定延迟会实打实吃掉你的性能余量。真实工程里的答案往往是：转发模式不是“非此即彼”，而要看端口速率、帧长度分布、链路误码率和业务对完整性/延迟的要求，综合做选择。

这也正是这篇文章想讲的：把两种模式的技术本质讲清楚，把常见场景下“为什么这么选”讲明白，再把实际项目里需要留意的细节和经验分享出来。最后你会得到一个自己的判断体系，而不是一套死记硬背的结论。

2. 先讲清楚原理：Cut-through 和 Store-and-forward 到底差在哪

2.1 Store-and-forward：老老实实把一帧存完再走

Store-and-forward，翻译过来就是“存储再转发”。一个帧从入端口进来，芯片需要先把整帧都写入缓冲，等到帧尾到达，并且完成FCS（帧校验序列）校验之后，才会把这个帧投递给出端口的排队调度器，再从出端口发出去。

这里有个很重要的点：如果入端口收到的帧是一个坏帧——比如CRC计算错误、帧长度小于64字节、帧长度超过标准上限、或者FCS直接校验失败——Store-and-forward 会在入口处直接把这个帧丢弃。这也是它最大的优势：它保证交换机转发出去的每一个帧，都是通过了完整性校验的“干净”帧。坏帧不会污染下游链路，也不会浪费下游设备的处理能力。

代价自然是延迟。Store-and-forward 的最小转发延迟至少等于“完整接收一个帧所需的时间 + 内部处理时间 + 从出端口完整发送一个帧所需的时间”。我后面会用一个具体计算例子来说明这个数字有多大。你只需要记住一个结论：帧越长，Store-and-forward 的延迟就越明显。

2.2 Cut-through：看到目的地址就“冲”出去

Cut-through 的思路完全不同。芯片收到帧之后，不需要等完整的一帧，只要解析到足够做转发决策的信息，一般是目的MAC地址（前14字节左右），就能立刻把已经收到的部分往出端口送。数据边到边在交换机里“流动”起来，而不是“停下来再启动”。

这等于把一个帧原本需要完整接收后才能发出的等待，压缩到“只等一个帧头”，省下了绝大部分帧体传输时间。所以从理论极限上看，无论帧多大，Cut-through 带来的帧头到帧头延迟通常都在几百纳秒到一微秒级别。对大型帧而言，这比 Store-and-forward 能省下一微秒甚至更多的时间。

但代价也很明确：Cut-through 在转发时根本不知道这个帧的FCS是否正确，因为FCS在帧尾。如果入端口收到了一个坏帧，Cut-through 交换机照样会把这个坏帧转发出去了。坏帧不但没被过滤，还会继续消耗下一跳网络的带宽和缓冲。如果网络里所有设备都是 Cut-through，一个坏帧就可能一路被传播到终端，整段链路上所有设备都为它做了无效转发。

2.3 Fragment-free 和其他折中方案

老工程师应该都听说过还有一个折中方案叫 Fragment-free，也叫 Modified Cut-through。这种模式要求交换机至少先接收前64字节再开始转发。

为什么是64字节？因为以太网最小的合法帧长度是64字节。之前讲过碰撞碎帧（runt frame），也就是冲突或电气干扰导致的小于64字节的帧，几乎都是错误帧。Fragment-free 等收到64字节之后，基本可以排除碰撞碎帧和大部分短帧错误，然后再按 Cut-through 的思路转发。它能过滤掉一类常见的错误帧，又不需要像 Store-and-forward 那样等完整帧到齐，算是一个中间档。

当然，这个折中也有它的尴尬之处。现在高速链路上，真正的错误帧来源已经不是CSMA/CD时代的碰撞碎帧，而是物理层的误码、光模块信号劣化、链路抖动引起的FCS错误。这类错误经常出现在帧的中间或尾部，只看前64字节根本无法察觉。所以Fragment-free在今天的意义更多是延续下来的兼容模式，实际芯片默认支持得不多，工程上也更少见。

2.4 一个小计算示例：同样64字节与1518字节，延迟差多少

讲一堆概念不如算一笔账。假设一个10Gbps端口，一个64字节的最小以太网帧，线上传输时间大约是：

64 × 8 / 10，000，000，000 = 51.2ns

如果按Store-and-forward，入口至少完整收完一个64字节帧需要51.2ns，出口发完这个帧又需要51.2ns，再加上芯片内部的查表和排队时间，单跳延迟很容易到300ns~500ns。而Cut-through只需要等到接收目的MAC后的第14字节才开始转发，等待时间大约为14 × 8 / 10Gbps = 11.2ns，加上芯片内部查找转发的时间，单跳延迟可以压在200ns以内。

再看1518字节的标准大帧。线上传输时间大约是：

1518 × 8 / 10，000，000，000 = 1.2144μs

Store-and-forward 入口收完就需要1.2144μs，出口再发出去又是1.2144μs，加一起光“收加发”就是2.4μs以上。如果链路还有排队或跨背板调度，单跳延迟上3微秒非常正常。Cut-through 则几乎不受帧长度影响，只要目的MAC到了，芯片就一路把后续字节往出口送，单跳延迟可能只有1微秒甚至更低。

这就解释了为什么Cut-through在存储网络、HPC、AI训练集群里这么受欢迎。因为这些场景里大帧、长消息很常见，Store-and-forward 每跳多出的那一两微秒，在多级交换网络里会被累计放大。而Cut-through的大帧优势，恰恰是很多人没意识到的重点。

3. 交换芯片实现层面的真实面貌

3.1 芯片内部不是一整块“存储”，是cell流水线

理论讲完了，回到芯片内部。很多非芯片背景的朋友会以为Cut-through意味着帧可以从入端口一路“穿”过交换芯片到出端口。实际上，现代交换芯片内部几乎都是先把数据切割成固定长度的cell（比如64字节或128字节一个cell），再通过Crossbar或者共享内存进行交换。

这带来一个很有意思的工程问题：一个1518字节的帧会被拆成十几个cell。如果你是做纯Store-and-forward，可以等所有cell都进入共享内存，组成完整帧后，再向出端口调度。但如果你要做Cut-through，就要允许第一cell到达后，芯片在查表完成的同时，立刻把cell投递到出端口的队列中。后面到达的cell依次跟着走。

所以，Cut-through真正考验的是芯片的流水线设计：头部解析要在最短时间内完成，查表结果要能立刻绑定到数据流上，后续cell不需要重新查表，直接沿着已经建立好的内部路径走。任何一个环节有等待，都会破坏“直通”的效果。这就是为什么老款芯片虽然也标称支持Cut-through，但实测延迟依然很高，因为它的流水线不够快，等它查完表，帧体都收了一大半了。

3.2 端口速率不匹配时到底发生了什么

这里有个很容易踩坑的细节：Cut-through不是在所有端口速率组合下都能生效。

假设一个千兆口收到数据，要转到一个万兆口发出。千兆口收帧的速度比万兆口发帧的速度慢，理论上只要入口到了足够多的字节，出口就可以立即开始发送，所以这种“低速进高速出”的场景，Cut-through反而比较好办。反过来，万兆口收到数据，要转到千兆口发出，情况就麻烦了。入端口已经在以10Gbps的速度把帧灌进来了，出口却只能按1Gbps发送。你不可能做到“边收边发还能控制速率”，因为数据生产速度大于消费速度。

这种情况下，芯片必须把完整一帧先缓冲下来，否则无法平滑地向低速端口发送。于是Cut-through自动“退化成”Store-and-forward行为。这不是故障，而是物理速率不匹配的必然结果。所以当你规划一个跨速率网络时，别指望Cut-through能带来全链路的直通延迟收益，数据到了跨速率端口，就不得不排队缓冲。

3.3 出口拥塞时“cut-through”还是会退化成排队

另一个让很多人困惑的问题是：为什么我开了Cut-through，延迟还是不稳定？这往往是因为出端口拥塞。

Cut-through省的是“入口等待帧收完”的时间，但它省不掉“出口排队”的时间。如果一个出端口被多个入端口同时访问，帧到出端口后还是要排队。出口队列一旦非空，后面来的帧就必须等待前面的帧发送完毕，此时表现在外部延迟上，基本上跟Store-and-forward没有太大差别。

所以，Cut-through的真实收益是“无拥塞或低拥塞路径上的确定性低延迟”，而不是拥塞场景下的救世主。如果网络里经常出现瞬时拥塞，你的延迟大头就不在转发模式上，而在流量管理和调度算法上。这也是为什么很多交换芯片虽然支持Cut-through，但默认不敢全端口开启，因为一旦出口拥塞严重，功能优势发挥不出来，反而可能让出端口的缓冲管理更复杂。

4. 什么场景适合哪一边：这是工程权衡，不是二选一

4.1 延迟敏感的HPC/AI/存储网络：Cut-through的舒适区

现在最典型的Cut-through拥护者，就是高性能计算、AI训练集群和分布式存储网络。这类网络对单跳延迟极其敏感，尤其当业务是RDMA或者NVMe-oF这类远程内存访问协议时，一次数据读取要在多个交换机之间往返。每跳多一微秒，一次操作可能就多出几微秒，累积到整个训练任务或存储基准测试上，时间的增长非常可观察。

AI训练集群里有个特点，消息大头通常是几十KB甚至几百KB的聚合通信数据。大帧走Store-and-forward时即使每跳多个几百纳秒，也会被几十跳放大成几十微秒。而Cut-through在大帧上优势最大，反而和这些场景完美匹配。再加上RoCEv2这类协议本身就是低延迟设计，如果交换层再用Store-and-forward，等于在端到端延迟预算里白白送掉了一个大块利润。

所以，只要链路误码率可控，业务对完整性又依赖上层协议重传或端到端校验，Cut-through就是这些场景的优先选择。实际中我也看到不少厂商的AI集群方案尽可能让网络层级少，同时在转发模式上开启低延迟模式，目的都是把每一跳的固定开销压到最低。

4.2 数据完整性要求高的企业/云网：Store-and-forward的主场

反过来，很多传统企业网络和云网络仍然更倾向于Store-and-forward，或者至少不敢全局放开Cut-through。原因是这些网络里对“坏帧传播”的容忍度很低。尤其是那些长距离、跨机房、经过多级光模块和铜缆的链路，误码率相对数据中心内部要高一些。出现FCS错误帧时，如果交换机用Cut-through把它直接转发出去，坏帧不仅浪费带宽，还会让下游设备产生不必要的处理开销，干扰正常运行。

另外，企业网络里的流量有明显的南北向特征，南北向流量经常经过软件转发、安全过滤、ACL、路由策略等环节，这些环节本身就要求帧被完整处理。与其在一部分链路上做Cut-through，一部分做Store-and-forward，不如统一采用Store-and-forward，换来的是行为可预测、排查简单。对运维团队来说，减少不确定性往往比省那一点延迟更值钱。

4.3 L2交换与L3路由的微妙区别

还有一点必须提，就是L2交换和L3路由对转发模式的影响不同。L2交换在转发以太网帧时，目的MAC查表完成后，理论上不修改帧内容，所以Cut-through容易实现。但L3路由在转发IP报文时，通常要修改以太网头：源MAC/目的MAC会变，TTL会减1，Checksum会重算。要做这些修改，你必须先把帧前面足够多的字段都收下来，改好之后才能向出端口发送。

这意味着纯Cut-through在L3转发场景里并不像L2那么顺畅。很多芯片实现L3转发时，即使数据面很快，也会在“头部重写”环节先缓存到一定长度，等头部重新封装完成后再开始发。这本质上是介于Cut-through和Store-and-forward之间的“头部截断式转发”。如果你在做跨VLAN路由或IP转发，别指望它能达到纯L2 Cut-through那样极致的低延迟。

5. 实际配置和选型手册

5.1 大多数交换设备默认是什么模式

首先要明确一个事实：绝大多数交换机出厂默认是Store-and-forward，而且很多中低端交换芯片根本不开放Cut-through选项。为什么？因为关闭Cut-through对大多数通用场景更安全，也降低了厂家在误码、异常帧处理上的支持成本。

但高端交换芯片、数据中心交换机、DPU和智能网卡里，这个选项通常是被开放的，只是默认策略偏保守。比如你拿到一台白盒交换机，用SONiC或者商业NOS，可能在转发表面上看不出来“Cut-through”这个词，而是一个叫“延迟模式”或“流水线加速”的开关。当然也有些设备厂商直接把它暴露成端口级或系统级的转发模式配置。

我自己的经验是先别急着改配置，而是确认你这台设备的芯片型号和规格。芯片是否真的支持Cut-through，支持的范围是L2单播、还是也支持多播和VXLAN封装，差别非常大。很多设备厂家表面开放了开关，但因为某些特性（比如ACL、VLAN翻译、隧道封装）强制要求Store-and-forward，实际开启后根本没有任何效果。

5.2 通用CLI与开放网络设备怎么调

不同厂商的命令差异很大。以常见的网络设备为例，有些会提供类似这样的开关：

switch(config)# forwarding-mode cut-through switch(config)# interface ethernet1/1 switch(config-if)# forwarding-mode cut-through

注意这不是某一家设备的固定命令，而是一个示意。关键是理解配置目标：你需要在系统级或在端口级指定转发模式。

在SONiC这种开放网络系统上，你还需要通过config_db.json修改相关的配置表，比如：

{ "PORT": { "Ethernet0": { "forwarding_mode": "cut-through" } } }

改完配置后必须保存并重启相关服务，否则不生效。而且在SONiC上开启Cut-through的同时，要确认你没有同时启用依赖完整帧解析的特性，比如某些高级ACL或者基于帧尾的统计功能，否则可能出现模式冲突。

这里提醒一下：改配置之前，一定要确认该端口下联的对端设备也能接受可能存在的坏帧传输。如果对端是存储设备或者金融交易系统，对错误帧极其敏感，那你宁可维持Store-and-forward。

5.3 白盒交换机/DPU上怎么改转发模式

在DPU和智能网卡上，这块更灵活。很多DPU会提供一个类似Nic模式或交换模式的配置项。比如你在DPU上启用内置交换功能时，可以选择：

• 低延迟模式，对应Cut-through优先
• 标准模式，对应Store-and-forward
• 自适应模式，让芯片根据端口速率和拥塞状态自动切换

自适应模式是我个人觉得最值得研究的。它本质上不是简单的二选一，而是让芯片做动态判断：当端口速率匹配、出口队列空闲、帧没有异常时，尽量走Cut-through路径；一旦检测到出口拥塞或者帧可能异常，就自动回退到Store-and-forward路径。这种模式在业务混合部署的场景特别好用，既能保住低延迟收益，又不至于在拥塞时产生额外风险。

不过自适应模式也有代价，就是芯片内部需要更复杂的业务识别和状态跟踪，有可能带来额外的硬件开销。有些低端DPU会说“支持自适应”，实际只是做了一种很粗的端口级判断，并不等于每帧级别的智能决策。选型时要问清楚。

6. 常见问题与排查实录

6.1 问题：误码场景下，Cut-through为什么“污染”一片

有一次我帮一个机房排查存储网络的IO异常，现象是某个交换机端口下出现大量CRC错误，但直接连接服务器的链路上CRC计数却不高。查了半天发现，链路上游有一根光模块性能劣化的链路，偶尔会产生FCS错误帧。刚好这台下游交换机开了Cut-through，坏帧没有被过滤，直接转发到了存储交换机，导致所有经过这条路径的大流量IO都出现偶发延迟和重传。

这就是Cut-through的典型负面案例。坏帧一旦被转发，你就很难快速定位错误的原始源头。因为这个坏帧会沿着数据路径继续走，消耗链路带宽和终端设备处理资源，制造“延迟变高、重传变多”的假象，但真正的病灶在几跳之外。

排查方法也很直接：先把可疑路径上的交换机转发模式临时改为Store-and-forward，再观察CRC错误计数和业务异常是否明显缓解。如果缓解，基本说明坏帧传播路径在这里起了放大作用。然后逐跳回溯，找到真正产生错误帧的物理链路，再更换模块或调整信号完整性参数。

对于误码率偏高的链路，我的建议是不要全局开启Cut-through，至少要在那些长距离、跨机房、多厂商光模块混合部署的链路上关闭。

6.2 问题：跨速率部署，直通延迟收益为什么“消失”了

还有个常见场景是网络里10G和25G端口混合，或者服务器是10G接入、核心是100G上行。有人开开心心在接入和核心都开了Cut-through，测试延迟时却发现匝道口没有达到预期。

原因就是我前面讲过的速率不匹配。比如服务器发一个1518字节帧到10G接入交换机，接入交换机转给100G核心，这种“慢进快出”还好。但到了核心交换机，如果要从100G端口转发到另一个10G端口，出口是比入口慢的，Cut-through就没法生效，必须完整收帧再按10G速率发。你全链路延时优化的希望在最后一下变成“存储转发”，前面的收益被后面吃掉了。

这种场景的优化思路不是死磕单个交换机的转发模式，而是尽量做到端到端速率对称。如果非对称无法避免，那就提前算清楚瓶颈端口在哪，在瓶颈端口附近不要期望Cut-through有收益。不要拿一个混合速率网络的平均延迟去跟别人纯25G网络的Cut-through延迟对比，那样没有意义。

6.3 问题：开启Cut-through后流量变“乱序”

另一个比较隐蔽的问题，是开启Cut-through后发现同一流的部分小包比大包先到，或者看起来像乱序。其实这不一定真是乱序，而是因为Cut-through模式下，一个大帧可以从入口“冲”到出口，而后续的普通帧可能在队列里被调度到另一个路径。如果芯片在不同转发路径之间没有做很好的顺序保证，就可能出现同一数据流内帧的到达顺序变化。

处理这类问题，先看是不是ECMP或链路聚合导致的多路径问题，再看转发模式是否影响了队列优先级。老实的做法是在开启Cut-through的同时，确保关键业务流走同一优先级队列，或者干脆只在单路径环境下开启。对于强一致性存储和交易类业务，乱序是不能接受的，这里的“低延迟”就要让位给“顺序确定”。

6.4 排查清单表

以上问题整理成一张速查表，方便你在现场快速定位：

7. 我的实操体会和建议

按我自己在多个数据中心、存储网络和白盒交换环境里的经验，转发模式这件事最忌讳的是拍脑袋决定。每次部署前，我都会花几分钟把这几件事确认一遍：整条数据路径上的端口速率是否对称，业务帧长分布是什么样，链路误码率有没有监控数据，以及业务对坏帧传播的容忍度如何。

如果链路质量好、业务就是典型的AI训练或存储大块读写，那我会优先开启Cut-through，并在关键路径上观察延迟和丢包曲线。如果链路经常有零星CRC错误、业务对数据完整性要求高，或者网络里有大量跨速率转发，那我宁可用Store-and-forward换一个确定性。最后再分享一个小技巧：很多设备支持在端口级别单独配置转发模式，不要在系统级别“一把梭”。核心东西向流量走Cut-through，南北向网关接口保留Store-and-forward，往往比全局统一配置更现实，也能避免很多莫名其妙的间歇性故障。