SSRC：時(shí)延敏感流的數(shù)據(jù)源端速率控制算法

楊洋，曹敏，楊家海，車(chē)嶸，劉偉

（1. 國(guó)防科技大學(xué)信息通信學(xué)院，陜西 西安 710106；2. 清華大學(xué)網(wǎng)絡(luò)科學(xué)與網(wǎng)絡(luò)空間研究院，北京 100084；3. 清華信息科學(xué)與技術(shù)國(guó)家實(shí)驗(yàn)室（籌），北京 100084）

1 引言

當(dāng)前，數(shù)據(jù)中心95%以上的數(shù)據(jù)流都是TCP流[1]，隨著業(yè)務(wù)種類(lèi)急劇增長(zhǎng)，流量的多樣性越來(lái)越突出。這些流量可以分為2類(lèi)：一類(lèi)是吞吐量敏感型的流量，例如，大量云計(jì)算業(yè)務(wù)由于虛擬機(jī)遷移、數(shù)據(jù)備份等操作產(chǎn)生的長(zhǎng)流；另一類(lèi)是時(shí)延敏感型的流量，例如，Web請(qǐng)求（包括搜索流量）業(yè)務(wù)、基于MapReduce[2]的并行計(jì)算業(yè)務(wù)以及社交網(wǎng)絡(luò)等在線(xiàn)業(yè)務(wù)產(chǎn)生的短流。數(shù)據(jù)中心為業(yè)務(wù)提供高可用聚合帶寬保證的同時(shí)，網(wǎng)絡(luò)擁塞也頻繁發(fā)生，同時(shí)網(wǎng)絡(luò)中出現(xiàn)的Incast現(xiàn)象逐漸成為數(shù)據(jù)中心區(qū)別于傳統(tǒng)互聯(lián)網(wǎng)的標(biāo)志性事件。由于當(dāng)前數(shù)據(jù)中心產(chǎn)生的短流類(lèi)型業(yè)務(wù)大部分是有流傳輸截止時(shí)間要求的業(yè)務(wù)，一旦傳輸路徑中出現(xiàn)鏈路擁塞，就會(huì)導(dǎo)致傳輸超時(shí)并嚴(yán)重影響用戶(hù)體驗(yàn)。由于TCP長(zhǎng)流的“貪婪性”會(huì)導(dǎo)致交換機(jī)緩存中數(shù)據(jù)分組排隊(duì)隊(duì)列增長(zhǎng)，直到緩存溢出產(chǎn)生分組丟失。如果鏈路中長(zhǎng)短流共存，會(huì)導(dǎo)致2種情況發(fā)生：一種是短流分組丟失導(dǎo)致Incast出現(xiàn)；另一種是雖然短流分組不丟失，但由于在緩存中排隊(duì)的短流數(shù)據(jù)分組轉(zhuǎn)發(fā)優(yōu)先權(quán)低于長(zhǎng)流數(shù)據(jù)分組，導(dǎo)致短流數(shù)據(jù)排隊(duì)時(shí)間超出流傳輸截止時(shí)間。由于數(shù)據(jù)中心短流具有突發(fā)、不可預(yù)測(cè)特性，網(wǎng)絡(luò)中任何一條傳輸鏈路都有可能存在因鏈路擁塞而產(chǎn)生的長(zhǎng)短流碰撞，導(dǎo)致出現(xiàn)短流分組丟失的可能性。因此，為保證數(shù)據(jù)中心時(shí)延敏感流的傳輸時(shí)間，有必要在數(shù)據(jù)源端對(duì)引起交換機(jī)緩存隊(duì)列長(zhǎng)度超過(guò)閾值的長(zhǎng)流進(jìn)行速率調(diào)節(jié)，以避免鏈路中長(zhǎng)短流碰撞而導(dǎo)致短流分組丟失。

當(dāng)前數(shù)據(jù)中心產(chǎn)生短流類(lèi)型的業(yè)務(wù)大部分是有流傳輸截止時(shí)間要求的業(yè)務(wù)，例如，Web請(qǐng)求類(lèi)業(yè)務(wù)、基于MapReduce并行計(jì)算業(yè)務(wù)等，一旦傳輸路徑中出現(xiàn)鏈路擁塞，就會(huì)導(dǎo)致傳輸超時(shí)并嚴(yán)重影響用戶(hù)體驗(yàn)。另外，由于網(wǎng)絡(luò)中存在大量采用分割/匯聚（partition/aggregate）技術(shù)的業(yè)務(wù)，例如，MapReduce以及搜索請(qǐng)求業(yè)務(wù)等，這種“多對(duì)一”的通信方式帶來(lái)的TCP Incast問(wèn)題也越來(lái)越突出[3]。由于 Incast問(wèn)題通常是由承載匯聚信息的短流分組丟失引起的，因此，Incast問(wèn)題的解決可以轉(zhuǎn)化為針對(duì)時(shí)延敏感的短流進(jìn)行避免傳輸鏈路擁塞的研究[4-6]。當(dāng)前針對(duì)數(shù)據(jù)中心時(shí)延敏感流量進(jìn)行數(shù)據(jù)源端速率控制的研究工作可以分為以下2類(lèi)。

1) 終端設(shè)備解決算法

終端設(shè)備的解決算法是指在數(shù)據(jù)發(fā)送端通過(guò)調(diào)整發(fā)送窗口值的大小來(lái)控制發(fā)送速率的算法。例如，TCP Newreno是對(duì)TCP的改進(jìn)版本，通過(guò)引入快速恢復(fù)機(jī)制避免了快速重傳之后馬上進(jìn)入慢啟動(dòng)階段而導(dǎo)致發(fā)送窗口減小過(guò)大的問(wèn)題，是當(dāng)前網(wǎng)絡(luò)通信普遍采用的協(xié)議。文獻(xiàn)[7]通過(guò)將最小超時(shí)重傳時(shí)間RTOmin（retransmission time out）減小到微秒級(jí)，緩解由于產(chǎn)生Incast問(wèn)題而造成的吞吐量下降。另一類(lèi)算法是設(shè)計(jì)改進(jìn)的TCP，例如，D2TCP[8]通過(guò)提前獲取數(shù)據(jù)流傳輸?shù)慕刂箷r(shí)間，并根據(jù)流截止時(shí)間作為調(diào)整擁塞窗口的懲罰因子，計(jì)算擁塞窗口大小，達(dá)到通過(guò)控制數(shù)據(jù)流傳輸速率來(lái)消除擁塞的目的。ICTCP[9]以接收端實(shí)際測(cè)量吞吐量與期望吞吐量之間的差值比率是否超過(guò)某個(gè)閾值，作為調(diào)整接收窗口大小的依據(jù)，并將調(diào)整的窗口信息以ACK信號(hào)反饋給發(fā)送端，達(dá)到控制數(shù)據(jù)流速率的目的，從而避免鏈路擁塞導(dǎo)致的短流分組丟失。文獻(xiàn)[10]提出 MMPTCP（maximum multi-path TCP），在終端設(shè)置數(shù)據(jù)流傳輸閾值，數(shù)據(jù)流傳輸初始階段是基于分組粒度的多路徑負(fù)載均衡，使時(shí)延敏感型的數(shù)據(jù)流受益；當(dāng)傳輸數(shù)據(jù)量超過(guò)閾值時(shí)，進(jìn)入第二階段，即由基于數(shù)據(jù)分組粒度的多路徑負(fù)載均衡方式切換到 MPTCP（multi-path TCP）[11]模式，有效地保證長(zhǎng)流吞吐量。文獻(xiàn)[3]則提出了應(yīng)用層的解決算法，以一定的隨機(jī)概率刻意延遲服務(wù)器對(duì)請(qǐng)求的響應(yīng)，從而在某個(gè)時(shí)間段減少同時(shí)參與請(qǐng)求響應(yīng)的服務(wù)器數(shù)量，解決Incast的同步屏障問(wèn)題。

