当前位置：首页 > NSDI > 正文

【NSDI 2022】Aquila：数据中心网络的统一、低延迟结构

NSDI
2022-10-07
2339
更新：2023-01-04 21:40:54

# 摘要/内容提要

> 数据中心工作负载已从过去十年的数据密集型、松散耦合的工作负载演变为更紧密耦合的工作负载，其中超低延迟通信对于网络上的资源分解和新兴编程模型至关重要。

> 我们介绍了Aquila，这是一种实验性的数据中心网络结构，以超低延迟支持作为一流的设计目标，同时也支持传统的数据中心流量。Aquila使用了一个新的2层基于cell的协议，即GNet，一个集成交换机，以及一个与GNet共同设计的具有低延迟远程内存访问(RMA)功能的定制ASIC。我们证明，Aquila能够在数百台主机上实现低于40µs的IP流量尾部结构往返时间(RTT)和低于10µs RMA执行时间，即使存在面向吞吐量的后台IP流量。这意味着在原型Aquila网络上运行的具有产品质量的键值存储的尾部延迟减少了5倍以上。

# 1、引言

在过去的十年中，数据中心网络取得了巨大的进步，控制平面随着非阻塞拓扑中的商用芯片的兴起，网络管理和验证以及高可用的网络设计技术，取得了根本性的进步。综上所述，社区现在正处于一个经济高效、易于管理和可扩展的网络设计和部署在行业中越来越普遍的位置。数万台服务器集群规模的丰富网络带宽可用于大规模超规模服务器及其承载的服务。

然而，所有这些进步都是在假设基于TCP的拥塞控制和以太网2层协议的情况下实现的。经过几十年的部署和增量演进，该2~4层堆栈具有难以置信的健壮性和弹性。然而，我们在数据中心看到了一个新的困难，因为多租户数据中心网络中缺乏性能可预测性和隔离性，分布式计算的进步越来越受到限制。在网络结构设计师的目标以及应用程序的预期和编程方面存在两到三个数量级的性能差异，这一情况并不少见，严重限制了基于集群的更高层次分布式系统的创新步伐。

当考虑到超级计算/HPC集群和新兴机器学习平台的状态时，这种担忧被放大了，其中单个应用程序受益于低延迟RDMA，集合操作，以及紧密集成的计算和通信能力。与生产数据中心环境相比，这些更专业化的设置的主要差异包括：i)能够采用单租户部署，或者至少是空间共享而不是时间共享；ii)减少了对故障处理的担忧；以及iii)愿意采用向后不兼容的网络技术，包括有线格式。

最近对分解机架规模架构的研究工作进一步突出了其中的一些挑战：支持跨广域主机对主机通信的相同NIC和交换机能否支持半径小得多的SSD和GPU设备？分解网络(disaggregation network)是否必须是一个单独的专用结构，或者是否可以与发送到100毫秒或更长距离的远程主机的TCP/IP通信进行多路复用？虽然运行专用于单个用例的第二(或第三)网络有一定的吸引力，但每个网络的控制和(同样重要的)管理开销引入了一种循环依赖性，在底层技术被证明/成熟之前，第二网络相对于现状是不值得的。然而，没有机会重复使用替代技术，因为这样做对未来几代人的成本和复杂性都是负面的，因为在新硬件上展示端到端的胜利之前，应用程序必须进行实质性的改进。

对向后兼容性的需求，再加上在部署“边上包/bag on the side”网络方面的挑战，威胁着数据中心网络和分布式系统形成新的僵化，我们只能按照TCP传输和商用以太网交换机的最低公分母进行编程，并具有相关的延迟、CPU效率和隔离限制。

在本文中，我们首次探索了另一种紧耦合(或基于Clique的)数据中心架构Aquila，这是一种支持可预测、高带宽和超低延迟通信的硬件实现。在我们的方法中，数据中心网络由几十个Clique组成，每个Clique拥有大约1-2k个网络端口。Clique通过标准以太网和IP在数据中心接口(例如，现有基于Clos的数据中心网络的主干层)上彼此互操作。然而，在Clique内，可以部署任何传输和第2层网络协议。适合单个Clique边界的应用程序可以采用Clique本地功能，包括健壮的RDMA、可预测的低延迟通信、设备分解、支持ML聚合原语等。我们假设基于IP的传输用于Clique之间的通信，这意味着任何Clique内部通信原语和创新必须与标准传输共存。然后，Clique成为部署、创新和同质化的单位，允许在现有数据中心中进行增量、向后兼容的部署。一个Clique也足够大，可以容纳除最大的分布式系统之外的所有分布式系统，尤其是当我们每台服务器上有数百个计算内核/core时。

Aquila是我们第一个基于自定义内部ASIC和通信软件的Clique实现，由cell交换非以太网基板GNet组成。

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l </span><span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">Aquila网络由单个硅组件构建，这些硅组件既是NIC，也是传统机架顶部(ToR)交换机的一部分；每个ToR-in-NIC(TiN)芯片连接到主机并直接连接到其他TiN芯片，以实现由单个复制硅组件构建的经济高效的网络，而不是由不同供应商提供的不同的NIC和交换机硅组件。</span>

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l </span><span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">GNet通过在Aquila网络边界终止以太网，并在完全定制、自我保护、接近无损的L2基板上传输流量，为Aquila内的主机以及Aquila Clique范围外的非Aquila联网组件提供了以太网的假象。</span>

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l </span><span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">Aquila通过实现直接网络而不是间接(Clos)拓扑进一步降低成本。为了充分发挥Dragonfly拓扑的功能，并摆脱以太网的实际限制，Aquila利用自适应路由，通过利用多条非最短路径，在主机对之间提供完整的点到点带宽。</span>

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l </span><span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">Aquila以称为cell的小数据块(而非数据包)传输数据，从而优化了小型交换的延迟，如基于RDMA和类似技术构建的分布式系统所使用的延迟。其在NIC和网络之间的紧密集成允许在多达1152台主机的内存系统之间实现超低RMA读取能力(4us中值)。</span>

