一種最小化數據中心網絡流延遲框架研究

趙正偉 任禎琴 趙旭鴿

摘 ?要：延遲是數據中心網絡及其承載應用的一個關鍵性能度量指標，越來越受到學術界和工業界的關注。文章提出一種綜合的協調機制，把負載均衡和擁塞控制統一起來，在多條等價路徑上均勻分布流量，利用ECN并結合流的優先級自適應地對擁塞做出反應。實驗結果顯示，該機制與目前采用的TCP和基于哈希的多路徑傳輸機制相比，對延遲敏感的流，應用吞吐率提高了30%，流完成時間的99th分位數降低了90%;對背景流量，流的平均完成時間降低50%～80%。

關鍵詞：擁塞控制;負載均衡;多路徑傳輸;數據中心網絡;顯式擁塞通告;時限

中圖分類號：TP393 ? ? 文獻標識碼：A 文章編號：2096-4706（2020）23-0044-07

Study on a Kind of Network Flow Latency Framework of Minimizing Data Center

ZHAO Zhengwei，REN Zhenqin，ZHAO Xuge

（School of Information Technology，Luoyang Normal University，Luoyang ?471934，China）

Abstract：Latency is a key performance measurement index of data center network and its load bearing application，which is getting more and more attention from academic circles and industrial circles. This pager proposes an integrated coordinated mechanism to unite load balancing and congestion control，and evenly distribute flow in several equivalent paths，uses ECN and combining priority level of flow to adaptively respond to congestion. Experimental results show，comparing to existing multi-path transmission mechanism based on TCP and Hash，the mechanism achieves an improvement of 30% in application throughput rate and an reduction of 90% in 99th percentile of flow completion time for latency-sensitive flow，and achieve a reduction of 50%～80% in average completion time of flow for background flow.

Keywords：congestion control;load balance;multi-path transmission;data center network;explicit congestion notification;time limit

0 ?引 ?言

近年來，隨著互聯網和云計算的快速發展，數據中心已經成為許多商業服務的關鍵基礎設施，如Web搜索、在線零售、社交網絡和廣告推薦系統等。這些服務通常是面向用戶的在線服務，延遲對用戶體驗有重要影響，并最終影響服務提供商的運營收入。例如，平均訪問延遲增加100 ms將使Amazon的收入減少約1%[1，2];增加100 ms的延遲會使Google的搜索請求減少0.2%～0.4%，并最終導致其收入減少[3]。此外，數據中心主存、外存和計算的分離也加劇了對低延遲網絡通信的要求[4-6]。

然而，在目前的數據中心網絡中，滿足流的時限約束非常困難，具體原因有：

（1）劃分-聚合負載模式：劃分-聚合設計模式（partition- aggregate workloa d）是目前許多大規模互聯網應用的基礎，如搜索引擎等。在該負載模式下，大量的小流在短時間內匯聚到交換機的一個端口上，導致端口緩沖溢出，繼而發生丟包和重傳[7-10]。

（2）順序依賴性的負載模式：順序依賴性的負載模式（dependent-sequential workload）是數據中心中另一種常見的通信模式，例如，為了構建一個用戶頁面，Facebook需要進行100～200次數據請求，其中很大一部分請求之間存在時序依賴關系[12]。文獻[12]指出，同一機柜內，約有10%的通信往返時間大于1 ms，也就是說，在最壞情況下，2～3個RTT就會導致一條流錯過時限。

（3）公平共享的傳輸層協議：TCP公平對待所有的流，擁塞發生時，在最小化流的完成時間以及錯過時限流的比例方面，遠不是最優的，不僅不能滿足應用的延遲要求，還會造成網絡帶寬浪費。

（4）基于隨機的負載均衡策略：目前數據中心大都采用ECMP在多條路徑之間均攤流量，通常會導致熱點的出現，多條流可能被調度到一條擁擠的路徑上，其他的路徑幾乎沒有流量。這會大量增加流的平均完成時間以及高分位數完成時間。

為此，本文提出一種綜合的協調機制，把數據中心網絡多路徑傳輸和擁塞控制有機地結合起來，減小數據中心網絡流延遲。該機制既能充分利用現代數據中心的多根樹拓撲，又能保證隨著擁塞的加劇，系統仍然能夠像TCP一樣收斂。同時在小規模的真實環境和大規模的仿真環境進行實驗，結果顯示該機制能夠大幅降低流延遲。