2) 交換設(shè)備支持的解決算法

交換設(shè)備支持的解決算法是指由交換機(jī)（或路由器）與終端主機(jī)共同解決擁塞避免的算法。例如，DCTCP（data center TCP）[1]基于 ECN（explicit congestion notification）[12]的功能，通過(guò)設(shè)置交換機(jī)緩存隊(duì)列長(zhǎng)度閾值，對(duì)超過(guò)閾值的數(shù)據(jù)分組進(jìn)行標(biāo)記，數(shù)據(jù)源端則根據(jù)反饋的擁塞程度信息按照一定的衰減因子動(dòng)態(tài)調(diào)整發(fā)送窗口，被標(biāo)記的分組數(shù)量越多、衰減因子越大，發(fā)送窗口就越小，從而始終保證交換機(jī)隊(duì)列長(zhǎng)度低于某個(gè)閾值，防止由于緩存溢出而丟棄數(shù)據(jù)分組。D3[13]則采用帶寬資源預(yù)留的方式，提前為數(shù)據(jù)流分配所需傳輸帶寬。數(shù)據(jù)源端首先獲取數(shù)據(jù)流截止時(shí)間以及流大小信息，在每一輪 RTT（round trip time）周期內(nèi)發(fā)送相關(guān)傳輸數(shù)據(jù)的帶寬需求信息，交換機(jī)收到該信息后計(jì)算出預(yù)留帶寬并將預(yù)留帶寬值寫(xiě)入數(shù)據(jù)分組頭。數(shù)據(jù)分組傳輸路徑上的所有交換機(jī)將執(zhí)行相同的操作，從而保證數(shù)據(jù)流在截止時(shí)間內(nèi)傳輸完畢。另外還有通過(guò)交換機(jī)向數(shù)據(jù)源端發(fā)送“暫停”幀實(shí)現(xiàn)流控的EFC（ethernet flow control）[14]機(jī)制以及基于IEEE 802.1Qau以太網(wǎng)標(biāo)準(zhǔn)提出的鏈路層擁塞控制算法 QCN（quantized congestion notification）[15]。

盡管當(dāng)前的研究算法對(duì)于避免數(shù)據(jù)中心出現(xiàn)擁塞鏈路而導(dǎo)致短流分組丟失，以及針對(duì)Incast問(wèn)題的解決都起到了積極的作用，然而在實(shí)際部署的可擴(kuò)展性、實(shí)施開(kāi)銷(xiāo)以及時(shí)效性方面都存在不足。其中，終端設(shè)備的解決算法對(duì)于TCP的改進(jìn)方法需要接入終端設(shè)備修改協(xié)議棧，實(shí)施難度高，可擴(kuò)展性不強(qiáng)。例如，D2TCP 、ICTCP、MMPTCP都需要在終端進(jìn)行閾值的設(shè)定以及相應(yīng)的判斷、計(jì)算操作，D2TCP還需要提前獲取數(shù)據(jù)流截止時(shí)間等信息；對(duì)TCP參數(shù)進(jìn)行調(diào)整實(shí)施難度雖然低，但是需要其他機(jī)制配合，否則效果不理想。例如，減小RTOmin雖然可以提升吞吐量，但也會(huì)導(dǎo)致欺騙性重傳。交換設(shè)備參與解決的算法需要設(shè)備的硬件支持，例如，DCTCP需要在交換機(jī)緩沖區(qū)的隊(duì)列長(zhǎng)度達(dá)到閾值時(shí)對(duì)數(shù)據(jù)分組進(jìn)行標(biāo)記；D3則需要交換機(jī)根據(jù)數(shù)據(jù)源端的帶寬需求信息計(jì)算出預(yù)留帶寬，并要求傳輸路徑上的所有交換機(jī)對(duì)這條數(shù)據(jù)流執(zhí)行相同的操作；EFC和QCN都需要特定的交換機(jī)支持。交換設(shè)備參與的解決算法對(duì)設(shè)備硬件要求高，部署開(kāi)銷(xiāo)較大，尤其對(duì)于數(shù)據(jù)中心大多使用低成本的商用交換機(jī)的情況，更不適合大規(guī)模的部署。另外，基于TCP連接的反饋回路調(diào)節(jié)源端速率的算法還存在時(shí)效性不強(qiáng)的問(wèn)題，例如，當(dāng)反饋回路出現(xiàn)鏈路擁塞或者發(fā)生故障時(shí)，將影響算法執(zhí)行的效率。

綜上所述，本文基于SDN/OpenFlow的架構(gòu)，提出了數(shù)據(jù)源端控制算法SSRC（SDN-based source rate control）。SSRC依據(jù)網(wǎng)絡(luò)的全局視圖，能夠快速定位可能發(fā)生擁塞的節(jié)點(diǎn)，并及時(shí)對(duì)目標(biāo)流的源端速率進(jìn)行調(diào)節(jié)，縮短算法的響應(yīng)時(shí)間。本文的主要貢獻(xiàn)如下。

1) 利用SDN的架構(gòu)設(shè)計(jì)能夠?qū)︽溌分谐霈F(xiàn)的長(zhǎng)流以及交換機(jī)緩存的隊(duì)列長(zhǎng)度進(jìn)行監(jiān)測(cè)，快速定位擁塞可能出現(xiàn)的位置，并確認(rèn)需要進(jìn)行源端速率調(diào)節(jié)的目標(biāo)長(zhǎng)流。

2) 控制器利用目標(biāo)長(zhǎng)流建立反饋回路，修改攜帶接收窗口大小的TCP_ACK數(shù)據(jù)分組，并直接將該數(shù)據(jù)分組推送到連接數(shù)據(jù)源端的接入層交換機(jī)，極大地縮短了算法機(jī)制的響應(yīng)時(shí)間，提高了算法的時(shí)效性。

3) 通過(guò)將NS3網(wǎng)絡(luò)仿真工具與FloodLight外部控制器相結(jié)合，形成基于 SDN架構(gòu)的網(wǎng)絡(luò)仿真平臺(tái)，仿真實(shí)驗(yàn)結(jié)果證明SSRC能夠保證時(shí)延敏感流的傳輸時(shí)間，同時(shí)能夠很好地解決Incast問(wèn)題。

2 算法設(shè)計(jì)關(guān)鍵問(wèn)題分析

