數(shù)據(jù)中心網(wǎng)絡(luò)中一種基于ECN的TCP慢啟動擁塞控制策略

黃家瑋，徐文茜，胡晉彬，王建新，葉 進

(1.中南大學(xué)信息科學(xué)與工程學(xué)院 長沙 410083；2.廣西大學(xué)計算機與電子信息學(xué)院 南寧 530004)

近年來，隨著在線搜索、社交網(wǎng)絡(luò)、電子商務(wù)等網(wǎng)絡(luò)應(yīng)用的飛速發(fā)展和普及，越來越多的在線應(yīng)用系統(tǒng)被遷移到數(shù)據(jù)中心中，利用大規(guī)模的計算和存儲資源為用戶提供各種網(wǎng)絡(luò)服務(wù)[1]。為了保證應(yīng)用請求的快速響應(yīng)，數(shù)據(jù)中心網(wǎng)絡(luò)(data center network, DCN)采用了高并發(fā)的網(wǎng)絡(luò)傳輸[2]。這樣的同步并發(fā)流極易造成某些路徑瞬時成為瓶頸，引起網(wǎng)絡(luò)擁塞，導(dǎo)致TCP連接出現(xiàn)頻繁丟包，最終出現(xiàn)TCP重傳超時(retransmission time-out, RTO)。一旦TCP超時發(fā)生，新一輪的請求必須要等上一輪中經(jīng)歷超時的連接完成超時重傳才會發(fā)出。此時，即使是一條TCP流超時帶來的空等時間(一般在200 ms以上)都會造成傳輸鏈路空閑，導(dǎo)致TCP吞吐率嚴(yán)重崩潰[3]。而且數(shù)據(jù)中心網(wǎng)絡(luò)具有超高帶寬[4]、超低時延的特性，這與傳統(tǒng)廣域網(wǎng)有很大的差別，所以傳統(tǒng)TCP在數(shù)據(jù)中心網(wǎng)絡(luò)中的應(yīng)用效果很差。

為了解決吞吐率崩潰問題，國內(nèi)外學(xué)者做出了很多研究。其中基于延時的協(xié)議TIMELY[5]、DX[6]和ICTCP[7]等都通過RTT的測量來檢測擁塞以調(diào)節(jié)擁塞窗口?；陲@式擁塞反饋(explicit congestion notification, ECN)的 協(xié) 議 DCTCP[8]、 D2TCP[9]和L2TCP[10]等利用ECN更準(zhǔn)確的反饋鏈路擁塞狀態(tài)來調(diào)節(jié)發(fā)送速率。然而這些協(xié)議僅專注于對擁塞避免階段的調(diào)窗算法改進，而忽略了由于慢啟動的激進增窗導(dǎo)致在進入擁塞避免之前就出現(xiàn)了超時問題。

在分析數(shù)據(jù)中心網(wǎng)絡(luò)中的流量發(fā)現(xiàn)，網(wǎng)絡(luò)中傳輸流大部分是延時敏感的小數(shù)據(jù)流(90%小于100 KB)[11]，而這些流很可能在慢啟動階段就完成傳輸。通過實驗驗證，DCTCP協(xié)議即使在并發(fā)度較小時，由于慢啟動激進的指數(shù)增窗方式也會出現(xiàn)超時現(xiàn)象，這對小流的吞吐率影響極大。

本文提出了一種基于ECN的TCP慢啟動擁塞控制策略GST來對TCP的慢啟動階段增窗算法進行調(diào)節(jié)改進，避免因為慢啟動增長過快而導(dǎo)致進入擁塞避免之前出現(xiàn)超時現(xiàn)象。測試中分別在DCTCP、D2TCP和L2TCP協(xié)議上部署了GST，對比了使用和不使用GST反饋調(diào)節(jié)慢啟動增窗的情況。測試結(jié)果表明，在使用了GST反饋調(diào)節(jié)慢啟動增窗之后，能將并發(fā)度提升3.4倍，吞吐率提升85倍。

1 相關(guān)工作

隨著互聯(lián)網(wǎng)應(yīng)用變得高度多樣化和復(fù)雜化，為了解決傳統(tǒng)傳輸控制協(xié)議的不足，緩解數(shù)據(jù)中心網(wǎng)絡(luò)中的TCP Incast現(xiàn)象[12]，國內(nèi)外許多學(xué)者在提高TCP對網(wǎng)絡(luò)數(shù)據(jù)擁塞控制的調(diào)控能力方面做了大量研究，尋求一些穩(wěn)定的方法讓數(shù)量動態(tài)變化的網(wǎng)絡(luò)用戶能高效使用有限的網(wǎng)絡(luò)帶寬資源。

