基于QUIC 傳輸?shù)某笮蛿?shù)據(jù)中心網(wǎng)絡性能研究

劉景林

（泉州經(jīng)貿(mào)職業(yè)技術學院信息技術系，福建 泉州 362000）

近年來，在網(wǎng)絡直播、網(wǎng)上貿(mào)易、云計算等應用需求的推動下，許多全球數(shù)據(jù)中心網(wǎng)絡相繼建立。與廣域網(wǎng)相比， 數(shù)據(jù)中心網(wǎng)具有部署靈活、 帶寬高、時延低等優(yōu)點。 數(shù)據(jù)中心網(wǎng)絡是由各種計算設備、 網(wǎng)絡互聯(lián)設備等相關設施組成的基礎服務集群。 在數(shù)據(jù)中心內(nèi)通過高速鏈路和交換機連接大量服務器的網(wǎng)絡，采用分層結構實現(xiàn)，每個應用程序運行在特定的服務器或虛擬服務器集上。 數(shù)據(jù)中心網(wǎng)絡具有控制域單一、 網(wǎng)絡體系結構同質(zhì)等不同于Internet 的特點，給設計帶來了機遇和挑戰(zhàn)[1]。由于TCP 協(xié)議在數(shù)據(jù)中心網(wǎng)絡應用中存在傳輸性能方面的局限性， 所以在數(shù)據(jù)中心網(wǎng)絡中引入了Google 開發(fā)的新的傳輸協(xié)議QUIC(Quick UDP Internet Connection)， 該協(xié)議是基于 UDP 的傳輸協(xié)議，目的是保證傳輸可靠性的同時降低網(wǎng)絡延遲。QUIC 不僅減少了握手時延，而且在擁塞控制中引入了嚴格的遞增序列號機制， 實現(xiàn)了無隊列頭阻塞的復用，理論上，在傳輸性能方面明顯優(yōu)于TCP協(xié)議[2]。

目前，超大型數(shù)據(jù)中心網(wǎng)絡的應用非常廣泛，隨著通信運營商網(wǎng)絡業(yè)務的不斷增加， 重點研究超大型數(shù)據(jù)中心數(shù)據(jù)傳輸?shù)木C合性能， 以實現(xiàn)支持更多的業(yè)務系統(tǒng)。 所以，關于如何提高超大型數(shù)據(jù)中心網(wǎng)絡的綜合性能方面， 亟待進一步深入的研究。

1 fat-tree 數(shù)據(jù)中心網(wǎng)絡

為了增加吞吐量、 降低時延以及緩解流量擁塞，數(shù)據(jù)中心網(wǎng)絡需要設計不同的拓撲結構[3]，如以fat-tree[4]和VL2[5]為代表的新型樹狀拓撲結構，以Dcell[6]和BCube[7]為代表的分層遞歸拓撲結構，以 SWDC（Small World Data Center）和 Jellfish[8]為代表的隨機小世界拓撲結構。 在數(shù)據(jù)中心網(wǎng)絡中，Leiserson 提出了fat-tree 的分層網(wǎng)絡拓撲結構，它具有帶寬平分的特點，應用極為廣泛。 以下是基于fat-tree 為背景研究QUIC 協(xié)議的網(wǎng)絡傳輸。

fat-tree 數(shù)據(jù)中心網(wǎng)絡采用多交換機級聯(lián)的三層拓撲結構，分為核心層、匯聚層和接入層（見圖1）。 然而，其與傳統(tǒng)的樹狀結構不同，接入交換機和匯聚交換機被劃分為不同的集群。 在集群中，每個接入交換機與每個匯聚交換機相連， 形成一個完整的二部圖。 每個匯聚交換機連接一部分核心交換機，使每個集群連接到核心層交換機[9]。在fattree 結構中， 提供了足夠的核心交換機來保證1∶1的網(wǎng)絡覆蓋率，并提供服務器間的無阻塞通信。

圖1 fat-tree 數(shù)據(jù)中心網(wǎng)絡

