一、拋磚引玉 — 計(jì)算機(jī)對(duì)網(wǎng)絡(luò)數(shù)據(jù)包的處理過程

圖1-1 圖片來源于

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

二、簡(jiǎn)單介紹RDMA和RoCE協(xié)議

2.1 RDMA和傳統(tǒng)TCP/IP對(duì)比

圖2-1 TCP/IP數(shù)據(jù)傳輸過程（圖片來源于網(wǎng)絡(luò)，侵刪）

圖2-2 RDMA數(shù)據(jù)傳輸過程（圖片來源于網(wǎng)絡(luò)，侵刪）

??通過圖片對(duì)比，我們可以直觀地看到，與傳統(tǒng)的TCP/IP數(shù)據(jù)傳輸方式相比，使用RDMA可以繞過內(nèi)核，直接從用戶空間訪問RDMA網(wǎng)卡，避免了操作系統(tǒng)中的多次內(nèi)存拷貝，從而實(shí)現(xiàn)了超低延遲和超大吞吐量的數(shù)據(jù)傳輸。[2]不過這里要注意一下，超低延遲的數(shù)據(jù)傳輸是有前提條件的。前提條件后面會(huì)詳細(xì)介紹。

2.2 RDMA網(wǎng)絡(luò)分類

??目前，大致有三類RDMA網(wǎng)絡(luò)，分別是Infiniband、RoCE、iWARP[3]

• Infiniband，無限帶寬技術(shù)，簡(jiǎn)稱IB。支持RDMA的新一代網(wǎng)絡(luò)協(xié)議，因此需要支持該技術(shù)的網(wǎng)卡和交換機(jī)。

• RoCE，一個(gè)兼容傳統(tǒng)以太網(wǎng)的RDMA協(xié)議。其較低的網(wǎng)絡(luò)標(biāo)頭是以太網(wǎng)標(biāo)頭，其較高的網(wǎng)絡(luò)標(biāo)頭（包括數(shù)據(jù)）是InfiniBand標(biāo)頭。這使得我們可以在標(biāo)準(zhǔn)以太網(wǎng)基礎(chǔ)設(shè)施（交換機(jī)）上使用RDMA，不過其網(wǎng)卡必須支持RDMA。目前RoCE協(xié)議分為兩個(gè)版本，RoCEv1和RoCEv2。一代的網(wǎng)卡并不兼容二代協(xié)議。支持RoCEv2的網(wǎng)卡為Mellanox CX4Pro以后的網(wǎng)卡，具體可以訪問NVIDIA官網(wǎng)。

• iWARP，一個(gè)允許在TCP上執(zhí)行RDMA的網(wǎng)絡(luò)協(xié)議。IB和RoCE中存在的功能在iWARP中不受支持。它支持在標(biāo)準(zhǔn)以太網(wǎng)基礎(chǔ)設(shè)施（交換機(jī)）上使用RDMA，并且只需要網(wǎng)卡支持iWARP（如果使用CPU卸載），否則所有iWARP堆棧都在SW中實(shí)現(xiàn)，其喪失了大部分RDMA性能優(yōu)勢(shì)。

??其中RoCE和iWARP協(xié)議都有軟件層面的兼容方案，即Soft-RoCE和SoftiWARP。本文因?yàn)椴⒉粫?huì)涉及太多iWARP方面的東西，所以只在這簡(jiǎn)單介紹下Soft-RoCE。

2.2.1 Soft-RoCE簡(jiǎn)單介紹

??Soft-RoCE是RDMA的一種純軟件實(shí)現(xiàn)的方式，因此不需要特定的硬件支持，但是其性能與硬件支持的RDMA還是有一些差距的。通過SoftS-RoCE我們可以在傳統(tǒng)的以太網(wǎng)進(jìn)行RoCE通信。

??雖然通過軟件模擬實(shí)現(xiàn)IB傳輸層帶來了一定的性能開銷，但是相比基于傳統(tǒng)套接字通信方式，Soft-RoCE因?yàn)闇p少了系統(tǒng)調(diào)用，發(fā)送端的零拷貝以及接收端的只需要單次拷貝等原因，仍然帶來了性能上的提升。[4]

