软件定义战术边缘数据中心 -- 船舶星阵化技术研究以及为什么需要Rust和WASM

一、抛砖引玉 — 计算机对网络数据包的处理过程

数据包从远端传入本地计算机，其本质只是电信号，需要先经过网卡的处理再进入到内存。这个过程，就是把网线中的高低电平，转换到网卡（NIC）上的一个缓冲区存储（通过网卡的稳压器将模拟信号转换为数字信号）。

数据到达了网卡的缓冲区中，还需要借助DMA配合网卡将数据存入内存的缓冲区，这个过程前提需要在内存中申请一个缓冲区sk_buffer，然后把缓冲区的地址告诉网卡，DMA就会等网卡的缓冲区有数据到来的时候将它拷贝到内核中。当数据包准备就绪，网卡触发CPU中断，中断处理函数将数据包交给上层协议（TCP，IP）处理。

上层协议处理完成后将数据存储到了TCP的缓存区，应用程序再通过系统调用将缓存区的数据拷贝到用户态。[1]这是示意图：

图1-1 图片来源于

https://cseweb.ucsd.edu/classes/fa09/cse124/presentations/TCPlinux_implementation.pdf

二、简单介绍RDMA和RoCE协议

2.1 RDMA和传统TCP/IP对比

如上所知，TCP/IP协议栈在接收发送报文时，‍‍内核需要进行多次上下文切换，‍‍每次切换需要耗费大约5-10μs。‍此外，它还需要至少三次的数据拷贝‍‍，而且需要利用CPU进行协议工作。而仅仅协议上处理就会带来大约几十微秒的‍‍固定时延。可见，传统网络协议栈时延成为数据传输时最明显的瓶颈。

于是，一种新的数据传输技术出现了。RDMA（Remote Direct Memory Access，远程直接数据存取）的内核旁路机制‍‍允许应用与网卡之间直接数据读写，‍‍这样可以将数据传输时延降低到‍‍接近1μs****。而RDMA的‍‍内存零拷贝机制允许接收端直接从发送端的内存读取数据，‍‍极大地减少了CPU的负担，‍‍提高了CPU的利用率。

图2-1 TCP/IP数据传输过程（图片来源于网络，侵删）

图2-2 RDMA数据传输过程（图片来源于网络，侵删）

通过图片对比，我们可以直观地看到，与传统的TCP/IP数据传输方式相比，使用RDMA可以绕过内核，直接从用户空间访问RDMA网卡，避免了操作系统中的多次内存拷贝，从而实现了超低延迟和超大吞吐量的数据传输。[2]不过这里要注意一下，超低延迟的数据传输是有前提条件的。前提条件后面会详细介绍。

2.2 RDMA网络分类

目前，大致有三类RDMA网络，分别是Infiniband、RoCE、iWARP[3]

• Infiniband，无限带宽技术，简称IB。支持RDMA的新一代网络协议，因此需要支持该技术的网卡和交换机。

• RoCE，一个兼容传统以太网的RDMA协议。其较低的网络标头是以太网标头，其较高的网络标头（包括数据）是InfiniBand标头。这使得我们可以在标准以太网基础设施（交换机）上使用RDMA，不过其网卡必须支持RDMA。目前RoCE协议分为两个版本，RoCEv1和RoCEv2。一代的网卡并不兼容二代协议。支持RoCEv2的网卡为Mellanox CX4Pro以后的网卡，具体可以访问NVIDIA官网。

• iWARP，一个允许在TCP上执行RDMA的网络协议。IB和RoCE中存在的功能在iWARP中不受支持。它支持在标准以太网基础设施（交换机）上使用RDMA，并且只需要网卡支持iWARP（如果使用CPU卸载），否则所有iWARP堆栈都在SW中实现，其丧失了大部分RDMA性能优势。

其中RoCE和iWARP协议都有软件层面的兼容方案，即Soft-RoCE和SoftiWARP。本文因为并不会涉及太多iWARP方面的东西，所以只在这简单介绍下Soft-RoCE。

2.2.1 Soft-RoCE简单介绍

Soft-RoCE是RDMA的一种纯软件实现的方式，因此不需要特定的硬件支持，但是其性能与硬件支持的RDMA还是有一些差距的。通过SoftS-RoCE我们可以在传统的以太网进行RoCE通信。

