本發(fā)明涉及一種數(shù)據(jù)中心網(wǎng)絡中基于任務感知的傳輸控制方法。

背景技術：

在現(xiàn)代數(shù)據(jù)中心中，普遍使用基于樹形的分治算法來下發(fā)數(shù)據(jù)或者計算到數(shù)以千記的服務器中去，在每臺服務器計算或者處理完畢之后，會把結果傳輸?shù)骄酆蠙C(Aggregator)進行組合和處理，聚合機處理完成之后才能把最終的結果返回給用戶。這樣的并行處理做法可以很大程度上的提高運行效率，降低用戶請求的等待時間，改善和提高用戶體驗。但是很明顯，如果某些服務器對下發(fā)的工作處理很慢，這樣聚合機就必須等待到所有的數(shù)據(jù)到達之后才能開始工作，從而導致用戶的等待時間加長。這被稱為掉隊者現(xiàn)象。最近的研究已經表明，在使用了新的硬件技術的數(shù)據(jù)中心內，網(wǎng)絡延時已經占據(jù)了85％的端到端應用延時。因此，很多現(xiàn)有的研究都在努力減少網(wǎng)絡延時(即拖尾流)，以求達到更好的用戶體驗?？傮w來說目前的方法可以分為兩大類：基于流的和基于任務的網(wǎng)絡傳輸控制方法。

基于流的網(wǎng)絡傳輸控制方法由于操作和邏輯相對簡單，實現(xiàn)和部署起來比較容易，響應也比較迅速。這些方法或者優(yōu)化和提高流完成時間(例如DCTCP、L²DCT和pFabric)，或者減少截止期限缺失率(例如D2TCP和D3)。但是由于它們都只專注于優(yōu)化流級別的性能而忽略了一個事實：其實一次用戶請求，或者說是任務，是由成百上千條流組成的，任何一條流沒有完成，則這次任務就沒有完成，也就是說拖尾流決定了這個任務的最終完成時間。因此，這些基于流的機制都不可避免的在不同程度上降低了數(shù)據(jù)中心所提供的應用的性能。下面的一個例子則可以很好的說明這個問題。最短流優(yōu)先調度算法會選擇調度任務中的最短流，即使這些流分屬于不同的任務。這樣做可以很好的降低平均流完成時間(Average flow completion time)。而在應用和任務的層面上看，平均任務完成時間則升高了(Average task completion time)，因為在任務完成過程中，不斷的有別的任務的流的來阻斷自己的傳輸。這樣加大了任務的完成時間，從而影響了用戶的體驗。

相比基于流的傳輸控制方法，基于任務的傳輸控制方法可以減少任務的完成時間，也就減少了用戶的等待時間。這些基于任務的傳輸控制方法總體來看可以分為兩個大類：一個是基于分布式架構的，另一個則是中心控制器架構的。分布式架構的控制方法，例如Baraat，通過下發(fā)調度策略到不同的交換機上面，成功的避免了交換機與中心控制器的計算和通信開銷。但是由于計算機基于本地任務信息來決定調度順序，而缺乏所調度的任務的全局信息。這樣會導致存在一種情況：即選中的任務的流，一部分會在某些交換機上成功調度，但是其它部分則會在某些交換機被阻塞，這樣仍然不能降低任務的完成時間。而基于中心控制器架構的方法，例如Varys和Rapier，需要一個復雜的系統(tǒng)來收集任務的全局信息，進行調度決策，以及保證決策的正確執(zhí)行。這個系統(tǒng)包括了中心調度器和安裝在網(wǎng)絡節(jié)點(例如服務器)上的中間件。雖然它們很接近最優(yōu)調度結果，但是這些方法的計算復雜度和控制開銷會隨著網(wǎng)絡規(guī)模的擴大而迅速的上升。在數(shù)據(jù)中心中，接近80％的流都是10KB到100KB的小流。這些只有10KB的小流在某些方法中，甚至可以在一個往返延時(Round trip time)中就可以完成。而如果這些小流還需要花費額外的一個RTT甚至更久的時間來等待中心調度器的調度決策，它們的完成時間則至少增加了100％。

