專利名稱：基于LT code的數(shù)據(jù)中心多對一數(shù)據(jù)傳輸協(xié)議(LTTP)的制作方法
技術(shù)領(lǐng)域：
數(shù)據(jù)中心網(wǎng)絡(luò)
背景技術(shù)：
在數(shù)據(jù)中心網(wǎng)絡(luò)中，不管是在線應(yīng)用(如網(wǎng)絡(luò)搜索)還是后臺任務(wù)(如以GFS為代表的分布式文件存儲系統(tǒng)和以MapReduce為代表的分布式計算等),其通信都具有barriersynchronized特性。然而這種特殊的多對一通信模式使用TCP作為傳輸層協(xié)議，當(dāng)通信的服務(wù)器數(shù)量較大時，通信的性能會急劇下降，發(fā)生TCP Incast。導(dǎo)致TCP Incast的原因主要有兩點1)當(dāng)通信的服務(wù)器數(shù)量增大時，一臺服務(wù)器會同時接收來自其它所有服務(wù)器的數(shù)據(jù)，這些數(shù)據(jù)會導(dǎo)致交換機的緩存溢出，從而導(dǎo)致丟包。2)發(fā)生丟包會導(dǎo)致TCP觸發(fā)超時重傳。然而TCP超時重傳定時器(RTO)的值一般為200ms，而數(shù)據(jù)中心網(wǎng)絡(luò)中的RTT—般為微秒級。因此一旦發(fā)生超時，TCP連接會在相對一段較長時間內(nèi)處于空閑，從而導(dǎo)致傳輸·性能低下。已有的解決方案可以分為兩類，其中一類解決方案將RTO的值設(shè)為微秒級，但需要升級操作系統(tǒng)和硬件。另一類解決方案采用改進的擁塞控制機制降低對交換機緩存的占用、避免發(fā)生超時重傳。但不能在通信的服務(wù)器數(shù)量足夠大時避免TCP Incast0本發(fā)明的目的在于設(shè)計一個用于數(shù)據(jù)中心網(wǎng)絡(luò)中多對一通信的數(shù)據(jù)傳輸協(xié)議，提高數(shù)據(jù)傳輸性能。

發(fā)明內(nèi)容
本發(fā)明的目的在于設(shè)ii 種基于編碼(LT code)的傳輸協(xié)議LTTP (LT codebased Transport Protocol),用于數(shù)據(jù)中心網(wǎng)中的多對一通信,實現(xiàn)數(shù)據(jù)的高效傳輸,避免TCP Incast的發(fā)生。I.本發(fā)明的特征在于在數(shù)據(jù)中心網(wǎng)絡(luò)中依次按以下步驟實現(xiàn)的步驟(1)，構(gòu)造一個數(shù)據(jù)中心多對一的數(shù)據(jù)傳輸網(wǎng)絡(luò)拓撲，包含多臺服務(wù)器、一臺交換機，其中多臺服務(wù)器由作為客戶端的任意一臺服務(wù)器和作為服務(wù)器端的其它服務(wù)器組成，其中客戶端和每一個服務(wù)器端構(gòu)成一對一通信通道，配置有一個控制通道和一個數(shù)據(jù)通道，所述控制通道傳輸客戶端向服務(wù)器發(fā)出的控制信息，其中包括服務(wù)請求信息、用于停止編碼的發(fā)送結(jié)束命令。所述控制通道采用TCP協(xié)議傳輸數(shù)據(jù)，數(shù)據(jù)通道采用用戶數(shù)據(jù)報協(xié)議m)P傳輸數(shù)據(jù)；交換機，不同的端口與各個所述服務(wù)器端直接或間接相連；步驟(2)，數(shù)據(jù)中心網(wǎng)絡(luò)內(nèi)的多對一的數(shù)據(jù)傳輸網(wǎng)絡(luò)拓撲依次按以下步驟實現(xiàn)多對一的數(shù)據(jù)傳輸步驟(2. I)，客戶端和各服務(wù)器端預(yù)置TCP友好速率控制協(xié)議TFRC，步驟(2. 2)，客戶端與各服務(wù)器端建立TCP連接，接通控制通道，步驟(2. 3)，客戶端通過各控制通道向?qū)?yīng)的各服務(wù)器端發(fā)送通信請求，
步驟(2. 4)，各服務(wù)器端收到所述通信請求后，使用數(shù)字噴泉碼LT Code對原始數(shù)據(jù)編碼，完畢后通過數(shù)據(jù)通道向客戶端發(fā)送編碼數(shù)據(jù)，步驟(2. 5)，客戶端通過為各服務(wù)器預(yù)置的基于TCP友好速率控制協(xié)議TFRC來控制各服務(wù)器端的數(shù)據(jù)發(fā)送速率，步驟(2. 6)，客戶端一旦恢復(fù)原始數(shù)據(jù)，就通過控制通道向相應(yīng)的作為發(fā)送方的服務(wù)器端發(fā)送結(jié)束命令，步驟(2. 7)，客戶端重復(fù)執(zhí)行步驟(2. 6)，一直到所有服務(wù)器端都發(fā)送完數(shù)據(jù)為
止。 本發(fā)明提出的方法的思路在于導(dǎo)致TCP Incast發(fā)生的原因主要是由于TCP的超時重傳時鐘與數(shù)據(jù)中心網(wǎng)絡(luò)中的RTT值不匹配，因此一旦發(fā)生超時重傳，TCP連接會在相對較長的一段時間內(nèi)空閑，使性能下降。不同于已有的基于TCP的解決方案，我們提出一種基于LT code的傳輸協(xié)議，使用UDP作為傳輸協(xié)議，從而避免了超時重傳對數(shù)據(jù)傳輸性能的影響。因為UDP既不能保證數(shù)據(jù)的可靠傳輸，也沒有提供擁塞控制機制，因此我們分別使用數(shù)字噴泉碼(LT code)和TFRC (TCP-Friendly Rate Control)實現(xiàn)數(shù)據(jù)的可靠傳輸和擁塞控制。我們稱這種基于LT code的傳輸協(xié)議為LT code based Transport Protocol(LTTP)。本發(fā)明優(yōu)點包括I)不要求升級硬件或操作系統(tǒng)；2)能夠有效解決TCP Incast問題，提高多對一數(shù)據(jù)傳輸效率；