最普遍的方案就是基于RTT測量，利用RTT變化來反映當(dāng)前鏈路擁塞情況，加速丟包恢復(fù)過程從而提高TCP吞吐量。TIMELY[5]作為基于延時的協(xié)議，無需交換機支持，利用RTT測量信息來調(diào)整發(fā)送速率，以獲得低延遲和高吞吐量。與TIMELY類似，DX[6]使用端到端延遲來決定增減擁塞窗口，實現(xiàn)近零排隊和高瓶頸鏈路利用率。但是數(shù)據(jù)中心網(wǎng)絡(luò)的RTT很小，而且動態(tài)變化，精準(zhǔn)測量成為改進的關(guān)鍵，直接影響協(xié)議性能。

基于經(jīng)典RED隊列管理算法，利用交換機ECN反饋來判斷擁塞狀態(tài)，可以準(zhǔn)確地判斷擁塞。DCTCP第一次全面討論尾部延遲，實現(xiàn)了數(shù)據(jù)中心網(wǎng)絡(luò)的高突發(fā)、低延遲、高吞吐率。但是，DCTCP協(xié)議即使當(dāng)并發(fā)度較小時，交換機緩存依然會出現(xiàn)部分流擁塞丟包甚至超時。L2TCP針對減少短流的流完成時間，以分布式的方法在發(fā)送端實現(xiàn)LAS調(diào)度。TCP-FITDC[13]是一種基于DCTCP的改進傳輸協(xié)議，通過RTT測量來進一步精確地估計鏈路擁塞程度，從而實現(xiàn)更準(zhǔn)確的擁塞控制。

在接收端，ICTCP[7]自適應(yīng)地調(diào)整接收窗口以調(diào)節(jié)總吞吐量，從而緩解Incast擁塞。作為接收端驅(qū)動的擁塞控制方案，PAC[14]主動地控制接收器側(cè)的ACK的發(fā)送速率，以防止Incast擁塞。ARS[15]是一種跨層設(shè)計，可緩解高度并發(fā)流下的TCP突發(fā)問題。ARS通過根據(jù)從傳輸層獲取的端到端擁塞信號對應(yīng)用請求進行批處理來動態(tài)調(diào)整并發(fā)TCP流的數(shù)量。

從交換機控制的角度，TCP-PLATO[16]引入了一個標(biāo)記系統(tǒng)，以確保標(biāo)記包優(yōu)先在交換機上排隊。因此，TCP發(fā)送方可以利用重復(fù)的ACK來觸發(fā)重傳，而不是等待超時。CP[17]為了保持TCP自時鐘同步，簡單地丟棄了包的數(shù)據(jù)字段而不是整個包，它需要快速和精確地檢測丟失的數(shù)據(jù)包以通知發(fā)送端。GIP[18]開始傳輸具有最小擁塞窗口大小的服務(wù)器請求單元以避免分組丟失，并且還冗余地傳輸服務(wù)器請求單元的最后分組以進一步減輕TCP超時。為了緩解由微突發(fā)流量造成的丟包，當(dāng)端口變得過載時，EDT[19]允許交換機的輸出端口暫時占用所有共享交換機緩沖區(qū)。

以上方法的問題都在于著眼于擁塞避免階段，并未考慮擁塞可能發(fā)生在更早的階段。為了避免并發(fā)傳輸中慢啟動階段增窗過快而造成的吞吐率崩潰問題，本文旨在緩解慢啟動階段的增窗方式，利用ECN標(biāo)記來動態(tài)調(diào)節(jié)慢啟動階段的擁塞控制算法。

2 問題分析

為了解數(shù)據(jù)中心網(wǎng)絡(luò)中的場景特點，分析協(xié)議傳輸中產(chǎn)生擁塞崩潰的現(xiàn)象的原因，本文就數(shù)據(jù)中心網(wǎng)絡(luò)中傳輸?shù)牧髁看笮『筒l(fā)度進行研究分析，并從流發(fā)送窗口和數(shù)據(jù)包序列號出發(fā)探究造成大量丟包產(chǎn)生超時現(xiàn)象的根本原因。

2.1 流大小分布

圖1 流大小分布圖

分析數(shù)據(jù)中心網(wǎng)絡(luò)中流量特點，發(fā)現(xiàn)大部分應(yīng)用產(chǎn)生的請求數(shù)據(jù)量很小[20]。如圖1所示，對比私有數(shù)據(jù)中心(PRV)和教育數(shù)據(jù)中心網(wǎng)絡(luò)(EDU)兩種類型的數(shù)據(jù)中心網(wǎng)絡(luò)流量特點，結(jié)果顯示90%的流量都小于100 KB。