可見，數(shù)據(jù)中心網(wǎng)絡中，現(xiàn)有的傳輸控制方法，或者使用了龐大的系統(tǒng)來保證精準的控制，但是增大了計算開銷和傳輸延遲，同時由于對現(xiàn)有的數(shù)據(jù)中心網(wǎng)絡改動較大，失去了普適性；或者使用了靈活的部署和簡單的機制來保證快速響應，但是結果也往往不準確，沒有辦法減少任務完成時間以及用戶的等待時間。因此，如何設計一個輕量級的、有效的、可兼容的基于任務的數(shù)據(jù)中心網(wǎng)絡傳輸控制方法，在減少任務完成時間的同時，也不增加計算和傳輸開銷，從而減少用戶的等待時間，是一個亟待解決的問題。

技術實現(xiàn)要素：

為了解決上述數(shù)據(jù)中心網(wǎng)絡中傳輸控制方法存在的準確性以及快速響應和龐大系統(tǒng)以及靈活部署這兩對矛盾，本發(fā)明提供了一種數(shù)據(jù)中心網(wǎng)絡中基于任務感知的傳輸控制方法。該方法基于傳統(tǒng)傳輸層，普遍適用的以任務為單位進行傳輸控制，通過接收端驅動的協(xié)調機制，來實現(xiàn)了流拖尾信息的共享，在保證控制準確度的同時，也由于使用了傳統(tǒng)TCP協(xié)議棧的功能，實現(xiàn)了靈活部署以及較低的開銷。

本發(fā)明解決上述技術問題的技術方案為：

基于支持ECN的交換機或者路由器、接收端和發(fā)送端；

一種數(shù)據(jù)中心網(wǎng)絡中基于任務感知的傳輸控制方法，包括以下步驟：

步驟1：發(fā)送端在傳輸層的報文頭部中增加任務信息和流信息字段，包括任務ID字段和流大小字段，并將報文發(fā)送給路由器或者交換機；

步驟2：路由器或者交換機根據(jù)網(wǎng)絡負載信息決定是否給發(fā)送端報文打上ECN標記用于顯示網(wǎng)絡負載信息，然后將報文轉發(fā)給接收端；

步驟3：接收端根據(jù)接收到的報文頭部攜帶的信息，更新任務表相關信息，并計算出任務預期完成時間T_t，并且通過返回給發(fā)送端的ACK報文的頭部捎帶回去該任務預期完成時間T_t以及路由器或者交換機加入的網(wǎng)絡負載信息；

步驟4：發(fā)送端接收接收端返回的ACK報文；

步驟5：發(fā)送端根據(jù)接收端返回的ACK報文，解析出任務預期完成時間和網(wǎng)絡負載信息，并且通過任務預期完成時間和其所發(fā)送的流的預期完成時間來算出拖尾度因子ω；

步驟6：發(fā)送端根據(jù)拖尾度因子和網(wǎng)絡負載信息調整自身擁塞窗口(發(fā)送速率)，使之適應當前的網(wǎng)絡擁塞狀態(tài)，并通過對擁塞窗口不同程度的改變，調整流的預期完成時間與任務預期完成時間之間的差距。

所述步驟3中，接收端維持一個任務表，任務表記錄以下信息：任務ID、任務中的每條流的流ID、每條流對應的流大小以及流的已接收的字節(jié)數(shù)；任務ID用于標識流所屬的任務，即一個任務可能由多條流組成，它們共享一個相同的任務ID，它是數(shù)據(jù)中心邊界服務器在收到相應用戶請求時隨機生成并且下發(fā)的；流ID通過TCP/IP協(xié)議的本身的五元組得到，用于區(qū)分不同的流，以便接收端更新任務表中對應流的表項；每條流的流大小字段的數(shù)值為應用層的具體應用所要傳輸?shù)臄?shù)據(jù)量，即數(shù)據(jù)的字節(jié)數(shù)，該值在應用準備發(fā)送數(shù)據(jù)時已經確定，無需更新；每條流的已接收的字節(jié)數(shù)，則在傳輸層協(xié)議自帶的序列號字段的基礎上，通過每條流的當前序列號與建立連接時最初的序列號的差值計算得出；流的已接收的字節(jié)數(shù)會隨著流已接收的序列號的增加而增加；

