夏 羽，廖蘋秀，崔 雷

(1.四川師范大學 計算機科學學院，成都 610101； 2.中國電子科技集團公司 第30研究所，成都 610041；3.華為技術有限公司，廣東 深圳 518129)

(*通信作者電子郵箱rainsia@163.com)

數(shù)據(jù)中心中TCP連接建立過程的優(yōu)化方法

夏 羽1*，廖蘋秀2，崔 雷3

(1.四川師范大學 計算機科學學院，成都 610101； 2.中國電子科技集團公司 第30研究所，成都 610041；3.華為技術有限公司，廣東 深圳 518129)

(*通信作者電子郵箱rainsia@163.com)

針對數(shù)據(jù)中心中由于SYN包丟失而引起的TCP連接被延遲從而錯過任務時間限制的問題，在無需更換現(xiàn)有設備以及無需修改應用和TCP的前提下，提出一種基于加權隨機早期檢測(WRED)協(xié)議的TCP連接初始化的優(yōu)化方法。該方法解決了連接優(yōu)化的三個關鍵問題：如何識別和標記SYN包，如何在交換機上為SYN包預留空間以及需要預留多少空間。與原TCP相比，優(yōu)化后TCP連接建立的時間極大地減少。實驗表明TCP連接初始化優(yōu)化方法可以解決任務錯過規(guī)定時間限制的問題。

數(shù)據(jù)中心；傳輸控制協(xié)議；三次握手；SYN分組

0 引言

數(shù)據(jù)中心已經(jīng)成為大數(shù)據(jù)、云計算和移動計算必不可少的基礎設施?，F(xiàn)代數(shù)據(jù)中心基本上是基于Internet模型建立的，因此大部分現(xiàn)有數(shù)據(jù)中心都直接使用經(jīng)典的TCP/IP模型。然而經(jīng)典的傳輸控制協(xié)議(Transmission Control Protocol, TCP)在數(shù)據(jù)中心環(huán)境中卻往往顯得力不從心，在筆者所在實驗數(shù)據(jù)中心當中部署和測試應用時，發(fā)現(xiàn)應用的性能顯得極其低下。經(jīng)過大量的收集、統(tǒng)計和分析工作，我們發(fā)現(xiàn)了TCP連接建立過程中存在的潛在問題：TCP握手數(shù)據(jù)包“SYN”一旦丟失，則會造成較大的連接時延，從而嚴重影響整個計算任務的性能、降低計算結果的準確性甚至使得整個計算任務錯過規(guī)定的計算時間。為了解決這個問題，提出了一種基于加權隨機早期檢測(Weighted Random Early Detection, WRED)的主動隊列管理方法來避免SYN包的丟失，從而優(yōu)化數(shù)據(jù)中心中TCP連接的建立過程。這種方法不需要更新現(xiàn)有數(shù)據(jù)中心的任何設備，也不需要更改現(xiàn)有的TCP，可以在任何數(shù)據(jù)中心當中有效地部署。

1 TCP連接建立問題

數(shù)據(jù)中心是大量的計算節(jié)點通過網(wǎng)絡相互連接而組成的高性能計算設施，這些計算節(jié)點之間相互協(xié)作，最終完成一個計算任務。這些計算任務的完成一般都有一定的時間限制，這個限制一般被稱為服務水平約定(Service-Level Agreement, SLA)。為了使計算節(jié)點獲得更多的處理時間，數(shù)據(jù)中心內(nèi)部都采用高速網(wǎng)絡連接。由于計算量龐大，數(shù)據(jù)中心中的計算任務一般都使用大量的計算節(jié)點并行運行，最后將這些計算結果匯總到同一個計算節(jié)點再作統(tǒng)一的處理，這種計算模型一般被稱為Map/Reduce[1]。