而針對不同大小的數(shù)據(jù)流，計算在無阻塞情況下，按慢啟動指數(shù)增長方式完成傳輸所需要的RTT數(shù)量。如圖2所示，90%的數(shù)據(jù)流將在4個RTT內(nèi)傳輸完成，即大部分數(shù)據(jù)流能在少數(shù)RTT內(nèi)完成傳輸，若此時發(fā)生超時，將嚴(yán)重影響傳輸?shù)耐掏侣省?/p>

圖2 流完成時間分布圖

2.2 高并發(fā)傳輸

數(shù)據(jù)中心網(wǎng)絡(luò)中的流量分布與其底層文件系統(tǒng)緊密相關(guān)。目前普遍使用的Hadoop文件系統(tǒng)(HDFS)[21]的分布式文件系統(tǒng)，使得數(shù)據(jù)中心網(wǎng)絡(luò)流量經(jīng)常表現(xiàn)為多對一的模式。在流到達的時間間隔上，文獻[22]的研究結(jié)果表明，流平均到達率105 條/s，即有100條流/ms到達。在這樣流量高并發(fā)的情況下，很容易使得瓶頸鏈路出現(xiàn)擁塞丟包引起超時，產(chǎn)生TCP Incast現(xiàn)象，引起吞吐率崩潰。

圖3 不同并發(fā)度吞吐量情況對比

通過實驗測試DCTCP協(xié)議并發(fā)情況下出現(xiàn)的吞吐率崩潰現(xiàn)象。驗證實驗利用NS2模擬器模擬網(wǎng)絡(luò)場景，鏈路帶寬為10 Gbps，緩存大小為100 packets，DCTCP協(xié)議默認閾值Kdc大小為65 packets，RTT為100 μs。從圖3可以看出，當(dāng)小并發(fā)(如4臺服務(wù)器)的時候，數(shù)據(jù)在0.001 1 s內(nèi)傳輸完成。而當(dāng)加大并發(fā)(如10臺服務(wù)器)的時候，則出現(xiàn)了超時現(xiàn)象，導(dǎo)致鏈路空閑等待200 ms，數(shù)據(jù)到0.202 2 s時才完成傳輸，出現(xiàn)吞吐量崩潰。

2.3 超時產(chǎn)生原因分析

為了探究出現(xiàn)超時現(xiàn)象究竟發(fā)生在傳輸?shù)哪囊粋€階段，驗證慢啟動的增長激進導(dǎo)致的超時現(xiàn)象。本文對發(fā)送端的窗口大小、發(fā)包情況和丟包情況進行實驗分析。

圖4 基礎(chǔ)性能結(jié)果

圖4a顯示了慢啟動階段擁塞窗口的增長呈指數(shù)級。經(jīng)過幾輪RTT，出現(xiàn)超時現(xiàn)象，一輪RTO之后再進行重傳。圖4b顯示了TCP序列號。大量丟包發(fā)生在指數(shù)增長階段。可見，由于慢啟動指數(shù)增長方式過于激進才導(dǎo)致大量丟包，從而引發(fā)超時。

2.4 小 結(jié)

綜上對數(shù)據(jù)中心網(wǎng)絡(luò)特點的研究和慢啟動傳輸過程中傳輸控制的分析，得出：1)數(shù)據(jù)中心網(wǎng)絡(luò)中90%的數(shù)據(jù)流都小于100 KB。2)分布式的存儲模式也使得數(shù)據(jù)中心網(wǎng)絡(luò)流量經(jīng)常表現(xiàn)為多對一的模式，數(shù)據(jù)流并發(fā)度大。3)慢啟動激進的指數(shù)增長方式是引發(fā)大量丟包產(chǎn)生超時的關(guān)鍵原因。而現(xiàn)有的改進協(xié)議都專注于擁塞避免階段，忽視了激進的慢啟動增長階段。因此本文提出了一種基于ECN的TCP慢啟動擁塞控制策略，動態(tài)反饋鏈路擁塞狀況來緩解慢啟動的增窗速率。

3 協(xié)議設(shè)計

