郭麗娜

（中國航天科工集團(tuán)第二研究院706所，北京100854）

0 引 言

由于數(shù)據(jù)中心網(wǎng)絡(luò)需要可靠傳輸，所以在廣域網(wǎng)成功應(yīng)用多年的TCP可靠傳輸協(xié)議目前也普遍應(yīng)用于數(shù)據(jù)中心網(wǎng)絡(luò)中，但是本身針對于廣域網(wǎng)環(huán)境設(shè)計(jì)的TCP協(xié)議并不適合高帶寬、低延遲的數(shù)據(jù)中心網(wǎng)絡(luò)環(huán)境，比如在網(wǎng)絡(luò)中普遍使用的Linux 操作系統(tǒng)中，TCP 的重傳超時(shí)計(jì)時(shí)器RTO 默認(rèn)值為200ms，該值遠(yuǎn)遠(yuǎn)大于數(shù)據(jù)中心網(wǎng)絡(luò)的平均RTT 值 （一般為10μs至100μs）［1］。

TCP Incast問題指［2］：在數(shù)據(jù)中心網(wǎng)絡(luò)中，當(dāng)多個(gè)發(fā)送者同時(shí)向一個(gè)接收者發(fā)送數(shù)據(jù)塊時(shí)，隨著發(fā)送者個(gè)數(shù)的增多，接收者的瓶頸鏈路吞吐率會急劇下降，產(chǎn)生吞吐率崩潰現(xiàn)象。由于這種多對一的網(wǎng)絡(luò)模型在數(shù)據(jù)中心網(wǎng)絡(luò)中普遍存在，所以TCP Incast成為數(shù)據(jù)中心網(wǎng)絡(luò)傳輸性能的突出問題。

本文對TCP Incast問題進(jìn)行了詳細(xì)的介紹，并通過NS2仿真實(shí)驗(yàn)對該問題進(jìn)行了深入的分析。

1 TCP Incast問題

1.1 問題背景

數(shù)據(jù)中心網(wǎng)絡(luò)的環(huán)境特點(diǎn)和通信模型是導(dǎo)致TCP In－cast問題的主要因素。

數(shù)據(jù)中心網(wǎng)絡(luò)鏈路為高帶寬、低延遲鏈路；同一個(gè)機(jī)架上的服務(wù)器由一個(gè)架頂交換機(jī)［3］（top of rack switch）鏈接，目前數(shù)據(jù)中心由于成本限制，采用的架頂交換機(jī)一般為商品交換機(jī)［4］，具有淺緩沖區(qū)的特點(diǎn)；同時(shí)數(shù)據(jù)中心網(wǎng)絡(luò)中大部分流量為短數(shù)據(jù)流［5］，如搜索引擎的查詢請求產(chǎn)生的數(shù)據(jù)流。

數(shù)據(jù)中心網(wǎng)絡(luò)具有典型的劃分聚合通信模型［4］（Partition／Aggregate）。如圖1 所示，當(dāng)一個(gè)任務(wù)請求到來，由一個(gè)Aggregator將任務(wù)分配給下層的多個(gè)Aggregator，逐層下發(fā)后最終分配給實(shí)際執(zhí)行任務(wù)的 Worker 節(jié)點(diǎn)。Worker執(zhí)行完任務(wù)后將結(jié)果返回給上層Aggregator，Aggregator逐層向上匯聚，最后得到結(jié)果。數(shù)據(jù)中心網(wǎng)絡(luò)中像搜索引擎這樣對時(shí)效性要求嚴(yán)格的應(yīng)用，在此過程中會限制延遲的時(shí)間，如果一個(gè)查詢請求延遲限制 （deadline）為250ms，每一層劃分都會縮小延遲限制值，超過deadline的任務(wù)就會被舍棄，影響最終結(jié)果的質(zhì)量。

圖1 劃分聚合通信模型

劃分聚合通信模型普遍存在于數(shù)據(jù)中心網(wǎng)絡(luò)的應(yīng)用程序中。例如搜索引擎：一個(gè)關(guān)鍵字的查詢請求分發(fā)給多個(gè)Worker進(jìn)行計(jì)算，然后將多個(gè)結(jié)果同時(shí)返回，最終匯聚給終端用戶；MapReduce計(jì)算模型［6］：大量的key－value鍵值對中間結(jié)果從多個(gè)mapper同時(shí)發(fā)送匯聚給reducer；分布式存儲集群［2］：多個(gè)存儲節(jié)點(diǎn)向請求數(shù)據(jù)的節(jié)點(diǎn)同時(shí)發(fā)送應(yīng)答。

