0 摘要

亞馬遜網(wǎng)絡(luò)服務(wù) (AWS) 對網(wǎng)絡(luò)進(jìn)行了重新梳理，以提供超級計(jì)算應(yīng)用程序所需的持續(xù)低延遲，同時(shí)保持公共云的優(yōu)勢：可擴(kuò)展性、按需彈性容量、成本效益以及快速采用更新的CPU和GPU。我們構(gòu)建了一個(gè)新的網(wǎng)絡(luò)傳輸協(xié)議，可擴(kuò)展的可靠數(shù)據(jù)報(bào) (SRD，Scalable Reliable Datagram)，旨在利用現(xiàn)代商業(yè)化的多租戶數(shù)據(jù)中心網(wǎng)絡(luò)（具有大量網(wǎng)絡(luò)路徑），同時(shí)克服它們的局限性（負(fù)載不平衡和無關(guān)流沖突時(shí)的不一致延遲）。SRD不保留數(shù)據(jù)包順序，而是通過盡可能多的網(wǎng)絡(luò)路徑發(fā)送數(shù)據(jù)包，同時(shí)避免路徑過載。為了最大限度地減少抖動(dòng)并確保對網(wǎng)絡(luò)擁塞波動(dòng)的最快響應(yīng)，在AWS自定義Nitro網(wǎng)卡中實(shí)施了SRD。SRD由EC2主機(jī)上的HPC/ML框架通過AWS彈性結(jié)構(gòu)適配器（EFA，Elastic Fabric Adapter）內(nèi)核旁路接口使用。

1 概述

云計(jì)算的主要好處之一是按照需要，瞬間提供和取消配置的資源。這與傳統(tǒng)的超級計(jì)算截然不同，傳統(tǒng)的超級計(jì)算機(jī)是定制的（需要數(shù)月或數(shù)年），因?yàn)槠涑杀竞腿萘肯拗?，超級?jì)算機(jī)通常是難以獲取的。使用定制系統(tǒng)進(jìn)行超級計(jì)算的主要原因之一是構(gòu)建高性能網(wǎng)絡(luò)并在應(yīng)用程序之間共享的挑戰(zhàn)。在云計(jì)算環(huán)境中，使用InfiniBand等專用硬件或?qū)Ｓ糜贖PC工作負(fù)載的商用硬件都非常昂貴、難以擴(kuò)展且難以快速發(fā)展。

AWS選擇使用現(xiàn)有AWS網(wǎng)絡(luò)（從100 Gbps開始）為客戶提供經(jīng)濟(jì)實(shí)惠的超級計(jì)算，并添加了新的HPC優(yōu)化網(wǎng)絡(luò)接口，作為AWS Nitro卡提供的網(wǎng)絡(luò)功能的擴(kuò)展。

正如預(yù)期的那樣，在共享網(wǎng)絡(luò)上運(yùn)行HPC流量會帶來一系列挑戰(zhàn)。AWS使用商用以太網(wǎng)交換機(jī)來構(gòu)建具有等價(jià)多路徑(ECMP)路由的高基數(shù)折疊 Clos 拓?fù)洹CMP通常用于使用流哈希在可用路徑上靜態(tài)地對流進(jìn)行條帶化。流到路徑的這種靜態(tài)映射有利于保持TCP的每個(gè)流的順序，但它不考慮當(dāng)前的網(wǎng)絡(luò)利用率或流率。哈希沖突會導(dǎo)致某些鏈路上出現(xiàn)“熱點(diǎn)”，從而導(dǎo)致路徑間負(fù)載分布不均勻、數(shù)據(jù)包丟失、吞吐量降低和尾部延遲高（如 Al-Fares等人、Ghorbani等人、Handley等人、Hopps等人和Vanini等人在文章中廣泛研究的那樣)。即使在過度配置的網(wǎng)絡(luò)中，大量流量也可能影響不相關(guān)的應(yīng)用程序。

數(shù)據(jù)包延遲和數(shù)據(jù)包丟棄會干擾HPC/ML應(yīng)用程序的低延遲要求，從而降低擴(kuò)展效率。延遲異常值對這些應(yīng)用程序具有深遠(yuǎn)的影響，因?yàn)樗鼈兺ǔＷ裱客讲⑿芯幊棠Ｐ?，?jì)算的周期之后是整個(gè)集群的批量同步。單個(gè)異常值將使整個(gè)集群等待，阿姆達(dá)爾定律決定了可擴(kuò)展性。