本文設(shè)計目的是新的慢啟動擁塞窗口增長算法，緩解激進的指數(shù)增長方式，以避免TCP Incast問題。設(shè)計要點包括：1)獲取慢啟動階段鏈路擁塞狀況?？紤]使用低開銷、更精準(zhǔn)的擁塞感知方法，將對交換機隊列設(shè)置新閾值K，利用ECN顯式擁塞反饋策略來感知網(wǎng)絡(luò)中的擁塞狀況[23]。2)設(shè)計平滑過渡階段的增窗算法。將從網(wǎng)絡(luò)容量角度出發(fā)，利用緩存隊列長度信息作為調(diào)窗因子，使得過度階段的增窗算法既能有效避免增長過快造成大量丟包，又能最大限度利用網(wǎng)絡(luò)容量。3)普遍適應(yīng)性。與原TCP協(xié)議兼容，保證鏈路共享公平性。在現(xiàn)有DCTCP協(xié)議基礎(chǔ)上，利用已有標(biāo)志位來反饋當(dāng)前鏈路擁塞情況。

需要說明的是，交換機連接并發(fā)主機的數(shù)量與網(wǎng)絡(luò)性能息息相關(guān)。相關(guān)理論研究與真實數(shù)據(jù)中心網(wǎng)絡(luò)應(yīng)用場景都表明[24]，當(dāng)并發(fā)服務(wù)器數(shù)量較小時，增加服務(wù)器數(shù)量能提升鏈路帶寬利用率。但當(dāng)并發(fā)服務(wù)器的數(shù)量增加到一定程度時，即使所有的發(fā)送方都降低擁塞窗口(甚至降為極小值)，交換機緩存依然會擁塞丟包，造成網(wǎng)絡(luò)性能的急劇下降。因此，尋求一種在鏈路帶寬和緩存容忍范圍內(nèi)，最大限度提升并發(fā)數(shù)量，同時保證較高的鏈路帶寬利用率的方法。

3.1 總體設(shè)計

協(xié)議設(shè)計為在慢啟動階段增加新交換機隊列長度閾值K，反饋鏈路狀況，超過K值之后進入慢啟動平滑過渡階段。如圖5所示，以DCTCP協(xié)議為例，整個傳輸過程分成3個部分：傳統(tǒng)慢啟動階段、平滑過渡階段和擁塞避免階段。新閾值K和DCTCP默認閾值Kdc決定這3個階段的分界。

圖5 設(shè)計框架圖

當(dāng)隊列長度超過閾值K之前，協(xié)議將保持原慢啟動指數(shù)增長方式，目的是當(dāng)跟其他TCP協(xié)議共存時保證鏈路帶寬的公平共享。隊列長度超過K之后，將進入平滑過渡階段。若這階段仍然按原慢啟動指數(shù)增長方式，窗口將大幅增長，造成大量丟包。因此本文設(shè)計平滑過渡階段擁塞窗口控制算法，使得鏈路能有較好的利用率，并避免大量丟包成功過渡到擁塞避免階段。而當(dāng)隊列長度超過Kdc之后，將按原協(xié)議擁塞避免算法進行窗口調(diào)節(jié)。

3.2 協(xié)議詳細設(shè)計

平滑過渡階段算法設(shè)計是保證從慢啟動階段平滑過渡到擁塞避免階段的重要部分。本文通過慢啟動階段的顯式擁塞反饋信息，設(shè)計新的慢啟動增窗算法，使得既能保持窗口持續(xù)增長又能緩解慢啟動激進的增長幅度，避免因為慢啟動增長速度過快造成的吞吐量崩潰現(xiàn)象。

3.2.1 慢啟動擁塞標(biāo)記

現(xiàn)有的顯式擁塞反饋機制ECN在IP包頭設(shè)置兩位(bit)的ECN域，一個是ECT(ECN-capable transport)位，另一個是CE(congestion experienced)位。同時，在TCP包頭中需要設(shè)置兩個標(biāo)志位：ECN-Echo和CWR(congestion window reduced)[25]。

設(shè)計旨在慢啟動階中采用交換機上的ECN顯式反饋位來獲取擁塞信息。為了避免額外的開銷，聯(lián)合使用ECN機制的兩個二進制位來編碼擁塞信息。兩個二進制位可以表達4種顯示情況：00,01,10,11。本文利用其中3種情況：00表示ECN不可用；10表示慢啟動階段閾值標(biāo)記(隊列長度超過K)；01表示DCTCP閾值標(biāo)記位(隊列長度超過Kdc)。這樣，在不增加包頭開銷的情況下，利用已有的ECN標(biāo)志位編碼來表示不同程度的擁塞狀態(tài)。

3.2.2 擁塞控制算法