所述步驟3中，任務表的更新流程為：接收端根據(jù)接收報文頭部的任務ID字段，查找任務表；若任務表中不存在該任務ID，則在表中插入一個新表項，其值為該任務ID、該任務中的流ID、對應的流大小和流的已接收字節(jié)數(shù)；若任務表中存在該任務ID，則進一步比對該任務ID對應的表項中是否存在接收報文頭部的流ID；若不存在該流ID，則新建一個表項并且寫入該任務ID、流ID、對應的流大小和流的已接收字節(jié)數(shù)；若存在該流ID，則更新對應的流大小和流的已接收字節(jié)數(shù)；

所述步驟3中，任務預期完成時間T_t＝(任務大小-任務已接收字節(jié)數(shù))/歷史接收速率；其中任務大小通過累加該任務ID下每條流的流大小得到；任務已接收字節(jié)數(shù)通過累加該任務ID下每條流的已接收字節(jié)數(shù)得到；歷史接收速率則通過任務已接收字節(jié)數(shù)比上花費的時間得出。

所述步驟5中，拖尾度因子ω計算方法如下：

$\mathrm{\ω}=\frac{T_f}{T_t}$

其中，T_f為發(fā)送端所發(fā)送的流的預期完成時間，該值等于流的剩余字節(jié)數(shù)比上當前的發(fā)送速率(T_f由發(fā)送端計算得到)。

所述步驟6分為兩種情況：

1)當接收端收到沒有打上ECN標記的ACK報文時，首先根據(jù)以下公式計算擁塞窗口的增窗因子k：

$k=\frac{\mathrm{\ω}}{{\mathrm{\ω}}_{max}}(1-\mathrm{\α})$

上式中，ω_max為拖尾度因子的最大值，通過實驗驗證得到(經驗值為2.25)；α為鏈路的擁塞程度，該值的計算方式為一次往返延時時間內發(fā)送的所有數(shù)據(jù)包(所有數(shù)據(jù)包的個數(shù)為擁塞窗口大小)中，被交換機打了ECN標記的數(shù)據(jù)包的比例，其取值范圍介于0到1之間，越大則說明網(wǎng)絡越擁塞；

然后，根據(jù)增窗因子k計算新的擁塞窗口，其計算公式如下：

${\mathrm{cwnd}}_{i+1}={\mathrm{cwnd}}_i+{\mathrm{cwnd}}_i^k$

其中，cwnd_i+1為下一輪擁塞窗口的數(shù)值，cwnd_i為當前擁塞窗口數(shù)值；當增窗因子較高時，本方法采用乘性增長(MI)算法計算擁塞窗口，其具體表現(xiàn)為，當鏈路沒有擁塞(α＝0)，且拖尾度較高(ω＝ω_max)時，增窗因子k的值為1，那么通過上述公式，下一輪擁塞窗口數(shù)值為cwnd_i+1＝2cwnd_i；否則，當增窗因子較低時，采用加性增長(AI)計算擁塞窗口，其具體表現(xiàn)為，當鏈路擁塞最大(α＝1)，或是拖尾度較低(ω→0)時，增窗因子k的數(shù)值為0，那么通過上述公式，下一輪擁塞窗口數(shù)值為cwnd_i+1＝cwnd_i+1；

2)當接收端收到打了ECN標記的ACK報文時，首先根據(jù)以下公式計算擁塞窗口的減窗因子β：

β＝α^ω；

然后根據(jù)減窗因子β計算新的擁塞窗口，其計算公式如下：

${\mathrm{cwnx}}_{+1}={\mathrm{cwnd}}_i\×(1-\frac{\mathrm{\β}}{2}).$

在步驟4與步驟5之間還存在以下步驟：發(fā)送端判斷計時器是否超時，以及是否收到三個重復的ACK報文；若計時器超時或收到三個重復的ACK報文，則傳統(tǒng)的擁塞控制方法進行傳輸控制；若計時器沒有超時，且未收到三個重復的ACK報文，則進入步驟5。

所述步驟2具體為：交換機或者路由器根據(jù)隊列長度是否超過預設的閾值決定是否給發(fā)送端報文打上ECN標記；若超過則打上ECN標記然后將報文轉發(fā)給接收端，若沒有超過則直接轉發(fā)。