構建fat-tree 網(wǎng)絡拓撲的規(guī)則是：fat-tree 拓撲中的(pod point of Delivery)個數(shù)為k，每個pod 連接的服務器個數(shù)為(k/2)2，每個pod 中的接入交換機和匯聚交換機個數(shù)為k/2， 核心交換機個數(shù)為(k/2)2，網(wǎng)絡中每個交換機的端口個數(shù)為k，網(wǎng)絡支持的服務器總數(shù)為k3/4。

fat-tree 結構可以通過核心層中的多個鏈路及時處理負載，避免網(wǎng)絡中的熱點，通過pod 中的合理分流避免過載。 fat-tree 的另一個優(yōu)點是它使用的所有交換機都是相同的， 這使得我們可以在整個數(shù)據(jù)中心網(wǎng)絡架構中使用普通的交換機[10]。

隨著網(wǎng)絡規(guī)模的擴大，fat-tree 的匯聚帶寬增加， 可以為數(shù)據(jù)中心提供高吞吐量的傳輸服務[11]。對于不同pod 之間服務器間的通信，源節(jié)點和目的節(jié)點之間存在多條并行路徑， 因此網(wǎng)絡的容錯性能良好，一般不存在單點故障。 采用商用設備取代高性能交換設備，大大降低了網(wǎng)絡設備開銷。 網(wǎng)絡直徑小，可以保證網(wǎng)絡上視頻、在線會議等業(yè)務的實時性要求。 規(guī)則對稱的拓撲結構，有利于網(wǎng)絡布線、網(wǎng)絡的自動配置及優(yōu)化升級。

目前， 數(shù)據(jù)中心網(wǎng)絡中的數(shù)據(jù)流在很多情況下是分布不均衡的[12]，例如，在基于Web 應用的數(shù)據(jù)中心中，當傳輸多個小數(shù)據(jù)流時，占用的帶寬較多，因此對擁塞控制突發(fā)提出了更高的要求。 而當前的QUIC 傳輸協(xié)議在TCP 擁塞算法的基礎上，它不使用TCP 根據(jù)字節(jié)序列號和ACK 來確認消息的有序到達，而是使用新建的序列號，每個序列號均嚴格遞增，因此如果包n 丟失，則重傳包n 的序列號不是n，而是大于n 的值，這樣就很容易解決TCP 重傳的歧義性問題， 并且這種機制可以顯著提高吞吐量[13]。

2 QUIC 協(xié)議及其應用

QUIC 是基于UDP 協(xié)議的低時延互聯(lián)網(wǎng)傳輸層協(xié)議，可以通過多路傳輸解決隊頭阻塞問題，通過0-RTT 握手降低傳輸層握手延時， 通過連接遷移更好地對移動性提供支持， 能夠較好地解決當今傳輸層和應用層面臨的各種需求， 包括處理更多的連接，減少連接延遲，保障數(shù)據(jù)傳輸?shù)目煽啃缘葐栴}。QUIC 已在SDN 網(wǎng)絡和空間網(wǎng)絡中進行了評估，其總體上優(yōu)于傳統(tǒng)TCP 協(xié)議，因此將其應用于數(shù)據(jù)中心網(wǎng)絡具有很大的優(yōu)勢。

TCP 最重要的特性之一是擁塞控制機制，它通過調(diào)整傳輸速率來避免擁塞崩潰（見圖2）。 QUIC在 UDP 上實現(xiàn)類似于 TCP+TLS+HTTP/2。 由于TCP 是在操作系統(tǒng)內(nèi)核和中間件固件中實現(xiàn)的，因此幾乎不可能對TCP 進行重大更改 （TCP 協(xié)議棧通常由操作系統(tǒng)實現(xiàn)，如Linux、Windows 內(nèi)核或其他移動設備操作系統(tǒng)）， 修改TCP 協(xié)議非常復雜，因為每個設備和系統(tǒng)的實現(xiàn)都需要更新。 但是，由于QUIC 是基于UDP 的， 因此沒有這樣的限制。QUIC 可以實現(xiàn)可靠的傳輸，與TCP 相比，它的流量控制功能是在用戶空間而不是在內(nèi)核空間，可以根據(jù)應用場景自由選擇，甚至自由調(diào)整和優(yōu)化，具有更大的發(fā)展優(yōu)勢。

圖2 QUIC 與 TCP 協(xié)議比較