發(fā)送端根據(jù)反饋回來的標(biāo)記ACK來調(diào)節(jié)下一輪發(fā)送窗口大小，因此K的取值直接影響下一輪發(fā)送窗口的大小。首先，在每個發(fā)送端基于標(biāo)記包的比例來估計當(dāng)前交換機緩存隊列長度q。

發(fā)送端的當(dāng)前發(fā)送窗口大小為w，已收到的標(biāo)記包個數(shù)為β。則隊列中未標(biāo)記包個數(shù)K與當(dāng)前隊列長度q的比值，跟接收端未收到標(biāo)記的包個數(shù)w?β與總發(fā)送窗口w大小的比值有近似等比關(guān)系：

則可估算出當(dāng)前隊列長度：q=wK/(w?β)。

本文算法設(shè)計的目的是使得既能緩解慢啟動激進的指數(shù)增窗方式，又能高效的利用網(wǎng)絡(luò)帶寬。因此設(shè)計緩沖階段的算法根據(jù)顯式反饋信息，使得調(diào)窗函數(shù)在指數(shù)增長和線性增長之間調(diào)節(jié)變化。調(diào)窗函數(shù)如下：，其中當(dāng)前隊列長度q接近K，說明鏈路擁塞情況不嚴(yán)重，則發(fā)送端發(fā)送窗口越接近指數(shù)增長模式；而當(dāng)q越接近Kdc，說明鏈路狀況開始出現(xiàn)擁塞，則使得發(fā)送窗口的增長接近線性增長模式。

3.3K取值分析

本文對慢啟動階段增加一位標(biāo)志位來顯示反饋當(dāng)前鏈路擁塞狀況?；贓CN的顯式擁塞反饋，即在交換機上設(shè)置門限值閾值取值為K(K

圖6 不同的K值對吞吐率的影響

如圖6，當(dāng)K取值很小(如K=5)時，雖未出現(xiàn)超時現(xiàn)象，但網(wǎng)絡(luò)利用率較低，帶寬利用率約為88%。當(dāng)K取值過大(如K=45)時，則無法及時退出慢啟動進入擁塞避免階段，導(dǎo)致大量丟包出現(xiàn)超時，導(dǎo)致吞吐率崩潰。而K=25時，既取得了100%的帶寬利用率，避免了大量丟包引發(fā)的超時。

圖7 G值變化圖

因此，為了選取最佳的K值，將根據(jù)網(wǎng)絡(luò)利用率以及交換機緩存利用率來進行建模分析。眾所周知，TCP的超時(一般為200 ms)是導(dǎo)致吞吐量崩潰的主要原因。發(fā)送端窗口整窗丟失[20]計算單條流出現(xiàn)超時的概率為：

式中，B為交換機緩存大??；n為并發(fā)服務(wù)器臺數(shù)；w為當(dāng)前流發(fā)送窗口大??；RTT為網(wǎng)絡(luò)往返時延；C為鏈路帶寬。而當(dāng)有n臺服務(wù)器并發(fā)時，網(wǎng)絡(luò)中發(fā)生超時產(chǎn)生吞吐率崩潰的概率為：

注入網(wǎng)絡(luò)包數(shù)量小于網(wǎng)絡(luò)容量時，鏈路利用率為nw/(B+C×RTT)；而發(fā)送包數(shù)量大于網(wǎng)絡(luò)容量時，若未超時，利用率近似為1；若出現(xiàn)超時，此時近似利用比率為RTT/RTO。綜合考慮網(wǎng)絡(luò)中超時概率和利用率來計算閾值K的取值，網(wǎng)絡(luò)有效利用率G為：

本文將在不同的并發(fā)度場景下計算不同的G值變化曲線，選取G值最高時的發(fā)送端發(fā)送窗口大小w來計算最優(yōu)的閾值K。對G進行求導(dǎo)發(fā)現(xiàn)：

由于RTT＜＜RTO，則 RTT/RTO＜＜1；則有因此，函數(shù)為減函數(shù)。

通過代入?yún)?shù)取值，得到隨著w取值變化的G值變化如圖7所示。圖7驗證了以上的分析，曲線是隨w變化的凸函數(shù)，其最高點時擁塞窗口的取值有而為了避免超時，至少要在最小超時窗口的前一輪進入慢啟動緩沖階段。因此計算出慢啟動調(diào)窗隊列長度閾值K：

4 性能評估

本文將GST算法應(yīng)用到不同的數(shù)據(jù)中心TCP協(xié)議，利用NS2模擬器對協(xié)議性能進行評估。首先，基于DCTCP協(xié)議對GST基本性能進行測試；然后，將GST方法應(yīng)用到D2TCP、L2TCP等數(shù)據(jù)中心TCP協(xié)議；最后，在兩種主流的應(yīng)用場景Web Search和MapReduce中測試GST的性能。

