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

背景技術(shù)：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1)當(dāng)接收端收到?jīng)]有打上ECN標(biāo)記的ACK報(bào)文時(shí)，首先根據(jù)以下公式計(jì)算擁塞窗口的增窗因子k：

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

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

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

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

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

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

β＝α^ω；

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

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

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

所述步驟2具體為：交換機(jī)或者路由器根據(jù)隊(duì)列長(zhǎng)度是否超過(guò)預(yù)設(shè)的閾值決定是否給發(fā)送端報(bào)文打上ECN標(biāo)記；若超過(guò)則打上ECN標(biāo)記然后將報(bào)文轉(zhuǎn)發(fā)給接收端，若沒(méi)有超過(guò)則直接轉(zhuǎn)發(fā)。

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

有益效果：

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

附圖說(shuō)明

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

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

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

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

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

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

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

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

具體實(shí)施方式

下面結(jié)合附圖對(duì)本發(fā)明作進(jìn)一步的說(shuō)明。

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

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

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

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

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

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

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

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

我們分別采用圖2和圖3兩種拓?fù)浣Y(jié)構(gòu)，在測(cè)試床和模擬測(cè)試兩種不同的測(cè)試環(huán)境下面測(cè)試本發(fā)明的性能。在如圖2所示的拓?fù)渲?，從架頂交換機(jī)(ToR Switch)開(kāi)啟ECN功能，且設(shè)置到接收端的兩條瓶頸鏈路帶寬為600Mbps，其他鏈路的帶寬為1Gbps。沒(méi)有排隊(duì)延遲的逐跳往返延時(shí)為100微妙且報(bào)文大小和和超時(shí)時(shí)間分別設(shè)置為1.5KB和200毫秒。所有機(jī)器運(yùn)行加載了本發(fā)明補(bǔ)丁的CentOS 6.5操作系統(tǒng)。而如圖3所示的拓?fù)渲?，整個(gè)拓?fù)涫褂玫氖且粋€(gè)樹(shù)形結(jié)構(gòu)。并且發(fā)送端到架頂交換機(jī)和架頂交換機(jī)到匯聚交換機(jī)的鏈路帶寬都為1Gbps，而匯聚交換機(jī)到接收端的鏈路帶寬為4Gbps。交換機(jī)的緩存大小設(shè)置為250個(gè)報(bào)文大小，并且ECN標(biāo)記閾值為65個(gè)報(bào)文大小。

1、有效性驗(yàn)證

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

2、測(cè)試床下的性能提升度

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

3、模擬實(shí)驗(yàn)測(cè)試環(huán)境測(cè)試結(jié)果

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

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

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

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

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