虽然通过软件模拟实现IB传输层带来了一定的性能开销，但是相比基于传统套接字通信方式，Soft-RoCE因为减少了系统调用，发送端的零拷贝以及接收端的只需要单次拷贝等原因，仍然带来了性能上的提升。[4]

简单来说，本地端和远端可以无需具备RDMA网卡，却仍能以RDMA的方式传输数据，其中任意一端如果使用Soft-RoCE，远端是不会感知到它和硬件的区别的，双方能够顺利建立传输通道。

同时，最新的Linux内核已经包含了Soft-RoCE，其使用的就是RoCEv2协议，依赖FUSE运行。现在所讲的RoCE协议，通常就是指RoCEv2协议。

2.2.2 RoCEv2协议介绍

当前RDMA在以太网上的主要传输协议是RoCEv2（RoCEv1基于L2层MAC地址, 不能路由, 只能运行在局域网中），RoCEv2是基于无连接的UDP协议，相比面向连接的TCP协议，UDP协议更加快速、占用CPU资源更少，但其不像TCP协议那样有滑动窗口、确认应答等机制来实现可靠传输。

2.3 RoCE协议补充介绍

RoCE可以运行在无损网络环境和有损网络环境中，如果运行在有损网络环境中，则称为弹性RoCE(Resilient RoCE)；如果运行在无损网络环境中，则称为无损RoCE(Lossless RoCE)。

• 弹性RoCE网络 - 可以发送RoCE流的有损网络环境，即无需开启PFC/ECN的网络环境
  https://community.mellanox.com/s/article/introduction-to-resilient-roce—faq

• 无损RoCE网络 - 网络中开启PFC流控功能，确保网络的无损特性
  https://community.mellanox.com/s/article/roce-v2-considerations#jive_content_id_Resilient_RoCE

简单来说，你只有在无损RoCE网络环境下，才能确保超低延时的数据传输。而有损网络环境下，如果发生丢包，则会导致流量中断。由于InfiniBand的语义，响应方只接收正确顺序的数据包。这时候接收端会将具有特定PSN（数据包序列号）的NACK控制数据包发送到Send端。如果频繁丢包的话，传输性能可想而知。[5]这是示意图：

图2-1 图片来源于

https://community.mellanox.com/s/article/introduction-to-resilient-roce—faq

三、软件定义战术边缘数据中心

3.1 研究意义

目前，地球上海洋总面积约为3.6亿平方公里,地球表面的总面积约5.1亿平方公里，海洋占地球表面总面积的71%，软件定义战术边缘数据中心的首要条件就是需要天地融合的卫星网络架构，而远洋是部署基站的高成本区域。

图3-1 天地网络融合的应用场景 图片来源于[6]

目前地面的移动通信系统大约只能覆盖到整个地球面积的6%，并且在灾难、战争等环境下，陆地网络首当其冲。因此基于陆地网络的数据中心极易遭到破坏损毁。这时，具备战术机动性，可与卫星网络相连接具备高性能数据互传能力的战术边缘数据中心就显得尤为重要。（空基数据中心的部署需要极高成本，就不在这讨论了）同时，战术边缘数据中心也是战术边缘云的核心组成部分。（战术边缘云是美国国防部（DoD）以2018年发布的《美国国防部云战略》为基础，制定了美国本土以外的云战略愿景和目标，即通过战术边缘的云创新实现全域优势。）

“作战人员在战术边缘使用的云设备将被加固并具有适应性，一旦具备足够的带宽或建立新的连接，将自动同步到更大的云。虽然国防部的某些项目不能立即迁移到云上，但其中一些系统可能最终被连接到云，而其他系统可能通过单独的非云解决方案来解决。但总的来说这种信息的自动同步将确保作战人员保留数据，反馈到模型中，并使用最新的算法进行战斗。在安全的环境中执行此操作将是一种力量倍增器，并直接支持云环境构建的主要目标：信息优势。”

2018年《美国国防部云战略》

3.2 软件定义卫星网络

---

天地融合的卫星网络架构依赖于软件定义卫星网络。SDN将网络控制平面与数据平面解耦合的特征使得旧网络协议能够得到更有效革新，有利于解决卫星网络升级难题。此外，SDN逻辑上集中控制和开放可编程的能力极大提升了卫星网络的兼容性，有利于卫星网络与其他网络架构及协议融合。