??簡(jiǎn)單來說，本地端和遠(yuǎn)端可以無需具備RDMA網(wǎng)卡，卻仍能以RDMA的方式傳輸數(shù)據(jù)，其中任意一端如果使用Soft-RoCE，遠(yuǎn)端是不會(huì)感知到它和硬件的區(qū)別的，雙方能夠順利建立傳輸通道。

??同時(shí)，最新的Linux內(nèi)核已經(jīng)包含了Soft-RoCE，其使用的就是RoCEv2協(xié)議，依賴FUSE運(yùn)行。現(xiàn)在所講的RoCE協(xié)議，通常就是指RoCEv2協(xié)議。

2.2.2 RoCEv2協(xié)議介紹

??當(dāng)前RDMA在以太網(wǎng)上的主要傳輸協(xié)議是RoCEv2（RoCEv1基于L2層MAC地址, 不能路由, 只能運(yùn)行在局域網(wǎng)中），RoCEv2是基于無連接的UDP協(xié)議，相比面向連接的TCP協(xié)議，UDP協(xié)議更加快速、占用CPU資源更少，但其不像TCP協(xié)議那樣有滑動(dòng)窗口、確認(rèn)應(yīng)答等機(jī)制來實(shí)現(xiàn)可靠傳輸。

2.3 RoCE協(xié)議補(bǔ)充介紹

??RoCE可以運(yùn)行在無損網(wǎng)絡(luò)環(huán)境和有損網(wǎng)絡(luò)環(huán)境中，如果運(yùn)行在有損網(wǎng)絡(luò)環(huán)境中，則稱為彈性RoCE(Resilient RoCE)；如果運(yùn)行在無損網(wǎng)絡(luò)環(huán)境中，則稱為無損RoCE(Lossless RoCE)。

• 彈性RoCE網(wǎng)絡(luò) - 可以發(fā)送RoCE流的有損網(wǎng)絡(luò)環(huán)境，即無需開啟PFC/ECN的網(wǎng)絡(luò)環(huán)境https://community.mellanox.com/s/article/introduction-to-resilient-roce---faq

• 無損RoCE網(wǎng)絡(luò) - 網(wǎng)絡(luò)中開啟PFC流控功能，確保網(wǎng)絡(luò)的無損特性https://community.mellanox.com/s/article/roce-v2-considerations#jive_content_id_Resilient_RoCE

??簡(jiǎn)單來說，你只有在無損RoCE網(wǎng)絡(luò)環(huán)境下，才能確保超低延時(shí)的數(shù)據(jù)傳輸。而有損網(wǎng)絡(luò)環(huán)境下，如果發(fā)生丟包，則會(huì)導(dǎo)致流量中斷。由于InfiniBand的語義，響應(yīng)方只接收正確順序的數(shù)據(jù)包。這時(shí)候接收端會(huì)將具有特定PSN（數(shù)據(jù)包序列號(hào)）的NACK控制數(shù)據(jù)包發(fā)送到Send端。如果頻繁丟包的話，傳輸性能可想而知。[5]這是示意圖：

圖2-1?圖片來源于

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

三、軟件定義戰(zhàn)術(shù)邊緣數(shù)據(jù)中心

3.1 研究意義

目前，地球上海洋總面積約為3.6億平方公里,地球表面的總面積約5.1億平方公里，海洋占地球表面總面積的71%，軟件定義戰(zhàn)術(shù)邊緣數(shù)據(jù)中心的首要條件就是需要天地融合的衛(wèi)星網(wǎng)絡(luò)架構(gòu)，而遠(yuǎn)洋是部署基站的高成本區(qū)域。

??

“作戰(zhàn)人員在戰(zhàn)術(shù)邊緣使用的云設(shè)備將被加固并具有適應(yīng)性，一旦具備足夠的帶寬或建立新的連接，將自動(dòng)同步到更大的云。雖然國防部的某些項(xiàng)目不能立即遷移到云上，但其中一些系統(tǒng)可能最終被連接到云，而其他系統(tǒng)可能通過單獨(dú)的非云解決方案來解決。但總的來說這種信息的自動(dòng)同步將確保作戰(zhàn)人員保留數(shù)據(jù)，反饋到模型中，并使用最新的算法進(jìn)行戰(zhàn)斗。在安全的環(huán)境中執(zhí)行此操作將是一種力量倍增器，并直接支持云環(huán)境構(gòu)建的主要目標(biāo)：信息優(yōu)勢(shì)。” 2018年《美國國防部云戰(zhàn)略》