為了處理某個計算任務，建立了一個基于FatTree結構[2]的數(shù)據(jù)中心。FatTree結構(如圖1所示)的優(yōu)點是在數(shù)據(jù)中心的任意層次都不需要使用更高性能的交換機/路由器的前提下對整個數(shù)據(jù)中心提供全二分帶寬(bisection bandwidth)，從而提高數(shù)據(jù)中心的性價比。在這個實驗數(shù)據(jù)中心中，使用Map/Reduce模型在不同的服務器上部署計算任務來收集和處理數(shù)據(jù)，然后在特定的時間點把這些分別處理的數(shù)據(jù)匯總到某個服務器集中處理。從收集、處理到匯總計算的時間必須被限制在某個預定的SLA之內(nèi)完成，但在實際實驗時發(fā)現(xiàn)，大量的計算任務遠遠地錯過了預定的SLA。

圖1 FatTree結構示例Fig. 1 Illustration of the FatTree data center

起初筆者認為這是由于TCP傳輸效率引起的，因此根據(jù)已有數(shù)據(jù)中心TCP優(yōu)化的相關文獻資料，更換了TCP的不同版本(例如DCTCP等[3-5])，但還是出現(xiàn)大部分的計算任務錯過了SLA。為了進一步分析其原因，我們收集了網(wǎng)絡運行過程中的信息，并對網(wǎng)絡的運行情況進行了分析。最終發(fā)現(xiàn)了數(shù)據(jù)中心中關于TCP的一個潛在問題：TCP連接建立過程中，一旦SYN包丟失，則連接建立過程被延遲，而由于缺少一些數(shù)據(jù)，使得計算精度被降低甚至整個計算任務超過時間限制而無效。

為了隱藏實驗數(shù)據(jù)中心應用的部署細節(jié)，同時也為了能更清楚地闡述在分析中發(fā)現(xiàn)的問題，使用一個簡化版本的實驗來說明連接延遲問題。如圖2所示，有21個服務器由一個端口速率均為1 Gb/s的48口交換機相互連接。其中20個服務器運行計算任務，而每個服務器處理10個單獨的計算任務。當每個服務器中相應的任務處理完成后，各個服務器將自己的處理結果匯總給一個特定的服務器。這20個服務器稱為工作節(jié)點(worker)，而這個特定的服務器被稱為匯總節(jié)點(aggregator)。當匯總節(jié)點接收到所有工作節(jié)點的計算結果后，整理這些結果，最后整個計算任務完成。交換機共有8 MB主存空間，這些主存平均分配給48個端口。由于交換機運行需要占用一定的主存，但手冊上并未給出具體數(shù)值，我們通過實驗提前估算了在平均分配策略下每個端口可以分配100 KB左右的隊列空間。此外，根據(jù)實驗統(tǒng)計，所有數(shù)據(jù)處理任務完成時間相差在500 ms以內(nèi)。為了便于理解和估計，將每個處理任務發(fā)送的數(shù)據(jù)量限制為1 MB,可以簡單計算需要傳輸?shù)目倲?shù)據(jù)量為20×10×1 MB=200 MB。由于瓶頸帶寬為1 Gb/s，在理想情況下，整個傳輸完成時間應該為1.6 s左右。然而在實際網(wǎng)絡中遠遠達不到全速率的傳輸，加上TCP握手時間、傳輸時間、TCP窗口調(diào)整速率損失以及TCP丟包重傳時間等因素，預計流完成時間應該在3 s以內(nèi)較為合理,但實際的實驗結果卻遠遠超出了3 s。

為了進一步分析原因，將這200個傳輸任務進行編號，分別記為0～200條流。在實驗中沒有任何其他背景流量的情況下，200條流的完成時間如圖3(a)所示，其中橫坐標表示流的編號，縱坐標則表示流從開始建立TCP連接到完成1 MB數(shù)據(jù)傳輸所經(jīng)歷的時間。從圖3(a)中可以看出，有少量的流用了9 s左右的時間才完成傳輸,這影響了整個數(shù)據(jù)的完整傳輸，降低了計算結果的質(zhì)量。