基于SDN的卫星网络统称为软件定义卫星网络。

不过，目前针对软件定义卫星网络的研究主要都停留在思路框架层面，在关键技术领域仍面临着许多挑战。[7]

虽然对于软件定义卫星网络系统架构的研究已经有了不少成果，但这些研究对于软件定义卫星网络系统架构的认识并不统一，目前尚未在国际上形成标准。基于此，笔者又从另一篇文章中找到一张表格，用来简单介绍当下对于软件定义网络系统的研究成果：

表3-2 卫星网络虚拟化方法比较 表格内容来源于[8]

3.3 船舶星阵化技术

船舶星阵化技术是基于软件定义网络技术、卫星通信和船舶海上通信等技术而诞生的一项非常适合于将远洋船舶改造成软件定义战术边缘数据中心的关键技术。

图3-3 基于海事的天地互联系统的未来构想 图片来源于[9]

图3-4 船舶星阵化链接 图片来源于[9]

表3-5 船舶通信系统比较 表格来源于[9]

表3-6 数据传输速率的大致要求 表格来源于[9]

5G系统将承担起陆地5G基站（简称陆基）与海基之间的服务连续性（未来也许会依靠6G系统）。

多接入系统的一个关键部分是需要依靠连接管理器来确保通信的服务质量（QoS），这需要统一和标准化的通信接口来实现。关于这部分，目前主要依靠D2D和MEC来实现，后面会详细介绍。

频谱共享技术可避免干扰并保证QoS的高质量。而卫星网络融合架构则抛出了新的问题。如何提高传输的可靠性及效果以及如何减少船舶定位系统和连接链路方面的干扰？（我国目前的解决方案是依靠VDES卫星）

关于VDES卫星这部分感兴趣的可以自己去检索相关资料，笔者就不在这详细介绍了。

3.3.1 基于SDN的多接入边缘计算（MEC）

3.3.1.1 解决延迟问题

MEC系统概念背后的两个主要动机是计算卸载和延迟减少。集中式数据中心或公共云的延迟非常高。这就是MEC服务器如此靠近边缘部署的原因。在决定处理请求的位置之前，MEC协调器必须根据客户端请求的延迟、能量和带宽要求做出明智的决策。

在尝试减少延迟时，必须考虑两个主要注意事项：

• 需要考虑客户端和能够处理此客户端请求的MEC服务器之间的距离。

  客户端和MEC服务器之间的距离是一个重要的决定因素。

• 需要比较传输成本与本地计算成本。这有助于确定计算是应该移动到MEC服务器还是应该在客户端本地处理。

MEC协调器需要提出一种解决方案，该解决方案可最大限度地降低设备的能耗，并满足客户端请求或应用程序的执行延迟约束（延迟要求）。

此外，需要考虑应用程序的性质 - 无论是延迟敏感（高响应性要求）还是计算密集型。延迟敏感请求应移至靠近客户端的MEC服务器（即使它们具有较少的资源），而计算密集型请求将针对更强大的MEC服务器（即使它们离客户端设备更远）。因此，来自同一设备的不同网络片可能具有不同的路径，并且可能由不同的MEC服务器处理。

3.3.1.2 SDN控制器与MEC集成

MEC ETSI规范的第一个版本似乎倾向于在虚拟化平台上提供MEC服务作为“网络服务”。这些服务基本上是运行与网络中间盒功能相关的软件的VNF的组合。通过在NFV平台上构建解决方案，可以管理这些MEC服务的完整生命周期（实例化、终止、扩展等）。NFV平台还支持VNF转发图，以在MEC服务上实现VNF的服务链。

将SDN添加到平台可以使网络具有更大的灵活性和动态性。SDN允许底层网络的全局视图，因此可以应用流量导向规则来实现复杂的服务链场景。它可用于管理互连分布式MEC服务器的网络。

SDN控制器可以托管“MEC协调器北向应用程序”，可以对其进行编程以处理各种情况：

• 监控在MEC服务器上运行的服务实例，以确定在计算能力、存储区域或某种服务类型方面可以使用哪个MEC服务器为终端设备上的客户端应用程序的请求提供服务？

• 监控MEC服务器的容量和利用率，以决定应该使用哪个MEC服务器来实例化服务实例？

• 如果有多个MEC服务器运行相同服务的实例，那么应选择哪一个来处理此服务的终端设备请求？

  理想情况下，请求应移至负载较小的服务器。