1.2 問題描述

由以上背景可知，數(shù)據(jù)中心網(wǎng)絡(luò)中普遍存在多對一的通信模型，如圖2所示，當(dāng)一個(gè)任務(wù)被分發(fā)給多個(gè)服務(wù)器處理后，多個(gè)服務(wù)器將執(zhí)行結(jié)果同時(shí)發(fā)送給請求者接收端，同一批發(fā)送的執(zhí)行結(jié)果稱為數(shù)據(jù)塊 （data block），其中每一個(gè)服務(wù)器發(fā)送一個(gè)服務(wù)請求單元 （SRU）。隨著同時(shí)發(fā)送的服務(wù)器數(shù)量的增多，接收端與交換機(jī)之間的鏈路吞吐率會急劇下降，這種多對一發(fā)送模式下接收者吞吐率崩潰的現(xiàn)象稱為TCP Incast問題。

圖2 TCP Incast多對一場景

1.3 問題原因

產(chǎn)生該問題的主要原因是：①數(shù)據(jù)突發(fā)性同時(shí)傳輸，交換機(jī)淺緩沖區(qū)容量有限，導(dǎo)致緩沖區(qū)溢出，造成后到數(shù)據(jù)包的丟失；②大量丟包導(dǎo)致TCP擁塞控制，發(fā)送窗口減半，降低發(fā)送速率；③TCP 對丟包進(jìn)行超時(shí)重傳，根據(jù)RTO 默認(rèn)值，超時(shí)一般會持續(xù)200ms，而數(shù)據(jù)中心網(wǎng)絡(luò)中RTT （10μs至100μs）遠(yuǎn)遠(yuǎn)小于RTO，導(dǎo)致鏈路有90%以上空閑［2］。

2 NS2仿真實(shí)驗(yàn)設(shè)計(jì)

本文基于廣泛使用的開源網(wǎng)絡(luò)仿真平臺軟件NS2［7］（版本為NS2.35），在Linux系統(tǒng) （Fedora 13）下開發(fā)仿真實(shí)驗(yàn)程序并運(yùn)行仿真實(shí)驗(yàn)。

如圖3所示，采用多對一的網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)，實(shí)線表示鏈路，所有鏈路帶寬為1000 Mbps，鏈路延遲為25μs，交換機(jī)R0和接收者R1之間為瓶頸鏈路。虛線表示節(jié)點(diǎn)綁定的代理，每個(gè)發(fā)送節(jié)點(diǎn)綁定TCP 協(xié)議和FTP 應(yīng)用，F(xiàn)TP發(fā)送SRU 大小256KB，接收者R1為每一個(gè)鏈接綁定接收代理TCPSink。仿真程序在所有發(fā)送者同一批SRU 都被接收到以后再發(fā)送下一批。

圖3 NS2仿真網(wǎng)絡(luò)拓?fù)?/p>

詳細(xì)實(shí)驗(yàn)參數(shù)設(shè)置如表1所示。下一節(jié)將通過改變交換機(jī)緩沖區(qū)大小、SRU 大小和RTO 最小值來分析實(shí)驗(yàn)結(jié)果。當(dāng)某一個(gè)參數(shù)變化時(shí)，其它參數(shù)保持不變。

表1 NS2仿真參數(shù)

實(shí)驗(yàn)結(jié)果主要考察瓶頸鏈路性能，即接收者R1的吞吐率隨著發(fā)送端Server數(shù)量不同的變化情況。

3 實(shí)驗(yàn)及分析

3.1 TCP Incast現(xiàn)象

如圖4所示，當(dāng)同時(shí)發(fā)送的Server數(shù)量較小時(shí)，吞吐率在900Mbps左右，當(dāng)Server數(shù)量增加到8時(shí)，吞吐率崩潰到100 Mbps 以下，產(chǎn)生TCP Incast現(xiàn)象，之后隨著Server數(shù)量的增多，吞吐率一直徘徊在100 Mbps到200 Mbps之間。

實(shí)驗(yàn)結(jié)果與文獻(xiàn) ［8］的結(jié)果一致，而文獻(xiàn) ［2］中的復(fù)現(xiàn)結(jié)果在Server數(shù)量為4時(shí)吞吐率降低到300 Mbps到400 Mbps之間，之后再降低到100 Mbps。