**Aquila的设计在几个方面不同于传统的以太网结构**：i)链路使用基于信用的流量控制；ii)交换机缓冲区较浅；以及iii)端到端准入限制。以太网中的这些原则中的任何一个都是有问题的，但综合起来，它们形成了一个内聚的设计。例如，流量控制的近无损链路可能会导致树饱和(tree saturation)，特别是在浅缓冲的情况下，但端到端准入控制限制了此类树的大小和传播，并确保它们是瞬态的。类似地，当可能出现下降时，准入控制也会失效，但链路级流量控制使下降非常罕见，从而允许在交换机元件中使用浅缓冲，因为不可能出现超限。

我们介绍了Aquila的详细设计、实现和评估。Aquila不是Clique设计的最终决定者；事实上，我们对Aquila系统的第一次体验表明，未来几代人还有许多需要改进的地方。然而，我们希望实现垂直集成的方法，包括主机软件堆栈、NIC、该交换机以及基于Clique的数据中心架构将支持新的数据中心创新模式，并为分布式系统提供新的功能，这些系统可以在数千台服务器和数十万个内核的边界内实现尖端而非最低公分母通信和分解能力。

# 2、目标和我们的方法

AAquila 与以太网的设计背离基于一组共同的目标，如下所述。单独来看，这些设计选择——例如流量控制、自定义第2层——将难以逐步应用于现有网络。但与此一致，Aquila的功能实现了一个完整的、高性能的设计点。

**可持续硬件开发**。为了与一个规模适中的Clique队一起维持硬件开发工作，我们选择在同一个硅芯片上构建一个具有NIC和交换机功能的单芯片。我们的基本见解和出发点是，中等基数交换机可以以适度的额外成本并入现有的NIC硅中，并且由此产生的许多被称为ToR-in-NIC(TiN)芯片的NIC/交换机组合可以通过pod中的铜背板连接在一起，这是一个与传统机架顶部(ToR)交换机大小相当的外壳。然后，服务器可以通过PCIe连接到pod，以实现其NIC功能。TiN交换机将通过优化的第2层协议GNet与同一Clique中的其他服务器连接，并通过标准以太网与其他Clique中的其它服务器连接。图1中的插图总结了TiN的主要组成部分。
<div align="center"> <img src="https://ngdcn.com/zb_users/upload/2022/10/202210071436163315597.png"/> </div>

**经济高效的非阻塞拓扑**。为了提高效率和降低延迟，我们选择了直连拓扑Dragonfly，这是一种经过充分研究的拓扑，它最大限度地减少了网络中的长光链路数量，同时仍然为均匀随机流量模式提供非阻塞带宽，最坏情况下的对抗流量(adversarial traffic)为2:1。图1展示了一个简化的Dragonfly拓扑，其中一个pod内的TiN完全连接在一个mesh中，多个pod也同样all-to-all地连接，形成一个紧密耦合的Clique网络。最大的Aquila网络支持一个pod中的12个TiN，48个pod，服务多达1152台主机。

与单独的NIC和交换机ASIC程序相比，将NIC和ToR组合到单个TiN芯片中是一种成本较低的创新途径，并且从一个通用的单个组件实现的设计旨在简化Aquila的库存管理(streamline inventory management)。此外，我们还实现了一种可选功能，允许成对主机共享一个TiN，从而将每台主机的网络正常化拥有成本减半，但以减少每台机器的持续带宽供应为代价。

**超低延迟网络**。为了优化超低延迟、欠负载和尾部，Aquila实现了基于cell的通信，为网络内的cell提供浅缓冲，流控制链路用于近乎无损的cell传输，硬件自适应路由可在纳秒内对链路故障做出反应，并在高负载下保持网络负载平衡。为了确保接收者不会不知所措，Aquila在入口为每个数据包执行端到端请求，这保证了在数据包可以拆分为cell并从源TiN传输之前，目标TiN上的资源是可用的。我们将这些延迟保护功能构建到Aquila的第2层协议GNet中。如图1所示，虽然Aquila网络结构在其边界处提供以太网数据包接口，但Aquila通过GNet传输传统的以太网/IP数据包，在入口分解，在出口重新组装和订购。

**用于传统流量和RMA/内存分解的统一结构**。Aquila将低延迟通信原语(RMA)与商品原语(IP)统一在一个公共结构中，以解决日益多样化的数据中心工作负载。提供高性能和传统连接的结构避免了边上网络和二级NIC的陷阱，降低了所有权成本和与两个独立网络的生命周期管理相关的工作量。管理单个网络的可用性、安全性、监控和升级已经足够具有挑战性——为单个用例管理单独的网络在任何成本/收益分析中都会引入非常高的标准。为了与传统协议一起实现高效的远程内存访问和内存分解，我们共同设计了一个远程内存访问协议1RMA，以直接在GNet上扩展跨Aquila Clique的内存访问，而不是在IP上分层。

在更大的基于Clos的软件定义数据中心网络生态系统中共存。典型的数据中心网络基于可扩展的Clos拓扑，其中聚合块通过Spine交换层连接；Aquila旨在通过其以太网端口集成到此类网络中。具有模块化微服务架构的分层软件定义网络(SDN)控制平面管理和控制数据中心内的各种网络块。

图2描述了Aquila在更广泛的数据中心网络的数据平面和控制平面生态系统中的集成。Aquila网络块通过以太网链路连接到数据中心的Spine交换层，类似于其他聚合块。数据中心网络的模块化架构实现了一种混合拓扑，即，在更大的Clos拓扑中集成为一个块的Dragonfly网络，据我们所知，这是同类网络中的第一个。

对于控制平面，我们采用了SDN控制器，通过TiN CPU上运行的精简机箱固件来配置、管理和TiN带内编程(图1)。与其他聚合块的SDN控制器类似，Aquila SDN控制器与四个中央块间路由控制器(IBR-C)(图2)中的每一个进行交互，以实现与其他聚合模块以及数据中心外部网络的通信。

