基于fast tcp的傳輸控制方法
【技術(shù)領(lǐng)域】
[0001] 本技術(shù)屬于云計算及網(wǎng)絡(luò)傳輸技術(shù)領(lǐng)域，具體涉及一種基于FAST TCP的傳輸控制 方法。
【背景技術(shù)】
[0002] 數(shù)據(jù)中心的拓撲結(jié)構(gòu)經(jīng)過多年的探索，有了很大的變化。圖1示出了常規(guī)的數(shù)據(jù) 中心網(wǎng)絡(luò)的拓撲結(jié)構(gòu)。在這種拓撲結(jié)構(gòu)中，架頂式的范圍（ToR)交換機接入層為安裝在機 架上的服務(wù)器提供連接。在每個聚集層（有時也被稱為分布層）的聚集交換（Aggregation Switch)將從多個接入層（TOR)發(fā)來的流量轉(zhuǎn)發(fā)到核心層。每一個ToR交換機連接到多個 聚集交換機的冗余。核心層將交換機通過核心路由Core Routers)連接到互聯(lián)網(wǎng)。一個特 例是平坦的兩層拓撲，僅使用兩層交換機。
[0003] Clos拓撲是基于多級交換機的一種拓撲結(jié)構(gòu)，每個交換機層次都和下一個交換機 層次的所有交換機相連，這樣大大增加了路徑的多樣性。圖2展示了一種典型的三層Clos 拓撲
[0004] 胖樹是一種特殊的Clos拓撲結(jié)構(gòu)。它是一種類樹結(jié)構(gòu)，如圖3所示，這種拓撲結(jié) 構(gòu)由k個端口的交換機組成，他們有k個連接點，每個連接點處有兩層（聚合層和邊緣層） k/2個交換機，而每（k/2)2個核心交換機有1個端口和這k個連接點鏈接。核心層交換機 和聚合層交換機連接，而邊緣曾交換機與Tor交換機連接。這一策略折衷了復雜度和路由 多樣性。
[0005] 近年來興起了虛擬數(shù)據(jù)中心網(wǎng)絡(luò)，虛擬數(shù)據(jù)中心網(wǎng)絡(luò)是在若干虛擬資源（虛擬 機，虛擬交換機，虛擬路由器等）之間構(gòu)成的虛擬連接，如所示，一個物理數(shù)據(jù)中心上可以 假設(shè)多個虛擬數(shù)據(jù)中心。雖然引入了虛擬化概念，資源利用可以更靈活有圖4架設(shè)在物理 數(shù)據(jù)中心上的虛擬數(shù)據(jù)中心及數(shù)據(jù)中心網(wǎng)絡(luò)效，用戶也可以屏蔽物理層的事宜，但是數(shù)據(jù) 中心網(wǎng)絡(luò)問題仍然客觀存在，必須加以解決。
[0006] TCP協(xié)議給數(shù)據(jù)中心帶來的問題之一就是TCP Incast現(xiàn)象，這里我們首先要對數(shù) 據(jù)中心網(wǎng)絡(luò)環(huán)境進行定義。數(shù)據(jù)中心網(wǎng)絡(luò)環(huán)境一般滿足如下條件：
[0007] a)服務(wù)器具有高性能CPU和較大的內(nèi)存；
[0008] b)具備高性能網(wǎng)卡，以及適當?shù)牟僮飨到y(tǒng)；
[0009] c)千兆以太網(wǎng)（或10Gb/sec)，由一臺交換機或者其他拓撲結(jié)構(gòu)構(gòu)成數(shù)據(jù)中心網(wǎng) 路，更多交換機可能會帶來好處，但是定義上沒有特別的限制。
[0010] d)存在大量一對一，多對一及一對多通信模式。此類傳輸模式存在于集群存儲以 及Hadoop等其他許多數(shù)據(jù)密集型分布式應用中。
[0011] 在簡單的帶寬環(huán)境下，比如使用scp將五臺機器上的數(shù)據(jù)復制到一個目的主機， 每個源機器能夠輸出900Mbps以上。如果每個發(fā)送者都以900Mbps的速度向接收端發(fā)送數(shù) 據(jù)，IG以太網(wǎng)交換機不久將只能丟棄部分數(shù)據(jù)包。
[0012] 但這種情形很容易理解：所有的機器不能同時發(fā)送900Mbps以上的數(shù)據(jù)，因為接 收端有帶寬上限，交換機必將丟棄一些數(shù)據(jù)包，然后每個TCP連接將降低發(fā)包速率。最終， 每個發(fā)送者將達到大約發(fā)送200Mbps的穩(wěn)態(tài)從而填滿瓶頸鏈接。
[0013] 事實上我們會遇到更困難的帶寬問題，如果有較大的群集，會出現(xiàn)大量服務(wù)器同 時向一個服務(wù)器傳輸數(shù)據(jù)的情況，則可能有發(fā)送到單個集群成員的流量"微爆"。交換機不 能緩沖所有的"微爆幀"，故有部分幀會被丟掉，下面的數(shù)據(jù)展示了"微爆"所導致的短時隙 內(nèi)的吞吐量崩潰。然后，TCP的擁塞控制機制開始干預，處理丟包和超時事件，減緩窗口增 長甚至減少窗口。
[0014] "Incast"是一種通信模式，在數(shù)據(jù)中心網(wǎng)絡(luò)環(huán)境下，它主要由TCP協(xié)議的擁塞控 制算法的特點引起。圖5所示為典型的TCP Incast傳輸模式場景。在這種模式中，客戶端 通過一交換機連接到數(shù)據(jù)中心的多臺服務(wù)器?？蛻舳税l(fā)出請求，數(shù)據(jù)從一個或多個服務(wù)器 通過交換機以many-to-one的方式通過瓶頸鏈路傳輸?shù)娇蛻舳?。客戶端以較大的邏輯塊 (如1MB)請求數(shù)據(jù)，而實際的數(shù)據(jù)塊則以較小的數(shù)據(jù)塊（如32KB)形式存儲在多服務(wù)器中， 稱為服務(wù)器的請求單元（SRU)。每一輪傳輸中，客戶端向所有存儲有被請求數(shù)據(jù)的服務(wù)器發(fā) 送數(shù)據(jù)請求，當所有服務(wù)器的數(shù)據(jù)均成功接收（即被請求數(shù)據(jù)塊成功傳輸）時，才進行下一 次數(shù)據(jù)塊請求。
[0015] 嚴格地定義Incast現(xiàn)象需要滿足如下三個條件：
[0016] 1.網(wǎng)絡(luò)環(huán)境：高帶寬（千兆網(wǎng)）低延遲及較小的交換機緩存
[0017] 2.同步塊傳輸模式，即每輪傳輸一個數(shù)據(jù)塊，所有數(shù)據(jù)塊收到后才進入下一輪傳 輸
[0018] 3.較小的數(shù)據(jù)塊；（最大256K，一塊數(shù)據(jù)在千兆網(wǎng)環(huán)境下在2毫內(nèi)秒可傳輸完畢）
[0019] 隨著并發(fā)發(fā)送者數(shù)量的增加，數(shù)據(jù)傳輸量可能超出交換機緩存大小，導致數(shù)據(jù)包 丟失，以及隨之而來的的超時重傳。從而可能導致吞吐量崩潰（急劇降低），如圖6所示，我 們稱之為TCP Incast現(xiàn)象。
[0020] TCP Incast問題可能出現(xiàn)在許多典型的數(shù)據(jù)中心應用當中。例如，在集群存儲系 統(tǒng)中，在存儲節(jié)點對數(shù)據(jù)的請求作出回應時；在網(wǎng)絡(luò)搜索過程中，許多工作機幾乎同時響應 搜索查詢；或在MapReduce批量處理作業(yè)的過程中，"shuffle"階段多個Mapper將中間數(shù) 據(jù)傳輸給Reducer時。由于存在范圍廣泛，對網(wǎng)絡(luò)效能影響惡劣，TCP Incast問題已經(jīng)引 起了許多研究人員的注意。研究人員在多層面提出了各種可能的解決方案，主要包括鏈路 層，傳輸層和應用層解決方案。這些方案中，部分具有較高的效率，但成本亦高，部分方案代 價低，但收效甚微。

