——國內主流公有云主機網(wǎng)絡應用性能評測

在上一篇文章“2017年主流公有云產品功能性分析”中,，我們對這些云主機廠商自身發(fā)布的功能性指標進行了一次簡單的分析對比。而公有云主機的實際應用性能,，還是無法從中進行體現(xiàn),。為此至頂網(wǎng)又策劃了本次國內主流公有云主機的網(wǎng)絡應用性能測試活動,。在本次活動中，至頂網(wǎng)同樣選擇的是對阿里云,、百度云,、騰訊云和青云這幾家主流云計算廠商的公有云產品進行評測。

骨感的云主機網(wǎng)絡應用性能評測

網(wǎng)絡應用性能測試,，是通過模擬真實的網(wǎng)絡應用請求,，對網(wǎng)絡產品的實際網(wǎng)絡應用處理能力進行評測。通過網(wǎng)絡應用測試,，應該可以完全真實的評估出網(wǎng)絡產品在現(xiàn)實應用中的實際應用情況,。當前全球主流的網(wǎng)絡應用性能測試儀表提供商，有思博倫和IXIA兩家,。

早在十幾年前,，這兩個廠商就開始向網(wǎng)絡及網(wǎng)絡安全廠商提供網(wǎng)絡應用性能的測試解決方案。當云計算,、SDN/NFV技術興起后,，思博倫和IXIA公司也相應推出了針對虛擬化產品的網(wǎng)絡應用性能測試產品。

在本次測試初期,，也曾規(guī)劃將他們推出的虛擬化網(wǎng)絡應用測試工具安裝到本次測試的云主機之中,。（可參見“公有云主機網(wǎng)絡應用性能 公開測試方案”）從而可以對“應用請求處理速率”、“應用請求響應時延”,、“并發(fā)用戶數(shù)”,、“應用流量”這些應用性能評估的關鍵指標進行最直接的評測。

然而理想很豐滿,，現(xiàn)實太骨感,。在經(jīng)過了多次嘗試之后，這兩款軟件在云主機上的安裝還是以失敗告終,。無奈之下,，只能退而求其次，采用在Linux上使用的Netperf工具完成本次測試工作,。

Test1：云主機網(wǎng)絡帶寬性能

公有云網(wǎng)絡應用,，首先要考慮到的就是帶寬。不同配置云主機,，所能提供的網(wǎng)絡數(shù)據(jù)轉發(fā)能力,，自然也就成了云主機網(wǎng)絡應用測試的首選項目。

在本次測試中,，至頂網(wǎng)將測試的重點放在了云主機的虛擬網(wǎng)絡端口之上。

本次測試中,，針對目前Web應用中最常用的2核4G,、4核8G和這幾家公有云廠商不需要提交工單時可選擇的最高配CPU核數(shù)云主機（核心數(shù)與內存比為1：2）進行了測試,。

測試的數(shù)據(jù)包大小定在了64Byet、512Byte,、1518Byte和不限數(shù)據(jù)包大小時最大數(shù)據(jù)緩沖的文件傳輸性能,。

【附注：考虛到阿里云新建數(shù)據(jù)中心服務器采用25G網(wǎng)絡互連，與其它廠家的萬兆（10G）網(wǎng)絡性能差距過大,。為了公平起見,，在本次測試中，未選擇阿里云新建25G數(shù)據(jù)中心的云主機進行評測,?！?/p>

云主機網(wǎng)絡帶寬測試結果如下：

云主機網(wǎng)絡帶寬測試結果線圖

云主機網(wǎng)絡帶寬測試結果（Mbps）

64Byte：騰訊云與青云不相伯仲，但測試結果存疑

64Byte是RFC2544測試中所定義的最小測試包長,。采用64Byte的包長進行測試,，主要目的是來看一下不同配置云主機的數(shù)據(jù)包轉發(fā)能力。

從上面的測試圖表中我們可以看出,，在64Byte網(wǎng)絡帶寬測試中,，最好成績?yōu)轵v訊云4核8G云主機，傳輸帶寬可以達到1115.11Mbps,。最低為阿里云32核64G云主機,，傳輸帶寬為310.86Mbps。除阿里云外,，其它三家云主機廠商的云主機64Byte小包的轉發(fā)性能基本都在1Gbps左右,。但這就產生了一個問題：

數(shù)據(jù)包轉發(fā)資源規(guī)劃問題

在云計算的虛擬網(wǎng)絡之中，數(shù)據(jù)包的轉發(fā)是依賴于CPU這個通用處理器進行處理的,。然而作為一個通用處理器,，CPU在處理數(shù)據(jù)包轉發(fā)的時候，效率并不是很高,。過高的數(shù)據(jù)包轉發(fā),，對CPU的處理能力占用，非?？捎^,。