**Clique作为托管紧密耦合应用程序的基础**。为了利用由Aquila Clique实现的紧密耦合、低延迟通信，我们调整了作业调度器，以了解Clique的位置。高带宽或延迟敏感的作业可以选择性地在一个Clique内的主机上调度，而其他作业仍然可以跨块装箱，而不管位置如何。

# 3、硬件设计

在本节中，我们介绍了关键设计目标如何推动硬件设计。总结为：

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l </span><span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">成本效益目标导致选择集成交换机和NIC的芯片TiN，以及Dragonfly等直连拓扑。第3.2节概述了选择Dragonfly的基本原理以及该选择对设计的影响。</span>

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l </span><span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">用于IP流量和低延迟RMA的共享结构。第3.3节描述了IP数据包如何穿越GNet结构，第3.4节详细说明了1RMA协议与GNet结构的共同设计方面。</span>

## 3.1 GNet交换和链路

**Cell交换机**。TiN芯片的交换能力由50端口cell交换机提供，该交换机针对低延迟进行了优化。选择了160字节的最大cell大小，以保持25G链路上的串行化延迟较小(~50ns)。32个端口是面向外部的GNet端口(其中24个是本地pod端口，8个是内部pod端口)。其余18个端口是芯片内端口，用于由各种业务端点(例如IP和1RMA)发送和接收的cell。核心cell交换机的直通延迟为20ns，无前向纠错(FEC)的总每跳延迟为40ns。GNet链路支持32个虚拟信道(VC)-用于避免死锁和QoS的FIFO队列。VC用于无死锁路由、区分服务类别以及分离请求和非请求流量。集中式仲裁器实现了iSLIP仲裁协议的一种变体，支持每个端口每个VC一个仲裁请求，确保没有VC或端口欠吞吐。为了支持可变cell大小，我们修改了iSLIP，使得入口和出口端口将“忙”信号传送给crossbar。“忙”表示端口正在跨crossbar传输cell。仲裁器在评估下一个请求授权接受周期的未决请求时会考虑到这一点。VC之间的服务质量(QoS)在输出缓冲区中实现，并支持加权循环和严格优先级。每个VC都有自己的输入FIFO空间，由可靠的信用机制保护，类似于PCI Express中使用的机制。共享缓冲区、共享信用方案被认为可以节省内存，但对于Aquila所需的相对较短的链路，独立FIFO的简单性和完全QoS隔离是首选。

**GNet链路级协议**。GNet链路支持大小在16字节到160字节之间的cell，具有频繁的反向流控制流量。可变长度cell的使用在线路上提供了非常高的协议效率(例如，1RMA请求很小)，即使在用于准入控制的附加控制流量之后也是如此。每个GNet cell都有一个8字节的公共路由报头，其中包含16位源和目标GNet地址、cell长度和类型、VC、递减跳数、8位报头CRC和跟踪启用位。为了实现GNet cell的高效传输，开发了一个定制的66/64位物理编码子层(PCS)，该子层将cell划分开销降至最低，并允许反向流控制流量作为非常紧凑的有序集发送。控制有序集用于：(1)cell划分的开始，(2)流控制，(3)时间同步(附录B)，(4)管理有序集(MOS)，以及(5)Phy up/down控制和故障检测。

## 3.2 Dragonfly cell结构

我们选择Dragonfly拓扑来管理光链路的成本，如图1所示。Dragonfly cell结构使用两种类型的GNet链路实现：每个TiN 24个本地链路，用于完全连接pod内的TiN，每个TiN 8个全局链路，用于pod之间连接，在数据中心楼层上相隔100米。本地链路实现为单通道、28 Gbps铜背板连接。全局链路是光学的，使用专门开发的低成本GNet光学模块。全局链路上的噪声通过FEC得到缓解，每跳延迟为30ns，带宽开销为6%。本地链路在没有FEC的情况下以可接受的范围以最低的延迟运行。本地和全局链路最终实现相同的链路级协议。由于Dragonfly拓扑的层次性，GNet地址有三个组件：pod id、TiN id和端点id。端点代表稍后详述的协议引擎(IP、1RMA和CPU)。

**避免死锁**。我们在Dragonfly拓扑中使用转弯规则和VC的组合来实现死锁避免。由于我们的预算为32个VC，我们希望尽量减少用于避免死锁的VC数量。在实现的路由方案中，我们在pod内采用了类似于奇偶校验符号方法的转弯规则，以实现无死锁的pod内路由。当从全局链路移动到本地链路时，VC会增加，在最差无故障路由(即通过中间pod的非最短路由)中，总共需要3个VC来避免死锁。考虑到10个流量类别，每个类别有3个路由VC，另外两个VC在某些动态故障避免场景中可用作转义VC。

**自适应路由**。在Aquila的Dragonfly网络上，大多数流量路由自适应地实现高吞吐量和最低延迟。TiN实现了本地自适应路由，该方案基于GNet交换机的可用信息，特别是每个端口的每VC输出队列长度，做出自适应路由决策。由于GNet的链路级流量控制和浅缓冲，这些队列深度反映了附近的拥塞。链路故障的表现类似，这也允许自适应路由算法围绕故障链路进行路由，直到SDN路由引擎删除失去连接的链路的条目。

自适应路由实现从路由表提供的八条路由中随机选择两条最小路由，并从24条非最小候选路由中考虑三条非最短路由。使用有利于最小路线的加权比较来评估五条候选路线。随机选择(而不是24路比较)使我们能够避免群集(flocking)、协调自适应路由决策以及将拥塞从一个地方转移到另一个地方。通过仅将路由限制为最小路由，或通过使用源地址和目标地址的哈希强制确定路由选择，可以启用其他路由模式。这些约束产生了Aquila的四种主要路由模式：完全自适应、最小自适应、确定性和最小确定性。确定性路由模式用于需要排序的cell类型。cell交换机使用基于表的路由，因为需要使用第4.2节中描述的SDN路由处理故障和升级，以及其他拓扑的灵活性。

## 3.3 IP流量