1 ?背景和相關工作

1.1 ?數據中心的網絡拓撲和負載均衡

為了提高性能和可靠性，現代數據中心大都采用多路徑的拓撲結構[13-16]，任意兩個節點之間有多條等價路徑，但是路由和轉發層面沒有有效利用這些等價路徑。數據中心的多路徑傳輸機制，根據粒度的不同，大致可以分為以下3類：

（1）以流為粒度的多路徑傳輸機制。目前，ECMP[17]是數據中心中多路徑傳輸的事實上的標準，但是經常發生負載分布不均[12，18，19]的情況。Hedera[18]、MicroTE[20]、Mahout[21]和BCube[13]根據當前的網絡狀況來選擇路徑，當網絡狀況隨時間變化時，被選擇的路徑可能已不是最優。VL2[15]和Monsoon[22]采用per-flow的Valiant Load Balancing（VLB），但是，這兩個工作都不在多條路徑上對單條流進行分割。

（2）以子流（sub-flow）為粒度的多路徑傳輸機制。MPTCP在主機端把一條TCP流分割成多條sub-flow，對于長度大于70 kB的流來說，MPTCP非常有效，然而對于長度小于10個分組的流來說，MPTCP的性能不如TCP[19]。FLARE[23]把一條流分解為一系列的突發（Flowlet），并把Flowlet路由到不同的路徑上。但是不能有效解決數據中心的同步突發問題，Flowlet會導致更大幅度隊列長度變化[22]。

（3）以分組為粒度的多路徑傳輸機制。Cisco的一些商用交換機[24]已經采用了比較成熟的分組噴射技術（packet spray），以分組的目的地址為單位進行輪循調度（round-robin）。文獻[25]提出在主機端以分組為單位在多條路徑之間進行分發，擴展性不是很好。DeTail[25]以分組為單位進行自適應的多路徑傳輸，但是，它幾乎全部廢棄了TCP層的功能，并且受到優先級數目有限的限制[10，26]。RPS[27]把一條流的分組隨機指派給多條等價路徑中的一條，盡管這可以降低復雜性，但RPS仍然會造成熱點問題。

1.2 ?數據中心的擁塞控制

同步突發是數據中心流量的一個基本特性，但是目前的數據中心網絡不能很好地處理這種情況，導致應用錯過時限，具體為：

（1）TCP/IP協議棧在網絡發生擁塞時，使用丟包作為對發送端的反饋，超時重傳機制經常導致丟包的流錯過時限。

（2）TCP平等對待所有的擁塞流，擁塞發生時，不能優先處理某些特殊的流，這對時延敏感流極其不利。RCP[28]、XCP[29]和DCTCP[7]在高速網絡中性能都獲得顯著的提升，然而，這些都是公平共享的，在減小流完成時間上遠不是最優的[8，9，20]。

更嚴重的是，由于TCP不能很好地滿足應用的時限要求，開發人員轉而尋求其他解決途徑。例如，據報道，Facebook正在開發基于UDP的擁塞控制協議，來滿足應用的延遲要求[7，14，15]。

2 ?系統設計與分析

2.1 ?系統概述

圖1展示了系統的設計方案及其信息交換過程。該系統的主要設計思想是，通過基于交換機隊列長度閾值的信號機制和ECN標記機制，把數據中心網絡多路徑傳輸和擁塞控制協調起來，主要目標是利用多路徑和提高小流的優先級來滿足小流的延遲需求。該機制由兩部分組成：

（1）在網絡側，我們在交換機上監控其端口隊列的瞬時長度，當超過閾值時，觸發一個擁塞信號并通告給網絡層，作為其多路徑路由選擇的依據，同時對隊列中的分組進行ECN標記。

（2）在主機側，接收端僅把ECN標記完整地寫入ACK，并反饋給發送端。發送端根據在每個RTT內接收到的ACK分組中的ECN標記信息，計算網絡的擁塞程度，根據這個擁塞程度和流的優先級動態調整其發送速率。

2.2 ?自適應的負載均衡

為了把分組轉發到隊列長度最短的等價路徑上，并且不帶來額外的計算開銷，本文提出一種自適應的多路徑傳輸機制。我們為交換機的每個緩沖隊列關聯一個信號，一旦隊列占用小于某個預先設置的閾值，就把信號置為有效，一旦隊列占用長度超過這個閾值，就把信號置為無效。這個信號反映的是網絡的擁塞狀況，所有端口的信號構成一個信號位圖，稱為信號位圖，如圖2所示。

