本發(fā)明涉及一種數(shù)據(jù)中心網(wǎng)絡(luò)中基于并發(fā)度感知的傳輸控制方法。
背景技術(shù)：
近年來，隨著云計(jì)算技術(shù)的迅猛發(fā)展，數(shù)據(jù)中心已經(jīng)成為了關(guān)鍵基礎(chǔ)設(shè)施，不僅承載大量的應(yīng)用程序并且提供各種各樣的用戶服務(wù)，如推薦系統(tǒng)、網(wǎng)絡(luò)搜索和mapreduce。為了給用戶提供更好的服務(wù)，部署在數(shù)據(jù)中心的各類應(yīng)用通常需要協(xié)調(diào)多臺(tái)服務(wù)器共同完成任務(wù)。為此，不同服務(wù)器之間需要進(jìn)行通信。由于各服務(wù)器之間的通信必須通過網(wǎng)絡(luò)來實(shí)現(xiàn)，而網(wǎng)絡(luò)問題又是數(shù)據(jù)中心的瓶頸問題，因此，數(shù)據(jù)中心中的網(wǎng)絡(luò)(即數(shù)據(jù)中心網(wǎng)絡(luò))成為了研究的熱點(diǎn)。
與傳統(tǒng)網(wǎng)絡(luò)相比，數(shù)據(jù)中心網(wǎng)絡(luò)具有很多獨(dú)特的屬性。一方面，由于數(shù)據(jù)中心的服務(wù)器和交換機(jī)等設(shè)備通常部署在一個(gè)較小的物理區(qū)域，因此往返傳輸延時(shí)(roundtriptime,rtt)很低，通常只有幾百微秒。另一方面，考慮到成本問題，數(shù)據(jù)中心網(wǎng)絡(luò)中的交換機(jī)并非定制，它所具有的緩存容量通常較小。此外，在數(shù)據(jù)中心網(wǎng)絡(luò)具有超高帶寬，且一對多或者多對多的通信模式廣泛存在于并行編程系統(tǒng)(如dryad和ciel等)、分布式文件存儲(chǔ)系統(tǒng)和大型排序系統(tǒng)等。這些獨(dú)特的屬性使得數(shù)據(jù)中心內(nèi)部流量急劇增長并呈現(xiàn)出與傳統(tǒng)互聯(lián)網(wǎng)不同的新特性。
大量的研究表明，數(shù)據(jù)中心網(wǎng)絡(luò)中通常采用tcp協(xié)議傳輸數(shù)據(jù)(占總流量的95％)，以確保給用戶提供可靠的服務(wù)。盡管tcp協(xié)議是一個(gè)非常成熟的通信技術(shù)，但是tcp協(xié)議是針對低帶寬和高延遲的廣域網(wǎng)設(shè)計(jì)。上述數(shù)據(jù)中心網(wǎng)絡(luò)特有的屬性以及特殊的業(yè)務(wù)需求使得在廣域網(wǎng)中運(yùn)行良好的tcp協(xié)議遇到了很多問題，其中tcpincast就是最重要的問題之一。
針對tcpincast問題，許多研究者深入分析了tcpincast為何會(huì)嚴(yán)重降低網(wǎng)絡(luò)吞吐率的原因。一方面，高扇入的并發(fā)度極易導(dǎo)致交換機(jī)出現(xiàn)嚴(yán)重的丟包，使得tcp協(xié)議中的快重傳機(jī)制失效，從而導(dǎo)致超時(shí)重傳。另一方面，在數(shù)據(jù)中心網(wǎng)絡(luò)中，由于rtt通常是微妙級(jí)的，而最小超時(shí)重傳時(shí)間(minimumretransmissiontimeout,rtomin)是毫秒級(jí)(默認(rèn)最小值為200ms)的。因此，一旦發(fā)生超時(shí)，鏈路會(huì)在相當(dāng)一段時(shí)間(約為幾百個(gè)rtt)內(nèi)處于空閑狀態(tài)，嚴(yán)重降低網(wǎng)絡(luò)性能。為了解決tcpincast問題，近年來，學(xué)術(shù)界提出了許多方案解決tcpincast問題。這些方案大致可分為以下幾大類：
1.調(diào)整系統(tǒng)參數(shù)。vijayvasudevan等人將最小超時(shí)重傳時(shí)間(默認(rèn)為200ms)修改成200us，避免超時(shí)導(dǎo)致鏈路長時(shí)間空閑。但該方法容易導(dǎo)致大量的假超時(shí)和假重傳。一些研究者通過修改分組的大小解決tcpincast問題，但這樣增加了分組頭的傳輸開銷，降低了網(wǎng)絡(luò)傳輸?shù)挠行掏侣省?/p>
2.設(shè)計(jì)新的傳輸協(xié)議。dctcp根據(jù)被ecn標(biāo)記包的比例調(diào)整擁塞窗口。dctcp具有較好的突發(fā)容忍性，實(shí)現(xiàn)很好的網(wǎng)絡(luò)性能。在dctcp的基礎(chǔ)上，研究者們還提出了d2tcp和l2dct等協(xié)議。但是這些協(xié)議的主要缺陷是無法很好的處理高并發(fā)的場景。ictcp根據(jù)網(wǎng)絡(luò)帶寬設(shè)置接收窗口，從而實(shí)現(xiàn)擁塞控制。然而，精確地估計(jì)當(dāng)前可用帶寬非常具有挑戰(zhàn)性。
3.跨層協(xié)議設(shè)計(jì)。plato采用包標(biāo)記方案維持ack-clocking從而避免超時(shí)。tfc利用令牌、可用帶寬和有效流的數(shù)量計(jì)算出每條流的擁塞窗口，從而實(shí)現(xiàn)擁塞控制。然而這些方法需要修改交換機(jī)，不利于實(shí)際環(huán)境的部署。此外，一些研究者采用編碼的方案來解決tcpincast問題，如lttp和tcp-acc。但是，基于編碼的方案不可避免的在網(wǎng)絡(luò)中傳輸大量的冗余包，降低帶寬的利用率。
此外，一些研究者提出了tcppacing。它的基本思想是發(fā)送端在一個(gè)rtt內(nèi)將整個(gè)窗口的分組均勻的發(fā)送到網(wǎng)絡(luò)中。在高并發(fā)的應(yīng)用中，tcppacing能夠降低流量突發(fā)從而減少丟包和超時(shí)，有利于提高吞吐量。然而，在低并發(fā)的應(yīng)用中，如果交換機(jī)的緩存容量足夠容納突發(fā)分組，tcppacing導(dǎo)致帶寬資源得不到充分利用從而降低網(wǎng)絡(luò)的性能。
因此，如何有效緩解或解決tcpincast從而避免吞吐率的坍塌已經(jīng)成為數(shù)據(jù)中心網(wǎng)絡(luò)領(lǐng)域一個(gè)非常重要和迫切需要解決的問題。
技術(shù)實(shí)現(xiàn)要素：
本發(fā)明所解決的技術(shù)問題是，針對現(xiàn)有技術(shù)的不足，提供了一種數(shù)據(jù)中心網(wǎng)絡(luò)中基于并發(fā)度感知的傳輸控制方法，利用高精度定時(shí)器控制分組的發(fā)送時(shí)間，使得到達(dá)交換機(jī)的分組控制在緩存能夠容納的范圍之內(nèi)，這樣能夠有效的避免交換機(jī)發(fā)生大量的丟包和超時(shí)，提高了網(wǎng)絡(luò)吞吐率。
本發(fā)明解決上述技術(shù)問題的技術(shù)方案為：
一種數(shù)據(jù)中心網(wǎng)絡(luò)中基于并發(fā)度感知的傳輸控制方法，其特征在于，在數(shù)據(jù)傳輸過程中，發(fā)送端根據(jù)當(dāng)前的擁塞窗口和并發(fā)度來調(diào)整相鄰分組的發(fā)送時(shí)間間隔從而控制發(fā)送速率。具體包括以下步驟：
步驟1：參數(shù)初始化；
步驟2：發(fā)送分組；
步驟3：發(fā)送端啟動(dòng)分組間隔調(diào)節(jié)定時(shí)器；定時(shí)器為發(fā)送端發(fā)送數(shù)據(jù)的一小段程序代碼，作為發(fā)送數(shù)據(jù)時(shí)的判斷條件，這樣做可以降低計(jì)算和控制開銷；
步驟4：發(fā)送端判斷分組間隔調(diào)節(jié)定時(shí)器是否到期，若是且數(shù)據(jù)沒有發(fā)送完畢，則發(fā)送下一個(gè)分組；若是且數(shù)據(jù)發(fā)送完畢，則結(jié)束；否則繼續(xù)等待；
步驟5：發(fā)送端收到ack后，利用當(dāng)前時(shí)間和上一次接收到ack的時(shí)間估算瓶頸鏈路的并發(fā)度；
步驟6：發(fā)送端根據(jù)并發(fā)度、擁塞窗口、緩存和鏈路容量計(jì)算相鄰分組的發(fā)送時(shí)間間隔，使之適應(yīng)當(dāng)前的網(wǎng)絡(luò)擁塞狀態(tài)；
步驟7：對相鄰分組的發(fā)送時(shí)間間隔進(jìn)行隨機(jī)化處理；
步驟8：發(fā)送端根據(jù)步驟7的處理結(jié)果更新分組間隔調(diào)節(jié)定時(shí)器的到期時(shí)間，并更新最近一次收到ack的時(shí)間，返回步驟3。
所述步驟1包括：設(shè)置擁塞窗口大小w、分組大小s、分組間隔調(diào)節(jié)定時(shí)器的到期時(shí)間t、最近兩次收到ack的時(shí)間t0和t1、鏈路容量c、往返傳輸延時(shí)rtt、分組的發(fā)送延時(shí)td、設(shè)置交換機(jī)每個(gè)端口的緩存容量為b。
所述步驟2中：發(fā)送端根據(jù)分組的目的ip地址將分組發(fā)送到目的主機(jī)。
所述步驟5中：發(fā)送端接收到ack后，記錄當(dāng)前的時(shí)間為t1，并判斷是否是首次接收到ack，如果是，則發(fā)送端將變量t0更新為t1，用于記錄最近一次接收ack時(shí)間，并轉(zhuǎn)步驟4；否則，發(fā)送端利用兩次收到ack的時(shí)間t0和t1以及發(fā)送延時(shí)td估算出瓶頸鏈路上的并發(fā)度n，具體計(jì)算方法如下：
tq＝t1-to
td＝s/c
其中，tq表示隊(duì)列延時(shí)。
所述步驟6中：發(fā)送端結(jié)合估算的并發(fā)度n、擁塞窗口w、鏈路容量c和緩存容量b計(jì)算出發(fā)送下一個(gè)分組的時(shí)間間隔，具體計(jì)算方法如下：
由于整個(gè)窗口的分組需要在一個(gè)rtt內(nèi)發(fā)送到網(wǎng)絡(luò)中，因此相鄰分組之間的時(shí)間間隔不能超過
所述步驟7中：在步驟6的基礎(chǔ)上，發(fā)送端對相鄰分組的發(fā)送時(shí)間間隔進(jìn)行隨機(jī)化處理，將其設(shè)置為t×(1+x)。其中，x是一個(gè)隨機(jī)變量，它的取值范圍是[-1,1]。該方法不僅能夠避免不同流出現(xiàn)窗口同步的現(xiàn)象，而且能夠保證整個(gè)窗口內(nèi)的分組在一個(gè)rtt內(nèi)發(fā)送到網(wǎng)絡(luò)中。
所述步驟8中：發(fā)送端將分組間隔調(diào)節(jié)定時(shí)器的到期時(shí)間更新為t，并將變量t0更新為t1，返回步驟3。
本發(fā)明的技術(shù)效果在于：
本發(fā)明發(fā)送端可以根據(jù)瓶頸鏈路的并發(fā)度及其擁塞窗口等信息動(dòng)態(tài)調(diào)整分組的發(fā)送時(shí)間間隔，從而調(diào)控發(fā)送速率。針對高并發(fā)的應(yīng)用，發(fā)送端增大相鄰分組的發(fā)送時(shí)間間隔，從而降低發(fā)送速率，這樣可以有效避免交換機(jī)丟棄大量的丟包而導(dǎo)致tcp超時(shí)，避免高并發(fā)導(dǎo)致的tcpincast問題。反之，針對低并發(fā)的應(yīng)用，發(fā)送端減少相鄰分組的發(fā)送時(shí)間間隔，甚至是背靠背的發(fā)送分組，這樣可以充分利用帶寬資源，實(shí)現(xiàn)高帶寬利用率。
附圖說明
圖1為本發(fā)明的流程圖。
圖2為測試本發(fā)明性能所使用的網(wǎng)絡(luò)拓?fù)鋱D。圖2(a)為incast場景示意圖，圖2(b)為fat-tree拓?fù)洹?/p>
圖3為本發(fā)明和其他方法在模擬測試環(huán)境中，測試不同方法在不同場景下所支持的并發(fā)度，其中本發(fā)明命名為ap。圖3(a)～圖3(d)分別為不同的往返時(shí)間rtt和鏈路容量c下，測試不同協(xié)議是否結(jié)合分組發(fā)送間隔調(diào)節(jié)方法的場景下所支持的最大并發(fā)度。
圖4為本發(fā)明在模擬測試環(huán)境中，隨著時(shí)間的變化，流數(shù)先增后減的場景下測量評(píng)估并發(fā)度的準(zhǔn)確性。其中本發(fā)明命名為ap。
圖5為本發(fā)明和其他方法在模擬實(shí)驗(yàn)測試環(huán)境中，在fat-tree網(wǎng)絡(luò)拓?fù)湎聹y試流的平均完成時(shí)間，其中本發(fā)明命名為ap。圖5(a)為不同方法隨著pod個(gè)數(shù)的增加，平均流完成時(shí)間變化圖；圖5(b)為不同方法隨著流個(gè)數(shù)的增加，平均流完成時(shí)間變化圖。
圖6為本發(fā)明和其他方法在測試床環(huán)境中，設(shè)置不同的緩存大小和服務(wù)請求單元大小，測量隨著流數(shù)增加的吞吐率。其中本發(fā)明命名為ap。圖6(a)為緩存大小為64kb且服務(wù)請求單元大小為64kb，測量隨著流數(shù)增加的吞吐率；圖6(b)為緩存大小為64kb且服務(wù)請求單元大小為128kb，測量隨著流數(shù)增加的吞吐率；圖6(c)為緩存大小為32kb且服務(wù)請求單元大小為32kb，測量隨著流數(shù)增加的吞吐率；圖6(d)為緩存大小為128kb且服務(wù)請求單元大小為32kb，測量隨著流數(shù)增加的吞吐率。
圖7為本發(fā)明和其他方法在測試床境中，測試web搜索應(yīng)用模式下的不同測試指標(biāo)的結(jié)果圖，其中本發(fā)明命名為ap。圖7(a)為不同方法隨著流數(shù)的增加獲得的搜索響應(yīng)時(shí)間；圖7(b)為不同方法隨著流數(shù)增加獲得的超時(shí)率。
具體實(shí)施方式
下面結(jié)合附圖對本發(fā)明作進(jìn)一步的說明。
參見圖1，圖1為本發(fā)明的流程圖。過程如下：
步驟1：參數(shù)初始化。設(shè)置擁塞窗口大小為w；設(shè)置分組大小為s；設(shè)置分組間隔調(diào)節(jié)定時(shí)器到期的時(shí)間間隔為t；設(shè)置最近兩次收到ack的時(shí)間為t0和t1；設(shè)置并發(fā)度為n；設(shè)置鏈路容量為c；設(shè)置往返傳輸延時(shí)為rtt；設(shè)置分組的發(fā)送延時(shí)為td；設(shè)置交換機(jī)每個(gè)端口的緩存容量為b；
步驟2：發(fā)送端根據(jù)分組的目的ip地址將分組發(fā)送到目的主機(jī)；
步驟3：發(fā)送端啟動(dòng)分組間隔調(diào)節(jié)定時(shí)器；
步驟4：發(fā)送端判斷分組間隔調(diào)節(jié)定時(shí)器是否到期，若是且數(shù)據(jù)沒有發(fā)送完畢，則發(fā)送下一個(gè)分組；若是且數(shù)據(jù)發(fā)送完畢，則結(jié)束；否則繼續(xù)等待；
步驟5：接收到ack后，發(fā)送端記錄當(dāng)前的時(shí)間為t1；如果發(fā)送端是首次接收到ack，則發(fā)送端將變量t0更新為t1，用于記錄最近一次接收ack時(shí)間；否則，發(fā)送端利用兩次收到ack的時(shí)間t0和t1以及發(fā)送延時(shí)td估算出瓶頸鏈路上的并發(fā)度n，具體計(jì)算方法如下：
tq＝t1-t0
td＝s/c
其中，tq表示隊(duì)列延時(shí)。
步驟6：發(fā)送端結(jié)合估算的并發(fā)度、擁塞窗口、鏈路容量和緩存容量計(jì)算出發(fā)送下一個(gè)分組的時(shí)間間隔，具體計(jì)算方法如下：
其中，n表示并發(fā)度；w表示擁塞窗口；b表示緩存容量；c表示鏈路容量。
由于整個(gè)窗口的分組需要在一個(gè)rtt內(nèi)發(fā)送到網(wǎng)絡(luò)中，因此相鄰分組之間的時(shí)間間隔不能超過
步驟7：在步驟6的基礎(chǔ)上，發(fā)送端對相鄰分組的發(fā)送時(shí)間間隔進(jìn)行隨機(jī)化處理，將其設(shè)置為t×(1+x)。其中，x是一個(gè)隨機(jī)變量，它的取值范圍是[-1,1]。該方法不僅能夠避免不同流出現(xiàn)窗口同步的現(xiàn)象，而且能夠保證整個(gè)窗口內(nèi)的分組在一個(gè)rtt內(nèi)發(fā)送到網(wǎng)絡(luò)中。
步驟8：發(fā)送端將分組間隔調(diào)節(jié)定時(shí)器的到期時(shí)間更新為t，并將變量t0更新為t1，返回步驟3。
我們分別在模擬仿真和測試床平臺(tái)測試上測試本發(fā)明的網(wǎng)絡(luò)性能。本發(fā)明ap可以嵌入到不同的tcp傳輸協(xié)議，提升網(wǎng)絡(luò)性能。在實(shí)驗(yàn)結(jié)果圖中，如果協(xié)議的下標(biāo)含有ap，則表示將ap嵌入到協(xié)議中。例如，dctcp表示原始協(xié)議，而dctcpap表示已將本發(fā)明ap嵌入到dctcp中。
1.模擬實(shí)驗(yàn)測試環(huán)境測試結(jié)果
本發(fā)明首先利用ns2.35網(wǎng)絡(luò)仿真平臺(tái)來實(shí)現(xiàn)，并進(jìn)行了性能測試。ns2已被網(wǎng)絡(luò)研究者廣泛使用，它在互聯(lián)網(wǎng)上公開發(fā)布的網(wǎng)址為：http://www.isi.edu/nsnam/ns。ns2.35是ns2的版本之一。
圖3使用的實(shí)驗(yàn)拓?fù)浜蛨D2(a)所示的incast場景示意圖一致。多個(gè)服務(wù)器連接到同一交換機(jī)，實(shí)驗(yàn)參數(shù)設(shè)置如下：交換機(jī)緩存為100個(gè)包；交換機(jī)進(jìn)行ecn標(biāo)記的閾值為65個(gè)包；所有鏈路容量均為10gbps；包大小為1500bytes；往返時(shí)間rtt為400us；最小超時(shí)重傳時(shí)間rtomin為200ms；sru大小為32kbytes。
圖3使用的實(shí)驗(yàn)拓?fù)浜蛨D2(a)所示的incast場景示意圖一致。多個(gè)服務(wù)器連接到同一交換機(jī)，每條服務(wù)器發(fā)送10包且每個(gè)包的大小為1500bytes。我們在不同的往返時(shí)間rtt和鏈路容量c的場景下進(jìn)行測試。
圖3(a)為往返時(shí)間rtt為100us且鏈路容量c為10gbps時(shí)，測試不同協(xié)議是否結(jié)合分組發(fā)送間隔調(diào)節(jié)方法的場景下所支持的最大并發(fā)度。
圖3(b)為往返時(shí)間rtt為100us且鏈路容量c為40gbps時(shí)，測試不同協(xié)議是否結(jié)合分組發(fā)送間隔調(diào)節(jié)方法的場景下所支持的最大并發(fā)度。
圖3(c)為往返時(shí)間rtt為300us且鏈路容量c為10gbps時(shí)，測試不同協(xié)議是否結(jié)合分組發(fā)送間隔調(diào)節(jié)方法的場景下所支持的最大并發(fā)度。
圖3(d)為往返時(shí)間rtt為300us且鏈路容量c為40gbps時(shí)，測試不同協(xié)議是否結(jié)合分組發(fā)送間隔調(diào)節(jié)方法的場景下所支持的最大并發(fā)度。
在圖3中，由于相鄰分組的發(fā)送間隔受限，不可避免限制了ap的有效性。盡管如此，各協(xié)議結(jié)合ap后，所支持的最大并發(fā)度都有所提升，性能提升高達(dá)2倍以上。
圖4使用的實(shí)驗(yàn)拓?fù)浜蛨D2(a)所示的incast場景示意圖一致。多個(gè)服務(wù)器連接到同一交換機(jī)，實(shí)驗(yàn)場景設(shè)置如下：初始階段，10臺(tái)服務(wù)器各發(fā)送一條長流到同一個(gè)接收端，然后，每隔10毫秒增加一條流，直至總流數(shù)達(dá)到50。由于新增加的流僅運(yùn)行0.6s，因此0.6s后，流的數(shù)量將逐漸減少，最終網(wǎng)絡(luò)中僅有10條長流。在測量的過程中，每隔2ms進(jìn)行采樣得到圖4所示的結(jié)果。測量結(jié)果顯示，本發(fā)明評(píng)估的流數(shù)與網(wǎng)絡(luò)中實(shí)際的流數(shù)非常接近。
除了以上給出的測試床的局部性能測試，為了全面比較該發(fā)明的高效性，我們在圖2(b)所示的fat-tree拓?fù)渲羞M(jìn)一步測試了平均流完成時(shí)間。實(shí)驗(yàn)參數(shù)設(shè)置如下：架頂交換機(jī)、匯聚交換機(jī)和核心交換機(jī)緩存的緩存分別為100、200和400個(gè)包；交換機(jī)進(jìn)行ecn標(biāo)記的閾值為65個(gè)包；所有鏈路容量均為10gbps；包大小為1500bytes；最小超時(shí)重傳時(shí)間rtomin為200ms；sru大小為64kbytes。實(shí)驗(yàn)結(jié)果如圖5所示。
圖5(a)為同一個(gè)pod內(nèi)的所有服務(wù)器隨機(jī)選擇其他pod內(nèi)某臺(tái)服務(wù)器作為接收端且每臺(tái)服務(wù)器與接收端建立10條tcp鏈接。實(shí)驗(yàn)結(jié)果顯示，當(dāng)pod數(shù)小于8時(shí)，無論各協(xié)議是否結(jié)合ap，它們獲得非常相近的結(jié)果。當(dāng)pod數(shù)大于8時(shí)，網(wǎng)絡(luò)擁塞變得更加嚴(yán)重，結(jié)合ap后的各協(xié)議比原始協(xié)議獲得更好的網(wǎng)絡(luò)性能。
圖5(b)為fat-tree拓?fù)渲械膒od數(shù)固定為8，變化每臺(tái)服務(wù)器與接收端建立的tcp鏈接數(shù)。其它實(shí)驗(yàn)參數(shù)和場景設(shè)置與圖5(a)相同。實(shí)驗(yàn)結(jié)果顯示，隨著每臺(tái)服務(wù)器發(fā)送流數(shù)的增加，各協(xié)議無論是否結(jié)合ap，其平均逐漸增加。當(dāng)每臺(tái)服務(wù)器發(fā)送的流數(shù)大于8時(shí)，結(jié)合ap后的各協(xié)議比原始協(xié)議獲得更好的網(wǎng)絡(luò)性能。
2、測試床下的性能提升度
為進(jìn)一步驗(yàn)證本發(fā)明的有效性，我們在測試床環(huán)境中對兩個(gè)典型的應(yīng)用(即網(wǎng)頁搜索和mapreduce應(yīng)用)進(jìn)行測試。在該次測試中，使用的實(shí)驗(yàn)拓?fù)浜蛨D2(a)所示的incast場景示意圖一致。服務(wù)器的配置如下：cpu型號(hào)為intelpentiumg6452.90ghz；內(nèi)存為4gb；硬盤容量為500gb；網(wǎng)卡速率為1gbps。所有服務(wù)器都安裝了centos6.5的操作系統(tǒng)，其linux內(nèi)核版本為2.6.38。此外，所有服務(wù)器都安裝了本發(fā)明的補(bǔ)丁。實(shí)驗(yàn)參數(shù)設(shè)置如下：交換機(jī)緩存為100個(gè)包；交換機(jī)進(jìn)行ecn標(biāo)記的閾值為65個(gè)包；限制交換機(jī)的出口速率為200mbps；包大小為1500bytes；往返時(shí)間rtt為300us；最小超時(shí)重傳時(shí)間rtomin為200ms。
圖6給出了不同協(xié)議在map-reduce應(yīng)用模式下面的測試結(jié)果。在實(shí)驗(yàn)過程中，我們逐漸增加流數(shù)，最終流數(shù)高達(dá)90。圖6(a)和圖6(b)中交換機(jī)的緩存大小固定為64kb，它們的服務(wù)器請求單元分別為64kb和128kb。實(shí)驗(yàn)結(jié)果顯示，各協(xié)議結(jié)合ap后都沒有發(fā)生超時(shí)且獲得了很高的吞吐率，而原始協(xié)議發(fā)生了超時(shí)導(dǎo)致吞吐率坍塌。此外，服務(wù)請求單元越大，所獲得的吞吐率越高。這是因?yàn)榉?wù)請求單元越大，各發(fā)送端所需的傳輸時(shí)間就越多。盡管有一些流發(fā)生超時(shí)，但未超時(shí)的流可充分利用可用的帶寬資源，減少鏈路的空閑時(shí)間從而增加吞吐率，圖6(c)和圖6(d)中服務(wù)請求單元的大小固定為32kb，它們的交換機(jī)的緩存大小分別為32kb和128kb。實(shí)驗(yàn)結(jié)果顯示，各協(xié)議結(jié)合ap后都沒有發(fā)生超時(shí)且獲得了很高的吞吐率，而原始協(xié)議發(fā)生了超時(shí)導(dǎo)致吞吐率坍塌。此外，交換機(jī)的緩存越大，所支持的并發(fā)度越多。這是因?yàn)榫彺嬖酱?，能夠存?chǔ)越多的分組，減少丟包和超時(shí)。然而，在數(shù)據(jù)中心網(wǎng)絡(luò)中部署大緩存的交換機(jī)會(huì)增加成本。相反，盡管交換機(jī)的緩存較小，但是各協(xié)議結(jié)合ap后都能獲得很好的網(wǎng)絡(luò)性能。
圖7給出了不同協(xié)議在網(wǎng)頁搜索應(yīng)用模式下面的測試結(jié)果。在實(shí)驗(yàn)過程中，我們逐漸增加流數(shù)，最終流數(shù)高達(dá)90。在實(shí)驗(yàn)過程中，所有流發(fā)送的總數(shù)據(jù)量固定為1m。也就是說，每條流的服務(wù)請求單元大小為1024/n，其中n為流的數(shù)量。圖7(a)測量了各協(xié)議是否結(jié)合ap的搜索響應(yīng)時(shí)間。實(shí)驗(yàn)結(jié)果顯示，tcpnewreno和dctcp協(xié)議首次發(fā)生超時(shí)的流數(shù)分別為12和28。這些協(xié)議超時(shí)后，它們的搜索相應(yīng)時(shí)間都超過200ms。幸運(yùn)的是，各協(xié)議結(jié)合ap方法后沒有發(fā)生超時(shí)，使得它們獲得較小的搜索響應(yīng)時(shí)間(大約為50ms)。圖7(b)測量了各協(xié)議的超時(shí)率。實(shí)驗(yàn)結(jié)果顯示，當(dāng)流數(shù)超過12時(shí)，tcpnewreno會(huì)遭受至少一次超時(shí)，而dctcp是在流數(shù)達(dá)到28時(shí)開始發(fā)生超時(shí)。然而，各協(xié)議結(jié)合ap方法后沒有發(fā)生超時(shí)。簡言之，本發(fā)明在網(wǎng)頁搜索應(yīng)用中所獲得的性能指標(biāo)優(yōu)于其它方法。