主机IP流量由传统的100 Gbps NIC发送和接收，该NIC能够支持最多两个独立主机的多主机操作。多主机能力的选择被认为是重要的，以便在每台机器的带宽分配方面提供一定程度的灵活性。TiN芯片上还有两个其他的IP流量来源：用于连接Aquila结构外部的100 Gbps外部以太网端口，以及到嵌入式管理处理器的低带宽端口。来自所有IP源的流量以相同的方式处理：数据包处理管道执行IP路由和cell化，即使用Aquila的IP over GNet协议，将IP数据包拆分为GNet cell，并将其遍历到最终目的地。

**分组处理逻辑**。通过GNet结构的每个IP分组仅经过输入分组处理和输出分组处理块一次。实际上，整个GNet Clique充当单级IP分组交换机。输入分组处理流水线：

L2以太网MAC地址在处理后从入站分组中剥离；通过GNet cell网络的数据包传输仅适用于IPv4/IPv6。非IP数据包(如ARP)可以封装或注入嵌入式控制处理器，符合我们的SDN控制平面的要求(第4节)。

**IP over GNet协议**。IP流量通过GNet上层协议穿越Aquila，如图3所示。通过cell结构发送的每个IP数据包发出发送请求(RTS)，并在传输任何数据之前等待清除发送(CTS，Clear to Send)握手。这些将作为16 byte GNet cell发送，以最小化带宽开销。握手协议执行三个功能：

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l </span><span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">当目标端点发出信号表示其有足够的输入带宽和缓冲区空间接收数据包时，它仅允许数据cell进入GNet网络，从而实现对IP包的请求。</span>

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l </span><span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">在传输任何数据cell之前，它在目的地分配硬件资源，例如，cell到分组重组缓冲区，以便始终有一个有保证的重组空间。</span>

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l </span><span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">RTS到达定义了包间顺序。当数据cell自适应路由并可能无序到达其目的地时，RTS排序确保可以在接收侧重建原始传输顺序。</span>

已经通过分组处理管道并且具有有效的GNet L2地址的分组被存储在分组入口缓冲区中。立即生成RTS；事实上，对于长数据包，可以在接收整个数据包之前发出RTS。RTS本身由8字节的路由报头和另外8字节的有效负载组成，其中包括IP数据包长度、服务类别(CoS)、数据包在入口缓冲区中的位置以及入口缓冲区使用情况的指示器。紧凑性很重要，因为RTS cell是未经请求的，并且仍然可以导致incast。然而，考虑到平均数据包大于1KB，RTS cell的incast表示网络中incast容量减少了64倍。

RTS cell由它们自己的VC承载，允许它们以高优先级发送，并在请求和非请求cell之间保持隔离。RTS VC通过GNet结构确定路由，使用由cell的流不变字段哈希选择的路径，确保按照发送顺序接收给定IP流的RTS cell。RTS cell在分组出口处被接收到FIFO队列中。分组数据传输由出口端通过将CTS发送回适当的入口端口来启动。除了8字节路由报头，CTS还携带一个指向入口缓冲区中的分组的指针(从RTS复制)和一个指向出口cell中分配位置的指针，用于分组重组缓冲区。CTS cell由CTS调度器发出，该调度器跟踪出口重组缓冲区容量的可用性，仅在有空间将cell重组为数据包时发出CTS。

当在数据包源接收回CTS时，所讨论的数据包作为一系列纯数据cell从入口缓冲区中取出，然后通过结构传输。数据cell可以(自适应地)通过结构采用许多不同的路线，并且数据cell可以以任何顺序到达最终目的地。cell在目的地的出口缓冲区中重新组装成分组。出口缓冲区的大小由输出端口带宽和cell结构往返延迟的带宽延迟乘积加上分组重新排序延迟的余量确定。数据包在主要用于重组的出口缓冲区中不会经历明显的排队，因此出口缓冲区明显小于入口缓冲区。

为了保持流中的数据包顺序，当调度器发出CTS时，数据包描述符将注册到与RTS到达顺序相关的数据包重排序逻辑中。数据包在接收到其所有数据cell后可在出口处传输，但可传输数据包将一直保留，直到在CTS发布顺序中位于其前面的同一流中的所有数据包都已成功转发到NIC。

RTS/CTS方案的一个重要优点是，RTS队列具有来自整个GNet结构的该目的地端口的所有请求分组需求的本地视图，而分组数据仍在入口缓冲区中排队。在存在严重incast的情况下，可以在保留结构带宽的同时丢弃数据包，即数据包数据不会穿过cell结构。出口侧可以通过发出CTS的变体(清除丢弃，CTD)来选择丢弃数据包，该变体从入口缓冲区中取出数据包并将其丢弃。当在深度超过给定阈值的RTS队列中接收RTS时，发送CTD。RTS队列的深度还为显式拥塞通知(ECN)标记提供信号；当数据包重新组装并准备发送时，如果RTS队列超过标记阈值，则应用ECN。

**IP的QoS支持**。每个独立端口和服务类别都有单独的RTS队列，总共有32个RTS队列支持四个独立端口上的八个CoS——一个用于外部以太网MAC，两个用于双主机NIC，一个用于控制处理器。CTS cell由数据包目的地的CTS调度器发出，该调度器在32个RTS队列之间分配带宽，在各个队列之间实现每个IP数据包的QoS。CTS调度器可以通过根据未完成分组提取的窗口限制CTS问题来限制进入出口缓冲区的流量，该窗口可以被调整以最小化cell结构内的数据cell的排队。调度器不尝试实现源之间的带宽公平性，因为到给定目标端口的所有源共享相同的RTS队列。

## 3.4 1RMA
为了将Aquila Clique的低延迟功能直接交付给分布式系统程序员，我们在TiN芯片中构建了1RMA的实现。1RMA是一种RMA协议，它向主机软件原则提供无序、分段、基于请求的远程内存访问原语(读、写和原子)，与RTS/CTS管理的GNet数据包传输的原则完全匹配。

