聊到交换芯片不管你研究的是数据中心核心交换机、白盒交换机还是带交换功能的网卡绕不开一对老冤家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 / 10000000000 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 / 10000000000 1.2144μsStore-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会减1Checksum会重算。要做这些修改你必须先把帧前面足够多的字段都收下来改好之后才能向出端口发送。这意味着纯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 排查清单表以上问题整理成一张速查表方便你在现场快速定位现象重点关注优先排查方向CRC错误帧被放大传播上游链路误码、光模块劣化临时切Store-and-forward逐跳查CRCCut-through开启后延迟依然高端口速率不匹配、出口拥塞检查是否跨速率转发观察端口队列利用率出现类似乱序ECMP路径、多队列调度关闭多路径或固定优先级队列开启Cut-through后ACL不生效芯片强制回退Store-and-forward查看芯片规格和系统日志小包时延迟没变化小包线速时间短收益不明显定量比较64字节和1500字节帧延迟7. 我的实操体会和建议按我自己在多个数据中心、存储网络和白盒交换环境里的经验转发模式这件事最忌讳的是拍脑袋决定。每次部署前我都会花几分钟把这几件事确认一遍整条数据路径上的端口速率是否对称业务帧长分布是什么样链路误码率有没有监控数据以及业务对坏帧传播的容忍度如何。如果链路质量好、业务就是典型的AI训练或存储大块读写那我会优先开启Cut-through并在关键路径上观察延迟和丢包曲线。如果链路经常有零星CRC错误、业务对数据完整性要求高或者网络里有大量跨速率转发那我宁可用Store-and-forward换一个确定性。最后再分享一个小技巧很多设备支持在端口级别单独配置转发模式不要在系统级别“一把梭”。核心东西向流量走Cut-through南北向网关接口保留Store-and-forward往往比全局统一配置更现实也能避免很多莫名其妙的间歇性故障。