因此，MEC协调器可以重用SDN架构，其中定制的北向应用定义了网络的行为。SDN控制器为这些应用程序提供北向API以触发命令。控制器还具有南向接口（通常是基于OpenFlow），它与被管理设备通信（在网络中使用OpenFlow交换机）。

来自MEC协调器北向应用程序的命令可以由SDN控制器转换为基于OpenFlow的低层流量控制规则，并发送到在网络中连接到MEC服务器或作为MEC服务器的一部分的OpenFlow设备。这些OpenFlow规则可以与MEC服务器上运行的“流量卸载服务”的规则集成。“流量卸载服务”是负责将流量路由到MEC应用程序或MEC应用程序的MEC平台服务。

SDN可以通过多种方式帮助基于MEC的基础设施：

• 计算负载平衡：

  使用与OpenFlow兼容服务器的南向接口定期收集基于OpenFlow的统计信息。

• 更简单的终端设备：

  通过支持以服务为中心的访问而不是以主机为中心的访问，所有服务实例都可以注册到SDN控制器。

• 网络边缘设备的易即插即用能力：

  SDN在很大程度上依赖于OpenFlow - 使用LLDP /OFDP可以轻松检测到新设备，并且可以轻松更新流量规则。

• 计算卸载的决策：

  集中式SDN控制器可以为设备提供有关信道条件，服务器负载等信息。

因此，可以在MEC中使用SDN概念来提供统一的控制平面接口，检索网络上下文或设备信息，并随后将该信息用于跨网络的智能流量控制。

以上关于MEC部分的内容全部来自[10]

图3-7 图片来源于[11]

简单来说，船舶星阵化技术的核心在于最佳的SDN控制器数量和位置以及网络和MEC服务器之间的互联方案。船舶可以看作是分布式系统架构中的节点，船舶之间的位置和距离以及通信方式将会对SDN的时延指标产生重大的影响。同时，SDN交换机和SDN控制器的部署策略也会严重关系到RDMA的传输性能。

3.4 软件定义数据中心

软件定义的数据中心（SDDC）是架构数据中心的一套总体性的思路，它包含三个部分：

• 软件定义计算（虚拟化服务器技术）

• 软件定义网络 SDN（包含还未实现的软件定义智能网卡）

• 软件定义存储 SDS

软件定义数据中心可以抽象并自动化物理方面的一切传统计算、存储和网络。这种自动化和抽象可以增强安全性，对于战术边缘数据中心来讲是最适合的。（如同在Rust里面，对于unsafe代码的封装也可以使得外部调用变得safe）

在过去的几年里，VMware一直在增加对ESXi（一种服务器虚拟化技术）的RDMA支持，可以预见，RDMA终将成为软件定义数据中心（虚拟化数据中心）的主要传输技术。[12]

四、为什么需要Rust

其实2019年的一篇文章【面向海上战术云的信息资源服务架构设计】[13]已经展望到了对于海基力量扩展为海上战术云的可行性，不过这篇文章只提出了架构的设想并未涉及底层的实现措施，且文章中的外部平台接入方案提到的JMS、AMQP等消息队列协议都是基于JAVA开发的，JAVA是基于JVM的具备GC的语言，GC时会存在世界暂停问题，除此之外，前不久，Apache Log4j2（基于Java 的日志记录工具）远程代码执行漏洞席卷全球，对不少企业带来巨大损失。还有其他问题，笔者就不在这一一展开了。

笔者认为JAVA可能并不适合用于未来战场或灾难环境中。以笔者的角度来看，Rust作为战术边缘云的主要开发语言将具备极大的优势，下面笔者将从四点进行详细说明。

4.1 性能和安全

Rust 速度惊人（可以媲美C/C++）而且内存利用率极高。由于没有运行时和垃圾回收机制，它能够胜任对性能要求特别高的服务。

Rust独特的所有权机制以及生命周期机制保证了内存安全和线程安全。Rust可以在利用极低的资源消耗同时做到安全高效以及兼备大规模并发能力，用Rust尝试开发兼备稳定性和极致性能的服务器程序或协议将不再是幻想，谁说鱼和熊掌不能兼得？

4.2 兼容性

Rust 语言和编译器有一个为期 6 周的发布循环。这意味着用户会稳定得到新功能的更新。其他编程语言发布大更新但不甚频繁；Rust 选择更为频繁的发布小更新。一段时间之后，所有这些小更新会日积月累。