然而通過隨后的大包網(wǎng)絡帶寬測試可以了解，百度云,、騰訊云,、青云最高也就是2Gbps左右的水平。小包時如此高的轉發(fā)性能,，對計算資源造成的浪費相對較高,。

為了對測試結果進行驗證，我們又對阿里云、百度云,、騰訊云,、青云的虛擬網(wǎng)絡端口重新測試并進行端口流量和數(shù)據(jù)包統(tǒng)計。

阿里云64Byte測試數(shù)據(jù)包統(tǒng)計截圖

百度云64Byte測試數(shù)據(jù)包統(tǒng)計截圖

騰訊云64Byte測試數(shù)據(jù)包統(tǒng)計截圖

青云64Byte測試數(shù)據(jù)包統(tǒng)計截圖

通過虛擬端口數(shù)據(jù)包統(tǒng)計我們可以了解,，64Byte文件傳輸中帶寬最低的阿里云云主機的數(shù)據(jù)包轉發(fā)速率反而最高,，達到30萬PPS左右。轉發(fā)帶寬最高的騰訊云主機的數(shù)據(jù)包轉發(fā)速率只能列到第二位,，轉發(fā)速率在15.6萬PPS左右,。按照物理千兆帶寬64Byte小包線速1.488MPPS（148.8萬PPS）計算，除阿里云外,，其它公有云廠商64Byte小文件數(shù)據(jù)傳輸帶寬與其轉發(fā)速率并不相符,。

問題分析：

實際上，當前的測試結果已經(jīng)是至頂網(wǎng)第二次對這幾家公有云主機進行測試而取得的,。在第一次時,，64Byet小包測試中，阿里云云主機也曾得到過1.1Gbps左右的測試成績,，但在向各家云主機廠商反饋測試結果時,，阿里云就即刻指出，測試結果與阿里云云主機處理性能不符,。

原因是為減輕虛擬網(wǎng)絡數(shù)據(jù)轉發(fā)負擔,，在數(shù)據(jù)包轉發(fā)時，虛擬網(wǎng)絡會自動對數(shù)據(jù)包進行合并（將TCP的較小數(shù)據(jù)包合并成一個大數(shù)據(jù)包后向目的地址發(fā)出）這樣在進行小包測試時,，就會出現(xiàn)這種“擴包”現(xiàn)象,，一個小數(shù)據(jù)包被虛擬網(wǎng)絡打成一個大數(shù)據(jù)包轉發(fā)，因此虛擬網(wǎng)絡傳輸時網(wǎng)絡帶寬自然就大大增加,。

在UDP傳輸時,，由于不帶傳輸狀態(tài)，所以UDP傳輸時不存在這種數(shù)據(jù)包歸并現(xiàn)象,，這一點同樣可以在TCP與UDP的傳輸性能對比中加以佐證,，在進行同樣包長的虛擬網(wǎng)絡性能測試中，TCP傳輸性能往往要好于UDP傳輸性能,；而置于傳統(tǒng)網(wǎng)絡環(huán)境中,，UDP的傳輸性能則會表現(xiàn)的更好。

然而考慮到在當前的網(wǎng)絡環(huán)境下,，數(shù)據(jù)傳輸還是以TCP協(xié)議為主,，而UDP則更多的用于一些對網(wǎng)絡傳輸可靠性要求不高的音、視頻數(shù)據(jù)傳輸之中,。因此,，在本次測試中,，還是選用了在TCP協(xié)議中的網(wǎng)絡轉發(fā)性能進行評估。

在本次測試中,，我們試圖通過Netperf加上-D參數(shù)（-D 參數(shù)的含義是：對本地與遠端系統(tǒng)的socket設置TCP_NODELAY選項,，其目的是快速準確發(fā)包）,，對這個問題進行規(guī)避,。但是從當前的測試結果來看，除阿里云在測試中的轉發(fā)速率與轉發(fā)帶寬相匹配外,，其它云主機小包數(shù)據(jù)傳輸還有很明顯的數(shù)據(jù)包合包（小包合并成大包）現(xiàn)象出現(xiàn),。因此在測試中，出現(xiàn)了64Bytes小包測試時數(shù)據(jù)包轉發(fā)性能與傳輸帶寬不匹配的情況,。（有關轉發(fā)速率與數(shù)據(jù)包合包的關系,，至頂網(wǎng)還會再找個時間，更進一步去進行了解,。）

512Byte-Max：

在虛擬網(wǎng)絡中,，數(shù)據(jù)包的轉發(fā)速率應當如何設置才會比較合理？為此,，至頂網(wǎng)又分別對512Byte,、1518Bytes以及虛擬網(wǎng)絡可允許的最大數(shù)據(jù)緩沖文件傳輸性能進行了測試。