采用典型的數(shù)據(jù)中心網(wǎng)絡(luò)多對一的拓撲，多個服務(wù)器通過一個瓶頸鏈路同時發(fā)送數(shù)據(jù)給一個聚合器。默認包大小為1.5 KB，鏈路帶寬為10 Gbps，RTT為100 μs，服務(wù)器請求單元(server request unit, SRU)大小為64～512 KB。在其他對比協(xié)議中，平均權(quán)重因子g為1/16，DCTCP默認交換機標(biāo)記門限值為65 pkts。

4.1 基礎(chǔ)性能結(jié)果

將GST-DCTCP與DCTCP進行基礎(chǔ)性能對比。模擬場景為25臺服務(wù)器并發(fā)，緩存大小為100 pkts。其中圖8a、圖8b選取對象為出現(xiàn)超時現(xiàn)象的單條流數(shù)據(jù)，而圖8c、圖8d為鏈路整體性能對比。

1)擁塞窗口：從圖8a看出，GST-DCTCP經(jīng)過緩沖慢啟動階段，緩解了慢啟動最激進的增長趨勢，有效地避免了超時現(xiàn)象；原DCTCP由于慢啟動階段增窗過于激進導(dǎo)致大量丟包，極易出現(xiàn)圖中所示的超時現(xiàn)象。

2)TCP序列號：為了從數(shù)據(jù)包的角度反映GST對超時現(xiàn)象的避免。隨機選擇一條流觀察發(fā)送數(shù)據(jù)包的TCP序號，如圖8b所示，原DCTCP因為慢啟動的激進增長導(dǎo)致了在0.000 8 s進入超時等待，最后傳輸完成時間在0.200 47 s；對比GST-DCTCP沒有發(fā)生超時現(xiàn)象，傳輸在0.010 7 s全部完成傳輸。

圖8 基礎(chǔ)性能對比

3)瞬時吞吐量：圖8c給出網(wǎng)絡(luò)瞬時吞吐率變化情況，GST-DCTCP由于很好地緩解慢啟動增長及時避免了大量丟包，未出現(xiàn)超時現(xiàn)象，整個傳輸過程幾乎使得瓶頸鏈路滿帶寬被利用；而DCTCP則由于超時的影響，鏈路空等200 ms，極大的影響了傳輸效率。

4)交換機緩存隊列：圖8d從隊列的角度看出對數(shù)據(jù)流的控制，GST-DCTCP能在關(guān)鍵時刻及時緩解慢啟動的增長，也能最大限度的利用鏈路容量(包括交換機緩存容量)，即能在不超時的情況下最大化傳輸速率。

4.2 不同協(xié)議性能對比

GST具有協(xié)議普適性，能很好地部署到各種數(shù)據(jù)中心TCP協(xié)議。從吞吐量的角度對比DCTCP、D2TCP和L2TCP部署GST前后的性能提升情況。測試場景為并發(fā)服務(wù)器數(shù)量從1臺到72臺，緩存大小為150 pkts。發(fā)送流大小為512 KB。

1)無背景負載時的性能：如圖9a所示，3種協(xié)議在小并發(fā)情況下由于慢啟動的快速增窗使得吞吐率相比部署了GST的協(xié)議能有更高的吞吐率；而隨著并發(fā)服務(wù)器數(shù)量的增加，原慢啟動增窗太過激進，出現(xiàn)超時現(xiàn)象。而對比部署了GST之后，避免了激進的慢啟動導(dǎo)致的超時現(xiàn)象，吞吐率基本能保持滿帶寬傳輸，大大提升了網(wǎng)絡(luò)利用率。由圖9b可知，DCTCP、D2TCP和L2TCP在較小的并發(fā)度都出現(xiàn)吞吐率崩潰現(xiàn)象，之后隨著并發(fā)數(shù)的增加吞吐率都保持在比較低的水平，而緩解慢啟動增長之后，有效地避免了超時。并發(fā)度由16臺提升到70臺，提高比例約為3.3倍。

圖9 無背景流不同協(xié)議對比

2)TCP背景長流負載測試：文獻[7]中對真實數(shù)據(jù)中心流量負載進行了測量和分析并發(fā)現(xiàn)同一機架內(nèi)并發(fā)長流數(shù)目的第75分位數(shù)為2。因此在本次此時場景中，測試了同時存在2條TCP背景長流時各種協(xié)議的性能，每條TCP長流均無限發(fā)送數(shù)據(jù)。