1.1 為什么不是 TCP

TCP是IP網(wǎng)絡(luò)中可靠數(shù)據(jù)傳輸?shù)闹饕侄危哉Q生以來一直很好地服務(wù)于Internet，并且仍然是大多數(shù)通信的最佳協(xié)議。但是，它不適合對延遲敏感的處理。對于TCP在數(shù)據(jù)中心，而最好情況的往返延遲差不多是25us，因擁塞（或鏈路故障）的等待時(shí)間異常值可以是50 ms，甚至數(shù)秒，即使當(dāng)替代無擁塞網(wǎng)絡(luò)路徑之間的任何地方可用。這些異常值的主要原因之一是丟失TCP數(shù)據(jù)包的重傳：TCP被迫保持重傳所以超時(shí)很多，這也解釋了操作系統(tǒng)延遲問題。

1.2 為什么不RoCE

InfiniBand是一種用于高性能計(jì)算的流行的高吞吐量低延遲互連，它支持內(nèi)核旁路和傳輸卸載。RoCE（RDMA over Converged Ethernet），也稱為InfiniBand over Ethernet，允許在以太網(wǎng)上運(yùn)行InfiniBand傳輸，理論上可以提供AWS數(shù)據(jù)中心中TCP的替代方案。我們考慮了RoCEv2支持，彈性結(jié)構(gòu)適配器(EFA)主機(jī)接口與InfiniBand/RoCE接口非常相似。但是，我們發(fā)現(xiàn)InfiniBand傳輸不適合AWS可擴(kuò)展性要求。原因之一是RoCE [v2]需要優(yōu)先級流量控制(PFC)，這在大型網(wǎng)絡(luò)上是不可行的，因?yàn)樗鼤斐申?duì)頭阻塞、擁塞擴(kuò)散和偶爾的死鎖。郭在文章中描述了一種大規(guī)模PFC問題的解決方案，但它明確依賴于比AWS數(shù)據(jù)中心小得多的數(shù)據(jù)中心規(guī)模。此外，即使使用PFC，RoCE在擁塞（類似于TCP）和次優(yōu)擁塞控制下仍會遭受ECMP沖突。

1.3 我們的方法

由于TCP和其他傳輸協(xié)議都不能提供我們需要的性能級別，因此在我們使用的網(wǎng)絡(luò)中，我們選擇設(shè)計(jì)自己的網(wǎng)絡(luò)傳輸協(xié)議?？蓴U(kuò)展的可靠數(shù)據(jù)報(bào) (SRD) 針對超大規(guī)模數(shù)據(jù)中心進(jìn)行了優(yōu)化：它提供跨多個(gè)路徑的負(fù)載平衡以及從數(shù)據(jù)包丟失或鏈路故障中快速恢復(fù)。它利用商用以太網(wǎng)交換機(jī)上的標(biāo)準(zhǔn)ECMP功能并解決其局限性：發(fā)送方通過操縱數(shù)據(jù)包封裝來控制ECMP路徑選擇。SRD采用專門的擁塞控制算法，通過將排隊(duì)保持在最低限度，有助于進(jìn)一步降低丟包的機(jī)會并最大限度地減少重傳時(shí)間。

我們做出了一個(gè)有點(diǎn)不尋常的“協(xié)議保證”選擇：SRD提供可靠但亂序的交付，并將次序恢復(fù)留給上層。我們發(fā)現(xiàn)嚴(yán)格的有序交付通常是不必要的，強(qiáng)制執(zhí)行它只會造成隊(duì)列頭部阻塞、增加延遲并減少帶寬。例如，如果使用相同的消息標(biāo)簽，消息傳遞接口 (MPI) 標(biāo)記的消息必須按順序傳遞。因此，當(dāng)網(wǎng)絡(luò)中的并行導(dǎo)致數(shù)據(jù)包無序到達(dá)時(shí)，我們將消息順序恢復(fù)留給上層，因?yàn)樗鼘λ璧呐判蛘Z義有更好的理解。