將圖3(a)中的流完成時間進一步分解為圖3(b)所示的連接建立時間和圖3(c)所示的流傳輸時間。連接建立時間是指從開始建立TCP連接到連接建立完成的時間，而流傳輸時間是指從TCP連接建立完成到1 MB數(shù)據(jù)傳輸完成所用的時間。從圖3(b)中可以清楚地看到，某些連接在創(chuàng)建時所消耗的時間就已經(jīng)超過了3 s，少量的連接甚至消耗了9 s左右；而圖3(c)所顯示的傳輸數(shù)據(jù)所占的時間僅為很少的一部分，用于傳輸?shù)淖畲髸r間僅為2.02 s。因此整個任務的完成時間主要由連接建立時間所決定。

圖2 實驗模型Fig. 2 Experimental model

圖3 200條流的完成、連接建立與傳輸時間Fig. 3 Completion, establishment and transfer time of 200 flows

Map/Reduce流量表現(xiàn)出極大的突發(fā)和匯聚特性，也被稱為高扇入(high fan-in)特性[6]。當大量的流申請和匯總節(jié)點建立連接時，由于交換機出口隊列中存在大量的分組，從而導致隊列擁塞。現(xiàn)有的工作多集中在研究數(shù)據(jù)包丟失之后如何快速重傳該數(shù)據(jù)包以避免200 ms的最小重傳超時時間(Retransmission TimeOut，RTO)[5,7-8]。而實驗表明，隊列擁塞也可能造成TCP握手數(shù)據(jù)包“SYN”丟失，此時發(fā)送端和接收端均無法發(fā)現(xiàn)SYN包的丟失，因此只能等待超時。通過實驗發(fā)現(xiàn)，超時時間大概是3 s左右(不同操作系統(tǒng)中超時時間略有不同)。筆者試圖減少這個延遲時間，但并沒有找到可以控制這個時延行為的環(huán)境變量。要減少這個超時時間，必須修改TCP，這和我們不修改當前運行環(huán)境的出發(fā)點相沖突。

SYN包被丟棄到超時的過程如圖4所示，當發(fā)送端發(fā)送的SYN包丟失之后，發(fā)送端和接收端都無法得知SYN包的丟失信息，因此發(fā)送端必須等待超時之后才會再次發(fā)送SYN包。接收端接收到SYN包之后回復SYN+ACK包，最后發(fā)送端回復ACK包后連接建立完成，發(fā)送端和接收端之間開始數(shù)據(jù)傳輸。如果重傳的SYN包再次因為擁塞而丟失，延遲時間將會呈指數(shù)增長，這個行為被稱為TCP的指數(shù)性回退(exponential backoff)。這就是實驗中為什么有的連接建立時間為9 s的原因。

圖4 由于SYN包丟失引起的TCP連接建立延遲Fig. 4 TCP connection establishment delay due to SYN packet loss

需要說明的是，在實際網(wǎng)絡中一般都會部署主動隊列管理(Active Queue Management， AQM)，例如隨機早期檢測(Random Early Detection, RED)協(xié)議[9]，來優(yōu)化TCP性能。主動隊列管理是在隊列還未達到最大值之前就開始主動丟棄一些數(shù)據(jù)包，從而提前使得TCP降低其擁塞窗口而降低網(wǎng)絡擁塞的有效方法。然而RED等協(xié)議無法區(qū)分普通數(shù)據(jù)包或者SYN包，因此即便在隊列未滿的情況下也會引起SYN包丟失。

在傳統(tǒng)Internet當中也存在SYN包丟失的問題，然而由于Internet網(wǎng)絡當中的往返時間較長(一般為500 ms以上)，同時用戶對網(wǎng)絡延遲的容忍度相對較高，因此問題并不嚴重。但是在數(shù)據(jù)中心中，往返時間較短(一般僅為100 μs左右[6-7])，且計算任務對網(wǎng)絡延遲的容忍度較低，因此SYN包丟失所帶來的影響更為突出。

2 基于WRED的連接建立優(yōu)化