當分組到達交換機時，交換機從多路徑路由表中取出所有可能的轉發端口Es同時獲取信號位圖S。接著把Es和S做按位與操作，得到所有可能的負載較輕的路徑Eg，并對分組頭做哈希操作，得到默認的ECMP的轉發端口Eh。如果Eh的負載也較輕（即Eh∈Eg），就把Eh作為轉發端口。否則，交換機就從Eg中隨機選擇一個端口轉發該分組。當沒有負載較輕的路徑時（即Eg=?），交換機還要對分組設置ECN標記。這里優先選擇ECMP計算出來的路徑，其主要目的是為了和傳統的ECMP保持一致，在一定程度上減小分組亂序的發生。

2.3 ?基于優先級的自適應的擁塞控制

2.3.1 ?網絡的擁塞程度

和DCTCP[7]一樣，我們采用ECN機制來獲取網絡的擁塞程度。發送端維護一個變量α，用來估計已標記分組的比例，每發送完一個窗口的數據（大概是一個RTT時間）更新一次：

α=（1-g）·α+g·F ? ? ? ? ? ? ? ? ? ? ? ? （1）

其中，F為最后一個窗口中被標記的分組的比例。0

2.3.2 ?基于時限的優先級劃分

為了優先處理時延敏感的流，我們引入了優先級的概念。優先級越高，擁塞時其擁塞窗口退避幅度越小。流的優先級定義為：

（2）

其中RD為在時限截止前發送完一條流剩余數據的期望速率，RA為從流開始到當前時刻的平均速率。

2.3.3 ?擁塞窗口的調節

為了根據網絡的擁塞程度和流的優先級來調節擁塞窗口，我們定義懲罰函數：

P=αp ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?（3）

這個函數被稱為Gamma校正函數。這個函數的一個優良特性是當自變量α在[0，1]之間變化時，其函數值也在這個區間變化，這就可以保證，當擁塞加劇時或者時限即將結束時，PDTCP可以像TCP一樣收斂。

接下來，根據懲罰函數P調節擁塞窗口：

（4）

可以看出，在網絡擁塞程度相同的情況下，優先級越高，懲罰函數P越小，窗口W退避得越少，從而保證能夠以較快的速度發送完畢。在所有的流中，擁塞程度相同時，延遲不敏感的流窗口退避程度最大，從而為延遲敏感的流騰出帶寬，滿足后者的時限約束。

2.3.4 ?提前優先級翻轉

當可以確定流不能滿足其時限約束時，提前將其優先級降為最低，為其他延遲敏感流騰出帶寬。

2.4 ?理論分析

假定N條無限長的流共享M個鏈路，N?M所以M條鏈路就是瓶頸鏈路。因為采用按分組的多路徑傳輸，所以在任何時刻，M條鏈路的隊列長度都是相同的。進一步假設N條流完全同步，鋸齒窗口完全一致，并且都有相同的RTT。這種通信模式是由數據中心中常見的劃分-聚合設計模式產生的。

根據文獻[30]，在t時刻，隊列長度由式（5）決定：

Q（t）= ? ? ? ? ? ? ? （5）

這里N條流共享一條瓶頸鏈路。RTT是往返時間，沒有排隊延遲。假設TCP進入到AIMD的擁塞避免階段。Wi（t）為第i條流在時間t時的窗口大小，C為鏈路帶寬，ε為被丟棄的分組數目。

這里N條流完全同步，其鋸齒窗口完全相同。我們忽略ε，因為PDTCP的設計初衷之一就是避免分組丟棄。所以，可以把式（5）變為：

M·Q（t）=N·W（t）-（RTT·C·M） ? ? （6）

式（6）的物理意義是這樣的：所有發出的分組，要么是在M條鏈路的隊列里，要么在M條鏈路上。

為了刻畫鋸齒窗口的特性，我們重點關注以下幾個變量：交換機隊列的最大長度Qmax、隊列的震蕩幅度A、震蕩的周期TC。其中最關鍵的是震蕩幅度A，因為算法的目標之一就是盡量維持隊列長度在其閾值K附近，震蕩幅度越小越好。因為N條流是完全同步的，所以交換機隊列也是鋸齒狀，只是震蕩幅度和發送端擁塞窗口不同，如圖3所示。

