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

【發明內容】

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