2.1 SYN包丟失和隊列長度關系

連接延遲問題的關鍵在于交換機端口擁塞之后，SYN包丟失會造成超時。本節(jié)試圖從根源上解決SYN包丟失所帶來的問題。

首先，SYN包丟失是由于隊列溢出引起的，因此試圖通過增加隊列長度來降低SYN包丟失的概率。由于實驗中使用的交換機是共享內(nèi)存的，可以控制給特定端口所分配的主存空間比例。為此改變匯總節(jié)點所連接的交換機端口的隊列大小，從100 KB增加到300 KB，然后收集不同隊列大小所對應的所有流的平均和最大完成時間，結果如圖5所示。從圖5可以看出，隨著分配的隊列空間的增加，所有流完成的平均時間變化不大，但是最大流完成時間總在3 s以上。這意味著，隨著隊列空間的增大，始終有SYN包丟失，并且存在丟失2次的可能。其原因在于只要不發(fā)生隊列溢出，發(fā)送端的TCP擁塞窗口就會一直擴大，直到發(fā)生擁塞而丟包，擁塞窗口才會減小。因此，無論給隊列分配多大空間，總會被填滿并引起SYN包丟失。此外，為了降低數(shù)據(jù)中心建立的成本，一般也不會在數(shù)據(jù)中心的接入層使用大主存的高端交換機[3]。因此，通過更換高端交換機來避免SYN包丟失是行不通的。

圖5 200條流的完成時間隨隊列大小的變化Fig. 5 Impact of buffer size on flow completion time

2.2 關鍵技術

目前大多數(shù)低端交換機都支持WRED主動隊列管理協(xié)議或者類似協(xié)議(例如華為系列的交換機)。WRED協(xié)議[10]在RED協(xié)議[9]的基礎上，通過IP數(shù)據(jù)包頭當中所攜帶的不同的DSCP (Differentiated Services Code Point)值來區(qū)分不同的閾值和丟包概率，從而提供區(qū)分服務。RED協(xié)議為隊列設置一個最小閾值(Thmin)和一個最大閾值(Thmax)。平均隊列長度小于最小閾值時不丟包；在最小閾值和最大閾值之間時，交換機以一定的概率丟棄數(shù)據(jù)包(不超過設置的最大丟包概率Probmax)；超過最大閾值時，丟棄所有的數(shù)據(jù)包。其具體過程如圖6所示。

圖6 RED協(xié)議圖示Fig. 6 Illustration of RED protocol

通過WRED協(xié)議來避免SYN包的丟棄的基本原理是為普通數(shù)據(jù)包設置一個隊列閾值，當達到閾值時，以一定的概率丟失數(shù)據(jù)包，從而為SYN包預留下隊列空間。由于數(shù)據(jù)中心當中往返時延(Round-Trip Time, RTT)較小，可以通過TCP的機制快速重傳丟失的數(shù)據(jù)包。但是通過TCP的現(xiàn)有機制無法快速重傳SYN包，因此，可以考慮犧牲部分數(shù)據(jù)包的存儲空間來換取更重要的SYN包的傳輸。

數(shù)據(jù)中心中一般不存在多媒體數(shù)據(jù)包，TCP包占95%以上，此外還有少量UDP廣播包用于廣播配置信息和少量ICMP包用于網(wǎng)絡控制，但這些數(shù)據(jù)包的量不會造成網(wǎng)絡擁塞，因此主要通過WRED協(xié)議控制TCP包的流量。如果數(shù)據(jù)中心中有其他數(shù)據(jù)包的流量較大，可以使用不同的DSCP參數(shù)和TCP進行隔離。

在具體實現(xiàn)過程中，需要解決以下三個關鍵問題。

1)交換機如何識別SYN包。