圖10 有背景流不同協(xié)議對比

圖10中，在有2條TCP長背景流情況下，同樣在未出現(xiàn)超時前(總流數(shù)n<16)，未部署GST的協(xié)議吞吐率略高；而當(dāng)并發(fā)數(shù)超過16臺后，未部署GST的協(xié)議都出現(xiàn)了吞吐量崩潰的現(xiàn)象。但是部署了GST的協(xié)議則能保持接近滿帶寬的吞吐率，大幅提升鏈路利用率。GST支持并發(fā)數(shù)提升比例約為3.4倍。

4.3 不同場景性能對比

數(shù)據(jù)中心網(wǎng)絡(luò)的流量分布表現(xiàn)出兩種不同的模型[24]：work seeks bandwidth pattern和scatter gather pattern。而對應(yīng)網(wǎng)絡(luò)中應(yīng)用廣泛的兩種場景分別為Web search和Map Reduce。針對這兩種應(yīng)用模型，本文在NS2上模擬了兩種場景，緩存大小為100 pkts，Web search應(yīng)用場景固定傳輸數(shù)據(jù)總量為2 MB，各服務(wù)器發(fā)送數(shù)據(jù)量相等。Map Reduce應(yīng)用場景每個發(fā)送端發(fā)送流大小為100 KB。

圖11 Web Search流量模型

圖12 MapReduce流量模型

從圖11中可以看出，對于Web search應(yīng)用模型，固定傳輸總數(shù)據(jù)量隨著并發(fā)服務(wù)器數(shù)量的增長，由于DCTCP在小并發(fā)的情況下就出現(xiàn)了Incast現(xiàn)象，吞吐率一直比較低，而GST-DCTCP避免了慢啟動激進增長造成的超時現(xiàn)象，吞吐率保持比較高，而且隨著并發(fā)度的增加波動也并不是很大。平均吞吐率由79 Mbps提升為6 800 Mbps，提升比例高達85倍。圖12表明在MapReduce應(yīng)用場景下，固定服務(wù)器發(fā)送數(shù)據(jù)流大小，增加服務(wù)器并發(fā)數(shù)量，同樣GSTDCTCP性能相比DCTCP有了大幅的提升。

5 結(jié)束語

針對數(shù)據(jù)中心網(wǎng)絡(luò)特點的研究，本文總結(jié)并發(fā)現(xiàn)數(shù)據(jù)中心網(wǎng)絡(luò)中大部分都是小數(shù)據(jù)流，并具有并發(fā)度大的特點；而慢啟動激進的指數(shù)增長方式是引發(fā)大量丟包產(chǎn)生超時的關(guān)鍵原因。針對現(xiàn)有研究都關(guān)注改進于擁塞避免階段算法，而忽視了對慢啟動階段激進增長的問題，本文提出了一種基于ECN的TCP慢啟動擁塞控制策略，動態(tài)反饋網(wǎng)絡(luò)擁塞狀況來緩解慢啟動的增窗速率。實驗表明，本方法有效避免了數(shù)據(jù)中心網(wǎng)絡(luò)并發(fā)傳輸中由于慢啟動階段發(fā)送窗口增長過快導(dǎo)致的吞吐率崩潰現(xiàn)象，使得并發(fā)度提升了3.4倍，吞吐率倍數(shù)提升了85倍，大幅優(yōu)化網(wǎng)絡(luò)應(yīng)用的整體性能。

[1]MEISNER D, SADLER C M, BARROSO L A, et al.Power management of online data-intensive services[C]//Proceedings of ISCA.New York, USA: ACM, 2011:319-330.

[2]JUDD G.Attaining the promise and avoiding the pitfalls of TCP in the datacenter[C]//Proceedings of NSDI.Berkeley,USA: USENIX Press, 2015: 145-157.

[3]REN Yong-mao, ZHAO Yu, LIU Pei, et al.A survey on TCP incast in data center networks[J].International Journal of Communication Systems, 2014, 27(8): 1160-1172.

[4]LIU Fang-ming, GUO Jian, HUANG Xiao-meng.EBA:Efficient bandwidth guarantee under traffic variability in datacenters[C]//IEEE/ACM Transactions on Networking.Piscataway: IEEE, 2017, 25(1): 506-519.

[5]MITTAL R, LAM V T, DUKKIPATI N, et al.TIMELY:RTT-based congestion control for the datacenter[C]//Proceedings of ACM SIGCOMM.New York, USA: ACM,2015: 537-550.