因為所有的發送者是完全同步的，考慮其中的一個。令PS（W1，W2）為發送者的窗口從W1增加到W2期間，一共發送的分組數目。這個過程需要W2-W1個RTT，并且期間的平均窗口大小為（W2-W1）/2，因而可以得到：

PS（W1，W2）=（W2-W1）·（W1+W2）/2=（W22-W12）/2 ?（7）

令W*=M·（C·RTT+K）/N，其為隊列長度接近K時的臨界窗口大小，超過這個之后，交換機開始設置CE代碼點。在下一個RTT，發送窗口增加到W*+1，發送端接收到CE標記。因此：

（8）

將式（7）帶入式（8），得：

α（P-P2/4）=（2W*+1）/（W*+1）2 ? ? ? ? ? ?（9）

假設懲罰函數P的值很小，忽略高次項，得：

αP=（2W*+1）/（W*+1）2 ? ? ? ? ? ? ? ? ? （10）

假定W*?1，式（10）右邊近似等于2/W*，將窗口退避懲罰函數的定義式P=α p帶入式（10），得：

αp+1≈2/W* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?（11）

由此得到α的近似值：

α=（2/W*）1/（p+1） ? ? ? ? ? ? ? ? ? ? ? ?（12）

下文計算隊列的震蕩幅度QA。定義WA為一條流的窗口震蕩幅度，如圖3所示。因為N條流是完全同步的，QA只是WA的簡單放大，即：

（13）

因為N條流共享M條鏈路，故：

M·QA=N·WA ? ? ? ? ? ? ? ? ? ? ? ? ? ?（14）

（15）

式（15）展示了PDTCP在多路徑下的一個重要特性：當N比較小時，隊列的震蕩幅度為O（（M·C·RTT）1/（p+1））。

當p=1，N較小時，振幅為，這就是DCTCP

在自適應多路徑傳輸下的情形。當p=0時，就是TCP在多路徑下的情形。

到此，我們得到：

TC=WA（inRTTs） ? ? ? ? ? ? ? ? ? ? ? （16）

最后，根據式（5），可以計算Qmax：

（17）

門限值K。交換機隊列長度的最小值計算為：

（18）

Qmin對N求導，并讓導數取0，求解N，得：

N=（1/2）（p/（1+p））1+p[M（C·RTT+K）] ?（19）

帶入式（18），并令Qmin>0，得到K的下界：

（20）

3 ?實驗結果

3.1 ?關鍵參數設置

我們根據文獻[5]來設置DCTCP，D2TCP和PDTCP的關鍵參數。對1 Gbps的鏈路，設置g=1/16。對PDTCP，和文獻[6]一樣，我們限制了流的優先級P的取值范圍在[0.5，2.0]之間。對所有的協議，我們把RTOmin設置為20 ms。

流的時限服從指數分布，均值分別為20 ms（tight）、30 ms（median）和40 ms（lax）[8]。我們用應用吞吐率即滿足時限的流的比例，作為這些時限約束流的性能度量指標。

3.2 ?真實環境結果和模擬器驗證

為了驗證模擬器的參數設置，我們同時在真實環境和ns-2中構建了一個36節點的Fat-tree拓撲，并使用相同的負載流量。結果顯示，真實實現和仿真實驗下各個指標的絕對值和相對差值都非常小，并且變化趨勢一致，這些關鍵的相似性說明模擬器的參數設置是可信的，能夠反映系統在真實實現下的性能。

3.3 ?仿真實驗結果

劃分-聚合負載模式。圖4（a）展示了當同步突發流數目從5增加到40時，應用吞吐率的變化情況。可以看出，與TCP+FH相比，PDTCP+AM有明顯的性能提升，例如，當并發的同步流數目是40時，PD2TCP+AM下95%的流滿足時限，而TCP+FH只能滿足65%流的時限。圖4（b）展示了流完成時間的99th分位數，我們把流完成時間歸一化到最優值上。PD2TCP+AM能夠獲得接近最優的性能，因為歸一化的流完成時間的99th分位數在1.0～1.2之間。TCP+AM與PD2TCP+FH比TCP+FH稍好，其值分別在1.4～2.5和1.1～1.6之間。TCP+FH表現最差，當并發流數目是40時，其歸一化的完成時間超過6，亦即最優值的6倍。同樣，對背景流量，PD2TCP+AM也能獲得接近最優的表現，如圖4（c）所示。