【發(fā)明內(nèi)容】

[0021] 本發(fā)明旨在至少解決上述技術(shù)問題之一。
[0022] 為此，本發(fā)明的一個目的在于提出一種基于FAST TCP的傳輸控制方法。
[0023] 為了實現(xiàn)上述目的，本發(fā)明的第一方面的實施例公開了一種基于FAST TCP的傳輸 控制方法，包括：數(shù)據(jù)控制模塊，所述數(shù)據(jù)控制模塊用于控制傳輸數(shù)據(jù)包；窗口控制模塊， 所述窗口控制模塊用于控制發(fā)送端的數(shù)據(jù)包的傳輸數(shù)量；以及估計模塊，所述估計模塊用 于根據(jù)發(fā)送端的數(shù)據(jù)包發(fā)送頻率、傳輸鏈路的帶寬、交換機的緩存容量、所述交換機的延時 隊列中數(shù)據(jù)包的平均延時計算擁塞避免閾值；所述方法包括以下步驟：Sl :獲取所述擁塞 避免閾值和所述客戶端當前數(shù)據(jù)包的傳輸數(shù)量；S2 :將所述客戶端所述當前數(shù)據(jù)包的傳輸 數(shù)量和所述擁塞避免閾值進行比較，如果所述客戶端當前數(shù)據(jù)包的傳輸數(shù)量不小于所述 擁塞避免閾值，所述估計模塊向所述窗口控制模塊發(fā)送擁塞反饋信息，所述窗口控制模塊 根據(jù)所述擁塞反饋信息減少數(shù)據(jù)包的傳輸數(shù)量以避免丟包。
[0024] 根據(jù)本發(fā)明實施例的基于FAST TCP的傳輸控制方法，可以通過監(jiān)控網(wǎng)絡(luò)傳輸規(guī) 模，針對不同的規(guī)模進行參數(shù)調(diào)整，達到在不同規(guī)模下的自適應，始終保證高吞吐量和穩(wěn)定 的傳輸性能。
[0025] 另外，根據(jù)本發(fā)明上述實施例的基于FAST TCP的傳輸控制方法，還可以具有如下 附加的技術(shù)特征：
[0026] 進一步地，所述擁塞避免閾值的計算公式如下：
[0028] 其中，w為所述發(fā)送端的所述當前數(shù)據(jù)包的傳輸數(shù)量，γ e (〇, 1]，baseRTT為所 述交換機延時隊列中數(shù)據(jù)包的最小RTT，qdelay是點對點的平均隊列延遲，α為修正系數(shù)，
9
[0030] 其中，q為隊列延時，α。、α η q#均為常數(shù)。
[0031] 本發(fā)明的附加方面和優(yōu)點將在下面的描述中部分給出，部分將從下面的描述中變 得明顯，或通過本發(fā)明的實踐了解到。
【附圖說明】
[0032] 本發(fā)明的上述和/或附加的方面和優(yōu)點從結(jié)合下面附圖對實施例的描述中將變 得明顯和容易理解，其中：
[0033] 圖1是現(xiàn)有技術(shù)中交換機拓撲結(jié)構(gòu)示意圖；
[0034] 圖2是現(xiàn)有技術(shù)中的Clos拓撲結(jié)構(gòu)示意圖；
[0035] 圖3是現(xiàn)有技術(shù)中的胖樹拓撲結(jié)構(gòu)示意圖；
[0036] 圖4是現(xiàn)有技術(shù)中的虛擬數(shù)據(jù)中心及數(shù)據(jù)中心網(wǎng)絡(luò)示意圖；
[0037] 圖5是現(xiàn)有技術(shù)中的TCP Incast傳輸模式示意圖；
[0038] 圖6是現(xiàn)有技術(shù)中的TCP Incast的示意圖；
[0039] 圖7是本發(fā)明一個實施例的流程圖。
【具體實施方式】
[0040] 下面詳細描述本發(fā)明的實施例，所述實施例的示例在附圖中示出，其中自始至終 相同或類似的標號表示相同或類似的元件或具有相同或類似功能的元件。下面通過參考附 圖描述的實施例是示例性的，僅用于解釋本發(fā)明，而不能理解為對本發(fā)明的限制。
[0041] 在本發(fā)明的描述中，需要理解的是，術(shù)語"中心"、"縱向"、"橫向"、"上"、"下"、"前"、 "后"、"左"、"右"、"豎直"、"水平"、"頂"、"底"、"內(nèi)"、"外"等指示的方位或位置關(guān)系為基于 附圖所示的方位或位置關(guān)系，僅是為了便于描述本發(fā)明和簡化描述，而不是指示或暗示所 指的裝置或元件必須具有特定的方位、以特定的方位構(gòu)造和操作，因此不能理解為對本發(fā) 明的限制。此外，術(shù)語"第一"、"第二"僅用于描述目的，而不能理解為指示或暗示相對重要 性。
[0042] 在本發(fā)明的描述中，需要說明的是，除非另有明確的規(guī)定和限定，術(shù)語"安裝"、"相 連"、"連接"應做廣義理解，例如，可以是固定連接，也可以是可拆卸連接，或一體地連接；可 以是機械連接，也可以是電連接；可以是直接相連，也可以通過中間媒介間接相連，可以是 兩個元件內(nèi)部的連通。對于本領(lǐng)域的普通技術(shù)人員而言，可以具體情況理解上述術(shù)語在本 發(fā)明中的具體含義。
[0043] 參照下面的描述和附圖，將清楚本發(fā)明的實施例的這些和其他方面。在這些描述 和附圖中，具體公開了本發(fā)明的實施例中的一些特定實施方式，來表示實施本發(fā)明的實施 例的原理的一些方式，但是應當理解，本發(fā)明的實施例的范圍不受此限制。相反，本發(fā)明的 實施例包括落入所附加權(quán)利要求書的精神和內(nèi)涵范圍內(nèi)的所有變化、修改和等同物。
[0044] 以下結(jié)合附圖描述根據(jù)本發(fā)明實施例的基于FAST TCP的傳輸控制方法。
[0045] C-FAST協(xié)議通過檢測隊列延遲調(diào)整擁塞窗口，以維持穩(wěn)定隊列長度；我們認為0 隊列長度是危險的，因為有隊列存在證明瓶頸鏈接是被占滿的，而0隊列長度的情況下，我 們無法判斷瓶頸鏈接是否被充分使用；同時，在數(shù)據(jù)中心中，RTT的尺度已經(jīng)很小，隊列延 遲則更小，我們選擇直接基于隊列延遲，并維持>〇穩(wěn)定隊列長度的FAST協(xié)議的擁塞避免策 略作為解決問題的基礎(chǔ)。