SYN包的識別需要解析傳輸層包頭，而交換機是二層設備，無法檢測四層包頭信息，因此考慮在端系統(tǒng)上進行識別。目前數(shù)據(jù)中心的應用幾乎都部署在虛擬機上，而我們無法同時修改所有的客戶端操作系統(tǒng)(Guest Operation System)，因此考慮在現(xiàn)有主操作系統(tǒng)中(或稱為Hypervisor)增加一個TCP代理，所有虛擬機上的數(shù)據(jù)包要發(fā)送出去，都必須經(jīng)過這個代理，如圖7所示。識別過程是通過匹配數(shù)據(jù)包包頭的特定字段，如果字段全部匹配上，則這個數(shù)據(jù)包是一個SYN包，同時將這個數(shù)據(jù)包的IP包頭中的DSCP字段進行標記，方便交換機識別。為了避免標記SYN包的DSCP值和網(wǎng)絡中已經(jīng)部署的DSCP值沖突，采用DSCP值當中專門為本地網(wǎng)絡和實驗網(wǎng)絡預留的數(shù)值段，即DSCP值最末兩位二進制位為11[11]。

圖7 TCP代理示意圖Fig. 7 Illustration of TCP proxy

2)WRED協(xié)議限制的是平均隊列長度，如何限制數(shù)據(jù)包的隊列占用。

WRED協(xié)議限制隊列長度是通過滑動平均 (moving average)的方式來計算歷史平均隊列長度，因此設定閾值智能控制平均隊長，實際隊列長度還是有可能達到最大隊長從而造成SYN包丟失。根據(jù)Cisco交換機的標準，WRED協(xié)議計算隊列長度的方式為：

avg(t)=avg(t-1)·(1-0.5exp)+qlen·0.5exp

其中:avg(t)為當前平均隊列長度，avg(t-1)為上一個周期的平均隊列長度，而qlen為當前的實際隊列長度。因此，當WRED參數(shù)exp取值為0時，則交換機將用實際隊列長度來控制丟包。本文將普通數(shù)據(jù)包對應最大閾值設為低于最大隊列長度的某個值，在隊列長度超過閾值后，數(shù)據(jù)包將被丟棄，從而為SYN包預留一定的空間；對于SYN包，將對應的最小閾值和最大閾值都設置為最大隊列長度，實際上就不會對SYN包進行丟棄，直到隊列滿為止。

3)需要為SYN包預留多少空間。

在最大閾值之上的空間是為SYN包預留的，普通數(shù)據(jù)包不能占用。如果預留空間過多，則會影響數(shù)據(jù)包的傳輸效率；而如果預留空間過少，則SYN包會因為隊列溢出而被丟棄。因此必須知道需要預留的空間大小。為此，統(tǒng)計了在0.4 ms內(nèi)到達隊列的SYN包數(shù)量(包括被丟棄的SYN包)。實際上，對于1 Gb/s的端口速率，在0.2 ms內(nèi)，隊列已經(jīng)可以清空24 KB的空間來存儲SYN包。考慮到實際網(wǎng)絡的傳輸效率，我們認為在0.4 ms內(nèi)同時到達的SYN包會因為空間不足而同時被丟棄。實驗結果表明在大多數(shù)情況下，在0.4 ms內(nèi)僅有1個SYN包同時到達，而同時到達2個SYN包的次數(shù)僅為10。因此在網(wǎng)絡正常的情況下，不會出現(xiàn)大量的SYN包同時到達的情況。在SYN泛洪攻擊的情況下，可能會出現(xiàn)網(wǎng)絡中存在大量SYN包的情況，從而導致SYN包溢出。然而本文討論的場景主要是在網(wǎng)絡中已經(jīng)有有效的防火墻的情況下，正常TCP流量的性能問題，因此此處假定防火墻已經(jīng)攔截了大量SYN包泛洪的情況。

將每個服務器上運行的任務數(shù)從10增加到16(由于實驗服務器CPU只有16核，如再增加任務數(shù)量會使每個任務無法以全速率運算，影響任務運行效率),此時最大流數(shù)量為320。圖8顯示了同時到達的SYN包的最大值與網(wǎng)絡中流數(shù)量的關系?？梢钥闯?，在0.4 ms內(nèi)，最大的SYN包并發(fā)數(shù)量為4，且出現(xiàn)次數(shù)僅為1。這種關系為預留隊列空間提供了很好的參考。