2.1 0-RTT 往返時延

RTT（Round-Trip Time）是客戶端與服務器連接成功以及連接速度的重要參數(shù)。

客戶端發(fā)送數(shù)據(jù)之前，QUIC 協(xié)議下僅需0-RTT 即可與服務器建立安全會話， 而TCP/IP 協(xié)議下的TCP+TLS 則需要1-3 RTT (s) 才能夠建立連接，其主要的改進是在QUIC 協(xié)議下，客戶端獲取到會話server config 以后，便能計算出密鑰，且不再重新建立新會話，直接發(fā)送應用數(shù)據(jù)，此機制稱為0-RTT。

QUIC 協(xié)議通過合并Transport Layer Security減少了建立安全連接所需的往返次數(shù)。 當客戶端第一次訪問服務器時， 它需要1 個RTT 來交換加密信息。 如果當前客戶機已訪問服務器，則不再需要RTT。 在QUIC 協(xié)議中，客戶機和服務器之間的連接時間最多是1 個RTT，是安全的，而TCP 協(xié)議需要 2 個 RTT 和另外 1 個 RTT 通過 TLS 加密數(shù)據(jù)。

QUIC 的連接采用加密和傳輸握手相結合的方式來減少確認次數(shù)，適用于數(shù)據(jù)中心網(wǎng)絡，有利于降低時延。

2.2 靈活的擁塞控制機制

QUIC 的擁塞控制是在傳統(tǒng)TCP NewReno 基礎上發(fā)展而來的，即基于擁塞窗口的擁塞控制，其核心原理基本一樣，但QUIC 可以靈活地使用擁塞控制多種算法， 一次選擇一個或幾個擁塞控制算法同時工作，但QUIC 在應用程序不需要停機和升級，TCP 需要在服務端進行修改， 而QUIC 現(xiàn)在只需要簡單的重新加載就能實現(xiàn)不同擁塞控制切換。

2.3 前向糾錯

QUIC 傳輸過程中應用了與TCP 差別很大的糾錯機制， 其隨時用 Forward Error Correction packet 來代替某些新的packet，由于Forward Error Correction packet 中有奇偶核驗機制， 能及時判斷出是否丟失， 并恢復packet 內(nèi)容段， 整個效率極高，且可根據(jù)傳輸請求的某一階段進一步優(yōu)化，以實現(xiàn)前向糾錯目的。

在QUIC 協(xié)議中， 用于確認數(shù)據(jù)的ACK 包增強了新的功能， 支持從接收包到返回ACK 的延遲值， 增加值的目的是更加精確地計算基于分數(shù)的RTT。 所以說在處理數(shù)據(jù)上， 較先前的TCP/IP 協(xié)議，可以綜合RTT 與CWND 來調(diào)節(jié)適合實時的擁塞算法，更加的靈活。 在數(shù)據(jù)中心網(wǎng)絡中，當流量過大時，傳統(tǒng)的匯聚交換機對負載均衡能力較弱，且實時性較差， 再者TCP/IP 協(xié)議不能較好地適時調(diào)節(jié)整個網(wǎng)絡的擁塞情況，而QUIC 的靈活處理機制具有較好的應用前景。

3 基于QUIC-UDP 傳輸?shù)膄at-tree超大型數(shù)據(jù)中心網(wǎng)絡性能測試

數(shù)據(jù)中心是大型網(wǎng)絡系統(tǒng)的核心， 既是眾多服務器的集中地，又是信息數(shù)據(jù)的總匯。 按文獻[14]設計了基于fat-tree 的超大型數(shù)據(jù)中心網(wǎng)絡。 本文的超大型數(shù)據(jù)中心網(wǎng)絡是指Pod 個數(shù)k＞30 的fattree 數(shù)據(jù)中心網(wǎng)絡。 網(wǎng)絡拓撲與圖 1 類似，f1 作為服務器，應用TCP 協(xié)議與QUIC-UDP 協(xié)議，而其他主機fn 作為應用服務器，主要研究其傳輸性能。