3.2 軟件定義衛(wèi)星網(wǎng)絡(luò)

??天地融合的衛(wèi)星網(wǎng)絡(luò)架構(gòu)依賴于軟件定義衛(wèi)星網(wǎng)絡(luò)。SDN將網(wǎng)絡(luò)控制平面與數(shù)據(jù)平面解耦合的特征使得舊網(wǎng)絡(luò)協(xié)議能夠得到更有效革新，有利于解決衛(wèi)星網(wǎng)絡(luò)升級(jí)難題。此外，SDN邏輯上集中控制和開放可編程的能力極大提升了衛(wèi)星網(wǎng)絡(luò)的兼容性，有利于衛(wèi)星網(wǎng)絡(luò)與其他網(wǎng)絡(luò)架構(gòu)及協(xié)議融合。

??基于SDN的衛(wèi)星網(wǎng)絡(luò)統(tǒng)稱為軟件定義衛(wèi)星網(wǎng)絡(luò)。

??不過，目前針對(duì)軟件定義衛(wèi)星網(wǎng)絡(luò)的研究主要都停留在思路框架層面，在關(guān)鍵技術(shù)領(lǐng)域仍面臨著許多挑戰(zhàn)。[7]

??雖然對(duì)于軟件定義衛(wèi)星網(wǎng)絡(luò)系統(tǒng)架構(gòu)的研究已經(jīng)有了不少成果，但這些研究對(duì)于軟件定義衛(wèi)星網(wǎng)絡(luò)系統(tǒng)架構(gòu)的認(rèn)識(shí)并不統(tǒng)一，目前尚未在國際上形成標(biāo)準(zhǔn)?；诖?，筆者又從另一篇文章中找到一張表格，用來簡(jiǎn)單介紹當(dāng)下對(duì)于軟件定義網(wǎng)絡(luò)系統(tǒng)的研究成果：

表3-2 衛(wèi)星網(wǎng)絡(luò)虛擬化方法比較 表格內(nèi)容來源于[8]

3.3 船舶星陣化技術(shù)

??船舶星陣化技術(shù)是基于軟件定義網(wǎng)絡(luò)技術(shù)、衛(wèi)星通信和船舶海上通信等技術(shù)而誕生的一項(xiàng)非常適合于將遠(yuǎn)洋船舶改造成軟件定義戰(zhàn)術(shù)邊緣數(shù)據(jù)中心的關(guān)鍵技術(shù)。

圖3-3 基于海事的天地互聯(lián)系統(tǒng)的未來構(gòu)想 圖片來源于[9]

圖3-4 船舶星陣化鏈接 圖片來源于[9]

表3-5 船舶通信系統(tǒng)比較 表格來源于[9]

表3-6?數(shù)據(jù)傳輸速率的大致要求?表格來源于[9]

3.3.1 基于SDN的多接入邊緣計(jì)算（MEC）

3.3.1.1 解決延遲問題

??MEC系統(tǒng)概念背后的兩個(gè)主要?jiǎng)訖C(jī)是計(jì)算卸載和延遲減少。集中式數(shù)據(jù)中心或公共云的延遲非常高。這就是MEC服務(wù)器如此靠近邊緣部署的原因。在決定處理請(qǐng)求的位置之前，MEC協(xié)調(diào)器必須根據(jù)客戶端請(qǐng)求的延遲、能量和帶寬要求做出明智的決策。

在嘗試減少延遲時(shí)，必須考慮兩個(gè)主要注意事項(xiàng)：

• 需要考慮客戶端和能夠處理此客戶端請(qǐng)求的MEC服務(wù)器之間的距離。

  客戶端和MEC服務(wù)器之間的距離是一個(gè)重要的決定因素。

• 需要比較傳輸成本與本地計(jì)算成本。這有助于確定計(jì)算是應(yīng)該移動(dòng)到MEC服務(wù)器還是應(yīng)該在客戶端本地處理。

3.3.1.2 SDN控制器與MEC集成