TCP長(zhǎng)流的“貪婪性”會(huì)導(dǎo)致交換機(jī)緩存中數(shù)據(jù)分組排隊(duì)隊(duì)列增長(zhǎng)，直到緩存溢出產(chǎn)生分組丟失。如果鏈路中長(zhǎng)短流共存，會(huì)導(dǎo)致2種情況發(fā)生：一種是短流分組丟失導(dǎo)致Incast出現(xiàn)；另一種是雖然短流分組不丟失，但由于緩存中排隊(duì)的短流數(shù)據(jù)分組轉(zhuǎn)發(fā)優(yōu)先權(quán)低于長(zhǎng)流的數(shù)據(jù)分組，導(dǎo)致排隊(duì)時(shí)間超出流傳輸截止時(shí)間。當(dāng)前在集群化存儲(chǔ)的系統(tǒng)內(nèi)，客戶(hù)端的應(yīng)用請(qǐng)求都以服務(wù)請(qǐng)求數(shù)據(jù)單元（SRU, service request unit）方式分別存儲(chǔ)在服務(wù)器上，只有當(dāng)客戶(hù)端收到所有服務(wù)器的 SRU后，才能繼續(xù)下一個(gè)服務(wù)請(qǐng)求。然而在鏈路出現(xiàn)擁塞造成排隊(duì)隊(duì)列處理時(shí)延增大甚至導(dǎo)致短流分組丟失嚴(yán)重時(shí)，會(huì)使完成一個(gè)TCP應(yīng)用請(qǐng)求至少經(jīng)歷200 ms的超時(shí)[16]。對(duì)于時(shí)延敏感的業(yè)務(wù)，將嚴(yán)重影響用戶(hù)體驗(yàn)；對(duì)于MapReduce之類(lèi)的并行計(jì)算業(yè)務(wù)，將嚴(yán)重浪費(fèi)計(jì)算資源。所以，時(shí)延敏感的短流受鏈路擁塞影響最大，其根本原因是交換機(jī)緩存隊(duì)列的積壓導(dǎo)致鏈路中出現(xiàn)的長(zhǎng)流與時(shí)延敏感的短流出現(xiàn)碰撞，造成短流分組丟失。

D2TCP和D3都是針對(duì)時(shí)延敏感的短流提出的解決算法，但是兩者都需要提前獲取數(shù)據(jù)流的截止時(shí)間，然而實(shí)際中這樣的信息可能無(wú)法提前獲取。ICTCP主要解決Incast問(wèn)題，但只是針對(duì)最后一跳的鏈路提出的解決算法，沒(méi)有考慮承載 SRU的短流分組丟失發(fā)生在中間交換節(jié)點(diǎn)的情況，并且通過(guò)接收端窗口大小來(lái)控制源端發(fā)送速率需要通過(guò)ACK將窗口信息反饋回發(fā)送端，如果反饋回路擁塞或者發(fā)生故障則嚴(yán)重影響算法的執(zhí)行效率。DCTCP通過(guò)設(shè)定交換機(jī)隊(duì)列長(zhǎng)度閾值的方式并基于 ECN將擁塞程度信息反饋回發(fā)送端，這樣的算法除了對(duì)交換設(shè)備要求高之外，也存在反饋回路影響算法執(zhí)行效率的問(wèn)題。

綜上所述，本文提出基于SDN/OpenFlow框架的解決算法，能夠克服現(xiàn)有算法存在的不足。由于SDN具有集中化管控的優(yōu)勢(shì)，控制器擁有全局的網(wǎng)絡(luò)資源視圖，因此更容易提前發(fā)現(xiàn)可能出現(xiàn)擁塞的節(jié)點(diǎn)，通過(guò)控制器下發(fā)策略避免擁塞；其次，當(dāng)發(fā)現(xiàn)可能的擁塞節(jié)點(diǎn)后，控制器能快速進(jìn)行響應(yīng)，相對(duì)于傳統(tǒng)網(wǎng)絡(luò)中接收端通過(guò)反饋回路進(jìn)行數(shù)據(jù)源端速率調(diào)節(jié)的算法，能夠極大地縮短響應(yīng)時(shí)間，提高算法的時(shí)效性。本文提出的基于 SDN/OpenFlow的數(shù)據(jù)源端速率控制算法需要解決2個(gè)關(guān)鍵問(wèn)題：一是設(shè)計(jì)算法的觸發(fā)機(jī)制，二是需要獲取數(shù)據(jù)源端優(yōu)化后的目標(biāo)發(fā)送速率。

3 算法設(shè)計(jì)

3.1 算法觸發(fā)機(jī)制

由于交換機(jī)緩存隊(duì)列積壓而出現(xiàn)長(zhǎng)短流碰撞是導(dǎo)致短流分組丟失的根本原因。同時(shí)，必須注意到分組丟失發(fā)生的位置除了包含最后一跳網(wǎng)絡(luò)節(jié)點(diǎn)設(shè)備外，網(wǎng)絡(luò)中間設(shè)備都有可能由于交換設(shè)備的緩存溢出而導(dǎo)致分組丟失。因此，算法設(shè)計(jì)的目標(biāo)是能夠通過(guò)全局網(wǎng)絡(luò)視圖，提前發(fā)現(xiàn)有可能出現(xiàn)擁塞的網(wǎng)絡(luò)節(jié)點(diǎn)，通過(guò)觸發(fā)算法避免鏈路由于TCP長(zhǎng)流的“貪婪性”造成交換機(jī)排隊(duì)隊(duì)列長(zhǎng)度增加從而導(dǎo)致短流分組丟失。因此，算法的觸發(fā)機(jī)制由2個(gè)關(guān)鍵條件決定：一是鏈路中出現(xiàn)長(zhǎng)流，二是出現(xiàn)長(zhǎng)流的交換設(shè)備中的隊(duì)列長(zhǎng)度超過(guò)閾值。當(dāng)2個(gè)條件同時(shí)滿(mǎn)足時(shí)算法被觸發(fā)，這樣設(shè)計(jì)的目的是，針對(duì)鏈路中容易引起短流分組丟失的目標(biāo)長(zhǎng)流，快速進(jìn)行擁塞避免策略響應(yīng)，增強(qiáng)算法執(zhí)行的時(shí)效性。

1) 長(zhǎng)流的發(fā)現(xiàn)

當(dāng)前OpenFlow的版本都支持2種方式統(tǒng)計(jì)數(shù)據(jù)流信息[17]：一種是基于控制器發(fā)送Read_State消息，對(duì)交換機(jī)狀態(tài)信息采用輪詢(xún)的方式統(tǒng)計(jì)；另一種由交換機(jī)發(fā)送異步消息對(duì)控制器進(jìn)行數(shù)據(jù)流信息的推送。由于交換機(jī)推送數(shù)據(jù)流信息的方式是當(dāng)該流傳輸結(jié)束或者流表刪除時(shí)向控制器推送消息，并不適合對(duì)長(zhǎng)流的探測(cè)，因此本文采用的方法是控制器以周期輪詢(xún)的方式獲取交換機(jī)相關(guān)數(shù)據(jù)流信息，并以此發(fā)現(xiàn)長(zhǎng)流。采用輪詢(xún)的方式探測(cè)長(zhǎng)流屬于OpenFlow自帶的原生測(cè)量，不會(huì)產(chǎn)生額外的探測(cè)開(kāi)銷(xiāo)，但需要注意的是輪詢(xún)周期不能設(shè)置過(guò)小，否則會(huì)加重控制器與交換機(jī)之間的通信負(fù)擔(dān)。通過(guò)對(duì)比實(shí)驗(yàn)，在保證能夠探測(cè)到目標(biāo)長(zhǎng)流的前提下，將控制器輪詢(xún)周期設(shè)置為5 s。