圖I. LTTP的工作流程client:客戶端switch:交換機server:服務(wù)器端establishes TCP connections:建立 TCP 連接send requests:發(fā)送請求報文send encoded packets:發(fā)送編碼報文send terminating signals:發(fā)送結(jié)束命令Control Channel (TCP):控制通道(基于 TCP)Data Channel (UDP):數(shù)據(jù)通道(基于 UDP)
具體實施例方式我們考慮到在多對一通信中，除了數(shù)據(jù)外，還有一些控制信息，比如客戶端向各個服務(wù)器端發(fā)送的請求信息和客戶端向服務(wù)器端發(fā)送的結(jié)束命令(以停止編碼)，為每一對通信雙方配置一個控制通道(control channel)和一個數(shù)據(jù)通道(control channel)。其中控制通道用于傳輸控制信息，而數(shù)據(jù)通道只傳輸數(shù)據(jù)。由于控制信息數(shù)據(jù)量很小，不適合采用編碼進行傳輸。因此控制通道使用TCP傳輸數(shù)據(jù)。數(shù)據(jù)通道使用UDP傳輸編碼數(shù)據(jù)、使用TFRC控制發(fā)送速率。由于TCP連接僅從客戶端向服務(wù)器端傳輸數(shù)據(jù)，而且這些服務(wù)器與不同的交換機端口相連，因此不會發(fā)生TCP Incast。對于數(shù)據(jù)中心網(wǎng)絡(luò)，當(dāng)進行多對一通信時，客戶端首先與所有參與通信的服務(wù)器端建立控制通道(TCP連接)。待所有控制通道建立完畢后，由客戶端通過控制通道向所有服務(wù)器端發(fā)送請求。服務(wù)器端在收到請求后，使用LT code對原始數(shù)據(jù)進行編碼，并使用數(shù)據(jù)通道向客戶端發(fā)送編碼數(shù)據(jù)。我們?yōu)槊恳慌_參與通信的主機部署TFRC，用于控制服務(wù)器端發(fā)送數(shù)據(jù)的速度。客戶端一旦恢復(fù)原始數(shù)據(jù)，就通過控制通道向相應(yīng)的服務(wù)器端發(fā)送結(jié)束命令。待請求的所有數(shù)據(jù)都恢復(fù)完畢，通信結(jié)束。我們建立了一個拓撲，多臺服務(wù)器通過一個交換機直接相連。其中一臺服務(wù)器作為客戶端，其它服務(wù)器作為服務(wù)器端。鏈路帶寬均為lGbps。我們在該拓撲上進行了實驗，由該客戶端向不同數(shù)量的服務(wù)器請求不同大小的數(shù)據(jù)，并分別使用LTTP、TCP和DCTCP重復(fù)上述實現(xiàn)，并比較LTTP與TCP和DCTCP的性能。實驗結(jié)果表明，TCP和DCTCP在服務(wù)器數(shù) 量較大時，均會發(fā)生TCP Incasto使用LTTP時,goodput未發(fā)現(xiàn)急劇下降的現(xiàn)象,能夠維持在750Mbps左右，說明本發(fā)明達到了預(yù)期目的。
權(quán)利要求
1.基于數(shù)字噴泉碼的數(shù)據(jù)中心多對一的數(shù)據(jù)傳輸方法，其特征在于在數(shù)據(jù)中心網(wǎng)絡(luò)中依次按以下步驟實現(xiàn)的 步驟(1)，構(gòu)造一個數(shù)據(jù)中心多對一的數(shù)據(jù)傳輸網(wǎng)絡(luò)拓撲，包含多臺服務(wù)器、一臺交換機，其中 多臺服務(wù)器由作為客戶端的任意一臺服務(wù)器和作為服務(wù)器端的其它服務(wù)器組成，其中客戶端和每一個服務(wù)器端構(gòu)成一對一通信通道，配置有一個控制通道和一個數(shù)據(jù)通道，所述控制通道傳輸客戶端向服務(wù)器發(fā)出的控制信息，其中包括服務(wù)請求信息、用于停止編碼的發(fā)送結(jié)束命令。所述控制通道采用TCP協(xié)議傳輸數(shù)據(jù)，數(shù)據(jù)通道采用用戶數(shù)據(jù)報協(xié)議UDP傳輸數(shù)據(jù)； 交換機，不同的端口與各個所述服務(wù)器端直接或間接相連； 步驟(2)，數(shù)據(jù)中心網(wǎng)絡(luò)內(nèi)的多對一的數(shù)據(jù)傳輸網(wǎng)絡(luò)拓撲依次按以下步驟實現(xiàn)多對一的數(shù)據(jù)傳輸 步驟(2. I)，客戶端和各服務(wù)器端預(yù)置TCP友好速率控制協(xié)議TFRC， 步驟(2. 2)，客戶端與各服務(wù)器端建立TCP連接，接通控制通道， 步驟(2. 3)，客戶端通過各控制通道向?qū)?yīng)的各服務(wù)器端發(fā)送通信請求， 步驟(2. 4)，各服務(wù)器端收到所述通信請求后，使用數(shù)字噴泉碼LT Code對原始數(shù)據(jù)編碼，完畢后通過數(shù)據(jù)通道向客戶端發(fā)送編碼數(shù)據(jù)， 步驟(2. 5)，客戶端通過為各服務(wù)器預(yù)置的基于TCP友好速率控制協(xié)議TFRC來控制各服務(wù)器端的數(shù)據(jù)發(fā)送速率， 步驟(2. 6)，客戶端一旦恢復(fù)原始數(shù)據(jù)，就通過控制通道向相應(yīng)的作為發(fā)送方的服務(wù)器端發(fā)送結(jié)束命令， 步驟(2. 7)，客戶端重復(fù)執(zhí)行步驟(2. 6)，一直到所有服務(wù)器端都發(fā)送完數(shù)據(jù)為止。
全文摘要
基于數(shù)字噴泉碼的數(shù)據(jù)中心多對一的數(shù)據(jù)傳輸方法屬于數(shù)據(jù)中心網(wǎng)絡(luò)數(shù)據(jù)傳輸技術(shù)領(lǐng)域，其特性在于，在作為通信雙方的客戶端與各服務(wù)器端之間建立基于TCP協(xié)議的控制通道和基于UDP協(xié)議的數(shù)據(jù)通道，在多對一的數(shù)據(jù)傳輸過程中，客戶端通過預(yù)置的TCP友好速率控制協(xié)議TFRC控制各服務(wù)器數(shù)據(jù)發(fā)送速率，借助于控制通道在恢復(fù)原始數(shù)據(jù)后向相應(yīng)的服務(wù)器端發(fā)送結(jié)束命令。本發(fā)明具有防止傳輸堵塞和提高傳輸效率的雙重優(yōu)點。
文檔編號H04L1/00GK102984172SQ20121053737
公開日2013年3月20日 申請日期2012年12月12日 優(yōu)先權(quán)日2012年12月12日
發(fā)明者李丹, 蔣長林, 徐明偉 申請人:清華大學(xué)