??MEC ETSI規(guī)范的第一個(gè)版本似乎傾向于在虛擬化平臺(tái)上提供MEC服務(wù)作為“網(wǎng)絡(luò)服務(wù)”。這些服務(wù)基本上是運(yùn)行與網(wǎng)絡(luò)中間盒功能相關(guān)的軟件的VNF的組合。通過在NFV平臺(tái)上構(gòu)建解決方案，可以管理這些MEC服務(wù)的完整生命周期（實(shí)例化、終止、擴(kuò)展等）。NFV平臺(tái)還支持VNF轉(zhuǎn)發(fā)圖，以在MEC服務(wù)上實(shí)現(xiàn)VNF的服務(wù)鏈。

??將SDN添加到平臺(tái)可以使網(wǎng)絡(luò)具有更大的靈活性和動(dòng)態(tài)性。SDN允許底層網(wǎng)絡(luò)的全局視圖，因此可以應(yīng)用流量導(dǎo)向規(guī)則來實(shí)現(xiàn)復(fù)雜的服務(wù)鏈場(chǎng)景。它可用于管理互連分布式MEC服務(wù)器的網(wǎng)絡(luò)。

SDN控制器可以托管“MEC協(xié)調(diào)器北向應(yīng)用程序”，可以對(duì)其進(jìn)行編程以處理各種情況：

• 監(jiān)控在MEC服務(wù)器上運(yùn)行的服務(wù)實(shí)例，以確定在計(jì)算能力、存儲(chǔ)區(qū)域或某種服務(wù)類型方面可以使用哪個(gè)MEC服務(wù)器為終端設(shè)備上的客戶端應(yīng)用程序的請(qǐng)求提供服務(wù)？

• 監(jiān)控MEC服務(wù)器的容量和利用率，以決定應(yīng)該使用哪個(gè)MEC服務(wù)器來實(shí)例化服務(wù)實(shí)例？

• 如果有多個(gè)MEC服務(wù)器運(yùn)行相同服務(wù)的實(shí)例，那么應(yīng)選擇哪一個(gè)來處理此服務(wù)的終端設(shè)備請(qǐng)求？

  理想情況下，請(qǐng)求應(yīng)移至負(fù)載較小的服務(wù)器。

??因此，MEC協(xié)調(diào)器可以重用SDN架構(gòu)，其中定制的北向應(yīng)用定義了網(wǎng)絡(luò)的行為。SDN控制器為這些應(yīng)用程序提供北向API以觸發(fā)命令。控制器還具有南向接口（通常是基于OpenFlow），它與被管理設(shè)備通信（在網(wǎng)絡(luò)中使用OpenFlow交換機(jī)）。

??來自MEC協(xié)調(diào)器北向應(yīng)用程序的命令可以由SDN控制器轉(zhuǎn)換為基于OpenFlow的低層流量控制規(guī)則，并發(fā)送到在網(wǎng)絡(luò)中連接到MEC服務(wù)器或作為MEC服務(wù)器的一部分的OpenFlow設(shè)備。這些OpenFlow規(guī)則可以與MEC服務(wù)器上運(yùn)行的“流量卸載服務(wù)”的規(guī)則集成?！傲髁啃遁d服務(wù)”是負(fù)責(zé)將流量路由到MEC應(yīng)用程序或MEC應(yīng)用程序的MEC平臺(tái)服務(wù)。

SDN可以通過多種方式幫助基于MEC的基礎(chǔ)設(shè)施：

• 計(jì)算負(fù)載平衡：

  使用與OpenFlow兼容服務(wù)器的南向接口定期收集基于OpenFlow的統(tǒng)計(jì)信息。

• 更簡(jiǎn)單的終端設(shè)備：

  通過支持以服務(wù)為中心的訪問而不是以主機(jī)為中心的訪問，所有服務(wù)實(shí)例都可以注冊(cè)到SDN控制器。

• 網(wǎng)絡(luò)邊緣設(shè)備的易即插即用能力：

  SDN在很大程度上依賴于OpenFlow - 使用LLDP /OFDP可以輕松檢測(cè)到新設(shè)備，并且可以輕松更新流量規(guī)則。

• 計(jì)算卸載的決策：

  集中式SDN控制器可以為設(shè)備提供有關(guān)信道條件，服務(wù)器負(fù)載等信息。