本發(fā)明中，通信過程的發(fā)送端通過顯式反饋信息計算網(wǎng)絡當前可用帶寬，并且根據(jù)它以及所發(fā)送的流的拖尾度來調整發(fā)送速率，路由器通過分組頭ECN信息反饋網(wǎng)絡負載，接收端回顯該ECN信息并且計算任務預期完成時間；發(fā)送端通過接收端在ACK中捎帶的任務預期完成時間以及自己計算的流預期完成時間，計算出拖尾度，并且和顯式反饋信息一起作為調整發(fā)送速率的依據(jù)。本發(fā)明通過結合端到端任務信息和網(wǎng)絡擁塞信息反饋，從而避免了額外的控制開銷、減少了部署的難度、提高協(xié)議普及性的同時保證了較低的任務完成時間和較高的吞吐率，因此，減少了用戶發(fā)送請求之后的等待時間。

有益效果：

本發(fā)明通過支持ECN的交換機或者路由器，以及接收端的任務信息統(tǒng)計和反饋，接收端可以得到任務的全局信息和鏈路上的擁塞信息。這樣在極少的改動網(wǎng)絡現(xiàn)有的架構的情況下，任務中的每條流就可以更加準確的知道自己在所屬的任務中的完成進度情況(包括是否拖尾，是否領先)，并且發(fā)送端可以根據(jù)當前的鏈路狀況和這條流的拖尾程度動態(tài)的調節(jié)它的發(fā)送速率。當拖尾程度較重的時候，發(fā)送端會根據(jù)鏈路的擁塞情況使擁塞窗口的增加在乘性增長(MI，擁塞較輕的時候)和加性增長(AI，擁塞較重的時候)之間變化；而拖尾程度較重的流，即使在減窗的時候，發(fā)送端也會根據(jù)它的權重和鏈路擁塞狀況來使窗口減少得較少。反之，若流的拖尾程度較輕，則不論鏈路的擁塞情況怎么樣，發(fā)送端都會使這條流的窗口增長限制在加性增長附近，而減窗則會接近原本窗口的1/2。但是值得注意的是，若鏈路的擁塞很嚴重(α＝1)，則無論流的拖尾度為多少，所有流都要按照加性增長增窗(cwnd_i+1＝cwnd_i+1)，且減窗也要按照傳統(tǒng)傳輸層一樣，減去1/2的窗口雖然其效果已經退化為傳統(tǒng)的擁塞控制方法，但是因為本方法在某輪發(fā)送返回的被ECN標記比例為100％(即α＝1)的時候采取這樣操作，而傳統(tǒng)擁塞控制算法只有當隊列滿了丟包之后(對于發(fā)送端，重復ACK即為發(fā)生丟包)才會有這樣的操作，所以本發(fā)明操作時間一般要早于傳統(tǒng)擁塞控制方法，從而減少了擁塞的時間。這樣做是為了在高鏈路負載的情況下實現(xiàn)公平性，也是為了能夠更快的減輕擁塞狀況。簡而言之，這些操作的目的是為了實現(xiàn)拖尾程度高的流能夠加速自己的發(fā)送速率，積極的搶占帶寬，來減少它的完成時間，同時也就減少了任務的完成時間，因為任務的完成時間是由拖尾程度最高的那些流決定的。而拖尾程度較低的流，由于自己本身的流完成時間并不決定任務的完成時間，即使自己提前完成了，任務還是需要等待剩下的流完成才能結束。這樣之前所利用的帶寬可以說是白白浪費了。所以這些流可以適當?shù)慕档妥约旱陌l(fā)送速率，從而把帶寬讓給那些需要提速的拖尾程度較重的流。這樣通過這些不同拖尾程度的流之間的搶帶寬和讓帶寬，從而達到更好地、更合理地帶寬方式，來減少任務的完成時間，也就最終減少了用戶的等待時間。

附圖說明

圖1為本發(fā)明的流程圖；圖1(a)、圖1(b)、圖1(c)分別為發(fā)送端、交換機或路由器、接收端的處理流程圖。

圖2為本發(fā)明的測試床環(huán)境。

圖3為本發(fā)明的模擬測試環(huán)境。

圖4為本發(fā)明在測試床環(huán)境中，不同方法的吞吐率變化圖，其中本發(fā)明命名為TaTCP。圖4(a)為DCTCP的吞吐率變化圖，圖4(b)為L²DCT的吞吐率變化圖，圖4(c)為TaTCP的吞吐率變化圖。