采用512Byte數(shù)據(jù)包長進行測試,，是因為在以往傳統(tǒng)網(wǎng)絡及網(wǎng)絡安全產品測試中發(fā)現(xiàn),，512Byte最接近實際網(wǎng)絡應用中的平均數(shù)據(jù)包長（約700-800Byte）。用它測試,，可以比較真實反映傳統(tǒng)網(wǎng)絡中實際的帶寬處理能力,。于是在虛擬網(wǎng)絡測試中，還繼續(xù)沿用了這個測試包長進行測試,。但虛擬網(wǎng)絡TCP傳輸具有合包現(xiàn)象,、而且最大包長也和傳統(tǒng)網(wǎng)絡有所不同。因此虛擬網(wǎng)絡平均包長還有待今后進行更多的虛擬網(wǎng)絡應用分析來確定,。期望那時候,，可以得到更加明確的虛擬網(wǎng)絡數(shù)據(jù)包轉發(fā)速率實際應用情況。

從512Byet開始,，這些云主機網(wǎng)絡帶寬性能明顯分為兩種結果：阿里云云主機與非阿里云云主機,。

阿里云

從512Byte起，本次測試中的阿里云主機網(wǎng)絡帶寬就開始出現(xiàn)分層,，2核4G云主機的網(wǎng)絡帶寬始終保持在1.1Gbps左右,，4核8G云主機的網(wǎng)絡帶寬在1.6Gbps左右，而32核64G云主機在512Byte時在2Gbps左右（注：在本項測試中,，只開啟Netperf的單進程進行測試,，導致測試壓力的不足，小數(shù)據(jù)包流量有所下降），1518-Max時達到6.5Gbps左右,。從當前測試結果來看,，阿里云對不同配置的云主機網(wǎng)絡帶寬，進行了細致的劃分,，云主機的配置越高,，分配的網(wǎng)絡帶寬也得到了相應的增長。

從作者個人角度來看,，拖服務器后腿最嚴重的,，實際上要數(shù)網(wǎng)絡帶寬。早在03,、04年的時候,，本人開始對服務器的網(wǎng)絡應用能力進行測試，那個時候千兆網(wǎng)絡接口就已經(jīng)出現(xiàn)了,。而到現(xiàn)如今,，服務器的處理器無論是從主頻，還是從處理器核數(shù)上,，都有了飛速的增長,，而千兆的網(wǎng)絡接口卻依然雷打不動的固化在服務器之上。在作者看來,，網(wǎng)絡傳輸能力與應用處理性能的不匹配是間接推動服務器虛擬化,，乃至于目前云計算技術發(fā)展的一個重要原因……

能力越大，責任也就越大,。如果用戶云主機主要是進行Web類應用處理的時候,，云主機的計算能力越高，所需要的網(wǎng)絡帶寬自然也需要相應的增加,。這樣一來也就不難理解阿里云云主機的網(wǎng)絡帶寬,，在不同的配置之下也會有所不同的原因了。至于這個帶寬配置是否合理,，在接下來的應用連接性能測試中,，我們至頂網(wǎng)還會更進一步的去進行分析。

（*有關阿里云32核云主機的網(wǎng)絡帶寬在512Bytes時,，僅達到了2Gbps的問題,，我們會在下面“多隊列網(wǎng)卡與單進程測試”的技術分析時會再詳細進行分析。）

百度云,、騰訊云,、青云

之所以將其它三家云主機廠商放到一起進行分析，是因為從512Bytes起,，這些云主機廠商不同配置的云主機網(wǎng)絡帶寬就基本處于“一個水平線”上,，基本都在1Gbps到2Gbps之間徘徊,。

實際上在第一次對云主機網(wǎng)絡性能測試的時候，百度云云主機的網(wǎng)絡帶寬是呈現(xiàn)全放開的一種狀態(tài),，各種配置云主機的最大網(wǎng)絡帶寬均可以達到5Gbps以上,。但是當?shù)谝淮谓Y果反饋回去之后，現(xiàn)在已經(jīng)迅速將網(wǎng)絡帶寬調整到了950Mbps左右,。

百度云云主機第一次網(wǎng)絡帶寬測試結果

上面談到過,，更高性能的云主機，需要有更高的網(wǎng)絡帶寬對其應用進行保障,。但百度云,、騰訊云和青云并未向云主機提供更高的網(wǎng)絡帶寬是出于什么樣的考慮呢,？在這里想對云主機網(wǎng)絡帶寬設置,，更進一步的來討論一下：

還是以目前常見的Web應用為例，在目前的云計算系統(tǒng)中,，要想對大流量,、高并發(fā)的網(wǎng)絡應用請求進行處理的時候，通常是采用負載均衡的方式,，將應用請求平均分配到多個云主機上分別進行處理,。在具有多個計算核心的云主機內部也是一樣，需要將應用請求分發(fā)到每個計算核心之上,，才可以將多核云主機的處理能力充分的發(fā)揮出來,。