我們選擇在AWS Nitro卡中實(shí)施SRD可靠性層。我們的目標(biāo)是讓SRD盡可能靠近物理網(wǎng)絡(luò)層，并避免主機(jī)操作系統(tǒng)和管理程序注入的性能噪音。這允許快速適應(yīng)網(wǎng)絡(luò)行為：快速重傳并迅速減速以響應(yīng)隊(duì)列建立。

圖1 不使用和使用EFA的HPC堆棧

SRD作為EFA PCIe設(shè)備公開給主機(jī)。EFA是Amazon EC2實(shí)例（即虛擬和裸機(jī)服務(wù)器）的網(wǎng)絡(luò)接口，使客戶能夠在AWS上大規(guī)模運(yùn)行緊密耦合的應(yīng)用程序。特別是，EFA支持運(yùn)行HPC應(yīng)用程序和ML分布式訓(xùn)練，目前支持多種MPI實(shí)現(xiàn)：OpenMPI、Intel MPI和MVAPICH，以及NVIDIA集體通信庫。如圖1所示，EFA提供了一個(gè)“用戶空間驅(qū)動(dòng)程序”，它利用操作系統(tǒng) (OS) 繞過硬件接口來增強(qiáng)實(shí)例間通信的性能（減少延遲、抖動(dòng)、避免OS系統(tǒng)調(diào)用、并減少內(nèi)存副本），這是擴(kuò)展這些應(yīng)用程序的關(guān)鍵。

2 可擴(kuò)展的可靠數(shù)據(jù)報(bào)設(shè)計(jì)

2.1 多路徑負(fù)載平衡

為了減少丟包的機(jī)會，流量應(yīng)該在可用路徑上均勻分布。即使對于單個(gè)應(yīng)用程序流，SRD發(fā)送方依然需要在多個(gè)路徑上噴灑（Spray）數(shù)據(jù)包。尤其是對于重量流，以最小化熱點(diǎn)的機(jī)會并檢測次優(yōu)路徑。我們將SRD設(shè)計(jì)為與未啟用多路徑的傳統(tǒng)流量共享網(wǎng)絡(luò)，因此僅隨機(jī)噴射流量是不夠的。為了盡量減少繁重的傳統(tǒng)流的影響，SRD避免使用過載路徑，這可以通過為每條路徑收集的往返時(shí)間 (RTT) 信息獲取。

在規(guī)模上，偶爾的硬件故障是不可避免的；為了允許從網(wǎng)絡(luò)鏈路故障中快速恢復(fù)，如果用于原始傳輸?shù)穆窂阶兊貌豢捎?，SRD能夠重新路由重傳的數(shù)據(jù)包，而無需等待，需要2-3個(gè)數(shù)量級時(shí)長的，整個(gè)網(wǎng)絡(luò)范圍的路由更新收斂。此路由更改由SRD完成，無需重新建立昂貴的連接通路。

2.2 無序交付

平衡多條可用路徑之間的流量有助于減少排隊(duì)延遲并防止數(shù)據(jù)包丟失，但是，它不可避免地導(dǎo)致大型網(wǎng)絡(luò)中的無序數(shù)據(jù)包到達(dá)。眾所周知，恢復(fù)網(wǎng)卡中的數(shù)據(jù)包排序非常昂貴，這些網(wǎng)卡通常具有有限的資源（內(nèi)存帶寬、重排序緩沖區(qū)容量或開放排序上下文的數(shù)量）。

我們考慮讓Nitro網(wǎng)卡按順序發(fā)送接收消息，類似于常見的可靠傳輸，如TCP或Infiniband可靠連接(RC)。但是，這將限制可擴(kuò)展性或在出現(xiàn)丟包時(shí)增加平均延遲。如果我們推遲向主機(jī)軟件發(fā)送亂序數(shù)據(jù)包，我們將需要一個(gè)大的中間緩沖區(qū)，并且我們將大大增加平均延遲，因?yàn)樵S多數(shù)據(jù)包被延遲，直到丟失的數(shù)據(jù)包被重新發(fā)送。大多數(shù)或所有這些數(shù)據(jù)包可能與丟失的數(shù)據(jù)包無關(guān)，因此這種延遲是不必要的。丟棄亂序數(shù)據(jù)包“解決”了緩沖問題，而不是延遲問題，并增加了網(wǎng)絡(luò)帶寬消耗。因此，我們決定將數(shù)據(jù)包傳送到主機(jī)，即使它們可能是亂序的。