2) 隊(duì)列長(zhǎng)度閾值

設(shè)置交換機(jī)緩存隊(duì)列長(zhǎng)度閾值Kt，如式(1)所示。

其中，C代表瓶頸鏈路帶寬，單位為 packet/s，即每秒傳輸數(shù)據(jù)分組的數(shù)量；RTT代表往返時(shí)延，單位為 s。在數(shù)據(jù)中心實(shí)際環(huán)境中，考慮到流量的突發(fā)特性，Kt往往不能取下限值，通常當(dāng)鏈路帶寬為1 Gbit/s時(shí)，設(shè)置Kt= 20；當(dāng)鏈路帶寬為10 Gbit/s時(shí)，設(shè)置Kt=65。

3.2 算法優(yōu)化問(wèn)題

當(dāng)算法觸發(fā)時(shí)，控制器需要計(jì)算出合理的數(shù)據(jù)源端發(fā)送速率，而發(fā)送速率值是由數(shù)據(jù)源端的發(fā)送窗口大小決定的。以往的研究工作中，對(duì)于數(shù)據(jù)源端發(fā)送窗口大小的反饋調(diào)節(jié)機(jī)制大部分都是基于一個(gè)前提條件，即N個(gè)數(shù)據(jù)源端發(fā)送的響應(yīng)請(qǐng)求數(shù)據(jù)分組同時(shí)到達(dá)接收節(jié)點(diǎn)。通過(guò)獲取并發(fā)窗口數(shù)從而計(jì)算出交換機(jī)緩存隊(duì)列的長(zhǎng)度或者瓶頸鏈路中剩余帶寬的大小，作為調(diào)整數(shù)據(jù)源端發(fā)送速率大小的關(guān)鍵參數(shù)。然而在實(shí)際環(huán)境中，由于中間節(jié)點(diǎn)排隊(duì)時(shí)延以及傳輸路徑的差異，N個(gè)數(shù)據(jù)源端發(fā)送的請(qǐng)求數(shù)據(jù)分組同時(shí)到達(dá)最后一跳節(jié)點(diǎn)的概率非常小，以此為計(jì)算基礎(chǔ)所帶來(lái)的誤差不可避免。因此，本文采用的方法是基于排隊(duì)論對(duì)數(shù)據(jù)流的到達(dá)行為進(jìn)行建模，從而設(shè)計(jì)更為合理的發(fā)送窗口調(diào)節(jié)機(jī)制。

3.2.1 數(shù)學(xué)模型

目前，數(shù)據(jù)流到達(dá)行為的研究主要針對(duì) TCP流，所采用的研究方法主要分為2種：一種是基于長(zhǎng)時(shí)間粒度統(tǒng)計(jì)發(fā)現(xiàn) TCP流具有自相似[18]或者長(zhǎng)相關(guān)的特性[19]，對(duì)此特性進(jìn)行具體研究；另一種是根據(jù)排隊(duì)論的相關(guān)理論進(jìn)行研究，例如文獻(xiàn)[20]通過(guò)實(shí)際測(cè)量和仿真分析指出在鏈路帶寬足夠的情況下，數(shù)據(jù)流的到達(dá)行為服從泊松分布。由于數(shù)據(jù)中心鏈路具有高帶寬、低時(shí)延特性，因此更適合采用排隊(duì)論對(duì)數(shù)據(jù)流的到達(dá)行為進(jìn)行數(shù)學(xué)建模并分析[21]。

文獻(xiàn)[1]指出，當(dāng)前數(shù)據(jù)中心普遍使用淺緩存的商用以太網(wǎng)交換機(jī)，此類(lèi)交換機(jī)的特點(diǎn)是采用共享緩存交換結(jié)構(gòu)。共享緩存結(jié)構(gòu)是指交換機(jī)所有的輸出和輸入端口都共享一個(gè)緩存池，并且所有經(jīng)過(guò)交換機(jī)轉(zhuǎn)發(fā)的數(shù)據(jù)分組都需要在緩存中存儲(chǔ)轉(zhuǎn)發(fā)，那么一臺(tái)交換機(jī)就可以抽象成一個(gè)服務(wù)窗口，此外，可以認(rèn)為交換機(jī)對(duì)數(shù)據(jù)流的轉(zhuǎn)發(fā)即對(duì)數(shù)據(jù)流的服務(wù)時(shí)間服從指數(shù)分布。由于算法被觸發(fā)時(shí)，控制器需要立即響應(yīng)，因此需要對(duì)源端發(fā)送速率進(jìn)行調(diào)整，假設(shè)t時(shí)刻算法執(zhí)行時(shí)需要數(shù)據(jù)源端減小數(shù)據(jù)分組進(jìn)入系統(tǒng)的概率，那么數(shù)據(jù)流的到達(dá)率就不再是穩(wěn)定值，而是依賴(lài)t時(shí)刻緩存隊(duì)列長(zhǎng)度k的函數(shù)，因此可以采用基于可變到達(dá)率的G/M/1/∞排隊(duì)模型進(jìn)行建模分析[22]，圖1描述了具有可變到達(dá)率的數(shù)據(jù)流生滅過(guò)程。

圖1 可變到達(dá)率的數(shù)據(jù)流生滅過(guò)程

以圖1為例，假設(shè)緩存隊(duì)列長(zhǎng)度為k（k≥1），數(shù)據(jù)流以的概率進(jìn)入排隊(duì)系統(tǒng)，λ為到達(dá)率，μ為交換機(jī)服務(wù)速率。可以得到該生滅過(guò)程穩(wěn)態(tài)下的數(shù)據(jù)流到達(dá)概率分布函數(shù)，如式(2)所示。

其中，Pk為t時(shí)刻隊(duì)列長(zhǎng)度處于k狀態(tài)的概率分布，ρ為數(shù)據(jù)流的排隊(duì)強(qiáng)度。

3.2.2 優(yōu)化問(wèn)題

當(dāng)t時(shí)刻算法觸發(fā)時(shí)，交換機(jī)緩存中隊(duì)列長(zhǎng)度超過(guò)設(shè)定閾值，控制器需要計(jì)算出數(shù)據(jù)源端合適的發(fā)送窗口大小以防止緩存溢出。此時(shí)，t時(shí)刻超出閾值部分的隊(duì)列長(zhǎng)度為

其中，Q(t)為t時(shí)刻交換機(jī)緩存隊(duì)列長(zhǎng)度；Kt為所設(shè)隊(duì)列長(zhǎng)度閾值；[?]+表示正值，保證優(yōu)化問(wèn)題有意義。那么優(yōu)化問(wèn)題就是使式(3)的隊(duì)列長(zhǎng)度差值G(t)最小，優(yōu)化問(wèn)題的目標(biāo)函數(shù)為