??因此，可以在MEC中使用SDN概念來提供統(tǒng)一的控制平面接口，檢索網(wǎng)絡(luò)上下文或設(shè)備信息，并隨后將該信息用于跨網(wǎng)絡(luò)的智能流量控制。

以上關(guān)于MEC部分的內(nèi)容全部來自[10]

??圖3-7?圖片來源于[11]

3.4 軟件定義數(shù)據(jù)中心

??軟件定義的數(shù)據(jù)中心（SDDC）是架構(gòu)數(shù)據(jù)中心的一套總體性的思路，它包含三個(gè)部分：

• 軟件定義計(jì)算（虛擬化服務(wù)器技術(shù)）

• 軟件定義網(wǎng)絡(luò) SDN（包含還未實(shí)現(xiàn)的軟件定義智能網(wǎng)卡）

• 軟件定義存儲(chǔ) SDS

?? 軟件定義數(shù)據(jù)中心可以抽象并自動(dòng)化物理方面的一切傳統(tǒng)計(jì)算、存儲(chǔ)和網(wǎng)絡(luò)。這種自動(dòng)化和抽象可以增強(qiáng)安全性，對(duì)于戰(zhàn)術(shù)邊緣數(shù)據(jù)中心來講是最適合的。（如同在Rust里面，對(duì)于unsafe代碼的封裝也可以使得外部調(diào)用變得safe）

?? 在過去的幾年里，VMware一直在增加對(duì)ESXi（一種服務(wù)器虛擬化技術(shù)）的RDMA支持，可以預(yù)見，RDMA終將成為軟件定義數(shù)據(jù)中心（虛擬化數(shù)據(jù)中心）的主要傳輸技術(shù)。[12]

四、為什么需要Rust

??其實(shí)2019年的一篇文章【面向海上戰(zhàn)術(shù)云的信息資源服務(wù)架構(gòu)設(shè)計(jì)】[13]已經(jīng)展望到了對(duì)于?；α繑U(kuò)展為海上戰(zhàn)術(shù)云的可行性，不過這篇文章只提出了架構(gòu)的設(shè)想并未涉及底層的實(shí)現(xiàn)措施，且文章中的外部平臺(tái)接入方案提到的JMS、AMQP等消息隊(duì)列協(xié)議都是基于JAVA開發(fā)的，JAVA是基于JVM的具備GC的語言，GC時(shí)會(huì)存在世界暫停問題，除此之外，前不久，Apache Log4j2（基于Java 的日志記錄工具）遠(yuǎn)程代碼執(zhí)行漏洞席卷全球，對(duì)不少企業(yè)帶來巨大損失。還有其他問題，筆者就不在這一一展開了。

??筆者認(rèn)為JAVA可能并不適合用于未來戰(zhàn)場(chǎng)或?yàn)?zāi)難環(huán)境中。以筆者的角度來看，Rust作為戰(zhàn)術(shù)邊緣云的主要開發(fā)語言將具備極大的優(yōu)勢(shì)，下面筆者將從四點(diǎn)進(jìn)行詳細(xì)說明。

4.1?性能和安全

Rust 語言和編譯器有一個(gè)為期 6 周的發(fā)布循環(huán)。這意味著用戶會(huì)穩(wěn)定得到新功能的更新。其他編程語言發(fā)布大更新但不甚頻繁；Rust 選擇更為頻繁的發(fā)布小更新。一段時(shí)間之后，所有這些小更新會(huì)日積月累。

每?jī)傻饺?，Rust 團(tuán)隊(duì)會(huì)生成一個(gè)新的 Rust?版本（edition）。每一個(gè)版本會(huì)結(jié)合已經(jīng)落地的功能，并提供一個(gè)清晰的帶有完整更新文檔和工具的功能包。新版本會(huì)作為常規(guī)的 6 周發(fā)布過程的一部分發(fā)布。

每個(gè)項(xiàng)目都可以選擇不同于默認(rèn)的 2015 edition 的版本。（Rust目前更新為2021版本）這樣，版本可能會(huì)包含不兼容的修改，比如新增關(guān)鍵字可能會(huì)與代碼中的標(biāo)識(shí)符沖突并導(dǎo)致錯(cuò)誤。不過除非選擇兼容這些修改，（舊）代碼仍將能夠編譯，即便升級(jí)了 Rust 編譯器的版本。