應(yīng)用程序處理亂序數(shù)據(jù)包對于字節(jié)流協(xié)議（如TCP）是站不住腳的，其中消息邊界對傳輸層是不透明的，但在使用基于消息的語義時(shí)很容易。每個(gè)流的排序或其他類型的依賴跟蹤由SRD之上的消息傳遞層完成；消息層排序信息與數(shù)據(jù)包一起傳輸?shù)搅硪欢?，對SRD不透明。

2.3 擁塞控制

多路徑噴灑減少了網(wǎng)絡(luò)中間交換機(jī)的負(fù)載，但它本身并不能緩解incast擁塞問題。Incast是一種流量模式，其中許多流會聚在交換機(jī)的同一接口上，耗盡該接口的緩沖區(qū)空間，從而導(dǎo)致數(shù)據(jù)包丟失。這在以多對一通信模式連接到接收器的最后一跳交換機(jī)中很常見，但也可能發(fā)生在其他層。

噴灑實(shí)際上會使incast問題變得更糟，因?yàn)閬碜酝话l(fā)送者的微突發(fā)，即使最初受到發(fā)送者鏈路帶寬的限制，即使不同的路徑依然有可能同時(shí)到達(dá)。因此，對于多路徑傳輸?shù)膿砣刂茖⑺新窂缴系木酆吓抨?duì)保持在最低限度是至關(guān)重要的。

SRD擁塞控制的目標(biāo)是以最少的傳輸中字節(jié)獲得公平的帶寬份額，防止隊(duì)列增長和數(shù)據(jù)包丟失（而不是依賴它們進(jìn)行擁塞檢測）。SRD擁塞控制有點(diǎn)類似于BBR，有額外的數(shù)據(jù)中心多路徑考慮。它基于每個(gè)連接的動(dòng)態(tài)速率限制，并結(jié)合飛行限制。發(fā)送方根據(jù)傳入確認(rèn)數(shù)據(jù)包的時(shí)間指示的速率估計(jì)調(diào)整其每個(gè)連接的傳輸速率，同時(shí)考慮最近的傳輸速率和RTT變化。如果大多數(shù)路徑上的RTT上升，或者如果估計(jì)速率變得低于傳輸速率，則會檢測到擁塞。該方法允許檢測影響所有路徑的連接范圍的擁塞，例如，在incast的情況下，擁塞機(jī)制通過重新路由獨(dú)立處理單個(gè)路徑。

3 用戶接口：EFA

Nitro卡上的SRD傳輸通過EFA向AWS客戶公開。EFA接口類似于InfiniBand verbs。然而，其SRD語義與標(biāo)準(zhǔn)InfiniBand傳輸類型截然不同。EFA用戶空間軟件有兩種形式：基本的“用戶空間驅(qū)動(dòng)程序”軟件公開可靠的亂序交付，由Nitro卡EFA硬件設(shè)備本地提供；而 libfabric “供應(yīng)者”層在驅(qū)動(dòng)之上，實(shí)現(xiàn)數(shù)據(jù)包重新排序作為消息分段和MPI標(biāo)簽匹配支持的一部分。

3.1 EFA 作為Elastic Network Adapter的擴(kuò)展

Nitro卡是一系列卡，可卸載和加速AWS EC2服務(wù)器上的網(wǎng)絡(luò)、存儲、安全和虛擬化功能。特別是，用于VPC的Nitro卡包括彈性網(wǎng)絡(luò)適配器 (ENA) PCIe控制器，該控制器將經(jīng)典網(wǎng)絡(luò)設(shè)備呈現(xiàn)給主機(jī)，同時(shí)還為AWS VPC實(shí)現(xiàn)數(shù)據(jù)平面。ENA使用 PCIe SR-IOV來提供高性能網(wǎng)絡(luò)功能，而無需管理程序參與；它將專用PCIe設(shè)備暴露給在AWS主機(jī)上運(yùn)行的EC2實(shí)例，與傳統(tǒng)的半虛擬化網(wǎng)絡(luò)接口相比，可實(shí)現(xiàn)更高的I/O性能、更低的延遲和更少的CPU利用率。EFA是AWS上的Nitro VPC卡提供的附加可選服務(wù)，適用于HPC和ML的高性能服務(wù)器。

3.2 EFA SRD傳輸類型