3.2 不同TCP改進(jìn)協(xié)議的性能

圖4 TCP Incast現(xiàn)象

由于TCP擁塞控制算法和差錯控制算法是影響TCP協(xié)議傳輸性能的主要因素，因此，我們實(shí)驗(yàn)比較了采用不同算法的幾種典型的TCP改進(jìn)協(xié)議在云數(shù)據(jù)中心網(wǎng)絡(luò)環(huán)境下TCP Incast場景中的性能。主要實(shí)驗(yàn)測量了快速恢復(fù)算法的NewReno、選擇性應(yīng)答的Sack、二分搜索尋找目標(biāo)窗口的Bic和通過上次擁塞事件消逝事件檢測網(wǎng)絡(luò)擁塞程度的HTCP。

如圖5所示，以上4種TCP改進(jìn)協(xié)議都產(chǎn)生了相同的吞吐率曲線趨勢，沒有改進(jìn)TCP Incast問題。細(xì)微的差別只是產(chǎn)生吞吐率崩潰的Server數(shù)量略有不同。

圖5 TCP改進(jìn)協(xié)議比較

3.3 不同緩沖區(qū)大小條件的性能

由1.3節(jié)的問題原因分析可知，產(chǎn)生TCP Incast問題的關(guān)鍵在于交換機(jī)緩沖區(qū)過小導(dǎo)致的溢出和丟包。因此，我們通過調(diào)整緩沖區(qū)大小，實(shí)驗(yàn)比較了不同緩沖區(qū)大小條件下的傳輸性能。圖6 顯示了實(shí)驗(yàn)結(jié)果，當(dāng)緩沖區(qū)由32 KB不斷增大到1024KB 時(shí)，吞吐率崩潰發(fā)生的Server數(shù)量隨之增大。

實(shí)驗(yàn)結(jié)果表明，通過增大瓶頸交換機(jī)緩沖區(qū)大小可以解決TCP Incast問題。但是該方法有兩個(gè)缺點(diǎn)：一是大緩沖區(qū)的交換機(jī)價(jià)格很高，如Force10E1200價(jià)格約為5萬美元［2］，架頂交換機(jī)都增大緩沖區(qū)會提高數(shù)據(jù)中心建設(shè)成本，違背數(shù)據(jù)中心通過規(guī)?；?jīng)濟(jì)原理降低成本的初衷；二是即使增大了交換機(jī)的緩沖區(qū)也會帶來問題，如前面所述，數(shù)據(jù)中心網(wǎng)絡(luò)多為延遲敏感的短數(shù)據(jù)流，大緩沖區(qū)會增大后到的短數(shù)據(jù)流排隊(duì)等待的時(shí)間［4］。

圖6 不同緩沖區(qū)大小比較

3.4 不同服務(wù)請求單元條件的性能

如圖7所示，實(shí)驗(yàn)結(jié)果顯示，增大服務(wù)請求單元SRU的大小有助于減輕TCP Incast問題。當(dāng)SRU 增大至8192 KB時(shí)，帶寬利用率可以保持在80%以上。更大的SRU 使得發(fā)送端Server在等待超時(shí)事件發(fā)生的同時(shí)更有效利用鏈路空余帶寬，減小等待超時(shí)對帶寬利用率的損耗。

圖7 不同SRU 比較

但是，該方法也存在以下兩個(gè)缺點(diǎn)：

（1）大的SRU 在數(shù)據(jù)中心網(wǎng)絡(luò)的大部分應(yīng)用中是不可行的。數(shù)據(jù)中心分布式計(jì)算的宗旨就是將一個(gè)任務(wù)分散到大量的計(jì)算節(jié)點(diǎn)，每個(gè)計(jì)算節(jié)點(diǎn)快速地計(jì)算完成一個(gè)小數(shù)據(jù)塊，最終匯聚返回結(jié)果。假設(shè)一個(gè)任務(wù)的總量為8 MB，若SRU 大至8 MB，則該任務(wù)只分配給一個(gè)計(jì)算節(jié)點(diǎn)，計(jì)算時(shí)間取決于單個(gè)節(jié)點(diǎn)處理8 MB 任務(wù)的時(shí)間；如果SRU為256KB，則該任務(wù)會分配給32 個(gè)計(jì)算節(jié)點(diǎn)，單個(gè)計(jì)算節(jié)點(diǎn)的計(jì)算時(shí)間明顯較小。