所有 Rust 編譯器都支持任何之前存在的編譯器版本，并可以鏈接任何支持版本的 crate。編譯器修改只影響最初的解析代碼的過程。因此，如果你使用 Rust 2015 而某個(gè)依賴使用 Rust 2021，你的項(xiàng)目仍舊能夠編譯并使用該依賴。反之，若項(xiàng)目使用 Rust 2021 而依賴使用 Rust 2015 亦可工作。[14]

而廣泛使用的JAVA以及Python語言在版本的兼容性上都無法盡善盡美，從長(zhǎng)遠(yuǎn)的角度來看，是不適合作為戰(zhàn)術(shù)邊緣云在應(yīng)用層的主要編程語言的。

4.3?云原生和邊緣計(jì)算的未來

過去幾年，云計(jì)算的邊界不斷向邊緣側(cè)延伸。作為云原生技術(shù)事實(shí)標(biāo)準(zhǔn)的Kubernetes+容器組合，自然也被很多人考慮部署到邊緣側(cè)。不過K8s+容器組對(duì)于邊緣計(jì)算場(chǎng)景來說，還是太過重了。因?yàn)檫吘壴O(shè)備通常硬件資源有限，沒有足夠的資源部署運(yùn)行完整的K8s。

很多邊緣設(shè)備基于ARM架構(gòu)，但大部分K8s發(fā)行版不支持ARM架構(gòu)。同時(shí)，很多邊緣設(shè)備所處環(huán)境復(fù)雜，無法保證穩(wěn)定可靠的網(wǎng)絡(luò)連接，而K8s的致命問題就是不支持離線運(yùn)行。所以對(duì)于戰(zhàn)術(shù)邊緣云來講，首先Pass。

而傳統(tǒng)容器方案，比如Docker，問題與K8s類似，Docker鏡像大小很容易就達(dá)到一兩百M(fèi)B以上，邊緣場(chǎng)景有不少內(nèi)存和磁盤空間小于1GB的微型設(shè)備，所以Docker對(duì)于戰(zhàn)術(shù)邊緣云來講也得Pass。

邊緣計(jì)算不僅需要更輕量的K8s，也需要更輕量、更快的容器方案，WebAssembly(WASM)就是近幾年出現(xiàn)的一個(gè)新選擇。

2021 年，云原生社區(qū)對(duì) WebAssembly 的興趣愈發(fā)濃厚，WebAssembly 在云原生方向也十分活躍。到目前為止，CNCF 已經(jīng)正式接收了至少三個(gè) WebAssembly 項(xiàng)目，包括：WasmEdge Runtime，一個(gè)云原生 WebAssembly runtime；wasmCloud，一個(gè) WebAssembly 應(yīng)用程序框架；Krustlet，一個(gè)在 Kubernetes pods 中運(yùn)行 WebAssembly 程序的工具。其中，WasmEdge 和 Kruslet 通過兩種不同的方式，做到了讓 Kubernetes 集群中的 WebAssembly 工作負(fù)載可以與傳統(tǒng)容器（例如 containerd、Docker 和 CRI-O）并列運(yùn)行，用戶可以使用與管理 Docker 應(yīng)用程序完全相同的工具來管理 WebAssembly 應(yīng)用程序。

而說到 WebAssembly 最初與 Docker、云原生產(chǎn)生關(guān)聯(lián)，就不得不提 Docker 聯(lián)合創(chuàng)始人 Solomon Hykes 在 2019 年 3 月份發(fā)布的一條推文。他在推文中表示：如果 WASM（WebAssembly）和 WASI（WebAssembly System Interface, WASM 系統(tǒng)接口）在 2008 年就已經(jīng)存在，那就沒有必要?jiǎng)?chuàng)建 Docker 了。

WasmEdge 目前的重點(diǎn)是推動(dòng) WebAssembly 更快地整合到后端生態(tài)里面，進(jìn)而往云原生和邊緣計(jì)算方向走得更遠(yuǎn)、更快。前不久，團(tuán)隊(duì)與 FutureWei 合作為 seL4 和 WasmEdge 構(gòu)建了一個(gè) WebAssembly 管理代理，使 WebAssembly 字節(jié)碼應(yīng)用程序能在 seL4 RTOS 上簡(jiǎn)單地被部署和執(zhí)行，這樣一來在如自動(dòng)駕駛汽車、無人機(jī)這樣的邊緣設(shè)備上也可以方便地運(yùn)行應(yīng)用程序容器。