这种排列不仅仅是巧合；我们共同设计了Aquila和1RMA基于GNet的协议。我们不是简单地将1RMA协议消息分层在分组层之上，而是将1RMA协议交换表示为GNet中的一类cell类型，与RTS和CTS一起，而不是在顶部，并确保它们在共享Aquila结构时遵守类似的端到端请求规则。协同设计的优势在于显著节省了延迟：虽然Aquila上的UDP/IP或TCP/IP往返会在其关键路径(RTS、CTS、数据，每个方向)上产生六次GNet半往返，但1RMA读取操作只会产生两次，从而从面向用户的延迟中节省宝贵的微秒。

我们通过完全在GNet帧内编码1RMA读取请求来实现协议协同设计。从根本上说，读取请求启动从接收端到发送端的数据传输，即，这种请求本质上已经是请求，其在传输层表示。GNet也建立在请求的基础上，但是在L2层。关键的见解是在单个cell类型Req中表达GNet(L2)和1RMA(L4)请求行为。由于Req cell请求反向数据移动，因此GNet处理Req的方式与CTS类似；主要差异来自cell大小，因为Req对读取请求(主机地址、内存标识符、HMAC等)进行完全编码，需要48B，比CTS大3倍的cell。Req在其他方面与CTS的行为类似，因为它可以自由地重新排序，而不违反上面协议层的假设。由于1RMA对无序交付具有高度容忍度，因此Req本质上与Aquila的自适应路由兼容。

我们还利用1RMA与面向主机的PCIe的紧密耦合来分别编码响应cell。1RMA NIC将每个单独的PCIe读完成负载作为一个不同的协议响应发送，这是一种硬件简化，可避免NIC中的响应合并逻辑、缓冲和开销。为了促进GNet中的这种行为，将Resp cell的大小设置为能够处理我们从主机根复合体观察到的最常见的PCIe完成大小。与Req一样，Resp可以自由地重新排序和自适应路由，发起1RMA NIC以到达顺序将各个响应段降落在目标主机内存中，因为不需要恢复整个请求间或请求内响应顺序。

最后，为了将延迟关键的1RMA流量与不太敏感的IP流量隔离开来，我们将大约一半的GNet虚拟通道映射为承载低延迟协议消息，1RMA与低延迟IP流量共享这些消息。由于IP流量是cell化的，1RMA响应不会排队等待来自竞争流的批量传输。总之，Aquila上的1RMA提供了近乎平滑的查找延迟，即使是在传统流量负载下，也可以在4us端到端内部提供大约864TB的DRAM。Aquila传输仅占2.5-3 us；剩余时间归因于PCIe延迟贡献。

## 3.5 嵌入式控制处理器

TiN芯片具有嵌入式控制处理器(ECP)，用于处理所有交换机侧控制和监控动作。硅的成本使ECP尽可能简单，因为它被复制到每个TiN芯片中。ToR的典型控制处理器可能是多核64位处理器，内存为8-16GB，TiN的ECP是32位ARM Cortex M7处理器，只有2MB的SRAM。

为了在GNet逻辑完全初始化之前引导嵌入式控制处理器(第4.4节)，使用管理有序集(MOS)，在GNet结构上实现了低带宽但可靠的带内控制路径。每个MOS 64位bit允许在直接连接的TiN芯片之间传输6个字节的数据，而不管GNet链路层是否up。我们在MOS原语之上分层了一个健壮的数据包实现PMOS，以承载调试和bootstrap通信。

## 3.6 把所有这些放在一起

图4描绘了TiN芯片的整体结构：

该设备具有以下接口：

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l </span><span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">两个x16 PCIe gen 3接口，为一台主机提供256 Gbps连接，或为两台主机中的每台主机提供128 Gbps连接；</span>

大约50%的芯片面积用于实现主机接口或NIC功能，50%用于交换功能。

# 4 软件定义网络

如第3节所述，在单个芯片中集成交换机和NIC将导致管理子系统在Aquila Clique的所有TiN中大量复制。为了保持Aquila Clique的成本效益，TiN ASIC的管理子系统保持简单——一个32位ARM Cortex M7处理器，具有适度的2MB SRAM，没有专用的管理以太网端口。因此，大部分路由计算和状态需要从交换机卸载到逻辑集中的分布式控制器，该控制器必须协调引导，带内fabric的管理和控制。在本节中，我们将介绍Aquila的软件定义网络(SDN)控制平面及其简化的固件如何解决控制和管理Aquila Clique的挑战，具体而言：

## 4.1 控制架构概述

Aquila控制器构建在SDN控制器平台之上，SDN控制器是一个由微服务组成的模块化SDN控制平面，以及一个称为网络信息库(NIB)的中央发布者/订阅者数据库。多个应用程序形成一个Aquila SDN星座，每个应用程序的冗余实例部署在单独的控制服务器上。图5的上半部分详细介绍了Aquila SDN控制器应用程序。

控制器的路由应用程序，即路由引擎(RE)，根据拓扑状态和外部可达性的变化计算Aquila网络块的路由解决方案。以类似于OpenFlow的流和组的形式将解决方案按顺序批量重新写入NIB，以实现无命中路由状态转换。另外，块间路由控制器(IBR)是数据中心范围的SDN控制域中的一个应用程序，它计算各个网络块之间的流量路由解决方案，并为Aquila的RE提供到达Aquila Clique外部目的地的出口路径。

从NIB接收路由更新后，Flow Manager(FM)对流和组编程操作进行排序。例如，只有在为无命中转换安装了流的引用组之后，才安装流，然后通过RPC将其发送到交换机前端应用程序(SFE)。SFE将流和组编程为TiN交换机，在流/组和硬件寄存器值之间进行转换，并使用编程结果完成RPC。然后FM将结果写回NIB供RE使用。

## 4.2 路由状态的处理

结构中的大量GNet端点和TiN交换机中的逐端口GNet路由表导致比非Aquila块大得多的路由状态，这增加了SDN系统中的CPU和内存需求。Aquila路由为IP和GNet流带来了扩展挑战。