圖5為本發(fā)明在測試床環(huán)境中，隨著網(wǎng)絡中任務的個數(shù)的增加，對于其他方法的任務完成時間的提升度。其中本發(fā)明命名為TaTCP。

圖6為本發(fā)明和其他方法在模擬實驗測試環(huán)境中，模擬網(wǎng)頁查詢應用模式下的不同測試指標的結果圖，其中本發(fā)明命名為TaTCP。圖6(a)為不同方法隨著任務中流個數(shù)增加，平均任務完成時間變化圖；圖6(b)為不同方法隨著任務中流個數(shù)增加超時率變化圖。

圖7為本發(fā)明在模擬實驗測試環(huán)境中，模擬云存儲應用模式下，相對其他方法在任務完成時間的提升度。其中本發(fā)明命名為TaTCP。圖7(a)為本發(fā)明相對于DCTCP的提升比例、圖7(b)為本發(fā)明相對于L²DCT的提升比例、圖7(c)為本發(fā)明相對于Baraat的提升比例。

圖8為本發(fā)明和其他方法在模擬實驗測試環(huán)境中，模擬Map-Reduce應用模式下的不同測試指標的結果圖，其中本發(fā)明命名為TaTCP。圖8(a)為不同方法隨著任務中流個數(shù)的增加，平均任務完成時間變化圖；圖8(b)為不同方法隨著任務中流個數(shù)增加，有效吞吐率變化圖。

具體實施方式

下面結合附圖對本發(fā)明作進一步的說明。

參見圖1(a)(b)(c)，它們?yōu)楸景l(fā)明的流程圖，分別描述了本發(fā)明所涉及的三個部分的處理過程。其過程如下：在連接建立后，發(fā)送端在每次發(fā)送之間判斷是否數(shù)據(jù)已經發(fā)送完畢。若發(fā)送完畢則結束；若沒有發(fā)送完畢，則會在發(fā)送的傳輸層報文頭部加入任務信息和流信息(包括任務ID和流大小，以便接收端計算任務的預期完成時間)。發(fā)送端所發(fā)送的數(shù)據(jù)報文，在經過交換機或者路由器的時候，該設備會根據(jù)隊列長度是否超過預設的閾值來對發(fā)送端的報文進行標記。若超過則進行標記ECN位然后轉發(fā)，若沒有超過則直接轉發(fā)。接收端在收到報文之后，會根據(jù)發(fā)送端在報文頭部加入的任務信息更新任務記錄，并且重新計算任務預期完成時間。在接收端生成ACK報文的時候，接收端會把該任務預期完成時間寫入ACK報文頭部，并且同時根據(jù)收到報文標記ECN位。發(fā)送端在收到ACK報文的時候，根據(jù)ACK報文頭部的任務預期完成時間和流自己的預期完成時間計算出拖尾程度。并且發(fā)送端會根據(jù)拖尾程度、ECN位和擁塞程度來計算下一輪擁塞窗口的大小。

本發(fā)明中采用拖尾程度來調節(jié)該方法的增窗因子和減窗因子。通過增窗和減窗因子，發(fā)送端可以實時的調節(jié)流的發(fā)送速率。具體地，如果發(fā)送端收到的ACK報文沒有標記ECN位，則在下一輪發(fā)送端的窗口可以增長為如下的數(shù)值：

${\mathrm{cwnd}}_{i+1}={\mathrm{cwnd}}_i+{\mathrm{cwnd}}_i^k$

其中cwnd_i+1為下一輪擁塞窗口的數(shù)值，cwnd_i為當前擁塞窗口數(shù)值。k則為增窗因子。當增窗因子較高時，即鏈路擁塞度較低且流的拖尾度較高，此時本方法采用乘性增長(MI)算法計算擁塞窗口；否則，采用加性增長(AI)計算擁塞窗口。而若收到了帶有ECN標記的ACK報文，發(fā)送端則需要根據(jù)減窗因子進行減窗操作，從而避免擁塞繼續(xù)加重，其計算方式如下：

${\mathrm{cwnd}}_{i+1}={\mathrm{cwnd}}_i\×(1-\frac{\mathrm{\β}}{2})$