與InfiniBand verbs一樣，所有EFA數(shù)據(jù)通信都是通過隊(duì)列對 (QP) 完成的，隊(duì)列對是包含發(fā)送隊(duì)列和接收隊(duì)列的可尋址通信端點(diǎn)，用于提交請求以異步發(fā)送和接收消息，直接來自/送到用戶空間。QP是昂貴的資源，傳統(tǒng)上需要大量QP才能在大型集群（其中通常在每個(gè)服務(wù)器上運(yùn)行大量進(jìn)程）中建立全對全進(jìn)程連接。EFA SRD傳輸允許如
https://github.com/amzn/amzn-drivers/blob/master/kernel/linux/efa/SRD.txt中所述，所需數(shù)量的QP顯著節(jié)省。EFA SRD語義類似于InfiniBand可靠數(shù)據(jù)報(bào)(RD)模型，但消除了RD限制（由處理從不同發(fā)送方到同一目標(biāo)QP的交錯(cuò)分段消息的復(fù)雜性難以維持，同時(shí)提供有序傳遞）。與RD不同，SRD QP提供無序數(shù)據(jù)并限制消息大小以避免分段。這允許支持多個(gè)未完成的消息，而不會創(chuàng)建隊(duì)頭阻塞，以便可以多路復(fù)用單獨(dú)的應(yīng)用程序流而不會相互干擾。

3.3 亂序數(shù)據(jù)包處理挑戰(zhàn)

EFA SRD QP語義為EFA上層處理引入了一種陌生的排序要求，我們稱之為“消息層”，通常由HPC應(yīng)用程序用于抽象網(wǎng)絡(luò)細(xì)節(jié)。與成熟的傳輸實(shí)現(xiàn)（如TCP）相比，這種新功能是輕量級的，因?yàn)樾遁d了可靠性層。

理想情況下，消息傳遞層完成的緩沖區(qū)管理和流量控制應(yīng)該與應(yīng)用程序緊密耦合，這是可行的，因?yàn)槲覀兊闹饕P(guān)注點(diǎn)是類似HPC的應(yīng)用程序，它已經(jīng)支持并且實(shí)際上更喜歡具有管理能力的用戶空間網(wǎng)絡(luò)用戶緩沖區(qū)。

對于消息語義，如果應(yīng)用程序消息傳遞層希望將數(shù)據(jù)接收到虛擬連續(xù)的緩沖區(qū)而不是收集列表中，那么對于大型傳輸?shù)南⒍蔚臒o序到達(dá)可能需要進(jìn)行數(shù)據(jù)復(fù)制。這并不比 TCP 差，后者需要從內(nèi)核緩沖區(qū)到用戶緩沖區(qū)的副本?？梢栽?EFA 中使用 RDMA 功能避免此副本（超出本文范圍）。

4 SRD性能評估

我們將 EFA SRD性能與AWS云上同一組服務(wù)器上的TCP（使用默認(rèn)配置）進(jìn)行了比較。我們不分析由于操作系統(tǒng)內(nèi)核繞過而產(chǎn)生的差異，因?yàn)樗鼘FA的影響與經(jīng)過充分研究的InfiniBand案例沒有本質(zhì)區(qū)別，并且它是與擁堵情況下網(wǎng)絡(luò)流量通行為差異相比較小。

MPI實(shí)現(xiàn)是另一個(gè)對HPC 應(yīng)用程序性能產(chǎn)生深遠(yuǎn)影響的因素，特別是對于早期版本 EFA 上的 MPI，如 Chakraborty等人的文章所示。12 由于我們的目標(biāo)是評估傳輸協(xié)議，并且 MPI 實(shí)現(xiàn)超出了本文的范圍，我們只在 OpenMPI 中使用了基本的 MPI 原語（包括重新排序邏輯），或者繞過 MPI 層的微基準(zhǔn)測試。

4.1 Incast FCT 和公平

我們評估了從4個(gè)服務(wù)器發(fā)送的48個(gè)獨(dú)立流，每個(gè)流運(yùn)行12個(gè)進(jìn)程，發(fā)送到單個(gè)目標(biāo)服務(wù)器，在最后一個(gè)網(wǎng)絡(luò)躍點(diǎn)處造成瓶頸。我們測量SRD和TCP的流完成時(shí)間( FCT)，并將其與最佳FCT進(jìn)行比較，即在100%的瓶頸鏈路利用率在流之間均分的情況下的理想 FCT。