每两到三年，Rust 团队会生成一个新的 Rust 版本（edition）。每一个版本会结合已经落地的功能，并提供一个清晰的带有完整更新文档和工具的功能包。新版本会作为常规的 6 周发布过程的一部分发布。

Cargo.toml 中的 edition 字段表明代码应该使用哪个版本编译。如果该字段不存在，其默认为 2015 以提供后向兼容性。

每个项目都可以选择不同于默认的 2015 edition 的版本。（Rust目前更新为2021版本）这样，版本可能会包含不兼容的修改，比如新增关键字可能会与代码中的标识符冲突并导致错误。不过除非选择兼容这些修改，（旧）代码仍将能够编译，即便升级了 Rust 编译器的版本。

所有 Rust 编译器都支持任何之前存在的编译器版本，并可以链接任何支持版本的 crate。编译器修改只影响最初的解析代码的过程。因此，如果你使用 Rust 2015 而某个依赖使用 Rust 2021，你的项目仍旧能够编译并使用该依赖。反之，若项目使用 Rust 2021 而依赖使用 Rust 2015 亦可工作。[14]

而广泛使用的JAVA以及Python语言在版本的兼容性上都无法尽善尽美，从长远的角度来看，是不适合作为战术边缘云在应用层的主要编程语言的。

4.3 云原生和边缘计算的未来

过去几年，云计算的边界不断向边缘侧延伸。作为云原生技术事实标准的Kubernetes+容器组合，自然也被很多人考虑部署到边缘侧。不过K8s+容器组对于边缘计算场景来说，还是太过重了。因为边缘设备通常硬件资源有限，没有足够的资源部署运行完整的K8s。

很多边缘设备基于ARM架构，但大部分K8s发行版不支持ARM架构。同时，很多边缘设备所处环境复杂，无法保证稳定可靠的网络连接，而K8s的致命问题就是不支持离线运行。所以对于战术边缘云来讲，首先Pass。

========================================================================================================

而传统容器方案，比如Docker，问题与K8s类似，Docker镜像大小很容易就达到一两百MB以上，边缘场景有不少内存和磁盘空间小于1GB的微型设备，所以Docker对于战术边缘云来讲也得Pass。

边缘计算不仅需要更轻量的K8s，也需要更轻量、更快的容器方案，**WebAssembly(WASM)**就是近几年出现的一个新选择。

2021 年，云原生社区对 WebAssembly 的兴趣愈发浓厚，WebAssembly 在云原生方向也十分活跃。到目前为止，CNCF 已经正式接收了至少三个 WebAssembly 项目，包括：WasmEdge Runtime，一个云原生 WebAssembly runtime；wasmCloud，一个 WebAssembly 应用程序框架；Krustlet，一个在 Kubernetes pods 中运行 WebAssembly 程序的工具。其中，WasmEdge 和 Kruslet 通过两种不同的方式，做到了让 Kubernetes 集群中的 WebAssembly 工作负载可以与传统容器（例如 containerd、Docker 和 CRI-O）并列运行，用户可以使用与管理 Docker 应用程序完全相同的工具来管理 WebAssembly 应用程序。

而说到 WebAssembly 最初与 Docker、云原生产生关联，就不得不提 Docker 联合创始人 Solomon Hykes 在 2019 年 3 月份发布的一条推文。他在推文中表示：如果 WASM（WebAssembly）和 WASI（WebAssembly System Interface, WASM 系统接口）在 2008 年就已经存在，那就没有必要创建 Docker 了。

WasmEdge 目前的重点是推动 WebAssembly 更快地整合到后端生态里面，进而往云原生和边缘计算方向走得更远、更快。前不久，团队与 FutureWei 合作为 seL4 和 WasmEdge 构建了一个 WebAssembly 管理代理，使 WebAssembly 字节码应用程序能在 seL4 RTOS 上简单地被部署和执行，这样一来在如自动驾驶汽车、无人机这样的边缘设备上也可以方便地运行应用程序容器。

以上关于WASM的内容来自[15]

而WebAssembly和Rust是紧密相关联的。WebAssembly是基于堆栈的虚拟机的二进制指令格式，它被设计为编程语言的可移植编译目标。目前很多语言都已经将 WebAssembly 作为它的编译目标了，但是不同的语言编译的成熟度不同。目前最高成熟度的语言有几个：C/C++/Rust。