**IP流**。一个由1152台主机和576个管理CPU组成的网络，可通过IPv4和IPv6寻址，需要大约190万个流，每个流都有一个输出端口。利用所有这些流都来自少量子网的观察结果，我们引入了一种新的索引组表示法，其中组中端口的索引对应于子网中的相同索引，这又将流的数量减少了576倍(fabric中的TiN数量)。

**GNet流**。如第3节所示，流量控制的GNet需要每个输入端口、每个虚拟通道的流量，这会导致具有50个端口的交换机的状态爆炸。一个简单的实现会导致近500万流量。为了适应如此大的规模，我们利用了路由的显著相似性。例如，第3.1节中描述的所有终端端口使用相同的路由，并且在NIB中仅表示一次。类似地，死锁避免转向规则为TiN芯片中的每个pod内端口定义了类似的角色。此外，所有跨端口的行为都相同。我们引入了六个端口类——表示端口在路由规则方面的等价类——将流的数量减少到大约700k。GNet流使用端口类作为匹配字段和输出操作。在使用端口类接收GNet流时，SFE将其扩展为针对每个成员端口的GNet流表的流，然后从输出中修剪不正确的成员端口，例如，以避免将流量发送回源。然后在交换机中对产生的流量进行编程。

即使有了这些优化，SDN系统的其余部分也需要更多的修改：

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l </span><span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">尽管进行了端口级优化，但NIB中的流量仍然是非Aquila网络块的10倍左右。为了补偿内存的增加，NIB的pub-sub接口被更改为保持压缩格式的状态，并仅在必要时解压。</span>

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l </span><span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">TiN交换机中可用的SRAM不够大，无法保存所有路由状态的快照。SFE能够对硬件编程操作进行速率限制，以避免交换机上的内存溢出。SFE和交换机之间的RPC接口的设计应确保最大的RPC可以装入内存，并且一次只允许一个未完成的RPC</span>

## 4.3 具有受限状态的交换机固件

交换机固件(见图5下半部分)在集成到TiN交换机芯片中的ARM Cortex M7 CPU上运行。由于物理尺寸和成本限制，固件只有2MB的片上SRAM可用。因此，它基于FreeRTOS和lwIP开源库构建，以适应空间限制。固件在大约100k行C和C++中实现。

我们明确决定固件不负责完全配置TiN芯片。通电时，固件启动GNet和以太网链路，并尝试通过以太网进行DHCP。这使控制器能够在初始化期间尽早连接，并完成必要的配置，以允许TiN芯片开始通过流量(详情请参见第4.4节)。

固件公开的编程API是低级的，允许SDN控制器直接访问硬件寄存器。API根据硬件寄存器描述生成，并允许SDN控制器代码使用芯片寄存器的符号名称以方便使用。来自TiN芯片的统计数据和计数器也可以使用低级API报告。SDN控制器能够配置一组应由固件定期报告的寄存器。其中一个编程API设置ARP/NDv6响应，以响应连接机器的请求，从而即使固件失去与SDN控制器的连接，IP到MAC的分辨率也可以正常工作。

固件支持非停止转发(NSF)重新启动，以将升级和意外软件错误造成的中断降至最低。在重新启动期间，固件可避免更改任何可能影响流量的配置。由于带内连接没有中断，控制器能够在重新启动后快速重新连接，而无需经过引导过程。由于采用了寄存器级API，无需保存和恢复状态信息，因此简化了NSF重启的实现，因为TiN芯片在重启期间保持所有控制器可见状态。

虽然固件本身是无状态的，但TiN芯片和SDN控制器不是。固件和SDN控制器之间的任何连接丢失后，必须启动协调过程，以解决硬件寄存器与SDN控制器意图之间的任何差异。如果连接失败时丢失了任何命令，则可能会出现这些差异。

## 4.4 带内控制和引导/Bootstrap

Aquila SDN控制中的一个关键挑战是，从SDN控制器到Aquila交换机的控制信道是带内的。这意味着控制器需要与TiN的管理CPU通信，然后才能对TiN的路由表进行编程。在引导过程中，控制器通过数据中心网络在频带内建立TCP连接，以迭代“波”的形式连接到Clique中的所有TiN，并在获得对每个后续波中TiN的控制时配置和编程路由表。

图 6 显示了通过 pod 内铜 GNet 链路以及 pod 间光 GNet 链路连接的 k 个 Aquila pod。一些TiN(例如，Pod 1和Pod k中的TiN 1、TiN 3)也通过以太网数据中心网络(DCN)链路连接到数据中心的Spine层。我们将这些TiN称为DCN连接。运行在外部控制服务器上的Aquila SDN控制器最初只能通过DCN链路访问。TiN固件通过DCN链路发送DHCP发现消息(如果可用)。这些DHCP消息由spine交换机中继到DHCP服务器，然后DHCP服务器根据TiN MAC地址为TiN管理CPU分配IP地址。

Aquila控制器根据其自身配置记录了每个TiN CPU的IP地址。控制器不断尝试使用分配的IP地址和已知的L4端口号通过TCP会话连接到每个TiN CPU。一旦TiN的固件知道IP地址，则发往该IP的控制器消息将被固件安装的ACL规则捕获并到达固件。响应Ack从数据包进入的同一接口发出，从而启用控制器和DCN连接TiN的交换机CPU之间的TCP连接。然后，控制器可以配置DCN连接的TiN并对其路由表进行编程。

一旦控制器与DCN连接的TiN建立TCP会话，它将该TiN用作代理TiN(如Pod 1、TiN 3)，以使用TiN CPU之间的点到点低带宽分组管理有序集(PMOS)协议(第3.5节)引导直接连接的目标TiN(例如Pod 1和TiN 2)。尚未配置其IP地址的目标TiN-还通过所有GNet链路通过MOS发送DHCP发现消息，这些消息被代理TiN捕获，并通过其自己的会话发送给控制器。控制器进而将发现消息中继到DHCP服务器，并同样中继DHCP响应，以便目标TiN间接了解其分配的IP地址。控制器继续通过PMoS上的代理TiN在目标TiN中配置和编程路由表。编程足够的路由状态后，控制器可以通过GNet路由管道建立到目标TiN的TCP连接，然后代理TiN(Pod 1，TiN 3)可以依次用于引导另一个目标TiN(例如，Pod 1、TiN 4)。一旦使用这个新的目标TiN建立了TCP会话，它也可以用作代理来引导直接连接的TiN(例如Pod 1、TiN 5)，等等。