圖2 最大FCT，突發(fā)48流incast

“突發(fā)”Incast FCT

我們在EFA/SRD或TCP上運(yùn)行了MPI帶寬基準(zhǔn)測試，此時(shí)發(fā)送方使用屏障在大約同一時(shí)間開始每個(gè)傳輸。圖2顯示了不同傳輸大小的理想和最大FCT。SRD FCT接近最優(yōu)，抖動(dòng)非常低，而TCP FCT有噪聲，最大時(shí)間比理想值高3-20倍。

圖3顯示了用于2 MB傳輸?shù)腇CT的CDF。超過50毫秒的TCP尾部延遲反映了重傳，因?yàn)樽钚≈貍鞒瑫r(shí)為50毫秒。即使僅查看50ms以下的樣本（即，當(dāng)延遲不是因于超時(shí)），大量樣本也比理想情況高3倍。

圖3 2 MB傳輸?shù)腇CT的CDF，突發(fā)48流incast

持續(xù)擁塞Incast下的流量吞吐量

為了了解TCP的高FCT方差（即使忽略長尾導(dǎo)致的超時(shí)），我們檢查了incast下的單個(gè)流吞吐量。我們使用繞過MPI的底層基準(zhǔn)測試來測量連續(xù)發(fā)送數(shù)據(jù)時(shí)的吞吐量。我們每秒對每個(gè)流的吞吐量進(jìn)行采樣。在100 Gb/s的組合速率下，每個(gè)流的預(yù)期公平份額約為2 Gb/s。

圖4分別顯示了兩個(gè)有代表性的發(fā)送方的TCP和SRD吞吐量。SRD流吞吐量對于所有流來說都是一致且接近理想的，而每個(gè)流的TCP吞吐量都在劇烈振蕩，并且某些流的平均吞吐量遠(yuǎn)低于預(yù)期，這解釋了FCT抖動(dòng)。

圖4 每秒采樣的吞吐量，48路incast典型流量

4.2 多路徑負(fù)載平衡

圖5 共享交換機(jī)間鏈路的獨(dú)立流

我們還評估了一個(gè)要求較低的案例，沒有相關(guān)的負(fù)載。如圖5所示，我們從位于同一個(gè)機(jī)架到位于另一個(gè)機(jī)架中的8個(gè)服務(wù)器，在一個(gè)全平分網(wǎng)絡(luò)中。每臺機(jī)器運(yùn)行16個(gè)MPI等級（進(jìn)程），所有數(shù)據(jù)都在不同的流上發(fā)送或接收到/從同一臺遠(yuǎn)程機(jī)器。TOR交換機(jī)上行鏈路的利用率為50%，下行鏈路預(yù)計(jì)不會擁塞，因?yàn)橹挥幸粋€(gè)發(fā)送方向發(fā)送數(shù)據(jù)到每個(gè)接收方。

圖6顯示了TCP和EFA的8個(gè)發(fā)送方之一的所有流的FCT（其他發(fā)送方看起來類似）。即使在理想的負(fù)載平衡下根本不會出現(xiàn)擁塞，但由于交換機(jī)間鏈路的ECMP平衡不均勻，TCP顯然會遇到擁塞甚至丟包。TCP中位延遲變化很大，平均值比預(yù)期高50%，而尾部延遲比預(yù)期高1-2個(gè)數(shù)量級。中值SRD FCT僅比理想值高15%，最大SRD FCT低于平均TCP FCT。

圖6 ECMP不平衡的影響

5 結(jié)論

EFA允許HPC/ML應(yīng)用程序在AWS公共云上大規(guī)模運(yùn)行。它提供始終如一的低延遲，尾部延遲數(shù)量級低于TCP。這是通過SRD提供的新型網(wǎng)絡(luò)傳輸語義，結(jié)合網(wǎng)絡(luò)接口卡和不同主機(jī)軟件層之間的非正統(tǒng)功能拆分來實(shí)現(xiàn)的。通過在Nitro卡上運(yùn)行SRD多路徑負(fù)載平衡和擁塞控制，我們既減少了網(wǎng)絡(luò)中丟包的機(jī)會，又可以更快地從丟包中恢復(fù)。

(正文完)