是通過一條高帶寬的虛擬網(wǎng)絡將應用請求發(fā)送到一個高處理能力的多核云主機上進行處理？還是通過多條較低帶寬的虛擬網(wǎng)絡,，將應用請求分發(fā)到多個處理能力較低的云主機上通過負載均衡的方式處理,？這個問題還需要根據(jù)具體的應用需求去具體的分析。

相對來說,，經(jīng)過多年技術發(fā)展完善的負載均衡技術,，在網(wǎng)絡傳輸穩(wěn)定性和可靠性方面都有很好的技術保障。如果用戶應用的計算量并不是很大的話,，通過負載均衡將訪問流量分配到較低配置和帶寬的云主機上,，在技術可行性上會更加的適宜。

當然,，像騰訊云32核心64G內存云主機配置下,，還只為云主機配置1Gbps左右的帶寬，是為了解決什么應用需求,，還需要更進一步去研究一下,。

此外，由于青云高配置云主機需要另外提交“工單”進行配置,，與此次想對各廠家云主機“本色”進行測試的目標不符,，因此未進行測試,。

多隊列網(wǎng)卡與單進程測試

在上面的結果分析中，還有一個細節(jié)沒有分析到,，那就是選測的青云云主機雖然只有兩種配置,，確有4個測試成績，其中兩個標注了“多網(wǎng)卡”,。

這里的“多網(wǎng)卡”全稱應是“多隊列網(wǎng)卡”：多隊列網(wǎng)卡技術,，最初是用來解決網(wǎng)絡IO QoS （quality of service）問題的，后來隨著網(wǎng)絡IO帶寬的不斷提升,，單核CPU不能完全滿足網(wǎng)卡的需求,，通過多隊列網(wǎng)卡驅動的支持，將各個隊列通過中斷綁定到不同的核上,，以滿足網(wǎng)卡的需求,。

在青云通過控制臺創(chuàng)建云主機的時候，可以很輕易的通過點選“網(wǎng)卡多隊列”選項的方式,，對多隊列網(wǎng)卡功能進行應用,。

可是從當前對青云云主機的測試結果來看，青云云主機在加載多隊列網(wǎng)卡功能后,，64Byte小包帶寬提升有限,，但大包網(wǎng)絡帶寬反而受到了影響。

初步分析,，這是由于Netperf這個測試命令在測試過程中,，只打開了一個進程，因此無法將數(shù)據(jù)轉發(fā)請求平均分配到多個網(wǎng)卡上進行處理的原因,。但是當我們準備加大測試時長,，并開啟多個Netperf進程進行測試的時候，卻被青云的網(wǎng)絡安全策略所攔阻,，無法繼續(xù)進行評測,。

多進程——來自阿里的復測

在第一次測試結束后，我們曾將結果發(fā)給這幾家云計算廠商進行確認,。沒想到很快阿里方面就傳來了反饋“測試方法不能反映阿里云云主機采用多隊列網(wǎng)卡技術后的最大性能,，并愿意提供阿里內部測試方法進行復測”?？梢越佑|到更多評測技術,，當然是我們至頂網(wǎng)所喜聞樂見的一個事情，于是又開始了一次針對阿里云32核64G內存云主機網(wǎng)絡帶寬和連接的復測活動,。

原本我們考慮到多線程問題,，也曾經(jīng)嘗試啟用多個云主機并使用iperf測試工具來對網(wǎng)絡帶寬進行測試，然而這樣測試的結果統(tǒng)計問題并沒有很好的得到解決,。因此這種測試的成績也未對外放出,。而且由于是在公有云上進行測試,，在現(xiàn)網(wǎng)環(huán)境中進行性能測試，更需要小心翼翼,，即便是在一個VPC網(wǎng)絡內部,，也怕會對公有云網(wǎng)絡造成什么不良的影響。

可阿里提供的測試方案要激進的多,，通過編寫腳本起100個netperf測試線程,，在200秒的測試時間內，同時對被測端進行測試,。而結果統(tǒng)計是通過查看被測端口流量的方式,。

Netperf單字節(jié)TCP轉發(fā)性能測試虛擬端口數(shù)據(jù)包速率統(tǒng)計

Netperf單字節(jié)UDP轉發(fā)性能測試虛擬端口數(shù)據(jù)包速率統(tǒng)計