排隊(duì)系統(tǒng)進(jìn)入穩(wěn)定的工作狀態(tài)時(shí)與時(shí)刻t無(wú)關(guān)，因此式(4)優(yōu)化的目標(biāo)函數(shù)G(t)可以變形為

其中，K為當(dāng)前隊(duì)列長(zhǎng)度。將式(2)代入式(5)并對(duì)其求和，整理后得到式(6)。

優(yōu)化問(wèn)題總是伴隨著約束條件。首先，鏈路實(shí)際負(fù)載不能超過(guò)鏈路自身承載能力，鏈路負(fù)載能力用Cl表示，即其次，優(yōu)化問(wèn)題變量的非負(fù)取值約束，即ri＞0。最終的優(yōu)化問(wèn)題為

算法1 SWAA

步驟2)定義了發(fā)送窗口修改函數(shù)，參數(shù)是優(yōu)化后的數(shù)據(jù)源端目標(biāo)速率值ri以及鏈路的平均時(shí)延步驟 3)～步驟 20)具體實(shí)現(xiàn)了數(shù)據(jù)源端目標(biāo)速率調(diào)節(jié)機(jī)制，其中，步驟8)鏈路的平均時(shí)延由時(shí)延抽樣值 sampled_rtt和抽樣次數(shù)sampled_num確定；步驟9)通過(guò)控制器輪詢(xún)周期及輪詢(xún)周期內(nèi)統(tǒng)計(jì)到的數(shù)據(jù)流計(jì)數(shù)器中的傳輸字節(jié)值計(jì)算出數(shù)據(jù)流i初始速率，從而獲得該流的到達(dá)率；步驟 17)通過(guò)調(diào)用發(fā)送窗口修改函數(shù)，得到數(shù)據(jù)源端的發(fā)送窗口目標(biāo)值并返回存儲(chǔ)，控制器通過(guò)將new_cwnd重新寫(xiě)入從反饋回路獲取到的TCP_ACK分組，最終達(dá)到調(diào)節(jié)數(shù)據(jù)源端速率的目的。

4 算法實(shí)現(xiàn)

當(dāng)前的研究工作中，通常依靠 TCP連接建立的反饋回路傳遞擁塞鏈路信息或者擁塞窗口大小調(diào)節(jié)信息，以達(dá)到調(diào)節(jié)發(fā)送速率的目的，避免鏈路擁塞的發(fā)生。但是，如果反饋回路擁塞或者發(fā)生故障則嚴(yán)重影響算法的時(shí)效性。本文SSRC算法能夠利用SDN/OpenFlow架構(gòu)的優(yōu)勢(shì)，很好地解決當(dāng)前研究算法時(shí)效性不高的問(wèn)題。首先，通過(guò)對(duì)鏈路中出現(xiàn)的長(zhǎng)流以及交換機(jī)隊(duì)列長(zhǎng)度的監(jiān)測(cè)，快速定位擁塞可能出現(xiàn)的節(jié)點(diǎn)位置并觸發(fā)算法；控制器利用TCP會(huì)話(huà)建立的反饋回路修改接入層交換機(jī)的反向流表匹配規(guī)則，極大地提高數(shù)據(jù)源端對(duì)擁塞節(jié)點(diǎn)的響應(yīng)時(shí)間，提高算法的時(shí)效性，在保證短流的傳輸截止時(shí)間的同時(shí)，防止出現(xiàn)Incast問(wèn)題。算法流程如圖2所示。具體步驟如下。

圖2 算法設(shè)計(jì)流程

1) 控制器定時(shí)向交換機(jī)查詢(xún)流表計(jì)數(shù)器值，同時(shí)監(jiān)控交換機(jī)緩存隊(duì)列長(zhǎng)度。當(dāng)計(jì)數(shù)器值大于長(zhǎng)流閾值（判斷為長(zhǎng)流），且隊(duì)列長(zhǎng)度大于設(shè)定閾值時(shí)，觸發(fā)算法。

2) 控制器向接收端接入交換機(jī)下發(fā) FlowMod命令。該 FlowMod關(guān)鍵參數(shù)如下：匹配項(xiàng)為T(mén)CP_ACK，優(yōu)先級(jí)為最高，HardTimeOut為RTT+ε（ε＜RTT）。

3) 在接入層交換機(jī)上，如果數(shù)據(jù)流與更新后的流表匹配成功，則將數(shù)據(jù)分組發(fā)送到控制器。

4) 控制器收到packet_in消息，判斷其reason== OFPR_ACTION后，修改數(shù)據(jù)分組cwnd值。

5) 將修改后的ACK分組，通過(guò)packet_out消息，直接推送到數(shù)據(jù)流源端的接入層交換機(jī)。

步驟2)的操作是由于數(shù)據(jù)源端速率更新后，至少在一個(gè) RTT時(shí)間后接收端才能收到更新的數(shù)據(jù)分組，因此，在RTT+ε內(nèi)都應(yīng)保持SSRC更新后的發(fā)送窗口值。

將上述步驟轉(zhuǎn)換成控制器端可執(zhí)行的算法程序，并提出數(shù)據(jù)源端控制算法 SSRC（SDN-based source rate control），如算法2所示。

算法2 SSRC

步驟1)～步驟4)設(shè)置了SSRC算法的初始值。步驟 5)～步驟 11)定義了長(zhǎng)流判斷函數(shù)。步驟 12)～步驟 16)定義了隊(duì)列長(zhǎng)度是否超過(guò)設(shè)置閾值的判斷函數(shù)。步驟18)～步驟33)是SSRC的核心代碼，其中，步驟18)～步驟24)判斷當(dāng)目標(biāo)長(zhǎng)流出現(xiàn)并且隊(duì)列長(zhǎng)度超出閾值，也就是步驟18)的判斷為真時(shí)，控制器會(huì)向交換機(jī)下發(fā) FlowMod的命令，即步驟 19)～步驟 23)代碼；步驟 25)～步驟 33)執(zhí)行了當(dāng)控制器接收到 packet_in消息時(shí)，判斷出產(chǎn)生packet_in的原因是FlowMod匹配項(xiàng)得以匹配，此時(shí)控制器會(huì)對(duì)數(shù)據(jù)分組進(jìn)行解析，獲得數(shù)據(jù)分組頭中的擁塞窗口值，調(diào)用SWAA算法進(jìn)行修改（步驟30)），并將修改后的數(shù)據(jù)分組直接推送到源端的邊緣層交換機(jī)。至此，SSRC執(zhí)行完畢。由于算法 2是在一段時(shí)間內(nèi)遍歷 n條數(shù)據(jù)流并進(jìn)行長(zhǎng)流的判定，因此算法2時(shí)間復(fù)雜度為O(n)。

5 仿真與評(píng)估

5.1 仿真平臺(tái)構(gòu)建

集中架構(gòu)的仿真平臺(tái)采用NS3+Floodlight進(jìn)行搭建。平臺(tái)運(yùn)行的宿主機(jī)是戴爾OptiPlex9020服務(wù)器，設(shè)備硬件的性能參數(shù)為：8核/3.4 GHz主頻的64位處理器，10 GB內(nèi)存，操作系統(tǒng)采用Ubuntu16.04版本。同時(shí)，宿主機(jī)部署了支持對(duì)OpenFlow協(xié)議分析的wireshark軟件。