圖8 同時的SYN包隨流數(shù)量的變化Fig. 8 Impact of the number of flows on the number of concurrent SYN packets

2.3 最終方案

在解決了以上三個關鍵問題后，本文提出了一種優(yōu)化TCP連接建立過程的簡單方案。

首先，在端系統(tǒng)中部署TCP代理用于匹配SYN包并標記特定的DSCP值，此處選擇DSCP值為111111表示SYN包；對于其他數(shù)據(jù)包則不作標記，如果邊界路由器部署有區(qū)分服務，則邊界路由器會標記數(shù)據(jù)包。

其次，更改網(wǎng)絡中交換機的WRED配置，將DSCP值為111111的最大閾值和最小閾值都改為隊列長度，因此SYN包永遠不會主動丟棄。對于其他數(shù)據(jù)包對應的DSCP值，最小閾值需要設置得相對較高，以避免不必要的丟包影響網(wǎng)絡利用率；最大閾值和最小閾值之間的差值也要足夠大以避免不同的TCP實例同步減小擁塞窗口。因此將其他DSCP值的最小閾值改為隊列長度的一半，最大閾值改為隊列長度減8個包大小，從而預留8個包的空間給并發(fā)的SYN包。

3 實驗與分析

網(wǎng)絡配置和第一章配置相同?？蛻舳说淖畲蠓侄未笮?Maximum Segment Size, MSS)設置為1 024，每個包的大小為1 KB，因此隊列可以存儲大約100個包。將111111對應的WRED的最大閾值和最小閾值都設置為100;對于普通數(shù)據(jù)包，設置最小閾值為50，最大閾值為92(即預留8個空間存儲SYN包)，最大閾值和最小閾值之間的最大丟包概率為5%。通過實驗統(tǒng)計這200條流的傳輸完成時間，結果如圖9(a)所示?？梢钥闯觯辛鞫荚? s以內(nèi)完成,最大完成時間僅為2.03 s。同樣將這個時間分解為連接建立時間和流傳輸時間，如圖9(b)和圖9(c)所示。可以清楚地看到，此時連接建立時間最大僅為1.4 ms；而流完成時間主要取決于傳輸時間，最大傳輸時間為約2.03 s。數(shù)據(jù)中心TCP傳輸效率的優(yōu)化已經(jīng)超出本文的主題范圍，可以參考其他文獻，如文獻[3,5,12-14]等。

圖9 優(yōu)化后的200條流的完成、連接建立與傳輸時間Fig. 9 Completion, establishment and transfer time of 200 flows after optimization

接著通過實驗驗證流數(shù)量變化對流完成時間的影響。將每個服務器運行的任務數(shù)量從10增加到16，然后統(tǒng)計所有流的平均完成時間和最大完成時間，結果如圖10所示?？梢钥闯鲭S著流數(shù)量的增加，平均完成時間呈線性增加，但是最大完成時間略有起伏，其原因在于對于不同情況所采用的WRED參數(shù)完全一致，并未調(diào)校，因此性能上會有所不同。此外，還考慮了理想情況下所有流均以最高速率傳輸時的流完成時間作為參考的預計完成時間。

圖10 完成時間隨流數(shù)量的變化Fig. 10 Impact of flow number on flow completion time

最后一組實驗考慮WRED參數(shù)對TCP性能的影響。WRED共有Thmin、Thmax和Probmax三個參數(shù)，其中Thmax在本方案中用來控制預留的空間，不能調(diào)整。因此實驗中先將Thmin的值從10增加到60，并統(tǒng)計所有TCP流的平均和最大完成時間，結果如圖11所示?？梢钥闯觯琓hmin的大部分值對最大完成時間的影響都不明顯，但在45時達到最小值。