為了方便直觀的對數(shù)據(jù)包轉發(fā)性能進行統(tǒng)計，在本項測試中,，將數(shù)據(jù)包轉發(fā)速率的測試字節(jié)大小定在了1Byte,，通過被測端口數(shù)據(jù)包轉發(fā)統(tǒng)計可以了解，阿里云32核64G云主機虛擬網(wǎng)絡端口的TCP轉發(fā)性能平均在2.2Mpps以上,，UDP的數(shù)據(jù)包轉發(fā)性能更可以提升至2.5Mpps,。這樣的轉發(fā)性能基本上可以滿足64Byte小包接近2G帶寬的數(shù)據(jù)轉發(fā)需求。以此推斷,，在256Byte就可以滿足8G網(wǎng)絡帶寬數(shù)據(jù)傳輸。阿里云32核64G云主機的網(wǎng)絡帶寬限制是在6.5Gbps（在上面不同云主機網(wǎng)絡帶寬測試中已經(jīng)驗證,，就不再重復測試了）左右來分析,，其可以提供充足的數(shù)據(jù)包轉發(fā)能力滿足網(wǎng)絡數(shù)據(jù)傳輸需求。

通過這個測試,，也讓我們對阿里云的虛擬網(wǎng)絡,，在高轉發(fā)速率下的網(wǎng)絡健壯性，有了更加充分的體驗,。

TEST2：云主機網(wǎng)絡連接能力評估

當前云計算網(wǎng)絡系統(tǒng),，是基于軟件定義網(wǎng)絡（SDN）進行的“轉發(fā)”與“控制”分離。對于上述幾個公有云的云主機轉發(fā)能力,，通過網(wǎng)絡帶寬我們已經(jīng)有了一個大致的了解,。而控制能力還需要去更進一步進行研究。

對于“控制”而言,，實際上就是在帶寬這條大馬路上劃出一條條行車的車道,。車道太少，需要上路的車都要排隊,，會影響傳輸效率,。車道太多，馬路上車輛擁擠,，同樣會對網(wǎng)絡傳輸造成不良的影響,。

當前這幾個云廠商的網(wǎng)絡控制能力如何,？至頂網(wǎng)通過云主機的網(wǎng)絡連接建立能力同樣進行了一次檢測。

在測試中,，至頂網(wǎng)選用的是Netperf加載TCP_RR和TCP_CRR參數(shù),，對云主機的網(wǎng)絡連接能力進行測試。為了了解在不同文件大小情況下,，云主機的連接建立情況,，本次測試還將本地和遠端系統(tǒng)的Socket發(fā)送與接收緩沖大小分別設置為64Bytes、1024Byte,、10240Byte,、102400Byte以及1024000Byte。

首先要來談一下的是Netperf測試所存在的問題：各廠商云主機配置不同,，網(wǎng)絡連接測試的成績十分相近,。在大文件應用傳輸時，如果網(wǎng)絡帶寬相同,，受到帶寬的限制,，云主機的網(wǎng)絡連接測試成績相近這很好理解。但是不同配置不同帶寬的云主機,，網(wǎng)絡連接性能如此相近就只能說明一件事情：應用請求沒有平均分配到各個計算核心上去,。這個測試所體現(xiàn)的，很有可能只是單個CPU內核的網(wǎng)絡應用處理能力,。

即便是單個核心,，也不妨礙我們去對這個云主機的網(wǎng)絡連接處理情況進行一下分析。下面我們就去具體的分析一下：

TCP_RR：

同帶寬測試一樣,，在應用連接中,，64Byte的數(shù)據(jù)傳輸也是屬于“神話”這個級別——只會在傳說中存在，在實際應用中用戶是萬萬不可能見到的,。（如果真出現(xiàn)的話,，那就是CC或DDoS了。）之所以64Byte甚至1Byte的應用連接測試至今還在使用,，是因為通過對作為TCP/IP定義的最小包長測試,，可以了解產品的最大處理性能。在網(wǎng)絡帶寬的測試中,，了解的是數(shù)據(jù)包轉發(fā)的處理能力,。而在連接性能測試中，同樣也可以對網(wǎng)絡連接建立能力進行評估,。并且由于連接建立通常是交由CPU進行處理,，因此在網(wǎng)絡應用性能測試中，最大連接處理能力，同樣也是對服務器網(wǎng)絡應用計算能力的一項重要評估,。

現(xiàn)在我們就通過Netperf加載TCP_RR和TCP_CRR參數(shù)來了解一下這幾個云主機“疑似”單核的最大網(wǎng)絡連接處理性能,。

為什么說是“疑似”單核，是因為測試結果有些讓人困惑,。首先看連接建立能力最強的阿里云主機,，64Byte時連接建立能力均在每秒1萬連接以上這讓其當仁不讓的站上了連接處理能力最強的第一梯隊。然而隨著內核數(shù)量的提升,，云主機處理性能會有一定幅度的下降,，不過這到可以理解，多核處理器在處理應用請求的時候本身就要先做一個判定,，是用哪一個內核去進行處理,，即便是一個單進程的處理任務只劃分到其中一個內核去進行處理，也需要進行一下判斷和計算資源分配,，這自然也會消耗掉一定的處理時間,，處理能力自然會有所下降。