（2）在快速的分布式存儲系統(tǒng)中，更大的SRU 會增加請求端內(nèi)核的內(nèi)存壓力，可能造成請求的失?。?］。

3.5 不同RTO 最小值條件的性能

如1.3節(jié)所述，造成TCP Incast問題的主要原因之一是TCP對丟包進(jìn)行超時(shí)重傳，而默認(rèn)的RTO 遠(yuǎn)遠(yuǎn)大于數(shù)據(jù)中心網(wǎng)絡(luò)的RTT值，重傳等待造成鏈路空閑。如圖8所示，減小RTO最小值有助于減輕Incast現(xiàn)象，提高吞吐率。

圖8 不同RTO 最小值比較

TCP協(xié)議存在延遲ACK 概念，即不立即發(fā)送ACK，而是等待一段延遲時(shí)間將ACK 與該方向發(fā)送的數(shù)據(jù)包一起發(fā)送。Linux 系統(tǒng)默認(rèn)的延遲ACK 等待時(shí)間為40 ms［9］，當(dāng)RTO 最小值減小至低于40ms時(shí)，將產(chǎn)生ACK 還未到達(dá)就超時(shí)重傳的冗余現(xiàn)象。所以我們通過關(guān)閉延遲ACK 觀察TCP Incast情況，如圖9所示，在RTO 最小值默認(rèn)200 ms時(shí)，關(guān)閉延遲ACK 對吞吐率沒有影響；在RTO 最小值減小到40 ms和1 ms時(shí)，關(guān)閉延遲ACK 有助于提高吞吐率。

圖9 不同RTO 及關(guān)閉延遲ACK 比較

但是該方法存在實(shí)現(xiàn)可行性和安全性兩個(gè)缺點(diǎn)。首先，小的RTO 最小值需要操作系統(tǒng)很小的時(shí)鐘粒度支持，現(xiàn)有的Linux 操作系統(tǒng)時(shí)鐘粒度無法實(shí)現(xiàn)1ms 的RTO 最小值［2］。其次，過小的RTO 最小值可能導(dǎo)致大量不必要的重傳，即使時(shí)鐘粒度支持小RTO 的實(shí)現(xiàn)，對于其取值的權(quán)衡也需要進(jìn)一步研究。

3.6 調(diào)整TCP擁塞窗口限值

通過對TCP Incast現(xiàn)象的深入分析，我們發(fā)現(xiàn)，造成吞吐率急劇下降的一個(gè)主要原因是各個(gè)服務(wù)器在傳輸時(shí)對發(fā)送速率缺乏約束，沒有根據(jù)網(wǎng)絡(luò)狀況進(jìn)行適應(yīng)性調(diào)整。因此，我們根據(jù)網(wǎng)絡(luò)狀況，通過動態(tài)調(diào)整擁塞窗口限值來控制各個(gè)服務(wù)器的發(fā)送速率，使其不超過其公平分享帶寬，以此避免擁塞發(fā)生，從而提高TCP Incast傳輸模式的傳輸性能。該算法主要原理如下：

首先，計(jì)算鏈路的容量

式中：BW——瓶頸帶寬，RTT——往返時(shí)延，Queue——鏈路上的隊(duì)列長度，其值主要由交換機(jī)的緩存大小決定。

然后，計(jì)算每個(gè)服務(wù)器流的公平分享容量

式中：N——同時(shí)傳輸?shù)姆?wù)器流數(shù)目。然后，設(shè)置每個(gè)流擁塞窗口的限值為Cs。

在每次傳輸初始，系統(tǒng)計(jì)算好Cs，動態(tài)調(diào)整擁塞窗口限值，而不是采用固定的默認(rèn)值。圖10顯示了在第2節(jié)介紹的實(shí)驗(yàn)配置下，采用動態(tài)擁塞窗口限值算法與默認(rèn)情況的實(shí)驗(yàn)結(jié)果對比，從圖中可以看出，采用動態(tài)擁塞窗口限值算法顯著地提高了TCP Incast傳輸模式的性能。

圖10 動態(tài)擁塞窗口限值效果 （1G 鏈路）

圖11顯示了在10G 瓶頸鏈路帶寬環(huán)境下，采用動態(tài)擁塞窗口限值優(yōu)化算法與默認(rèn)窗口的實(shí)驗(yàn)結(jié)果對比，在10G高速網(wǎng)絡(luò)環(huán)境下，在服務(wù)器數(shù)目較大時(shí)，該算法相對于1G鏈路帶寬環(huán)境優(yōu)勢更明顯。