NS3仿真器采用v3.6版本，使用Floodlight控制器作為外部控制器，并通過(guò)Tapbridge與NS3相連。由于NS3具有離散時(shí)間仿真的特點(diǎn)，即一旦仿真開(kāi)始，就不能中途修改參數(shù)。為了實(shí)現(xiàn)SSRC的控制功能，本文編寫(xiě)2個(gè)功能模塊預(yù)置在Floodlight的應(yīng)用程序中：一個(gè)是 AddDSCPFlowMod，實(shí)現(xiàn)下發(fā)流表和添加meter entry；另一個(gè)是DSCPController，實(shí)現(xiàn)解析數(shù)據(jù)分組和修改發(fā)送窗口值后，將攜帶發(fā)送窗口目標(biāo)值的數(shù)據(jù)分組直接推送到連接發(fā)送端的接入層交換機(jī)。

仿真拓?fù)溥x擇當(dāng)前數(shù)據(jù)中心普遍采用的以交換機(jī)為核心的多層拓?fù)浣Y(jié)構(gòu)，實(shí)驗(yàn)將構(gòu)建K（交換機(jī)接入端口數(shù)）值可變的胖樹(shù)（fat-tree）拓?fù)洌⒁訩=8即具有8個(gè)POD（performance optimization datacenter）的拓?fù)湟?guī)模進(jìn)行仿真實(shí)驗(yàn)，如圖3所示。其中，核心層的交換機(jī)編號(hào)為S101～116，匯聚層的交換機(jī)編號(hào)為S201～S232，邊緣層的交換機(jī)編號(hào)為S301～S332，終端主機(jī)的編號(hào)為H001～H128。

5.2 實(shí)驗(yàn)設(shè)計(jì)

5.2.1 實(shí)驗(yàn)對(duì)象選擇

SSRC性能實(shí)驗(yàn)的對(duì)比算法選擇TCP_NewReno以及先前研究工作中具有代表性的2個(gè)解決算法。其中，代表終端解決算法采用文獻(xiàn)[3]的方法，即減小最小超時(shí)重傳時(shí)間 RTOmin，該算法依然基于NewReno算法，只是減小了RTOmin值，實(shí)現(xiàn)方法簡(jiǎn)單，易于部署；DCTCP則代表交換設(shè)備解決算法，基于ECN的標(biāo)記功能，但是不同于ECN對(duì)交換機(jī)平均隊(duì)列長(zhǎng)度閾值做出響應(yīng)，DCTCP是對(duì)交換機(jī)瞬時(shí)隊(duì)列超過(guò)閾值的數(shù)據(jù)分組進(jìn)行標(biāo)記，其次，ECN的發(fā)送端在收到接收端標(biāo)記的響應(yīng)數(shù)據(jù)分組后，發(fā)送窗口減半，而DCTCP發(fā)送端通過(guò)感知網(wǎng)絡(luò)中間節(jié)點(diǎn)的擁塞程度來(lái)動(dòng)態(tài)調(diào)節(jié)發(fā)送窗口大小，具體做法是被標(biāo)記的分組數(shù)量越多、衰減因子越大，發(fā)送窗口就越小。相比ECN，DCTCP對(duì)網(wǎng)絡(luò)擁塞的響應(yīng)更加及時(shí)并且能保證網(wǎng)絡(luò)吞吐量的需求，是針對(duì)Incast問(wèn)題比較有效的解決算法。

5.2.2 關(guān)鍵變量設(shè)置

考慮到NS3仿真平臺(tái)與實(shí)際部署的差距，設(shè)計(jì)實(shí)驗(yàn)時(shí)首先需要對(duì)仿真過(guò)程中的關(guān)鍵變量（即會(huì)對(duì)實(shí)驗(yàn)結(jié)果產(chǎn)生重要影響但不是實(shí)驗(yàn)研究對(duì)象的變量）進(jìn)行設(shè)定，關(guān)鍵變量設(shè)置的合理性將直接關(guān)系到實(shí)驗(yàn)結(jié)果的準(zhǔn)確性。本實(shí)驗(yàn)需要設(shè)置的關(guān)鍵變量是仿真系統(tǒng)默認(rèn)的 RTOmin值以及背景流個(gè)數(shù)（長(zhǎng)流）。

1) RTOmin值

圖3 實(shí)驗(yàn)拓?fù)?/p>

NS3-3.26版本內(nèi)核的默認(rèn) RTOmin=1 s，但是在實(shí)際實(shí)驗(yàn)過(guò)程中發(fā)現(xiàn)了虛假重傳的現(xiàn)象。證明實(shí)驗(yàn)如下。20個(gè)數(shù)據(jù)源端在沒(méi)有背景流的條件下同時(shí)發(fā)送請(qǐng)求短流，并保證足夠的鏈路帶寬以及數(shù)據(jù)接收端的緩存容量完全可以容納所有的數(shù)據(jù)分組。通過(guò)對(duì)實(shí)驗(yàn)數(shù)據(jù)統(tǒng)計(jì)發(fā)現(xiàn)并沒(méi)有出現(xiàn)分組丟失現(xiàn)象，然而經(jīng)過(guò)wireshark抓取分組分析卻發(fā)現(xiàn)了虛假重傳現(xiàn)象，如圖4所示。當(dāng)RTOmin=1 s時(shí)，所有發(fā)送短流都存在虛假重傳。因此，為了準(zhǔn)確還原對(duì)比算法的實(shí)驗(yàn)效果，仿真中針對(duì)RTOmin參數(shù)值的設(shè)置需要考慮2個(gè)關(guān)鍵要素：首先，需要模擬出DCTCP運(yùn)行的默認(rèn)RTOmin值，既能保證不發(fā)生虛假重傳，又能保證不會(huì)因?yàn)?RTOmin值過(guò)大而增大時(shí)延；其次，需要模擬出 Linux內(nèi)核中默認(rèn)的RTOmin=200 ms的TCP連接傳輸效果。為了滿(mǎn)足以上目標(biāo)，實(shí)驗(yàn)重新設(shè)計(jì)如下：20個(gè)主機(jī)同時(shí)發(fā)送請(qǐng)求短流，在沒(méi)有背景流的情況下，以0.1 s為步長(zhǎng)改變RTOmin，統(tǒng)計(jì)這20條數(shù)據(jù)流在不同RTOmin值下發(fā)生虛假重傳的比例。實(shí)驗(yàn)結(jié)果如圖4所示，可以觀(guān)察到當(dāng)RTOmin＜3.1 s時(shí)，所有的數(shù)據(jù)流都會(huì)發(fā)生至少一次的虛假重傳，隨著RTOmin值增加，發(fā)生虛假重傳的百分比減少，當(dāng)RTOmin＞5 s時(shí)，基本達(dá)到穩(wěn)定值，即所有數(shù)據(jù)流都不會(huì)受到虛假重傳的影響。

圖4 最小超時(shí)重傳時(shí)間設(shè)置分析