但是在青云的云主機上,，情況正好相反,，4核8G云主機的連接處理能力好于2核4G的云主機，但性能又不是成倍的提升,，64Byte每秒1萬連接所占帶寬僅在5Mbps左右,，也遠沒有超出網(wǎng)絡帶寬限制范圍之外，這樣的結果到底是在云系統(tǒng)中進行了連接數(shù)限制,，還有有其它原因,？還有待進一步去進行了解。

從云主機網(wǎng)絡連接TCP_RR測試結果線圖可以看出,，除阿里云云主機外，其他云主機網(wǎng)絡連接建立能力從2048Byte開始出現(xiàn)大幅下降,。而此時,，即便是按連接處理能力最高的阿里云6500以上的網(wǎng)絡連接建立能力計算，其網(wǎng)絡傳輸帶寬也未能超過540Mbps,，可以確定并不是因為網(wǎng)絡帶寬的限制導致了網(wǎng)絡連接建立能力的下降,。

那么是由于數(shù)據(jù)包轉發(fā)性能設置過高，造成的應用連接處理能力下降,，還是這些云主機在處理多數(shù)據(jù)包時CPU處理能力降低,？（10240Byte及以后的測試文件大小超出了虛擬網(wǎng)絡的最大數(shù)據(jù)緩沖文件大小，會分成多個數(shù)據(jù)包進行轉發(fā)）,。這種情況對實際網(wǎng)絡應用會造成什么樣的影響,？這些問題還需要在今后深入研究。

TCP_CRR

按照Netperf的解釋,，采用TCP_CRR參數(shù),，會在連接數(shù)據(jù)傳輸完畢后,，將連接進行斷開。更像是實際網(wǎng)絡中HTTP協(xié)議傳輸數(shù)據(jù)時的情況,。由于每次連接都需要重新進行建立,，對服務器的應用負載會更大一些。

在TCP_CRR的測試過程中我們發(fā)現(xiàn)在64Bytes到10240Byte時,，不同云主機的連接處理性能出現(xiàn)了明顯的“分層”現(xiàn)象,。從云主機網(wǎng)絡連接TCP_CRR測試結果線圖中我們可以清楚的看出，處于最頂層的是阿里云2核4G,、4核8G,、32核64G云主機。下方是青云的4核8G和2核4G云主機,。再下面是騰訊云的32核64G,、4核8G和2核4G云主機。而百度云的云主機處于最低下的位置,。

這個排序,，應該可以比較清晰的體現(xiàn)出不同云主機在“單核”時的網(wǎng)絡應用處理能力了。

原本計劃通過1024Byte-1024000Byte這些不同大小文件,，在進行連接測試的過程中,，同樣對云主機的數(shù)據(jù)傳輸性能再進行一下分析。然而由于測試工具Netperf的單線程測試能力,，并不能將應用連接很好的分配到云主機的多核處理器之上,，因此云主機有限的處理能力，不能很好的對網(wǎng)絡數(shù)據(jù)傳輸進行處理,。

但是1024000Byte這種接近1MBytes的文件大小對于云主機的處理能力要求已經(jīng)是十分的有限了,，可是在測試結果中百度云和騰訊云的云主機依然未達到1000Mbps的網(wǎng)絡傳輸帶寬，這樣的應用處理能力就讓人十分費解了,。而且在這種大文件之下,，騰訊云的連接處理能力會被百度云進行反超，這個問題,，還有待更進一步了解,。

注：阿里云在2核4G云主機上133TPS的成績應該是受到其1.1Gbps網(wǎng)絡帶寬的影響，青云的處理情況應當也是同理,。（1024000*8*133=1089536000bps）,，騰訊云與青云傳輸帶寬相仿，但連接處理速率相差比較明顯,。

阿里的多線程網(wǎng)絡連接性能測試

同樣,，在阿里技術人員的肯定與支持下，至頂網(wǎng)也對阿里云32核64G云主機的多線程網(wǎng)絡連接處理能力進行了測試：通過編寫腳本起大量netperf -TCP_RR與netperf -TCP_CRR測試線程的方式，在200秒的測試時間內,，對被測端進行測試,。

同樣為了方便進行統(tǒng)計，對網(wǎng)絡連接性能的測試字節(jié)大小定在了1Byte,，嘗試著通過統(tǒng)計收,、發(fā)端口的數(shù)據(jù)包傳輸速率，對TCP的連接建立速率進行統(tǒng)計,。

通過收集被測端口數(shù)據(jù)包轉發(fā)統(tǒng)計可以了解：在Netperf TCP_RR測試中,，阿里云32核64G云主機網(wǎng)絡連接處理能力達到了74萬PPS以上的成績。而在Netperf TCP_CRR測試中,，連接處理能力有所下降,，達到44萬PPS的處理成績。（注：這里統(tǒng)計的還是云主機虛擬網(wǎng)口的數(shù)據(jù)包轉發(fā),，在連接建立時還會有建立連接的握手等數(shù)據(jù)包同樣統(tǒng)計在其中,，其實際處理能力有待今后采用更專業(yè)的測試工具或方法再進行驗證。）