圖11 動態(tài)擁塞窗口限值效果 （10G 鏈路）

但是，調(diào)整擁塞窗口限值的方法具有依賴于計(jì)算和手動配置的局限性，難以適用于變化的環(huán)境。

4 結(jié)束語

本文通過NS2仿真實(shí)驗(yàn)對數(shù)據(jù)中心網(wǎng)絡(luò)中的TCP Incast問題進(jìn)行了研究。通過改變交換機(jī)緩沖區(qū)、服務(wù)請求單元SRU、RTO 最小值等影響因素進(jìn)行實(shí)驗(yàn)和比較分析，發(fā)現(xiàn)增大緩沖區(qū)、增大SRU、減小RTO 最小值以及在小RTO 情況下關(guān)閉延遲ACK 等方法可以減輕TCP Incast問題，但是這些方法在數(shù)據(jù)中心網(wǎng)絡(luò)中都存在缺點(diǎn)和局限性。由于TCP擁塞控制算法是影響TCP 協(xié)議性能的一個(gè)主要原因，而標(biāo)準(zhǔn)TCP協(xié)議擁塞控制算法是針對低帶寬低時(shí)延的網(wǎng)絡(luò)環(huán)境設(shè)計(jì)的，現(xiàn)有主流的各種TCP改進(jìn)協(xié)議的擁塞控制算法主要是針對高帶寬高時(shí)延網(wǎng)絡(luò)進(jìn)行改進(jìn)的，在低帶寬低時(shí)延的云數(shù)據(jù)中心網(wǎng)絡(luò)環(huán)境中性能同標(biāo)準(zhǔn)TCP一樣性能不佳，因此，要從根本上解決云數(shù)據(jù)中心網(wǎng)絡(luò)中TCP Incast性能問題，需要研究針對云數(shù)據(jù)中心網(wǎng)絡(luò)特點(diǎn)的TCP擁塞 控制算法和 傳輸協(xié)議［3－4，10－12］。

［1］Chen Y，Griffith R，Liu J，et al.Understanding TCP Incast throughput collapse in datacenter networks ［C］／／In Proc 1stACM Workshop on Research on Enterprise Networking，2009.

［2］Phanishayee A，Krevat E，Vasudevan V，et al.Measurement and analysis of TCP throughput collapse in cluster－based storage systems［C］／／Proceedings of the 6th USENIX Conference on File and Storage Technologies，2008：1－14.

［3］Wu H，F(xiàn)eng Z，Guo C，et al.ICTCP：Incast congestion con－trol for TCP in data center networks［C］／／In ACM CoNEXT，2010.

［4］Alizadeh M，Greenberg A，Maltz D，et al.Data center TCP（DCTCP）［C］／／In Proc ACM SIGCOMM，2010.

［5］Kandula S，Sengupta S，Greenberg A，et al.The nature of datacenter traffic：Measurements and analysis ［C］／／In Proc of Internet Measurement Conference，2009.

［6］Dean J，Ghemawat S.MapReduce：Simplified data processing on large clusters［C］／／6th Symposium on Operating Systems Design and Implementation，2008：137－149.

［7］The network simulator－ns－2［EB／OL］.［2013－09－01］.http：／／www.isi.edu／nsnam／ns／.

［8］Zhang J，Ren FY，Lin C.Modelling and understanding TCP Incast in data center networks［C］／／Proceedings of the 30th IEEE International Conference on Computer Communications，2011.

［9］Vasudevan V，Phanishayee A，Shah H，et al.Safe and effective fine－grained TCP retransmissions for datacenter communication ［C］／／In Proceedings of the ACM SIGCOMM，2009：303－314.

［10］Adrian S－W Tam，Kang Xi，Yang Xu，et al.Preventing TCP Incast throughput collapse at the initiation，continuation，and termination ［C］／／In Proc IEEE 20th International Workshop on Quality of Service，2012.

［11］Jaehyun Hwang，Joon Yoo，Nakjung Choi.IA－TCP：A rate based Incast－avoidance algorithm for TCP in data center networks［C］／／In Proc IEEE International Conference on Communications，2012：1292－1296.

［12］Jun Zhang，Jiangtao Wen，Jingyuan Wang，et al.TCP－FITDC：An adaptive approach to TCP Incast avoidance for data center applications［C］／／In Proc ICNC，2013.