接下來將Thmin的值固定為45，然后改變Probmax的值從2%到50%，統(tǒng)計所有流的平均和最大完成時間，結果如圖12所示?？梢钥闯?，Probmax值在12%～44%時TCP性能較好，并且在14%～22%時達到最佳性能。

圖11 WRED最小閾值對TCP性能的影響Fig. 11 Impact of Thmin on TCP performance

圖12 WRED最大丟包概率對TCP性能的影響Fig. 12 Impact of Probmax on TCP performance

4 結語

針對TCP連接建立過程中由于擁塞而出現(xiàn)的SYN包丟失所帶來的數(shù)據(jù)中心任務失敗問題，本文提出了一種基于WRED協(xié)議的方法來避免SYN包的丟失。這種方法無需更改任何設備和協(xié)議，可以在現(xiàn)有數(shù)據(jù)中心當中直接部署。實驗證明，該方法有效地降低了TCP連接建立的時間，避免了任務超時的問題。然而TCP傳輸?shù)男阅芎蚖RED協(xié)議的設置的參數(shù)相關，未來的實驗中可以進一步設計一種自適應的方法來自動配置WRED參數(shù)。此外，本文提出的方法提高了TCP連接建立的成功率，同時也使得TCP之間競爭更加激烈。在未來的研究中如果可以考慮網(wǎng)絡的擁塞情況，適當?shù)乜刂埔欢〞r間段內(nèi)TCP連接成功的數(shù)量，則效果會更好。

References)

[1] DEAN J, GHEMAWAT S. MapReduce: simplified data processing on large clusters [J]. Communications of the ACM — 50th Anniversary Issue: 1958-2008, 2008, 51(1): 107-113.

[2] MYSORE R N, PAMBORIS A, FARRINGTON N, et al. PortLand: a scalable fault-tolerant layer 2 data center network fabric [C]// SIGCOMM 2009: Proceedings of the ACM SIGCOMM 2009 Conference on Data Communication. New York: ACM, 2009: 39-50.

[3] ALIZADEH M, GREENBERG A, MALTZ D A. et al. Data center TCP (DCTCP) [J]. ACM SIGCOMM Computer Communication Review — SIGCOMM ’10, 2010, 40(4): 63-74.

[4] 葉進,李陶深,葛志輝.數(shù)據(jù)中心網(wǎng)絡基于優(yōu)先級擁塞控制的最后期限可感知TCP協(xié)議[J].軟件學報,2015,26(S2):61-70. (YE J, LI T S, GE Z H. Priority-based congestion control scheme for deadline-aware TCP in data center networks [J]. Jounal of Software, 2015, 26(2): 61-70.)

