上周有位朋友在群里甩了张截图上面就一句话“延迟从低到高UALink SUE RDMA (RoCEv2) 标准以太网 (TCP)”让我评一评。我回了一句这张排序图有参考价值但括号里的问号才是精华——因为把这几样东西按延迟排出序来本身就是把“盖楼用的预制板”和“快递柜”放在同一条传送带上比尺寸。现实中谁是倒数第一、谁是正数第一完全取决于你测的是哪一跳、跑什么流量、网络负载到没到临界点以及SUE到底指的是哪一种方案。这篇文章就来拆一拆这个排序它为什么看起来合理、哪里经不起推敲、以及如果真想验证一遍该怎么用最小成本把数据测出来。无论你是做AI集群、存储网络还是超低延迟交易系统看完之后应该能对“网络延迟排序”这件事建立一个更立体的判断框架而不是把一张图当真理。1. 先把四个选手放在同一张桌子上它们到底在解决什么问题1.1 UALink给AI加速器修的“院内走廊”标题里的UALink指的是一类面向AI加速器之间的高速互连规范。它解决的核心问题是当一台服务器里插了多张GPU/AI芯片训练大模型跑集合通信时数据在卡与卡之间搬运的延迟和带宽不能成为瓶颈。这类互连的特点是链路非常短、路径非常确定、协议极简。不需要IP路由、不需要拥塞控制、甚至不需要传统意义上的“网络协议栈”。因为链路通常只在同一个服务器内部或者顶多跨一个非常紧凑的背板/机柜所以它可以把延迟压到亚微秒甚至纳秒量级。打个比方UALink就像办公楼内部给总裁修的一部直通电梯按钮只设终点站不需要和其他人挤。它压根不是一个通用网络而是特定硬件之间的一种物理和协议约束。1.2 SUE一个“模糊但方向明确”的蹭热度选手标题里的SUE说实话我不确定它到底指向哪个具体方案。如果你问的是前一阵业界热炒的“超低延迟以太网”一类概念有厂商叫超以太网也有厂商有自己的私有缩写那么SUE代表的应该是保留以太网物理层但把传统TCP/IP那一大套协议栈砍掉或者极度精简化从而在通用以太网设备上做出接近专用互连的延迟表现。为什么这类方案近年特别热因为UALink这类专用互连虽好但它只解决“机内/机柜内”的问题。一旦数据要跨交换机、跨机柜、跨数据中心你还是得回到以太网家族。于是有人想能不能让以太网也变得足够简单、足够快让AI训练和HPC场景不必再依赖专用协议SUE这类方案通常做的事情包括跳过内核协议栈、用用户态网卡、优化队列调度、避免交换机的PFC风暴最终把端到端时延从几百微秒压到几十微秒甚至更低。1.3 RoCEv2在以太网上跑RDMA的“工程妥协”RoCEv2是“RDMA over Converged Ethernet version 2”的缩写。RDMA设计的初衷是让网卡直接把数据从一台机器内存搬到另一台机器内存CPU不参与拷贝。第一版RoCE只能工作在无损以太网环境第二版把它封装进UDP/IP理论上可以跨三层网络。但这里有一个关键的代价RoCEv2需要底层网络提供无损保障否则数据包一丢重传机制会让延迟立刻爆炸。为了做到无损交换机上得开PFC优先级流控、ECN显式拥塞通知网卡上要配好流控阈值。这和“标准以太网随随便便就能跑”有本质区别。一句话RoCEv2是在“不想换专用硬件、又想要接近RDMA性能”之间做的工程妥协。它的延迟比传统TCP低但部署和调优的复杂程度要高一个数量级。1.4 TCP最常见、最“厚”的通用网络协议标准以太网TCP/IP其实不是一个协议而是一整套分层协议栈应用数据要先经过Socket接口进入内核内核里TCP协议栈负责分段、重传、拥塞控制然后IP层路由最后网卡把它发出去。对面收到后再层层解包。流程没毛病但每一步都在为“通用性”付代价。TCP的设计目标是可靠、公平、能够适应各种不可控的网络环境从拨号上网到卫星链路都希望它能跑。因此它要做慢启动、拥塞避免、快速重传、超时重传这些机制使得它在链路拥塞时不会把网络打爆但也注定它的延迟比“以简单换快”的方案高不少。好在TCP有最大的生态优势任何设备都支持出了问题人人都会排查。1.5 一张表看懂四者的基本差异技术解决什么问题典型端到端延迟量级适用距离部署成本UALink类加速器互连卡间/加速器间数据搬运亚微秒到数微秒机内或同机柜高专用硬件SUE类超低时延以太网增强跨设备但希望极低延迟数微秒到数十微秒机柜内/跨机柜中高需配合新网卡RoCEv2在以太网上实现RDMA数十微秒到百微秒数据中心内部高需要无损配置TCP over 以太网通用可靠的网络通信百微秒到毫秒全局通用低开箱即用注意这里说的“典型延迟量级”是相对正常负载下的估计值。一旦网络拥塞、丢包、PFC触发任何方案的延迟排序都会被打乱。这一点后面专门讲。2. 延迟到底从哪里来看懂组成才好判断排序2.1 延迟不是“一个数”而是四段路程之和网络延迟由四部分组成处理延迟、排队延迟、传输延迟、传播延迟。用快递打个比方处理延迟快递员在站点分拣包裹的时间。对应网卡封包解包、协议栈处理、交换机查表转发。排队延迟包裹在站点等待装车的时间。对应数据包在交换机/网卡队列里排队的时间。传输延迟把包裹装到货车上的时间。对应网卡把数据包“放到链路上”的时间取决于带宽和包大小。传播延迟货车在公路上跑的时间。对应电磁信号在光纤/网线中传输的时间取决于物理距离。很多人在讨论延迟排序时脑子里只想着“传播延迟”——以为两根光纤短的快。但在数据中心内部支配延迟的往往是处理和排队这两项尤其是排队延迟。交换机拥塞、网卡队列满、TCP丢失重传都可能让一个原本5微秒的网络链路变成5毫秒的抖动地狱。2.2 协议栈越厚相当于中转站越多为什么TCP延迟高而RoCEv2低最直观的解释是处理路径长短。TCP的数据从应用发出要经过应用缓冲区 → 内核Socket层 → TCP层 → IP层 → 网卡驱动 → 网卡硬件。接收端再反向走一遍。每一层都有状态维护和判断逻辑尤其是TCP的拥塞控制算法它要计算窗口、决定发多少包、何时重传。这些事情在CPU上做速度再快也要消耗几十到几百个CPU周期。RoCEv2的路径就短不少应用数据直接映射到网卡内存由网卡硬件负责把数据打成带UDP头的RDMA报文CPU全程不碰数据面。硬件处理当然比软件快但快的前提是你得先把整个网络调成“无损”状态不然一个丢包就能把一切拖回原始社会。UALink和SUE类方案就更极端它们干脆把网络层状态全部拿掉链路两端知道对方就是“邻居”包头极短转发逻辑固定。这就是为什么它们能把处理延迟压到极低。2.3 确定性 VS 统计复用轻载时谁都不差拥塞时才见真章这里有一个非常重要的认知在低负载下TCP、RoCE、SUE、UALink的延迟差距远没有想象中那么大。因为流量不高队列基本不排队大家都能以接近物理极限的速度把包发过去。差异主要在“负载上来之后谁会先崩、崩到什么程度”。标准以太网上的TCP遇到拥塞会主动降低发送速率让队列慢慢消化代价是平均延迟增加但整体可控。RoCEv2遇到拥塞时如果PFC配置不当会把拥塞压力“传导”到附近所有交换机出现“队头阻塞”导致所有流量一起卡住。这就是业界常说的PFC风暴——本来想保护无损结果把整个网络搞瘫。SUE类的思路则是通过更精细的流控和调度在不牺牲利用率的前提下尽量维持低延迟。它的挑战在于要解决PFC的副作用又要保证无损这需要在交换机上有更聪明的队列管理和端到端协同。可以说SUE的目标不是比RoCEv2“快”而是比RoCEv2“稳”。3. 排序A“UALink SUE”这个不等号在什么条件下成立3.1 UALink为什么能压到最低路径短、协议简、无竞争UALink这类加速器互连能拿到最低延迟根本原因有三点。第一拓扑是固定的。Token Ring、Fat-Tree、无交换直连——设计者明确知道每一跳去哪儿不需要查路由表不用做动态转发决策。第二数据面极其精简。它不需要IP层的地址协商不需要UDP端口号甚至不需要传统的重传机制端到端的设计就是“发出去就成功”。第三不存在跨设备排队。至少在本机内部数据通过背板直接到另一张卡没有交换机的出端口竞争。所以“UALink SUE”在机内通信场景下几乎必然成立。一个是自己院子里的专用走廊一个还要出门过马路怎么比3.2 SUE想要挑战的其实是“RoCEv2那一段”而不是UALink如果你认真看SUE类方案的宣传材料会发现它们对标的主要是RoCEv2而不是加速器互连。因为它们要解决的是“跨交换机、跨机柜”的问题。SUE类方案通常做的事情包括跳过UDP封装减少包头处理、把无损流控做得更细按流控而不是按优先级、配合支持多路径的负载均衡避免单路径排队、以及在网卡上实现更激进的硬件卸载。这些手段加在一起可以让跨交换机的端到端延迟从RoCEv2的“数十微秒”压到“接近十微秒”。但如果你拿SUE去和UALink比那就是拿“城市快速路”去比“直升机专线”。SUE再快也要受交换机和物理距离限制而UALink根本不出楼。所以标题里“UALink SUE”这个不等号只有在讨论“机内”时是对的一旦跨交换机就变成“SUE出现之前根本没有可比方案”的问题了。3.3 换个距离尺度排序马上就会变测延迟最忌讳不谈距离。物理距离每增加100米光速在光纤里的传输延迟大约增加0.5微秒。如果你的数据中心里跨机柜的链路有100米光纤那么仅传播延迟就是0.5微秒——这已经比UALink端到端整体延迟还高了。而如果跨楼、跨园区几公里的光纤直接把基础传播延迟拉到几十微秒这时候你再追求“少一层UDP封装”就没什么意义了。所以任何让你背下来的延迟排序都要先问一句这个排序的测量距离是多少同一机柜内排出来的结果和跨三层网络排出来的结果可能完全是两个次序。4. 排序B“SUE RoCEv2 TCP”这个部分其实值得商榷4.1 RoCEv2比TCP快这句话总体成立先说结论在数据中心内部、负载适中、配置正确的前提下RoCEv2确实比TCP延迟低一截。低在哪TCP慢在“面向连接的复杂状态”。建立连接要三次握手每个包要确认丢包要重传拥塞要退避。这些机制保证了可靠性但延迟被拉高。RoCEv2无连接不握手数据直接进网卡硬件CPU不参与数据面拷贝。我们用sockperf压测时经常能看到同两台机器、同一条链路TCP ping-pong延迟在30-60微秒而RoCEv2可以做到4-8微秒。这个差距在“写一个键值对然后再读回来”这样的小消息场景里会被放大得很明显。4.2 但为什么有时RoCEv2反而比TCP差RoCEv2对网络质量有非常苛刻的要求。它依赖底层无损机制如果交换机上PFC配置不当出现链路级流控把数据包“憋”在交换机队列里那表现可能比TCP还差。出现PFC暂停时所有流向拥塞端口的流量都会被桌头阻塞整个网络延迟呈指数级恶化。而TCP遇到拥塞至少会快速重传、主动降低速率把延迟控制在一个可预测的范围。另外RoCEv2在多路径能力上天然不行。传统RoCEv2基于五元组哈希做负载均衡流粒度较粗一条大流容易压到某条链路造成拥塞。而TCP在拥塞时会自动收敛有些部署配合等价多路径也能做更细的调度。所以在高拥塞、强突发、路径不均衡的场景下RoCEv2的实际延迟完全可能反超TCP。这就是为什么大型AI训练集群里的网络团队会把眼见调通RoCEv2当大工程不是配置完就能用你得持续监控PFC计数、ECN标记、丢包率。任何一个交换机端口出了微突发延迟特征就可能变。4.3 SUE排在最左是不是太乐观了如果SUE指的是超低延迟以太网增强方案那么它的排序位置取决于一个前提它是否仍然要求无损网络。如果SUE要完全规避丢包那它和RoCEv2其实面临同样的PFC调优问题只是机制可能更先进。如果SUE允许有损但通过网卡侧的超快重传和端到端协同来兜底那它在链路质量好时也许能比RoCEv2更低但在链路出现丢包、重传时它的延迟会非常不稳定。我个人的判断是把SUE放在RoCEv2左边反映了“新一代超低时延以太网方案”的雄心但在没有明确厂商、明确实现之前把所有同类方案都默认为最优风险很大。你更应该把它看成“RoCEv2的加强版候选”而不是一个有着稳定排序的既定事实。4.4 不同负载场景下的排序会变成什么样我拉一张表按“同一机柜内、跨交换机”的场景估算大概的延迟次序场景由低到高的排序轻载机内直连UALink类 SUE类 RoCEv2 TCP轻载跨一台交换机SUE类 ≈ RoCEv2 TCP重载交换机无明显流量拥塞SUE类 ≈ RoCEv2 TCP重载触发PFC或队列丢包TCP RoCEv2 ≈ SUE类都崩看谁的流控聪明跨机房物理距离主导TCP和RoCEv2差距变小距离决定一切注意我这里是按“更低的延迟排前面”。这里的“”不是数学大于号而是“从低到高”的排序方向。实际看到末尾时别被方向带晕。5. 别急着下结论自己动手测一遍5.1 测试环境怎么搭最省事想验证这部分排序最直接的方法是用两台直连的服务器装好网卡驱动分别用不同协议跑ping-pong和小包延迟测试。不需要复杂的集群不需要生产环境只要有两台服务器最好同一机房、同一交换机下或者直连。支持RoCE/自适应以太网的网卡。Linux系统装上sockperf、qperf、ib_write_bw这些工具。测试端口单独配别让人家正在跑业务的交换机参与否则数据全是噪声。如果只是对比TCP和RoCEv2sockperf的ping-pong就够用了。如果想测UALink那类专用互连那你得真有对应的加速器背板和专用工具——这一般不是普通测试环境能碰到的我们这里先不展开。5.2 测之前必须避开的三个坑我不止一次看到有人拿着被污染的延迟数据跟别人争论最后发现是测试方法出了错。下面三个坑凡是做网络延迟对比的都绕不过去。第一个坑CPU调频没关。现在服务器的CPU都有动态调频测试时如果CPU降频了协议栈处理延迟会凭空多出几十微秒。先跑cpupower frequency-set -g performance把CPU锁在高频再测。第二个坑打开irqbalance的干扰。中断负载均衡会把网卡中断在不同CPU间调来调去打造成小包延迟的极差变大。要么用systemctl stop irqbalance要么把网卡队列的CPU绑定irqaffinity定死测试端一定要绑核。第三个坑只跑一次就下结论。网络延迟本身就是随机过程CPU调度、PCIe总线的噪声、链路错误重传都会让单次测量失真。我习惯每次测试至少跑3轮每轮至少1万次ping-pong取p50和p99看。p50代表典型表现p99代表最坏体验这两个数都有意义。5.3 一个可复现的最小测试脚本假设两台服务器IP分别为192.168.1.10和192.168.1.11网卡支持RoCE或者至少支持普通UDP。先跑TCP延迟再跑基于UDP的延迟RoCEv2核心链路本质上绕过了内核协议栈但如果你没有对应网卡可以先用UDP近似看趋势# 服务端选一台 # TCP测试的接收端 sockperf server -i 192.168.1.10 -p 12345 # 客户端发起TCP ping-pong sockperf ping-pong -i 192.168.1.10 -p 12345 --tcp -m 64 -t 10 -o tcp_64.txt # 基于UDP/RDMA路径的延迟测试这里用UDP代替RoCE做近似 sockperf server -i 192.168.1.10 -p 12346 --udp sockperf ping-pong -i 192.168.1.10 -p 12346 --udp -m 64 -t 10 -o udp_64.txtsockperf输出的结果里latency summary会给出p50、p95、p99等值。跑完之后可以再用-m 1024、-m 4096试几种消息大小观察消息大小对延迟的影响。如果你有真正的RoCE网卡千万别只是开着网卡默认配置测。需要先设置好无损参数比如把交换机端口流控打开、PFC优先级配好、网卡上设置好ECN阈值否则RoCE表现甚至不如TCP。这一步是很多人在实验室里测出“RoCE更慢”的原因。5.4 结果怎么解读均值会骗人分位数才是真相我测过很多次TCP的p50可能稳定在50微秒但p99能跳到500微秒以上。RoCEv2的p50是6微秒可一旦拥塞p99可能直接烧到几千微秒。如果只看均值你会觉得“RoCEv2好像也没好太多”但看p99区别就拉开了——普通业务的体验往往更接近高百分位尤其是在交易系统和AI推理这种对尾延迟敏感的场景。这也能解释为什么很多生产环境里运维宁可保留一部分TCP流量也不全切到RoCEv2TCP最差表现可以预测RoCEv2最差表现取决于PFC有没有生效、有没有人误开了一条大流。6. 修正这个排序什么条件下才能把“问号”改成“句号”6.1 按“同一机柜、正常工作负载”修正后的排序如果非要给一个更接近现实的排序我会这样修正机内/背板场景UALink类加速器互连 RoCEv2跨PCIe/专用通道 TCP。SUE如果没有专用硬件不进这个跑道。跨交换机、机柜内场景SUE类增强以太网 ≤ RoCEv2 TCP。这里的≤真正取决于你有没有把无损配置调好以及流控算法的实际表现。跨数据中心场景TCP ≈ SUE ≈ RoCEv2。因为物理距离造成的传播延迟已经占大头协议栈差异反而被稀释了。这时候优化网络重点不再是“换协议”而是“少绕路、近部署”。所以标题里的原始排序在最理想的“机内直连、轻载、配置完美”条件下大体成立但只要加任何一个现实条件——比如距离变远、流量变高、出现丢包——它就变得有误导性。6.2 延迟之外真正影响体验的还有“延迟分布”做网络的人都知道有时比平均延迟更重要的是延迟抖动jitter和尾延迟。同样是平均30微秒一个系统是“稳定在29-31微秒”另一个系统是“大部分3微秒偶尔300微秒”给上层业务带来的体感完全不同。前者适合交易系统后者只能跑跑普通查询。这个维度上TCP和RoCEv2各有苦衷TCP的抖动来自内核协议栈的调度和拥塞退避RoCEv2的抖动来自无损流控的连锁反应。SUE类方案如果能做到“少丢包、少PFC、多路径分担”才有可能同时在p50和p99上碾压RoCEv2——但这需要非常成熟的交换机生态配合目前仍然属于工程前沿。6.3 不同业务该选谁选型建议如果你在做的业务是AI大模型训练那么卡间通信必须用UALink类的专用加速器互连跨节点通信则应优先考虑RoCEv2或者你的设备厂商推荐的增强以太网方案。别拿TCP做训练框架的集合通信带宽和延迟都吃亏。如果你是对象存储、数据库同步、消息队列这类通用业务TCP仍然是性价比最高的选择。RoCEv2让存储网络延迟降一个量级但运维复杂度也升一个量级。你能接受为“无损”付出的运维成本再考虑。如果你是高频交易或金融极速交易那么每一微秒都值钱。这个时候UALink类只在机内有用真正的瓶颈通常在跨机柜和跨数据中心链路上。你需要的不只是“更快的协议”而是“更近的服务器”和“更少的网络跳数”。很多场景下把核心服务搬到同一个交换机下可能比换任何协议都有效。6.4 别把延迟排序当真理当参考坐标系最后再分享一段我自己的体会。做网络越久越是觉得“A比B快”这种结论必须附带前缀什么距离、什么负载、什么消息大小、什么网卡、什么交换机。没有这些前缀的延迟排序就像没有单位的速度——数值再漂亮也没法指导决策。“UALink SUE RoCEv2 TCP”这个式子当作入门话题没问题它至少让你知道专用互连比通用网络快新方案比旧方案有野心。但如果真要落地请把它修正成“在XX条件下谁大概率比谁低”。把问号带着走而不是急着把问号抹掉。真要选型那天我的建议永远是先拿sockperf在自己的服务器上测一周收集p50、p99和抖动数据再决定信谁。因为在数据中心里最不可靠的东西有两样厂商的PPT和网络工程师没有测过就直接说出的“我觉得”。