DCN连接的TiN通常比目标TiN引导更快，目标TiN通过较慢的PMOS协议进行配置，导致引导时间分布在3分钟到48分钟之间。几个引导波同时发生，导致一个全尺寸Clique的启动时间约为2.5小时。

# 5、实验结果

我们提供了一组研究Aquila网络关键方面的结果，包括其数据平面性能及其对所应用度量指标的影响。

## 5.1 数据平面性能

Aquila的数据平面性能在由576个TiN组成的原型Aquila试验台上进行了评估。我们用了500台主机。除非另有规定，否则两台主机共享一个NIC。我们使用了两个工作负载，它们都运行基于延迟的拥塞控制：

UR：一种基于用户空间微内核的IP流量生成器，Pony Express，可生成具有泊松到达的均匀随机流量模式。

CliqueMap：通过Pony Express或1RMA使用远程内存访问(RMA)的键值存储。

对于我们的评估，我们使用了三个指标：

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l </span><span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">**IP结构RTT(µs)**：我们使用NIC硬件时间戳测量Aquila结构RTT，不包括远程主机上的处理和Ack合并延迟。这是对Aquila结构内部传输和排队延迟的真实测量，包括GNet和IP组件。</span>

<span style="font-family: Wingdings;color: #222222;letter-spacing: 1px;font-size: 16px;background: #FFFFFF">l </span><span style="color: #222222; letter-spacing: 1px; font-size: 16px; background: #FFFFFF; font-family: 微软雅黑;">**1RMA总执行延迟(µs)**：从向硬件提交RMA命令到硬件发出该命令完成的时间。该指标测量的不仅仅是结构中的排队和传输延迟，因为它包括远程端的PCIe事务延迟。</span>

负载下的延迟。我们检查了负载下IP和1RMA流量的延迟。我们使用了CliqueMap客户端基准测试，使用RMA进行4KB大小的值查找。通过改变500台主机上CliqueMap客户端的QP，我们以类似于均匀随机的流量模式改变了每台机器提供的负载。图7根据提供的负载绘制了结构RTT。它表明，即使网络接近每台机器50 Gbps的NIC线路速率，并且在70%负载下低于20µs，结构延迟仍保持在40µs以下。

1RMA与GNet共同设计(第3.4节)，图8显示，即使在使用500个CliqueMap客户端从500个CliqueMap后端读取生成的4KB RMA读取的高负载下，该共同设计的总执行时间也低于10µs。

1RMA延迟隔离。Aquila是一个统一的网络，由低延迟1RMA流量和常规IP流量共享，可能对延迟不敏感。在我们的下一次评估中，我们表明，尽管与IP流量共享网络，Aquila仍以低尾延迟提供延迟敏感的流量。为此，我们比较了Aquila和传统以太网中有无背景IP流量的延迟敏感流量的延迟。

对于以太网网络，我们采用标准QoS技术将低延迟(或重要)流量与面向吞吐量的快/批量传输流量隔离。我们在高优先级QoS类(H)上以10000 QPS运行了200个CliqueMap查找实例，在低优先级类(L)上运行了平均负载为10 Gbps的64 KB消息的UR流量模式。H类和L类之间的相对出口调度优先级为8:1。图9中的橙色和青色条形图显示，此类基于QoS的方案为CliqueMap流量与批量IP流量提供了合理的隔离，从而导致HiPri CliqueMap流量在结构RTT中的排队适度增加，尽管基线延迟较高。
<div align="center"> <img src="https://ngdcn.com/zb_users/upload/2022/10/202210071511365524121.png"/> </div>

重复使用1RMA作为传输的相同实验，我们可以看到，Aquila上的1RMA提供了更低的基线(小于5µs的中值和尾部延迟)，尽管与IP流量共享相同的GNet结构。高优先级1RMA流量使用与低优先级Pony Express IP流量不同的虚拟信道，因此几乎不受添加批量流量(蓝色和红色条)的影响。即使低优先级1RMA流量与批量IP流量(黄色和绿色条)共享虚拟通道，总延迟也略高于10µs，但仍低于以太网上的Pony Express流量(橙色和青色条)。
<div align="center"> <img src="https://ngdcn.com/zb_users/upload/2022/10/202210071511462945953.png"/> </div>

突发大小的影响。我们在Aquila学到的教训之一是自拥挤/self-congestion现象。Aquila中的IP网络具有每TiN 100 Gbps的注入速率，而全规模Aquila拓扑中两个POD之间的最短路径上的总带宽限制为50 Gbps。这导致cell采用非最短路由，即使由于突发，总注入速率远低于链路速率。我们通过将点到点流量的注入速率保持在0.6Gbps，但使用Pony Express改变RPC的消息大小来显示这种效果。改变消息大小只会影响注入的突发性。图10显示，随着消息大小的增加，尾部结构延迟增加超过40µs。然而，在Aquila的半规模版本中重复相同的实验，我们将pod间带宽与每个TiN的IP注入速率进行匹配，我们发现消息大小对结构中的排队没有影响。提供更高的最短路径带宽可以在突发流量条件下会折中地得到更好的性能，以换取更小的拓扑最大规模。

## 5.2 应用影响

为了了解应用程序的影响，我们比较了使用1RMA和Pony Express在Aquila网络上作为RMA传输的CliqueMap查找(4KB大小的对象)延迟。我们使用O(100)个后端和客户机，每秒钟从每个客户机发出不同的查询。图11显示了Aquila上的1RMA如何在低QPS时将中值和尾部延迟降低50%，在高QPS时降低300%以上。与之前的工作一样，1RMA的更高负载水平带来更低的延迟，因为单个服务器可能在低负载下处于低功率状态。