網(wǎng)絡中的所有鏈路均設為全雙工鏈路， 設置鏈路帶寬等， 并使用iperf 工具產(chǎn)生模擬的數(shù)據(jù)中心流量。傳輸吞吐量的計算流程為：首先主機f1 作為服務器，客戶端主機數(shù)據(jù)傳輸前，記錄開始時間t1；然后客戶端主機fn 向服務器主機f1 發(fā)request請求， 服務器主機f1 收到請求時做出response 回應，并傳輸網(wǎng)頁；客戶端主機fn 收到網(wǎng)頁后，判斷是否完整，若完整無誤，記錄結束時間t2；最后計算本次傳輸吞吐量，其值為傳輸網(wǎng)頁大小/(t2-t1)。

網(wǎng)絡傳輸中最常見的應用是Web 網(wǎng)頁的瀏覽，即在兩主機中通過瀏覽器渲染包括html、各種腳本、控制樣式等文件。 為了進一步研究QUIC 和TCP 兩種協(xié)議的傳輸特點，實現(xiàn)在數(shù)據(jù)中心網(wǎng)絡中的不同網(wǎng)絡條件下加載相同網(wǎng)頁進行性能測試，分別設計了3 種基于fat-tree 拓撲結構的數(shù)據(jù)中心網(wǎng)絡，如表1 所示。

表1 3 種不同類型的fat-tree 數(shù)據(jù)中心網(wǎng)絡

網(wǎng)絡傳輸性能測試所使用的服務器和客戶端均采用64 位Linux 內(nèi)核， 操作系統(tǒng)為xfce 4.10。QUIC 協(xié)議的QUIC-go 的較新版本是0.15.4。HTTP服務器是Nginx 1.14。 TCP 初始窗口大小默認設置為1024。測試網(wǎng)頁是HTML 語言編寫的，包括大量文本、5 幅圖像和 JavaScript 腳本， 總大小為15.6MB。網(wǎng)絡拓撲工具使用mininet，該軟件是一個通過虛擬終端節(jié)點、 交換機和路由器連接起來的網(wǎng)絡模擬器，可以方便地創(chuàng)建一個數(shù)據(jù)中心網(wǎng)絡，其采用虛擬化技術，使系統(tǒng)與實際網(wǎng)絡基本一致。TCP 服務器使用Nginx 服務器， 是一種高性能的Web 服務器，具有低功耗、穩(wěn)定性好、并發(fā)性強以及易于配置等優(yōu)點。

本次測試使用TC 和 Netem、mahimahi 工具模擬不同的網(wǎng)絡環(huán)境， 該工具支持TCP 和QUIC 協(xié)議， 可以記錄整個Web 傳輸過程， 包括記錄Web內(nèi)容的 recordshell、 回放存儲 Web 內(nèi)容的 replayshell、模擬延遲帶寬鏈路的delayshell，用于模擬指定數(shù)據(jù)傳輸?shù)乃俣葞掓溌返膌inkshell，以及用于模擬指定丟包率鏈路的lossshell。

LinkShell 的原理是使用數(shù)據(jù)包傳遞跟蹤文件來模擬鏈接。uplink 鏈路跟蹤文件模擬從LinkShell容器到Internet 的鏈接，downlink 鏈路跟蹤文件模擬從 Internet 到LinkShell 容器的鏈接。 LinkShell可以模擬時變鏈路（如蜂窩鏈路）和具有固定鏈路速度的鏈路。 當數(shù)據(jù)包到達鏈路時（從Internet 或LinkShell）， 它將根據(jù)其預期的方向直接放入兩個數(shù)據(jù)包隊列中的一個：uplink 隊列或downlink 隊列。 LinkShell 根據(jù)相應的輸入數(shù)據(jù)包傳遞跟蹤從每個隊列釋放數(shù)據(jù)包。 跟蹤文件中的每一行表示一個數(shù)據(jù)包傳遞機會：在仿真中可以傳遞MTU 大小的數(shù)據(jù)包的時間。 整個記錄過程是在字節(jié)級別完成的。因此，跟蹤wget 請求中的一行可以傳遞幾個較小的數(shù)據(jù)包，這些數(shù)據(jù)包的大小總和為1 500字節(jié)。 如果在傳輸過程中出現(xiàn)的瞬間字節(jié)不可用，則會再次傳輸一次。 LinkShell 可以嵌套在DelayShell 中， 以靈活地創(chuàng)建具有用戶提供的單向延遲和用戶提供的鏈接速率的鏈接。