[5] 陸菲菲,郭得科,方興,等.數(shù)據(jù)中心網(wǎng)絡高效數(shù)據(jù)匯聚傳輸算法[J].計算機學報,2016,39(9):1750-1762. (LU F F, GUO D K, FANG X, et al. Algorithm of efficient data aggregation transfers in data center networks [J]. Chinese Journal of Computers, 2016, 39(9): 1750-1762.

[6] VASUDEVAN V, PHANISHAYEE A, SHAH H, et al. Safe and effective fine-grained TCP retransmissions for datacenter communication [J]. ACM SIGCOMM Computer Communication Review — SIGCOMM ’09, 2009, 39(4): 303-314.

[7] CHEN Y, GRIFFITH R, LIU J. Understanding TCP incast throughput collapse in datacenter networks [C]// WREN ’09: Proceedings of the 1st ACM Workshop on Research on Enterprise Networking. New York: ACM, 2009: 73-82.

[8] TAM A S-W, XI K, XU Y, et al. Preventing TCP incast throughput collapse at the initiation, continuation, and termination [C]// IWQoS 2012: Proceedings of the 20th International Workshop on Quality of Service. Piscataway, NJ: IEEE, 2012: 1-9.

[9] FLOYD S, VAN JACOBSON. Random early detection gateways for congestion avoidance [J]. IEEE/ACM Transactions on Networking, 1993, 1(4): 397-413.

[10] WURTZLER M. Analysis and simulation of Weighted Random Early Detection (WRED) queues [R]. Evanston, Illinois: Northwestern University, Electrical Engineering and Computer Science, 2002.

[11] NICHOLS K, BLACK D L, BLAKE S, et al. RFC2474: Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 headers [S/OL]. [2016- 11- 05]. https://tools.ietf.org/html/rfc2474.

[12] MUNIR A, QAZI I A, UZMI Z A, et al. Minimizing flow completion times in data centers [C]// INFOCOM 2013: Proceedings of the 2013 International Conference on Computer Communications. Piscataway, NJ: IEEE, 2013: 2157-2165.

[13] XIA Y, WANG T, SU Z, et al. Preventing passive TCP timeouts in data center networks with packet drop notification [C]// CloudNet 2014: Proceedings of the 3rd International Conference on Cloud Networking. Piscataway, NJ: IEEE, 2014: 173-178.

[14] 孫三山,汪帥,樊自甫.軟件定義網(wǎng)絡架構下基于流調(diào)度代價的數(shù)據(jù)中心網(wǎng)絡擁塞控制路由算法[J].計算機應用,2016,36(7):1784-1788. (SUN S S, WANG S, FAN Z F. Flow sheculing cost based ccongestion control routing algorithm for data center network on software defined network architecture [J]. Journal of Computer Applications, 2016, 36(7): 1784-1788.)

This work is partially supported by the Scientific Research Fund of Sichuan Provincial Education Department (16ZB0064) and Sichuan Normal University Fund (Project name: Research and Optimization of Data Center Networks).

XIAYu, born in 1983, Ph. D., lecturer. His research interests include high-performance switching, data center network.

LIAOPingxiu, born in 1983, M. S., engineer. Her research interests include protocol analysis, network device testing.

CUILei, born in 1982, engineer. His research interests include design and implementation of high-speed switches, network interfacing.

OptimizationoftheTCPconnectioninitiatingprocessindatacenters

XIA Yu1*, LIAO Pingxiu2, CUI Lei3

(1.SchoolofComputerScience,SichuanNormalUniversity,ChengduSichuan610101,China；2.The30thInstitute,ChinaElectronicsTechnologyGroupCorporation,ChengduSichuan610041,China；3.HuaweiTechnologiesCompanyLimited,ShenzhenGuangdong518129,China)

An SYN packet might be dropped when initiating a Transmission Control Protocol (TCP) connection in data centers, causing the tasks missing the expected deadline; accordingly, without changing the existing devices, applications and the TCP itself, a viable mechanism based on Weighted Random Early Detection (WRED) was proposed to avoid the drop of SYN packets. Three related key problems were solved by the proposed method: how to mark and recognize the SYN packets; how to reserve space for the SYN packets in switches; how much space is required for reserving. Compared with the original TCP, the TCP connection establishment time was greatly reduced after optimizing. The simulation results show that the connection initialization optimization method can solve the problem of tasks missing the expected deadline.

data center; Transmission Control Protocol (TCP); three-way handshake; SYN packet

TP393.06

A

2017- 02- 20;

2017- 03- 27。

四川教育廳基金資助項目(16ZB0064)；四川師范大學基金項目(項目名稱：數(shù)據(jù)中心網(wǎng)絡的研究和優(yōu)化)。

夏羽(1983—)，男，云南昆明人，講師，博士，主要研究方向：高性能交換、數(shù)據(jù)中心網(wǎng)絡； 廖蘋秀(1983—)，女，四川樂山人，工程師，碩士，主要研究方向：協(xié)議分析、網(wǎng)絡設備測試； 崔雷(1982—)，男，河南鄭州人，工程師，主要研究方向：高性能交換機設計與實現(xiàn)、網(wǎng)絡接口。

1001- 9081(2017)08- 2157- 06

10.11772/j.issn.1001- 9081.2017.08.2157