目前对于WebAssembly来说的最佳选择还是Rust。因为Mozilla同时全力在推 WebAssembly 和 Rust（WebAssembly 标准是由Mozilla主导的，同时Rust也诞生于Mozilla）。[16]更多细节可以去Rust中文社区查看。

4.4 对RDMA的支持方案

4.4.1 Async-RDMA

Datenlord封装了一层符合Rust风格、便于Rust开发者使用的RDMA Rust binding，目前已经开源。包括rdma-sys和async-rdma，前者是对RDMA接口的unsafe封装，后者是safe封装（尚未完成）。[17]

项目地址：https://github.com/datenlord/async-rdma

4.4.2 Async-UCX

UCX 是一个高性能网络通信库，它作为 MPI 所依赖的通信模块之一在高性能计算领域得到广泛的使用。UCX 使用 C 语言编写，为了在 Rust 项目中使用它，需要将它的 C 接口包装成 Rust 库。清华大学团队用 Rust 实现的高性能分布式文件系统 MadFS，底层就使用了Rust包装过的UCX作为通信模块，它在大规模 RDMA 网络上展现出了良好的性能。[18]

项目地址：https://github.com/madsys-dev/async-ucx

总结

笔者使用总体架构图来总结构成软件定义战术边缘数据中心的技术要点吧。（原创部分，转载请说明）

图4-1 SDX技术平面架构剖析图（以船载平台为例）

图4-2 软件定义战术边缘数据中心宏观架构图（以船载平台为例）

在编程语言方面，链路层需要p4语言的加持，而应用层的开发则离不开Rust和WebAssembly。Rust不仅可以编译成WASM运行在WASM虚拟机上，还可以运行在eBPF中，这两种虚拟机技术都是当今云原生领域最火的。所以，笔者只想说一句，Rust战未来！

参考引用

[1] https://mp.weixin.qq.com/s/uIASAeayB7noOrBOzBc3_g

[2] https://blog.csdn.net/qq_21125183/article/details/80563463

[3] https://community.fs.com/blog/roce-rdma-over-converged-ethernet.html

[4] https://zhuanlan.zhihu.com/p/361740115

[5] https://community.mellanox.com/s/article/introduction-to-resilient-roce—faq

[6] 面向天地融合的卫星网络架构和传输关键技术 - 徐晖,缪德山,康绍莉,孙韶辉 · 大唐移动通信设备有限公司

[7] 软件定义卫星网络关键技术研究 - 吴帅 · 国防科技大学

[8] 卫星网络组网关键技术研究综述 - 吴炀 · 国防科技大学

[9] ViRePAS - Virtual Research Platform for Autonomous Ships - Marko Höyhtyä

[10] https://www.sdnlab.com/21700.html

[11] 5G Cellular D2D RDMA Clusters - Yitzhak Bar Geva

[12] https://zhuanlan.zhihu.com/p/362880535

[13] 面向海上战术云的信息资源服务架构设计 - 唐素纯,李 宁,于 钺,韦广立 · 中国舰船研究院

[14] https://kaisery.github.io/trpl-zh-cn/appendix-05-editions.html

[15] https://mp.weixin.qq.com/s/BoZ5lFtZynRwf2rRdw6kXA

[16] https://blog.csdn.net/u012067469/article/details/100100813/

[17] https://rustmagazine.github.io/rust_magazine_2021/chapter_3/rust_rdma.html

[18] https://zhuanlan.zhihu.com/p/397199431

最后

本文章部分内容参考或来源于网络，无法做到准确溯源，如涉及版权问题，请第一时间告知本人，本人会立刻删除相关内容或补上引用说明。（笔者联系方式：gongshu@petalmail.com）对于大幅引用片段的标题笔者已作标红，这种引用是为了保护技术的权威性，同时彰显重要性，如果通过简化描述或者是近似描述的方式将不能表达出引用文章和技术对于本文章的必要性以及保证严谨性，所以这种引用并非是恶意的。

本文章的目的仅是为了笔者正在编写的一个后续将会开源的基于Rust的高性能文件传输协议做前调，对于文章内容的真实性请读者自行判断，请勿将该文章用作其他用途，由此产生的一切后果笔者概不承担。

END