整個測試實驗中網(wǎng)絡傳輸和網(wǎng)絡信息的具體設置見表2。

表2 數(shù)據(jù)中心網(wǎng)絡參數(shù)設置

實驗中，將QUIC 部署在基于fat-tree 的超大型數(shù)據(jù)中心網(wǎng)絡中，TCP 和QUIC 服務器部署在主機f1 中，fn 是客戶端。 利用 wget 傳輸工具，得到 TCP和QUIC 的網(wǎng)頁傳輸時間， 并計算出對應的PLT（Page Loading Time）。 為了評價 TCP 與 QUIC 兩種不同協(xié)議的傳輸性能， 選擇相同單位時間內(nèi)網(wǎng)頁加載時間作為評價標準。 為了消除不穩(wěn)定因素，每次試驗重復60 次。

基于 fat-tree 的 k=2 數(shù)據(jù)中心網(wǎng) h1 和 h8 在不同核心交換機和相同聚合交換機下的網(wǎng)絡性能分析，如圖3 所示。

圖3 基于fat-tree 數(shù)據(jù)中心網(wǎng)絡的TCP/QUIC 傳輸性能測試比較

為了進一步研究移動網(wǎng)絡環(huán)境下兩種協(xié)議的傳輸性能方面的差異， 實驗模擬不同upLink 與downLink 下帶寬為20Mbps 的網(wǎng)絡環(huán)境。模擬移動網(wǎng)絡命令如下：mm-delay 20 mm-link--meter-all

/usr/share/mahimahi/traces/Verizon-LTE-short.up

/usr/share/mahimahi/traces/Verizon-LTE-short.down

其傳輸結果見圖4。

圖4 基于fat-tree 數(shù)據(jù)中心網(wǎng)絡的TCP/QUIC 移動傳輸性能測試比較

從圖3 可以看出， 隨著帶寬和丟包率的增加，TCP 和QUIC 的傳輸性能均有所下降，但TCP 的傳輸性能下降幅度會更大些。 在5Mbps 帶寬下，TCP的吞吐量剛開始很高，但隨著丟包率增加到1%左右，QUIC 的吞吐量超過了 TCP。 在 20Mbps 帶寬下，隨著丟包率的增加，QUIC 除了時延5ms 外，其吞吐量始終超過 TCP。 首先，QUIC 在 100Mbps 帶寬下的吞吐量較高， 而在100Mbps 帶寬下延時2ms 時，QUIC 的吞吐量基本相同， 在 5ms 及 10ms延時時，其輸出吞吐量接近于0。

從圖4 可知， 在移動網(wǎng)絡環(huán)境中低丟包率情形下，QUIC 傳輸性能明顯優(yōu)于TCP。 隨著丟包率增加，QUIC 由于其前向糾錯等功能， 所以一直優(yōu)于TCP。

4 結論

通過構建基于超大型數(shù)據(jù)中心網(wǎng)絡中的fattree 拓撲環(huán)境，對TCP 和QUIC 的網(wǎng)絡傳輸性能進行研究，并在不同的網(wǎng)絡環(huán)境中進行測試，比較基于TCP 和QUIC 的數(shù)據(jù)中心網(wǎng)絡傳輸性能的差異，發(fā)現(xiàn)隨著丟包率的增加，兩種協(xié)議的傳輸性能（指吞吐量）均有所下降，但TCP 的下降幅度要大得多，QUIC 在高丟包率網(wǎng)絡環(huán)境下傳輸性能要明顯優(yōu)于TCP。 在移動網(wǎng)絡環(huán)境下，QUIC 傳輸性能一直優(yōu)于傳統(tǒng)的TCP 協(xié)議， 隨著數(shù)據(jù)中心網(wǎng)絡規(guī)模的增大，TCP 和QUIC 的網(wǎng)絡傳輸能力趨于穩(wěn)定。 在今后的研究中，將進一步擴大數(shù)據(jù)中心網(wǎng)絡規(guī)模，比較高負載、高丟包率等網(wǎng)絡環(huán)境中二者的性能差異。