netperf TCP_RR

netperf TCP_CRR

考慮到上面這種測試方案過于“激進”,，為避免對其他公有云廠商虛擬網(wǎng)絡造成過大影響,，這個測試就沒有在其它公有云上進行復測。希望今后有機會可以對更多公有云網(wǎng)絡系統(tǒng)進行更全面的性能展示,。

對于上面的應用測試結果,，至頂網(wǎng)想表達的觀點有兩點：

1、對阿里云云主機的網(wǎng)絡連接處理能力表示肯定,。強大的網(wǎng)絡連接處理能力,，為網(wǎng)絡應用傳輸提供了充分的計算能力保障。

2,、現(xiàn)階段給每個應用請求分配10Mbps的網(wǎng)絡帶寬,，基本上可以保障常見網(wǎng)絡應用的流暢運行。即便是減少到1Mbps帶寬時,，對于以圖文為主的應用,，用戶也并非不可以接受。但是在每兆帶寬上有10個以上的新建連接請求時,，最好還是進行“報警”處理的比較好。無法及時處理的應用請求會迅速產生應用請求的堆積,，對應用和網(wǎng)絡系統(tǒng)產生無法預測的應用壓力,。

問題小結：應用與帶寬

本次至頂網(wǎng)對公有云云主機網(wǎng)絡應用性能的“摸底”測試活動至此就告一段落了。現(xiàn)在將本次測試活動發(fā)現(xiàn)的問題在這里小結一下：

健壯性值得肯定,，應用與帶寬處理尚待完善

首先值得肯定的是,，在本次評測活動中，這幾家公有云廠商的云主機產品，都十分順利的完成了網(wǎng)絡帶寬與應用處理能力的評測,。對現(xiàn)實中正在使用的網(wǎng)絡進行評測和實驗室網(wǎng)絡評測不同,，一不小心，就會對現(xiàn)網(wǎng)應用造成無法估量的重大影響,。因此,，至頂網(wǎng)這次評測，也是十分的小心翼翼,，生怕會出現(xiàn)什么紕漏,。但根據(jù)目前測試情況來看，雖然測試的這幾個公有云廠商的云主機網(wǎng)絡管理機制有所不同,，但對網(wǎng)絡流量隔離處理的都十分理想,，云主機虛擬網(wǎng)絡健壯性都經(jīng)受住了這次考驗。

其次是計算能力與網(wǎng)絡帶寬的匹配,。在這方面阿里云確實帶了一個好頭,，隨著計算能力提升，網(wǎng)絡帶寬也提供了相應的保障,，希望其它云計算廠商在網(wǎng)絡帶寬設置上也可以更加多樣一些,，為不同網(wǎng)絡應用提供更加靈活的帶寬選擇。

最后想談一下應用連接與網(wǎng)絡帶寬匹配問題,。應用連接對網(wǎng)絡傳輸影響問題的發(fā)現(xiàn),，應該可以追溯到網(wǎng)絡安全的傳奇企業(yè)Netscreen，因此在傳統(tǒng)的網(wǎng)絡及網(wǎng)絡安全產品中,，都對網(wǎng)絡應用性能測試十分的重視,。而依據(jù)現(xiàn)在的測試情況來看，公有云廠商對虛擬網(wǎng)絡的網(wǎng)絡應用連接處理能力認識,，還不是十分深入,。一味追求連接性能，或者對應用連接放任不理都有可能會引發(fā)網(wǎng)絡傳輸?shù)墓收铣霈F(xiàn),。希望今后云計算廠商可以提供出更加合理的網(wǎng)絡帶寬與應用連接匹配規(guī)范,。便于用戶在突然出現(xiàn)高并發(fā)、大流量網(wǎng)絡應用情況時,，可以及時進行處理,，避免網(wǎng)絡連接擁塞問題的出現(xiàn)。

云主機網(wǎng)絡應用優(yōu)勢總結

在本次評測過程中發(fā)現(xiàn),，各個公有云廠商在應用處理時,，有自身不同的特色，在這里也為大家來小結一下：

阿里云：綜合應用處理能力出色

在本次測試中,，網(wǎng)絡及應用處理能力最出色的,，當數(shù)阿里云的云主機產品,。在網(wǎng)絡層上，與物理網(wǎng)絡相仿的數(shù)據(jù)包轉發(fā)處理能力設計,。在傳輸層上,，十分強悍的網(wǎng)絡連接處理性能。比較完美的體現(xiàn)出,，阿里云云主機對不同網(wǎng)絡應用的全面綜合考量,。由此可以更好的適用于各類不同云計算的網(wǎng)絡應用之中。