[6]LEE C, PARK C, JANG K, et al.Accurate Latency-based congestion feedback for datacenters[C]//Proceedings of USENIX ATC.Berkeley, USA: USENIX Press, 2015:403-415.

[7]WU Hai-tao, FENG Zhen-qian, GUO Chuan-xiong, et al.ICTCP: Incast congestion control for TCP in data center networks[C]//Proceedings of CoNEXT.New York, USA:ACM, 2010.

[8]ALIZADEH M, GREENBERG A, MALTZ D A, et al.Data center TCP (DCTCP)[C]//Proceedings of ACM SIGCOMM.New York, USA: ACM, 2010: 63-74.

[9]VAMANAN B, HASAN J, VIJAYKUMAR T N.Deadlineaware datadcenter TCP (D2TCP)[C]//Proceedings of ACM SIGCOMM.New York, USA: ACM, 2012: 115-126.

[10]MUNIR A, QAZI I A, UZMI Z A, et al.Minimizing flow completion times in data centers[C]//Proceedings of INFOCOM.Piscataway, USA: IEEE, 2013: 2157-2165.

[11]CHEN Yan-pei, GRIFFITH R, LIU Jun-da, et al.Understanding TCP incast throughput collapse in datacenter networks[C]//Proceedings of WREN Workshop.New York, USA: ACM, 2009: 73-82.

[12]VASUDEVAN V, PHANISHAYEE A, SHAH H, et al.Safe and effective fine-grained TCP retransmissions for datacenter communication[C]//Proceedings of ACM SIGCOMM.New York, USA: ACM, 2009: 303-314.

[13]ZHANG Jun, WEN Jiang-tao, WANG Jing-yuan, et al.TCP-FITDC: an adaptive approach to TCP incast avoidance for data center applications[C]//Proceedings of ICNC.Piscataway, USA: IEEE, 2013: 1048-1052.

[14]BAI Wei, CHEN Kai, WU Hai-tao, et al.PAC: Taming TCP incast congestion using proactive ACK control[C]//Proceedings of ICNP.Piscataway, USA: IEEE,2014: 385-396.

[15]HUANG Jia-wei, HE Tian, HUANG Yi, et al.ARS:Cross-layer adaptive request scheduling to mitigate TCP incast in data center networks[C]//Proceedings of INFOCOM.Piscataway, USA: IEEE, 2016: 1-9.

[16]SHUKLA S, CHAN S, TAM A S W, et al.TCP PLATO:Packet labelling to alleviate time-out[J].IEEE Journal on Selected Areas in Communications, 2014, 32(1): 65-76.

[17]CHENG Peng, REN Feng-yuan, SHU Ran, et al.Catch the whole lot in an action: Rapid precise packet loss notification in data centers[C]//Proceedings of USENIX NSDI.Berkeley, USA: USENIX Press, 2014: 17-28.

[18]ZHANG Jiao, REN Feng-yuan, TANG Li, et al.Taming TCP incast throughput collapse in data center networks[C]//Proceedings of ICNP.Piscataway, USA: IEEE, 2013:1-10.

[19]SHAN Dan-feng, JIANG Wan-chun, REN Feng-yuan, et al.Absorbing micro-burst traffic by enhancing dynamic threshold policy of data center switches[C]//Proceedings of INFOCOM.Piscataway, USA: IEEE, 2015: 118-126.

[20]BENSON T, AKELLA A, MALTZ D A.Network traffic characteristics of data centers in the wild[C]//Proceeding of IMC.New York, USA: ACM, 2010: 267-280.

[21]BORTHAKUR D.The hadoop distributed file system:Architecture and design[EB/OL].[2016-10-16].https://svn.eu.apache.org/repos/asf/hadoop/common/tags/release-0.16.3/docs/hdfs_design.pdf.

[22]KANDULA S, SENGUPTA S, GREENBERG A, et al.The nature of data center traffic: Measurements and analysis[C]//Proceedings of ACM SIGCOMM.New York, USA:ACM, 2009.

[23]BAI W, CHEN L, CHEN K, et al.Enabling ECN in multi-service multi-queue data centers[C]//Proceedings of NSDI.Berkeley, USA: USENIX Press, 2016: 537-549.

[24]CHEN Wen, REN Feng-yuan, XIE Jing, et al.Comprehensive understanding of TCP incast problem[C]//Proceedings of INFOCOM.Piscataway, USA: IEEE,2015: 1688-1696.

[25]XIA Yong, SUBRAMANIAN L, STOICA I, et al.One more bit is enough[C]//Proceedings of ACM SIGCOMM.New York, USA: ACM, 2005: 37-48.