4.4.1?Async-RDMA

Datenlord封裝了一層符合Rust風(fēng)格、便于Rust開發(fā)者使用的RDMA Rust binding，目前已經(jīng)開源。包括rdma-sys和async-rdma，前者是對(duì)RDMA接口的unsafe封裝，后者是safe封裝（尚未完成）。[17]

項(xiàng)目地址：https://github.com/datenlord/async-rdma

4.4.2?Async-UCX

UCX 是一個(gè)高性能網(wǎng)絡(luò)通信庫，它作為 MPI 所依賴的通信模塊之一在高性能計(jì)算領(lǐng)域得到廣泛的使用。UCX 使用 C 語言編寫，為了在 Rust 項(xiàng)目中使用它，需要將它的 C 接口包裝成 Rust 庫。清華大學(xué)團(tuán)隊(duì)用 Rust 實(shí)現(xiàn)的高性能分布式文件系統(tǒng) MadFS，底層就使用了Rust包裝過的UCX作為通信模塊，它在大規(guī)模 RDMA 網(wǎng)絡(luò)上展現(xiàn)出了良好的性能。[18]

項(xiàng)目地址：https://github.com/madsys-dev/async-ucx

總結(jié)

圖4-1?SDX技術(shù)平面架構(gòu)剖析圖（以船載平臺(tái)為例）

圖4-2 軟件定義戰(zhàn)術(shù)邊緣數(shù)據(jù)中心宏觀架構(gòu)圖（以船載平臺(tái)為例）

在編程語言方面，鏈路層需要p4語言的加持，而應(yīng)用層的開發(fā)則離不開Rust和WebAssembly。Rust不僅可以編譯成WASM運(yùn)行在WASM虛擬機(jī)上，還可以運(yùn)行在eBPF中，這兩種虛擬機(jī)技術(shù)都是當(dāng)今云原生領(lǐng)域最火的。所以，筆者只想說一句，Rust戰(zhàn)未來！

參考引用

[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] 面向天地融合的衛(wèi)星網(wǎng)絡(luò)架構(gòu)和傳輸關(guān)鍵技術(shù) -?徐暉,繆德山,康紹莉,孫韶輝?·?大唐移動(dòng)通信設(shè)備有限公司

[7] 軟件定義衛(wèi)星網(wǎng)絡(luò)關(guān)鍵技術(shù)研究 - 吳帥 · 國防科技大學(xué)

[8] 衛(wèi)星網(wǎng)絡(luò)組網(wǎng)關(guān)鍵技術(shù)研究綜述 - 吳煬?·?國防科技大學(xué)

[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] 面向海上戰(zhàn)術(shù)云的信息資源服務(wù)架構(gòu)設(shè)計(jì)?-?唐素純,李 寧,于 鉞,韋廣立?·?中國艦船研究院

[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

最后

本文章部分內(nèi)容參考或來源于網(wǎng)絡(luò)，無法做到準(zhǔn)確溯源，如涉及版權(quán)問題，請(qǐng)第一時(shí)間告知本人，本人會(huì)立刻刪除相關(guān)內(nèi)容或補(bǔ)上引用說明。（筆者聯(lián)系方式：gongshu@petalmail.com）對(duì)于大幅引用片段的標(biāo)題筆者已作標(biāo)紅，這種引用是為了保護(hù)技術(shù)的權(quán)威性，同時(shí)彰顯重要性，如果通過簡(jiǎn)化描述或者是近似描述的方式將不能表達(dá)出引用文章和技術(shù)對(duì)于本文章的必要性以及保證嚴(yán)謹(jǐn)性，所以這種引用并非是惡意的。

本文章的目的僅是為了筆者正在編寫的一個(gè)后續(xù)將會(huì)開源的基于Rust的高性能文件傳輸協(xié)議做前調(diào)，對(duì)于文章內(nèi)容的真實(shí)性請(qǐng)讀者自行判斷，請(qǐng)勿將該文章用作其他用途，由此產(chǎn)生的一切后果筆者概不承擔(dān)。

END

本文使用 文章同步助手 同步