順序依賴負載模式。在該流量模式下，PD2TCP+AM的性能提高比在劃分-聚合流量下更明顯。如圖5所示，當工作流的達到速率在1 600個/秒時，PD2TCP+AM和TCP+ FH的應用吞吐率分別是96%和70%，歸一化流完成時間的99th分位數分別是1.5和45。對背景流，在1 600工作流/秒時，歸一化的流完成時間分別是1.6和9.5。

這些結果說明，與TCP+FH相比，PDTCP+AM在性能上有明顯的提升，其原因是自適應的多路徑機制充分利用了拓撲結構中的多條等價的最短路徑，并且以分組為粒度選擇最不擁堵的路徑。這種機制能同時降低流的排隊延遲，并提高流的吞吐率。此外，在擁塞時，PDTCP優先處理延遲敏感的流，進一步降低了這類流的排隊延遲。

4 ?結 ?論

延遲是數據中心網絡主要的性能指標之一，降低數據中心網絡流延遲面臨許多挑戰。本文提出一種協調一致的數據中心網絡擁塞控制和多路徑傳輸機制，同時解決數據中心網絡對高帶寬和低延遲的要求。同時在真實和仿真環境中，采用真實的數據中心流量模型對該機制進行評價。實驗結果顯示，該機制與目前數據中心采用的TCP和基于哈希的多路徑傳輸機制相比，能夠有效提高延遲敏感流的應用吞吐率和99th分位數完成時間，并能同時提高背景流的吞吐率。

參考文獻：

[1] HOFF T. Latency is Everywhere and it Costs You Sales-How to Crush it [EB/OL].（2009-07-25）.http：//highscalability.com/blog/2009/7/25/latency-is-everywhere-and-it-costs-you-sales-how-to-crush-it.html.

[2] KOHAVIR R，LONGOTHAM R. Online experiments：Lessons learned [J] Computer ，2007，40（9）：103-105.

[3] BRUTLAG J. Speed matters for Google web search [EB/OL].[2020-10-15].https：//services.google.com/fh/files/blogs/google_delayexp.pdf.

[4] GAO P X，NARAYAN A，KARANDIKAR S. Network requirements for resource disaggregation [C]//Proceedings of the 12th USENIX conference on Operating Systems Design and Implementation.Berkeley：USENIX Association，2016：249-264.

[5] SHAN Y Z，ZHANG Y Y，CHEN Y L，et al. LegoOS：a disseminated，distributed OS for hardware resource disaggregation [C]//13th USENIX Symposium on Operating Systems Design and Implementation.Berkeley：USENIX Association，2018：69-87.

[6] KUMAR G，DUKKIPATI N，JANG K，et al. Swift：Delay is Simple and Effective for Congestion Control in the Datacenter [C]//Proceedings of the Annual conference of the ACM Special Interest Group on Data Communication on the applications，technologies，architectures，and protocols for computer communication.New York：Association for Computing Machinery，2020：514-528.

[7] VASUDEVAN V，PHANISHAYEE A，SHAH H，et al. Safe and Effective Fine-grained TCP Retransmissions for Datacenter Communication [J].ACM SIGCOMM Computer Communication Review，2011，39（4）：303-314.

[8] CHEN Y P，GRIFFITH R，LIU J D. Understanding TCP incast throughput collapse in datacenter networks [C]//Proceedings of the 1st ACM SIGCOMM 2009 Workshop on Research on Enterprise Networking.Barcelona：Association for Computing Machinery，2009：73-82.

[9] ALIZADEH M，GREENBERG A G，MALTZ D A，et al. Data center TCP （DCTCP）[J].ACM SIGCOMM Computer Communication Review，2010，40（4）：63-74.

[10] WILSON C，BALLANI H，KARAGIANNIS T，et al. Better Never than Late：Meeting Deadlines in Datacenter Networks [J].ACM SIGCOMM Computer Communication Review，2012，41（4）：50-61.

[11] OUSTERHOUT J K，AGRAWAL P，ERICKSON D，et al. The case for RAMClouds：Scalable high-performance storage entirely in DRAM [J].ACM SIGOPS Operating Systems Review，2009，43（4）：92-105.

[12] ZATS D，DAS T，MOHAN P，et al. DeTail：reducing the flow completion time tail in datacenter networks [J].ACM SIGCOMM Computer Communication Review，2012，42（4）：139-150.