將以前作者心目中像豆腐渣一樣的虛擬網(wǎng)絡,，做到與物理網(wǎng)絡同樣的穩(wěn)定,，在其中必然有非常大的艱辛付出。

青云：Web應用處理

良好的連接建立能力,，是網(wǎng)站應用訪問的基本保障,。傳輸帶寬雖然沒有很高的設置，但與系統(tǒng)的負載均衡產品結合也可以很好的解決傳輸帶寬的問題,。這樣虛擬網(wǎng)絡設計,，應該可以較好的保障Web類應用處理效果。

未來如果可以將多隊列網(wǎng)卡的網(wǎng)絡帶寬進行更合理的規(guī)劃,，應該可以釋放出更理想的網(wǎng)絡應用處理能力,。

騰訊云：網(wǎng)游及小文件傳輸

在網(wǎng)絡游戲應用中，用戶每一個操作所產生的數(shù)據(jù)量并不很大,，但操作頻次會非常密集,。這也就意味著，在云計算虛擬網(wǎng)絡中,，需要為其提供更強的數(shù)據(jù)包轉發(fā)能力,，但未必會需要有很高的網(wǎng)絡帶寬（微信、QQ等即時通訊產品實際上也有著相似的網(wǎng)絡應用需求）,。從這個角度來考慮,，就不難理解騰訊云為什么沒有為云主機設計很高的網(wǎng)絡帶寬，而提供了較強的數(shù)據(jù)包轉發(fā)能力了,。

如果可以進一步提升大文件時的網(wǎng)絡連接建立性能,，應該可以釋放出更好的網(wǎng)絡應用處理能力。

百度云：文件存儲類網(wǎng)絡應用

對于網(wǎng)絡存儲產品而言,，本身不需要很高的數(shù)據(jù)包轉發(fā)及應用連接處理能力,，但需要有很高的網(wǎng)絡傳輸帶寬進行保障，百度云的低轉發(fā),、低連接和高帶寬虛擬網(wǎng)絡設計,，可以很好滿足網(wǎng)絡數(shù)據(jù)存儲的應用需求。

但是在第二次測試中將其帶寬大幅度降低,，這樣可以適用于何種網(wǎng)絡應用,，還需要再具體去研究一下。

對于云計算的虛擬網(wǎng)絡而言,，網(wǎng)絡帶寬,、轉發(fā)性能乃至于網(wǎng)絡連接的管理控制，都是可以根據(jù)用戶需求去進行調整的,。之所以在本次測試中沒有用“工單”去打攪這些云主機廠商,，就是希望對他們云主機的“原始”云主機性能進行一個了解。從測試所得數(shù)據(jù)來看,，也比較符合這些公有云廠商自身主營網(wǎng)絡業(yè)務特色,。

但是，技術這種“東西”并不是“說有”就可以有的,，需要通過應用能力的展示,，才可以讓用戶去真實了解。在今后還希望各家公有云廠商可以更加開放一些,，可以更加主動的對自身技術性能進行展示,。這樣也可以讓用戶更加有針對性的對公有云產品去進行選擇。

測試的問題與不足

下面總結一下本次測試中的不足：

在本次測試中,，深深感受到現(xiàn)有Linux中的測試工具對多核心,、大規(guī)模云計算系統(tǒng)評測和統(tǒng)計能力不足。而且測試指標和測試方法也存在不完善的地方,。但是目前專業(yè)的虛擬化測試工具現(xiàn)在還很難在各公有云廠商的云計算環(huán)境中進行部署,。

希望今后專業(yè)測試儀表廠商能與公有云廠商相互配合，在公有云廠商的云市場上也提供出專業(yè)的虛擬化網(wǎng)絡測試工具,，方便用戶直接進行使用,。從而使用戶可以更有效的對自身云計算系統(tǒng)應用處理能力有直觀的了解。

測試儀表廠商最好也可以提供一些更加精簡的,、可以輕松在Linux上進行安裝的測試工具,，方便用戶在不同云系統(tǒng)上進行測試。

在這里想告訴大家的是：網(wǎng)絡的世界是一個連接的世界,。無論是物理還是虛擬,、有線或是無線，在網(wǎng)絡中進行合理的連接管理控制,，是網(wǎng)絡應用順暢進行的重要保障,。也期望今后可以有更多云計算廠商，能將他們的網(wǎng)絡帶寬與應用連接管理控制能力,，更多的向用戶展示出來,，為今后的云計算、物聯(lián)網(wǎng)乃至于人工智能提供更堅實的網(wǎng)絡基礎保障,。

公有云主機的技術性能評估,，就暫時告一段落了,，有機會的話，我們還會再更進一步的對公有云廠商的質量控制能力和產品服務水平進行一個評估,。當然還希望各個云計算廠商繼續(xù)給予配合,。