其中，cwnd_i+1下一輪擁塞窗口的數(shù)值，cwnd_i為當前擁塞窗口數(shù)值。β則為減窗因子?？梢钥吹?，當減窗因子較小時，下一輪擁塞窗口減少的較少。反之當減窗因子較大時，下一輪擁塞窗口的值則變得較小。但是，由于β的值最大只為1，因此，在鏈路擁塞很重，或者流的拖尾度較輕的時候，擁塞窗口會減半，這樣不僅可以在鏈路擁塞嚴重時候各條流之間實現(xiàn)公平共享帶寬，也可以每條流都可以快速的退避以減少鏈路擁塞的時間。

綜上所述，采用本發(fā)明方法可以在不改變網(wǎng)絡現(xiàn)有拓撲結構的同時，把傳輸控制的單元由流變?yōu)榱巳蝿?，從而成功避免了基于流傳輸控制方法中拖尾流對任務完成時間的影響，大幅減少了任務完成時間和用戶等待時間。

利用NS2.35網(wǎng)絡仿真平臺，和真實的測試床對其性能進行了測試。NS網(wǎng)絡模擬器是一種通用的多協(xié)議網(wǎng)絡模擬軟件，它是互聯(lián)網(wǎng)上公開發(fā)布的(網(wǎng)址：http://www.isi.edu/nsnam/ns)，目前已被網(wǎng)絡研究者廣泛使用。NS2.35是它的版本之一。

我們分別采用圖2和圖3兩種拓撲結構，在測試床和模擬測試兩種不同的測試環(huán)境下面測試本發(fā)明的性能。在如圖2所示的拓撲中，從架頂交換機(ToR Switch)開啟ECN功能，且設置到接收端的兩條瓶頸鏈路帶寬為600Mbps，其他鏈路的帶寬為1Gbps。沒有排隊延遲的逐跳往返延時為100微妙且報文大小和和超時時間分別設置為1.5KB和200毫秒。所有機器運行加載了本發(fā)明補丁的CentOS 6.5操作系統(tǒng)。而如圖3所示的拓撲中，整個拓撲使用的是一個樹形結構。并且發(fā)送端到架頂交換機和架頂交換機到匯聚交換機的鏈路帶寬都為1Gbps，而匯聚交換機到接收端的鏈路帶寬為4Gbps。交換機的緩存大小設置為250個報文大小，并且ECN標記閾值為65個報文大小。

1、有效性驗證

該實驗驗證了本發(fā)明在TCP協(xié)議棧內工作的有效性。f_A1、f_A2和f_B分別為發(fā)送端3、發(fā)送端1和發(fā)送端2發(fā)送的相同大小的流。由于發(fā)送端1和發(fā)送端2在共享一條出口帶寬，所以同屬于同一個任務A的流f_A2會逐步的落后于f_A1，從而變成拖尾流。在圖4(a)和圖4(b)中可以看到由于DCTCP和L²DCT都是基于流的傳輸控制方法，因此不能夠加快拖尾流f_A2。而在圖4(c)中，本發(fā)明(TaTCP)通過接收端的任務信息反饋，流f_A2發(fā)現(xiàn)自己是拖尾流。接下來它的數(shù)據(jù)發(fā)送速率就會逐步加快，以追趕領先流f_A1。這樣任務A的完成時間就會減少。通過減少任務A的完成時間，任務A和B的平均任務完成時間相比于DCTCP和L²DCT下降了近15％。從本實驗結果來看，本發(fā)明對現(xiàn)有的TCP協(xié)議棧的修改很好的實現(xiàn)了預計目標，減少了任務的平均完成時間。

2、測試床下的性能提升度

該實驗測試本發(fā)明在較高網(wǎng)絡負載情況下的性能。該實驗仍然使用了測試床環(huán)境來進行測試。在該次測試中，存在兩種任務存在于網(wǎng)絡中。第一種任務由兩條流組成，由發(fā)送端1或者發(fā)送端3發(fā)送并且分別經過兩個不同的交換機，通過兩條不同的瓶頸鏈路到達接收端。另一種任務由單條流組成，且通過發(fā)送端2發(fā)往接收端。每條流的大小相同，且所有流都是同時發(fā)送。本實驗逐步增加第一種任務的個數(shù)，由原本的1條增加8條。第二種任務保持為一條不變。從圖5可以看到，隨著網(wǎng)絡中任務的個數(shù)增加，也就是網(wǎng)絡負載逐步變重，相比較于其他數(shù)據(jù)中心常見的傳輸控制協(xié)議，本發(fā)明仍然能夠減少最多14％，最低6％的平均任務完成時間。

3、模擬實驗測試環(huán)境測試結果

除了以上給出的測試床的局部性能測試，為了全面比較該發(fā)明的高效性，我們進一步測試了在復雜拓撲結構情況下，該發(fā)明的各項性能指標，包括了：平均任務完成時間，超時率和有效吞吐率。實驗場景包括了網(wǎng)頁查詢、云存儲和Map-Reduce這些不同的應用場景。測試的傳輸控制機制包括了：DCTCP、L²DCT、TaTCP和Baraat。其中DCTCP和L²DCT是基于流的傳輸控制方法，TaTCP(本發(fā)明)和Baraat只是基于任務的傳輸控制方法。

(1)圖6給出了不同機制在網(wǎng)頁查詢應用模式下的測試結果。在該測試中，一共有40個任務，每個任務由i條流組成，任務的總大小為2MB保持不變，任務中流大小為2MB/i。在實驗過程中，任務中流的個數(shù)i由8逐步增加到40。圖6分別統(tǒng)計了不同流個數(shù)下任務的平均完成時間和超時率。從圖6(a)中可以看到，本發(fā)明一直都具有最小的平均任務完成時間。并且在任務中流個數(shù)為28之前都低于100毫秒，遠遠低于其他方法。圖6(b)匯總了40條任務中，經歷過至少一次超時的任務所占的比例。圖中所示，TaTCP至少在22條流才開始超時，明顯大于其他機制的15或16條流。可見本發(fā)明在網(wǎng)頁查詢模擬測試環(huán)境下，性能指標要明顯優(yōu)于其它方法。

(2)圖7給出了不同機制在云儲存應用模式下的測試結果。在該測試中每個任務中的流個數(shù)保持不變，但是每條流的大小服從10KB到4MB的帕累托分布。在實驗過程中，任務的個數(shù)由20逐步的增加到50。如圖7(a)和(b)所示，在輕網(wǎng)絡負載的時候，本發(fā)明TaTCP可以保持相對于基于流的傳輸控制機制(DCTCP和L²DCT)20％以上的提升度。即使網(wǎng)絡負載變重，TaTCP也能保持近10％的優(yōu)勢。雖然對于Baraat這種基于任務的傳輸控制性能提升沒有相比于基于流的那么大，但是也能夠最少提升了5％的平均任務完成時間。

(3)圖8給出了不同機制在Map-Reduce應用模式下面的測試結果。在該測試中，一共有40個任務，每個任務中得流所發(fā)送的字節(jié)數(shù)都相等且為32KB。在實驗過程中，任務中得流個數(shù)由8條逐步增加到40條。圖8分別統(tǒng)計了不同流個數(shù)下任務平均完成時間和任務的平均有效吞吐率。從圖8(a)可以看到，本發(fā)明TaTCP的平均任務完成時間直到29條流才開始增加，而基于流的傳輸控制協(xié)議在20左右就已經開始增長了。雖然Baraat由于本身的基于任務的機制使得他得性能優(yōu)于上述兩種協(xié)議，但是也只能支持到24條流。同樣，在圖8(b)中，TaTCP也取得了最高的平均有效吞吐率，性能優(yōu)于其他三種不同的方法。

從以上實驗數(shù)據(jù)看來，本發(fā)明方法在以上幾個方面具有比其他方法更優(yōu)秀的性能。這是因為本方法使用了基于任務的擁塞控制方法，從而成功避免了基于流的方法所忽視掉的拖尾問題。而由于本發(fā)明具有鏈路全局信息，相比于只能知道交換機本地任務信息的Baraat能夠能加合理的利用帶寬，從而達到更優(yōu)秀的性能，成功的減少了任務的平均完成時間。并且該方法對現(xiàn)有的網(wǎng)絡架構修改較少，可以很輕易的部署到現(xiàn)有的網(wǎng)絡中，保證了本發(fā)明的普及型。