為了保證實(shí)驗(yàn)結(jié)果的準(zhǔn)確性以及還原比較對(duì)象原本的實(shí)驗(yàn)效果，需要進(jìn)一步確認(rèn)RTOmin值。從圖4的分析中可以觀(guān)察到，RTOmin≥5.8 s時(shí)性能比較穩(wěn)定，通過(guò)多次測(cè)試，最終確認(rèn)RTOmin=10 s。為了驗(yàn)證合理性，以默認(rèn)值 10 s為基準(zhǔn)，比較了當(dāng)RTOmin設(shè)置過(guò)小的情況下虛假重傳的表現(xiàn)。圖5顯示了主機(jī)10.1.1.3在RTOmin= 1 s和RTOmin= 10 s下的實(shí)驗(yàn)結(jié)果對(duì)比。

從圖5可以觀(guān)察到，當(dāng)RTOmin=1 s時(shí)，在TCP通信連接建立的過(guò)程中，所有數(shù)據(jù)分組幾乎同時(shí)在22 s左右發(fā)送，導(dǎo)致數(shù)據(jù)流時(shí)延增大，而此時(shí)的RTOmin值又太小，因此導(dǎo)致在24 s源端又發(fā)送了一次連接請(qǐng)求。當(dāng) RTOmin=10 s時(shí)，可以明顯看到源端3次握手后順利地建立了連接，縮短了流傳輸?shù)臅r(shí)間。

此外，實(shí)驗(yàn)也模擬了 RTOmin設(shè)置過(guò)大的情況，并以保證 Linux內(nèi)核中默認(rèn)RTOmin=200 ms時(shí)的TCP并發(fā)連接時(shí)的網(wǎng)絡(luò)性能表現(xiàn)（吞吐量下降2個(gè)數(shù)量級(jí)），測(cè)試后發(fā)現(xiàn)RTOmin=100 s時(shí)可以滿(mǎn)足對(duì)比要求。最終，對(duì)比實(shí)驗(yàn)結(jié)果發(fā)現(xiàn)，當(dāng)RTOmin=10 s時(shí)，流完成時(shí)間為 6.3 s，當(dāng)RTOmin=100 s時(shí)，流完成時(shí)間變成了103.4 s，因此本實(shí)驗(yàn)設(shè)置 RTOmin=10 s能夠模擬出真實(shí)的網(wǎng)絡(luò)情況。

2) 背景流個(gè)數(shù)

圖5 RTOmin分別為1 s和10 s設(shè)置分析

在以往研究工作的同類(lèi)實(shí)驗(yàn)中，一般選擇背景流為5條。但是實(shí)際應(yīng)根據(jù)實(shí)驗(yàn)規(guī)模來(lái)確定，因?yàn)楸尘傲鲾?shù)目太大，占總數(shù)據(jù)流的比重過(guò)大，一方面會(huì)加劇請(qǐng)求短流的分組丟失；另一方面在模擬 Incast環(huán)境時(shí)，即使請(qǐng)求短流并發(fā)數(shù)目很小也會(huì)有嚴(yán)重的分組丟失現(xiàn)象。背景流數(shù)目太少又無(wú)法提供客觀(guān)的比較值，在計(jì)算吞吐量時(shí)會(huì)有較大誤差。因此應(yīng)選擇與實(shí)際環(huán)境中請(qǐng)求短流和背景流比例相匹配的數(shù)據(jù)流個(gè)數(shù)為宜，具體的比例參見(jiàn)DCTCP[1]。圖6是在并發(fā)服務(wù)器個(gè)數(shù)分別為 20和 30下，改變背景流個(gè)數(shù)，對(duì)20條請(qǐng)求短流完成時(shí)間的統(tǒng)計(jì)結(jié)果，目標(biāo)為盡量減小背景流數(shù)目變化對(duì)不同并發(fā)數(shù)下流完成時(shí)間的影響，最終選定本次實(shí)驗(yàn)的背景流數(shù)為6條。

圖6 背景流數(shù)量設(shè)置分析

5.2.3 實(shí)驗(yàn)部署

通過(guò)對(duì)實(shí)驗(yàn)關(guān)鍵變量的分析與設(shè)置，本文實(shí)驗(yàn)部署如下：實(shí)驗(yàn)瓶頸鏈路帶寬設(shè)置為100 Mbit/s，網(wǎng)絡(luò)節(jié)點(diǎn)交換機(jī)的緩存容量為64 KB。實(shí)驗(yàn)拓?fù)淙鐖D3所示，每個(gè)POD連接16臺(tái)服務(wù)器主機(jī)，共8個(gè)POD，編號(hào)為1～8。數(shù)據(jù)發(fā)送端和接收端屬于不同POD，故設(shè)定POD8中一臺(tái)主機(jī)為接收端，同時(shí)為了避免服務(wù)器接入鏈路成為瓶頸鏈路，發(fā)送端主機(jī)由其余 POD平均分配，其中，POD1～POD6分別隨機(jī)選擇一臺(tái)主機(jī)，以隨機(jī)時(shí)間依次開(kāi)始向接收端發(fā)送的長(zhǎng)流作為背景流量；每個(gè)POD另外選擇1～12臺(tái)主機(jī)并發(fā)產(chǎn)生SRU，每個(gè)SRU大小設(shè)為256 KB，因此接收端共計(jì)請(qǐng)求數(shù)據(jù)源端發(fā)送流量大小為N×SRU，N為并發(fā)數(shù)，1≤N≤80。SSRC的性能表現(xiàn)將基于數(shù)據(jù)流完成時(shí)間、網(wǎng)絡(luò)平均吞吐量以及分組丟失率這3個(gè)指標(biāo)進(jìn)行評(píng)估。

5.3 性能評(píng)估

5.3.1 數(shù)據(jù)流完成時(shí)間

由于NS3仿真平臺(tái)的特殊性，在實(shí)際環(huán)境中，平均流完成時(shí)間正比于并發(fā)服務(wù)器個(gè)數(shù)，系數(shù)為同時(shí)，考慮到NS3平臺(tái)中使用了CSMA信道，以及其他可能的干擾因素，為了保證實(shí)驗(yàn)的嚴(yán)謹(jǐn)性，進(jìn)行圖7 (a)所示的實(shí)驗(yàn)，找出在沒(méi)有背景流的情況下，增加并發(fā)服務(wù)器個(gè)數(shù)與數(shù)據(jù)平均流完成時(shí)間擬合的二次函數(shù)。圖7(b)為4種算法在增大并發(fā)服務(wù)器個(gè)數(shù)下的表現(xiàn)。首先，由于背景流的存在，所有算法下短流的傳輸時(shí)間都受到了很大的影響。例如比較并發(fā)數(shù)為45條，增加6條背景流，共 51條數(shù)據(jù)流同時(shí)競(jìng)爭(zhēng)信道時(shí)，短流的平均流完成時(shí)間最優(yōu)可達(dá)到10.50 s（SSRC、NewReno下為30.12 s），而沒(méi)有背景流存在時(shí)，45條數(shù)據(jù)流傳輸?shù)钠骄魍瓿蓵r(shí)間為5.33 s，也就是說(shuō)出現(xiàn)了成倍的增長(zhǎng)。此外，對(duì)比4種算法的表現(xiàn)可以得出，并發(fā)數(shù)較少時(shí)，不同算法表現(xiàn)沒(méi)有太大差異，流完成時(shí)間基本維持在7 s左右；隨著數(shù)據(jù)流并發(fā)數(shù)的增多，流完成時(shí)間開(kāi)始增加。相比于其他3種算法，SSRC增加幅度為 62.3%，NewReno、RTOmin和DCTCP分別為411.4%、273.2%和168.1%，SSRC的優(yōu)化效果十分明顯。