# 6、讨论

虽然我们对Aquila设计的方法使我们能够为数据中心网络开发统一的低延迟网络结构，但我们必须克服许多挑战。我们强调了接下来的一些关键挑战。

单芯片部分和直接连接拓扑。虽然单芯片设计为Aquila网络提供了一个规模适中的Clique队和成本效益的可持续发展模型，但该方法对架构和部署有几个关键影响。首先，单个部分意味着我们必须将Aquila部署为直接连接网络拓扑，因为间接拓扑(如Clos网络)对于TiN芯片不可行。虽然直接连接拓扑本身不是缺点，但不利于增量部署。其次，从多代路线图的角度来看，NIC和交换机架构的演变是相互耦合的。

为简单起见，我们将 Aquila Clique 设计为一个同质的部署单元，而无意混合不同代的硬件。此外，整个Clique的网络覆盖范围(最多24个机架容纳所有TiN卡和网络光纤)设计为预先部署，主机可以根据需要逐步填充。使用间接拓扑，可以预先部署少量网络机架(例如4个)，并以增量方式部署服务器机架。对于直连拓扑，所有服务器机架(可能没有服务器)都必须预先部署。此外，对于给定的光技术，间接拓扑支持更大的部署灵活性：所有服务器机架只需位于网络机架半径(比如)100米以内。在我们的直连拓扑结构中，必须小心布局机架占地面积，以使所有机架对之间的GNet光纤长度在(比如)100米的预算范围内。

由于细的最短路径链接导致的自拥塞。Dragonfly拓扑的规模可以增加，直到每对pod之间只有一个全局链接。然而，来自TiN的注入带宽与pod到pod带宽之间的不匹配会导致自拥塞，即使在低负载下，尤其是对于大型MTU数据包，一些cell的路由可能是最小的，而另一些cell的路径可能是非最小的。因此，即使对于低平均负载下的点到点流，由于cell和数据包重组而引入的延迟也存在一些差异。

对于我们最初的Aquila原型，我们选择了576个TiN的Clique大小，其中pod到pod的带宽为2x25Gbps，是每个TiN最大注入带宽200Gbps的1/4，这是Dragonfly配置中Clique规模和自拥塞之间的平衡。此外，我们调整了自适应路由，从最短路径交换到非最短路径，以减少自拥塞造成的差异。

cell交换和请求的开销。cell交换和请求是Aquila实现可预测、低网络延迟的关键功能。由于每个160字节的GNet cell具有8字节的GNet报头，因此交换GNet cell的开销约为5%。尽管RTS/CTS cell通过GNet网络获得高优先级，但每个IP分组的RTS/CTS请求引起了通过网络的额外往返的延迟开销，并且对于具有大MTU的分组，该开销得到了进一步缓解。我们认为这两种开销都是可以接受的，以换取即使在高注入负载下的低尾延迟。考虑到更大的GNet cell大小以及在低负载下不产生请求开销的能力，我们正在研究进一步降低这些开销的技术。

调试cell交换网络。由于Aquila Clique内部不是一个IP路由结构，标准调试工具(如TracerRoute)仅显示整个Aquila结构的1跳。为了调试Aquila中的数据黑洞，我们在TiN中实现了cell trace功能。标记有位的cell被cell路径中的每个TiN采样，并通过UDP发送到中央收集器。然后，收集器可以缝合数据包组成cell的路径，并对任何配置错误或故障硬件进行三角测量。

TiN上的有限RAM和低级固件API。为了节省成本和板空间，我们只为TiN芯片上运行的固件提供了2MB的RAM，这使我们实现了自定义固件。固件开发大大增加了开发工作，因为许多基础设施必须定制或重新实现(例如，日志记录、内存分配和闪存)。

将寄存器级API公开给SDN控制器以编程TiN芯片的决定具有将复杂度从资源受限的固件移开以及简化使用不停止转发(NSF)升级固件的能力的优点。这还意味着，由于硬件的所有功能都已公开，因此无需推出新的固件版本即可实现新功能。这种方法的一个挑战是跨多个硬件代维护该接口，因为SDN控制器需要知道每个芯片的寄存器级细节。

对于未来的设计，我们正在研究向NIC添加更多的计算，以便它可以基于Linux。将RaspberryPi等效计算添加到每个NIC中，相对于开发速度的预期收益，可能会最小程度地增加单位成本。此外，更多的计算将取消使用更高抽象级别的API的障碍，如P4运行时。

遗留应用程序的性能。虽然Aquila为共同设计的案例(如带有1RMA的CliqueMap)提供了显著的应用程序性能改进(第5节)，但它对遗留应用程序没有显著的积极影响。我们观察到，遗留应用程序的尾部延迟由主机软件堆栈控制，包括线程唤醒延迟。此外，对于IP软件堆栈，RTS队列长度由主机拥塞控制算法控制，而不是由GNet结构cell延迟控制。展望未来，我们正在转变传输和网络协议，以在本地利用面向未来的硬件改进，从而造成一种有趣的紧张局势，即在大多数车队部署新设计的硬件之前，大量的软件投资可能不会产生净积极影响。

# 结论

在本文中，我们介绍了Aquila，这是我们首次涉足数据中心网络生态系统中集成的紧密耦合网络(Clique)，实现了Clique规模的资源分解和可预测的低延迟通信。我们的主要目标是倡导围绕Clique的数据中心网络的新设计架构，并鼓励在紧耦合网络中进行新的研究和开发，以支持高性能计算、ML训练和网络分解，同时与数据中心规模的传统TCP/IP/以太网流量进行互操作。我们相信，我们对Aquila原型的经验，无论是正面的还是负面的，都将为未来在这一空间的探索奠定基础。

# 参考文献

Gibson, Dan et al. “Aquila: A unified, low-latency fabric for datacenter networks.” NSDI (2022).

> 译者注：由于本人水平有限，如有纰漏，请以参考文献文章为准。

<font color=red>**欢迎扫码关注微信公众号“网络技术风云汇”，更快速接收更多网络技术咨询。**</font>