[13] GUO C X，LU G H，LI D，et al. BCube：A High Performance，Server-centric Network Architecture for Modular Data Centers [J].ACM SIGCOMM Computer Communication Review，2009，39（4）：63-74.

[14] GUO C X，WU H T，TAN K，et al. DCell：A scalable and fault-tolerant network structure for data centers [J].ACM SIGCOMM Computer Communication Review，2008，38（4）：75.

[15] GREENBERG A G，HAMILTON J R，JAIN N，et al. VL2：A Scalable and Flexible Data Center Network [J].Communications of the ACM，2009，54（3）：95-104.

[16] MYSORE R N，PAMBORIS A，FARRINGTON N，et al. PortLand：A Scalable Fault-Tolerant Layer 2 Data Center Network Fabric [J].ACM SIGCOMM Computer Communication Review，2009，39（4）：39-50.

[17] Cisco.Cisco Data Center Infrastructure 2.5 Design Guide [EB/OL].[2020-10-15].http：//www.cisco.com/univercd/cc/td/doc/solution/dcidg21.pdf.

[18] AL-FARES M，RADHAKRISHNAN S，RAGHAVAN B，et al. Hedera：dynamic flow scheduling for data center networks [C]//Proceedings of the 7th USENIX Symposium on Networked Systems Design and Implementation.San Jose：USENIX Association，2010：19.

[19] RAICIU C，BARR? S，PLUNTKE C，et al. Improving Datacenter Performance and Robustness with Multipath TCP [J].ACM SIGCOMM Computer Communication Review，2011，41（4）：266-277.

[20] BENSON T，ANAND A，AKELLA A，et al. MicroTE：Fine Grained Traffic Engineering for Data Centers [C]//Conference on emerging Networking Experiments and Technologies.New York：Association for Computing Machinery，2011：1-12.

[21] CURTIS A R，MOGUL J，TOURRILHES J. DevoFlow：Scaling Flow Management for High-Performance Networks [J].ACM SIGCOMM Computer Communication Review，2011，41（4）：254-265.

[22] GREENBERG A G，LAHIRI P，MALTZ D A，et al. Towards a next generation data center architecture [C]//Proceedings of the ACM SIGCOMM 2008 Workshop on Programmable Routers for Extensible Services of Tomorrow.New York：Association for Computing Machinery，2008：57-62.

[23] SINHA S，KANDULA S，KATABI D. Harnessing TCPs Burstiness using Flowlet Switching [C]//Hot Topics in Networks HotNets-Ⅲ.San Diego：2004.

[24] Cisco. Per-packet load balancing [EB/OL].[2020-10-15].https：//www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipswitch_cef/configuration/15-s/isw-cef-15-s-book/isw-cef-load-balancing.html#GUID-C725A4B8-9263-4D2C-95FB-F31D14E477C4.

[25] GEOFFRAY P，HOEFLER T. Adaptive Routing Strategies for Modern High Performance Networks [C]//2008 16th IEEE Symposium on High Performance Interconnects.Stanford：IEEE，2008：165-172.

[26] HONG C Y，CAESAR M，GODFREY P B. Finishing Flows Quickly with Preemptive Scheduling [J].ACM SIGCOMM Computer Communication Review，2012，42（4）：127-138.

[27] DIXIT A，PRAKASH P，HU Y C，et al. On the impact of packet spraying in data center networks [C]//2013 Proceedings IEEE INFOCOM.Turin：IEEE，2013：2130-2138.

[28] DUKKIPATI N. Rate control protocol （rcp）：congestion control to make flows complete quickly [D].Stanford：Stanford University，2007.

[29] KOHAVI R，LONGBOTHAM R，SOMMERFIELD D，et al. Controlled experiments on the Web：survey and practical guide [J].Data Mining and Knowledge Discovery，2009，18：140-181.

[30] APPENZELLER G，KESLASSY I，MCKEOWN N. Sizing Router Buffers [J].ACM SIGCOMM Computer Communication Review，2004，34（4）：281-292.

作者簡介：趙正偉（1982—），男，漢族，河南澠池人，講師，博士，主要研究方向：數據中心網絡;任禎琴（1983—），女，漢族，河南焦作人，講師，博士，主要研究方向：非線性系統;趙旭鴿（1992—），女，漢族，河南汝州人，助教，碩士，主要研究方向：大數據。