圖7 流完成時(shí)間比較

5.3.2 網(wǎng)絡(luò)平均吞吐量

吞吐量主要針對(duì)長(zhǎng)流來(lái)分析。長(zhǎng)流對(duì)于時(shí)延不是十分敏感，但是對(duì)于吞吐量的要求很高，當(dāng)鏈路發(fā)生擁塞時(shí)，長(zhǎng)流分組丟失會(huì)造成吞吐量的斷崖式下降。另一個(gè)特征是TCP NewReno下不同背景流的吞吐量方差很大，反映出部分長(zhǎng)流在傳輸過(guò)程中的分組丟失可能更多，而一旦發(fā)生分組丟失，很難再和其他正常傳輸?shù)臄?shù)據(jù)流競(jìng)爭(zhēng)信道，最終表現(xiàn)為鏈路資源分配的不均勻。因此實(shí)驗(yàn)就上述 2個(gè)方面進(jìn)行比較。由圖8(a)可以看出，相比于其他算法，隨著并發(fā)數(shù)的增多，SSRC依然能保持較高的吞吐量；圖8(b)進(jìn)一步從吞吐量的標(biāo)準(zhǔn)差對(duì)比來(lái)驗(yàn)證 SSRC性能。圖 8(b)中不同的虛線(xiàn)是對(duì)不同并發(fā)數(shù)下吞吐量標(biāo)準(zhǔn)差的一次線(xiàn)性擬合，可以清晰地看出，通過(guò) SSRC對(duì)源端速率的精確控制，能夠保證鏈路充分利用，并且較為平均地將資源分配給每一條數(shù)據(jù)流。

圖8 吞吐量性能比較

5.3.3 分組丟失率

分組丟失對(duì)于長(zhǎng)流會(huì)造成吞吐量的明顯下降，對(duì)于時(shí)延敏感的短流會(huì)造成超時(shí)重傳。為了明確NS3中長(zhǎng)流和短流在并發(fā)時(shí)各自的特性，設(shè)計(jì)了以下實(shí)驗(yàn)：數(shù)據(jù)中心拓?fù)渲芯S持6條背景流，在仿真開(kāi)始后的 23 s左右（此時(shí)背景流傳輸穩(wěn)定），30個(gè)服務(wù)器并發(fā)發(fā)送大小為2 KB的SRU，統(tǒng)計(jì)在這30個(gè)服務(wù)器第一個(gè)分組發(fā)送后，每秒內(nèi)長(zhǎng)流和短流各種傳輸?shù)臄?shù)據(jù)分組數(shù)目，以及分組丟失的數(shù)目（在RTOmin算法下）。仿真實(shí)驗(yàn)中，第一個(gè)短流的數(shù)據(jù)分組在23.484 645 s發(fā)出，最后一個(gè)數(shù)據(jù)分組在35.837 998 s收到，統(tǒng)計(jì)后得到的結(jié)果如圖9所示。

圖9 長(zhǎng)短流分組丟失比較

短流在開(kāi)始的4 s內(nèi)，發(fā)生了嚴(yán)重的分組丟失現(xiàn)象，而長(zhǎng)流的分組丟失不嚴(yán)重，說(shuō)明在開(kāi)始競(jìng)爭(zhēng)信道時(shí)，交換機(jī)緩存中基本上都是長(zhǎng)流的數(shù)據(jù)分組，后來(lái)到達(dá)的短流很容易超過(guò)閾值而被丟棄，也就是說(shuō)短流在與長(zhǎng)流的競(jìng)爭(zhēng)中處于劣勢(shì)。5～8 s，鏈路依然繁忙，此時(shí)已經(jīng)有部分的短流占據(jù)了緩存，導(dǎo)致之后的長(zhǎng)流分組丟失率上升，而且短流本身只有2 KB，很容易塞滿(mǎn)交換機(jī)而不被丟棄。9 s后短流基本已經(jīng)傳輸完成，通過(guò)交換機(jī)的數(shù)據(jù)分組占比快速下降，即使緩存溢出，被丟棄的概率也很小。此外，整個(gè)實(shí)驗(yàn)結(jié)果都反映了長(zhǎng)流的“貪婪性”，因?yàn)槿绻溌焚Y源均勻分配，每個(gè)時(shí)間段內(nèi)發(fā)送的數(shù)據(jù)分組平均應(yīng)該有 16.67%來(lái)自長(zhǎng)流，而實(shí)際中長(zhǎng)流占比最少時(shí)（第 7 s）也達(dá)到了總傳輸量的33.33%，而且長(zhǎng)流占比的下降很可能是之前連續(xù)的分組丟失使源端退避而暫時(shí)降低了鏈路資源的占用。通過(guò)上面的實(shí)驗(yàn)可以看出，NS3環(huán)境下長(zhǎng)短流基本的特性和實(shí)際網(wǎng)絡(luò)環(huán)境中一致。在長(zhǎng)短流特性已知的前提下保證背景流數(shù)目為 6且不變，增加并發(fā)服務(wù)器個(gè)數(shù)，對(duì)短流的分組丟失率進(jìn)行統(tǒng)計(jì)，如圖10所示。對(duì)比發(fā)現(xiàn)，SSRC的控制算法降低分組丟失率的表現(xiàn)優(yōu)越，即使在鏈路狀態(tài)十分惡劣的情況下，也基本能夠保證分組丟失總數(shù)在10個(gè)以?xún)?nèi)。

圖10 分組丟失率比較

6 結(jié)束語(yǔ)

本文針對(duì)數(shù)據(jù)中心網(wǎng)絡(luò)如何保證時(shí)延敏感流的傳輸時(shí)間問(wèn)題進(jìn)行了相關(guān)研究，在

SDN/OpenFlow的架構(gòu)下，提出了一種基于數(shù)據(jù)源端速率控制的算法 SSRC。該算法能夠準(zhǔn)確定位可能發(fā)生擁塞的節(jié)點(diǎn)設(shè)備，通過(guò)控制器快速進(jìn)行應(yīng)對(duì)策略的響應(yīng)，相較于傳統(tǒng)網(wǎng)絡(luò)中接收端通過(guò)反饋回路進(jìn)行數(shù)據(jù)源端速率調(diào)節(jié)的算法，能夠極大地縮短響應(yīng)時(shí)間，解決現(xiàn)有算法時(shí)效性不高的問(wèn)題。最后，通過(guò)將NS3仿真工具與Floodlight外部控制器相連，實(shí)現(xiàn)SDN/OpenFlow架構(gòu)下的數(shù)據(jù)中心網(wǎng)絡(luò)環(huán)境中進(jìn)行，同時(shí)與 DCTCP等 3種解決算法進(jìn)行比較，仿真實(shí)驗(yàn)結(jié)果證明SSRC能夠保證時(shí)延敏感流的傳輸時(shí)間，同時(shí)能夠很好地解決Incast問(wèn)題。