基于LoadRunner的定制化業(yè)務背景流量生成系統(tǒng)

趙 瑜,吳承榮,嚴 明

(復旦大學 計算機科學技術學院,上海 200433)

0 概述

擬態(tài)防御技術[1]等新型網(wǎng)絡安全防御技術的實際效果評估是一個熱門研究課題。目前,常用的評估方法是建立“試驗場”模擬被測業(yè)務系統(tǒng)的日常負載,構(gòu)造可能的攻擊手段,并對防御系統(tǒng)和業(yè)務系統(tǒng)的抵御攻擊能力進行測試?！霸囼瀳觥敝芯W(wǎng)絡流量的主要組成為前景流量與背景流量。在測試過程中精心構(gòu)造的,與測試某項功能(如特定安全防御功能)直接相關的流量為前景流量,而與前景流量無關,且作為實驗環(huán)境存在的正常業(yè)務流量即為背景流量。對一個系統(tǒng)進行評估時,背景流量的作用是將其置于典型的日常運行狀態(tài),使得特定的測量數(shù)據(jù)能夠真實反映其在日常情況下的表現(xiàn)。如擬態(tài)防御、移動目標防御等[2]新型網(wǎng)絡安全防御理念在系統(tǒng)中引入了非確定性因素,防御成功與否不再是確定性事件。目標系統(tǒng)在典型日常運行狀態(tài)下的系統(tǒng)性能表現(xiàn)與防御成功概率是反映系統(tǒng)防御能力的重要指標。然而,非定制化、固定內(nèi)容的簡單背景流量不具備逼真性,不能起到將被測系統(tǒng)置于日常運行典型狀態(tài)的效果,無法真實評估系統(tǒng)防御能力。因此,背景流量的逼真度對評估結(jié)果的有效性意義重大。

背景流量生成的方法包括導入互聯(lián)網(wǎng)實際流量法,以及使用儀器設備等測試儀器生成精確背景流量法。但是前者只能測試防火墻、路由器類二層設備,無法測試交互應用,后者自主性不足,受限于測試儀器提供的協(xié)議支持和自定義功能,通常不能支持符合特定字段的受限隨機定義以及符合特定概率分布要求的定制化流量,無法提供業(yè)務操作的深度模擬。以上2種方法通常只適用于系統(tǒng)穩(wěn)定性測試或壓力測試,均不具備足夠的自主性和可控性,且不能實現(xiàn)按需生成流量,尤其是當流量模擬的需求較復雜細致或模擬精度要求較高時,它們通常無法滿足要求。理想的背景流量生成系統(tǒng)具備的特性有:系統(tǒng)應當基于少量樣本規(guī)模化生成被測系統(tǒng)可接收的逼真背景流量,系統(tǒng)生成的背景流量需要符合被測系統(tǒng)正常運行時所遇背景流量的時空概率分布,背景流量發(fā)送系統(tǒng)能夠?qū)Ρ粶y系統(tǒng)的流量接收狀況進行實時監(jiān)控并可自適應調(diào)節(jié)發(fā)送過程。

上述方法與現(xiàn)有的工具或產(chǎn)品均無法全面支持以上需求,因此,本文將圍繞如何為被測Web業(yè)務系統(tǒng)生成復雜定制化仿真背景流量展開研究,在現(xiàn)有研究的基礎上,提出一個針對Web業(yè)務系統(tǒng)的基于LoadRunner(LR)的定制化業(yè)務背景流量生成系統(tǒng),實現(xiàn)流量的實時監(jiān)控以及自適應調(diào)節(jié),完成對業(yè)務背景流量的深度模擬。

1 國內(nèi)外研究現(xiàn)況

逼真的背景流量生成并非僅依靠反復發(fā)送固定的流量,或者循環(huán)批量發(fā)送實際截獲的流量樣本就能實現(xiàn),這些無效的背景流量在交互式被測系統(tǒng)上將被丟棄,因此,應在識別系統(tǒng)流量模型的基礎上,為流量模型引入隨機化模擬數(shù)據(jù),從而生成逼真流量。流量建模是對流量樣本進行抽象化,參考流量識別的實驗結(jié)果,構(gòu)造一個以生成背景流量為基礎的理論模型。從流量生成角度而言,可將背景流量模型粗略分為時間分布模型、空間分布模型和時空分布模型。時間分布模型是主流的網(wǎng)絡流量模型。傳統(tǒng)的流量模型一般是基于泊松過程,如較為經(jīng)典的泊松(Poisson)模型[3]、馬爾科夫(Markov)模型和回歸(Regression)模型等,這些模型的共同特點為短相關性[4]。文獻[5]提出了網(wǎng)絡流量具有自相似的特性,此后,研究人員相繼提出了很多基于自相似特性的流量模型。常見的自相似網(wǎng)絡流量模型有重尾分布的ON/OFF模型、M/G/∞排隊模型、FBM/FGN模型[6]與FARIMA模型等。空間分布模型可在鏈路層上考慮流量的空間分布,著眼于宏觀上不同鏈路上的流量密度分布,如文獻[7]中的重力模型是基于矩陣來體現(xiàn)和實現(xiàn)流量空間分布,空間特性還體現(xiàn)在網(wǎng)絡熱點的存在、集群的負載均衡策略以及業(yè)務層或用戶層的數(shù)據(jù)流空間分布等方面。時空分布模型是針對流量在時間和空間2個維度上的分布,適用于更精準的模擬需求,但模型耦合度高,且實現(xiàn)過程較為復雜。

在以上理論研究的基礎上,流量生成技術也同步推進,目前,已實現(xiàn)了許多開源或閉源的流量生成工具及軟件。流量生成技術中最簡單的分類是按照流量層次區(qū)分,主要分為數(shù)據(jù)包層次流量生成器、流層次流量生成器和應用層次流量生成器[8-9]等?，F(xiàn)有的常見流量生成器工具[10]主要包括數(shù)據(jù)包級流量生成器Scapy和Cat Karat Packet Builder,基于libpcap的以太網(wǎng)數(shù)據(jù)包生成器Bit-Twist,Linux內(nèi)核級數(shù)據(jù)包生成器KUTE,應用程序和數(shù)據(jù)包級網(wǎng)絡生成器D-ITG,還有用戶友好的GUI和詳細的數(shù)據(jù)包頭定制功能的數(shù)據(jù)包級流量生成器Ostinato,根據(jù)各種流量特性產(chǎn)生合成流量的HAR-POON,以及根據(jù)真實軌跡的特征生成流量的高級流量生成器SWING等。雖然現(xiàn)已實現(xiàn)較多優(yōu)秀的開源或商業(yè)流量生成工具,但它們的設計初衷多數(shù)是針對壓力測試、極限測試等需求,日常背景流量的逼真模擬并不是其主要的追求目標。因此,它們較少關注流量的時空分布和一些涉及業(yè)務的流量特征分布,無法很好地完成流量的按需生成和對業(yè)務背景流量的深度模擬?；诖?為滿足“試驗場”對Web類型業(yè)務背景流量的仿真需求,本文設計并實現(xiàn)一個基于Web的業(yè)務背景流量生成系統(tǒng),可生成定制化的深度仿真業(yè)務背景流量。

2 系統(tǒng)設計

2.1 總體設計思路

在“試驗場”中,由于業(yè)務系統(tǒng)在短期內(nèi)業(yè)務模式變動有限,且具有一定的可重復性和可提取性,因此可采用負載生成工具作為流量模擬系統(tǒng)的生成源。網(wǎng)絡壓測(或負載測試)工具在市面上種類繁多,著名的諸如LoadRunner、Apache JMeter[11]等。Apache JMeter是一個利用Java實現(xiàn)的開源壓力測試工具,LoadRunner是一款模擬實際用戶操作,并對系統(tǒng)進行實時監(jiān)測的負載測試軟件。Apache JMeter設計小巧但依賴JDK環(huán)境,腳本修改與擴展大多基于對功能模塊的熟悉,而不依賴編程,且監(jiān)測與結(jié)果分析功能沒有LoadRunner健全,同時,軟件生態(tài)系統(tǒng)也不如LoadRunner完整。LoadRunner從版本12.55開始兼容Apache JMeter腳本,因此,本文系統(tǒng)的實現(xiàn)選擇基于LoadRunner。LoadRunner作為一款性能測試工具,雖然為流量生成提供了數(shù)據(jù)包構(gòu)造的核心功能,但單獨使用時依然不能滿足項目需求。首先,它不支持流量的時空分布等特征的實現(xiàn)。LoadRunner對于流量在時序上的分布,僅考慮以性能為主的同步到達模式[12],即使支持異步到達,粒度也過于粗糙且隨意。同時,在壓力測試過程中,用戶思考時間往往被忽略,這顯然不符合流量仿真模擬的需求。其次,它采用進程或線程模擬獨立的虛擬用戶,可能在一定程度上出現(xiàn)計算資源或操作系統(tǒng)資源受限的情形,但在真實場景中這種情況基本不會出現(xiàn)。最后,LoadRunner的處理邏輯是基于重復腳本的形式,但是在實際網(wǎng)絡中,即使是同一個操作的數(shù)據(jù)包構(gòu)造也不盡相同,因此需要通過定制實現(xiàn)流量內(nèi)容的異構(gòu)化(如操作與請求的異構(gòu)),同時也實現(xiàn)流量中數(shù)據(jù)(即內(nèi)容)的異構(gòu),而不是簡單的重復。

本文系統(tǒng)采用以下技術解決上述問題:

1)使用以基于泊松過程的ON/OFF模型為主、思考時間等時間分布相關指標為輔的方式,實現(xiàn)流量在鏈路層、應用層和用戶層的時間分布深度仿真。

2)以一個單獨模塊實現(xiàn)流量中網(wǎng)絡實體空間分布。

3)為了更加真實地還原用戶場景,流量生成采用基于容器的分布式流量發(fā)送陣列方式,這是因為選擇分布式部署方式能夠便捷地擴展大規(guī)模網(wǎng)絡的流量生成,解決資源上限問題,且容器技術便于一致性部署與調(diào)控。

4)開發(fā)可擴展腳本實現(xiàn)流量內(nèi)容的深度異構(gòu),包括操作異構(gòu)與請求異構(gòu)等?？稍谒枇６壬蠈I(yè)務操作的各種變量進行精確賦值,模擬生成大規(guī)模復雜異構(gòu)網(wǎng)絡下的用戶產(chǎn)生的業(yè)務背景流量。

5)設計一個負責實施監(jiān)控與自反饋調(diào)節(jié)的模塊來自動更正參數(shù)偏移,使其具有自適應性,以保證結(jié)果的可測與可控,從而形成閉環(huán)結(jié)構(gòu)。

2.2 本文系統(tǒng)整體架構(gòu)

本文系統(tǒng)主要由9個功能模塊組成,具體如圖1所示。該系統(tǒng)基于Web應用場景中經(jīng)典的C/S架構(gòu),主要在客戶端之前與客戶端之后擴展或插入功能模塊,最后可在系統(tǒng)邊界與服務器之間得到目標流量。

圖1 本文系統(tǒng)整體架構(gòu)Fig.1 Overall architecture of the proposed system

本文系統(tǒng)整體架構(gòu)中9個模塊的主要功能分別為:

1)流量分析模塊。流量分析模塊是系統(tǒng)運行的前期準備模塊。針對待測業(yè)務系統(tǒng)進行業(yè)務操作、通信模式的識別,遵循請求-應答的基本操作對模式,整理出業(yè)務操作對雙向流,選取典型的業(yè)務類型及操作并對時序組合,以此作為LoadRunner腳本的初期結(jié)構(gòu)。

2)輸入模塊。輸入模塊是系統(tǒng)一次運行的起點,也是與用戶交互的窗口。輸入模塊向用戶提供GUI和簡單的錯誤反饋信息,并接收流量分析結(jié)果轉(zhuǎn)化的規(guī)范化配置信息,以YAML配置文件作為標準輸入形式。

3)預處理模塊。預處理模塊接收系統(tǒng)首次輸入的控制信息與重要參數(shù),生成啟動核心生成模塊的重要參數(shù)文件和配置文件。

4)LoadRunner核心控制模塊。LoadRunner核心控制模塊與負載生成模塊合作負責數(shù)據(jù)包的初步生成和發(fā)送。LoadRunner核心控制模塊主要由LoadRunner Controller部件擴展而來,根據(jù)配置啟動LoadRunner Controller,并同步調(diào)用負載生成器,指導負載生成器發(fā)起客戶端請求并生成流量。

5)負載生成模塊。負載生成模塊是實際產(chǎn)生流量的模塊,由若干負載生成器(Load Generator)組成,向上承接同步模塊與LoadRunner核心控制模塊的控制命令,向下模擬真實客戶端向目標服務器發(fā)起請求,并生成流量。負載生成模塊應具有良好的可擴展性,其設計為分布式結(jié)構(gòu)。每一個負載生成器的核心是Load Generator容器。

6)空間分布實現(xiàn)模塊?？臻g分布實現(xiàn)模塊與實時監(jiān)測模塊均在拓撲上,處于系統(tǒng)的邊界,且與被測服務器端鄰近?？臻g分布實現(xiàn)模塊實現(xiàn)對流量空間分布的控制,在負載生成器之后,并對數(shù)據(jù)包中代表空間分布的重要特性進行重寫,如IP等。在空間分布實現(xiàn)模塊之后流量將最終定型,不再有其他修改。

7)實時監(jiān)測模塊。實時監(jiān)測模塊對負載生成器生成的、且經(jīng)過空間分布實現(xiàn)模塊轉(zhuǎn)換后的流量進行實時監(jiān)控。實時監(jiān)測模塊是系統(tǒng)自適應調(diào)控流量生成的依賴,且最后可根據(jù)實時監(jiān)測的日志信息,得到更完整的錯誤提示與結(jié)果評估依據(jù)。

8)反饋調(diào)節(jié)模塊。反饋調(diào)節(jié)模塊幫助系統(tǒng)形成一個閉環(huán)。它處理實時監(jiān)測模塊收集的信息,合成反饋調(diào)節(jié)指令,并通知同步模塊,后者通過修改配置參數(shù)及參數(shù)文件的方式實時調(diào)整負載生成器的工作,由此保證系統(tǒng)流量生成的準確性。

9)同步模塊。同步模塊接收反饋信息,實時修改重要參數(shù),并利用同步模塊向LoadRunner核心控制模塊和各負載生成器發(fā)送控制信息并傳輸文件,協(xié)助整個系統(tǒng)的閉環(huán)調(diào)節(jié)機制工作。

依賴以上模塊,本文系統(tǒng)可實現(xiàn)定制化流量的深度仿真功能。接下來將詳細說明該系統(tǒng)實現(xiàn)的主要技術與關鍵方法。

2.3 定制化背景流量生成的關鍵方法

2.3.1 LoadRunner核心功能的使用

LoadRunner是原Mercury公司、現(xiàn)HP公司開發(fā)的一項自動負載測試工具,它能模擬實際網(wǎng)絡用戶的操作,以此產(chǎn)生流量。LoadRunner主要由Virtual User Generator(VUGen)、Controller、Load Generator、Analysis和Launcher 5個部件組成。其中,VUGen用于建立虛擬用戶腳本,Controller是實施負載測試的控制中心,Load Generator是流量生成的真實源。LoadRunner的工作流程[13]如圖2所示。

圖2 LoadRunner工作流程Fig.2 Workflow of LoadRunner

LoadRunner具有參數(shù)化的擴展功能,但是并不提供任何關于流量分布或概率的控制。本文系統(tǒng)利用LoadRunner的核心功能,即模擬用戶生成數(shù)據(jù)包功能,并著眼于擴展定制化腳本的開發(fā)與修改,在原VUGen腳本的基礎上,擴展其他如思考時間分布化、流量異構(gòu)化內(nèi)容的隨機生成等功能,使系統(tǒng)對交互的控制更佳、對測試的表現(xiàn)力更強,且生成的流量更細致逼真。在結(jié)合流量生成需求的場景下,再輔以其他功能模塊的容器技術、分布式架構(gòu)和自適應技術等,實現(xiàn)流量的按需發(fā)送與深度仿真。LoadRunner支持的協(xié)議很多,鑒于本文主要針對Web類型流量,可選擇TCP、HTTP、HTTPS或WebSocket等協(xié)議進行腳本編寫。若考慮到更便捷地保留請求與附加資源的關聯(lián)性,則應用層協(xié)議是更好的選擇。

2.3.2 基于ON/OFF模型的流量生成

本文系統(tǒng)采用重尾分布的ON/OFF模型作為時間分布模型,負載生成模塊中的各節(jié)點作為模型中的生成源。重尾分布的ON/OFF模型能夠較好地解釋流量自相似特性的形成原因[14],因此,本文系統(tǒng)以其作為流量時間分布的實現(xiàn)參考模型。

若一個隨機變量X的分布函數(shù)滿足式(1),則其滿足重尾分布。

(1)

研究表明,重尾分布的ON/OFF模型符合電信系統(tǒng)與網(wǎng)絡流量的自相似性。

本文系統(tǒng)采用最常見、最簡單的重尾分布,即Pareto分布,它的概率密度函數(shù)[17]和分布函數(shù)分別為:

(2)

(3)

其中,α為形狀參數(shù),β為最小截止參數(shù)。

在流量生成測試過程中,在鏈路上若以恒定速率傳輸文件,則理論上一個文件的傳輸時間可以趨于無窮。但源具有最小單位的持續(xù)時間,這可能是一個數(shù)據(jù)包的發(fā)送時間,且在概率上較小的持續(xù)時間是占多數(shù)的,因此,重尾分布使得ON態(tài)的持續(xù)時間以短時為主,但從統(tǒng)計角度而言,長的持續(xù)時間起著決定性作用。實際上,文件的傳輸時間總是有限的,不可能出現(xiàn)理論上ON態(tài)無限持續(xù)時間的情形,因此系統(tǒng)采用截尾重尾分布(Truncated Heavy-Tailed Distribution),即當持續(xù)時間超過某一上限時,截取其值為上限值或重新取值即可。本文系統(tǒng)利用預處理模塊接收模型參數(shù),生成具有重尾分布的ON/OFF態(tài)時間序列的參數(shù)文件,且文件指明了每個ON態(tài)以及OFF態(tài)的持續(xù)時間。在負載生成器啟動階段,將該參數(shù)文件同步給各負載生成器,負載生成器各自根據(jù)參數(shù)文件,通過執(zhí)行腳本時檢查當前時間與ON態(tài)預定時間段是否重合,以此判斷是否應當發(fā)送下一個數(shù)據(jù)包。在理論上,控制粒度應為發(fā)送一個數(shù)據(jù)包的時間,但是實際上對腳本層次進行控制時,處理的最細粒度為一次請求-響應的過程,因此該方法的實現(xiàn)過程對精度的控制有限。

在模型實現(xiàn)前需計算有關參數(shù),實現(xiàn)ON/OFF模型的一個重點是ON/OFF態(tài)時間周期的確定[18]。對于服從Pareto分布的情形,生成符合分布的周期隨機數(shù)需要確定α和β的值,且對于ON態(tài)和OFF態(tài)需各自確定其β的值。α為重尾特性參數(shù),βON和βOFF分別為ON態(tài)和OFF態(tài)可取的最小值。在實際過程中,α值通常取αON和αOFF之間的值,1<αON,αOFF<2。βON取決于數(shù)據(jù)生成源發(fā)送一個數(shù)據(jù)包的最短時間,而βOFF則由各源的負載比例,即由流量與帶寬之比確定。依據(jù)文獻[18]中的假設與推算,可以得到βOFF的計算方法為:

(4)

其中,TON=(αON-1)/αON,TOFF=(αOFF-1)/αOFF。

在實現(xiàn)過程中選擇逆變換法生成ON/OFF態(tài)持續(xù)時間序列。根據(jù)已知的Pareto分布函數(shù)F(x),得到其逆函數(shù)F-1(x),再假設隨機變量U符合(0,1)上的均勻分布,令隨機變量X=F-1(U),則根據(jù)U的隨機變量值得到X的取值序列,符合分布F(x)。由此,可利用Numpy生成大量符合Pareto分布的ON/OFF態(tài)持續(xù)時間序列,將其保存在中間參數(shù)文件on_off_XX.dat中,并同步給各負載生成器,即可實現(xiàn)數(shù)據(jù)生成源的自行控制。

2.3.3 網(wǎng)絡實體空間分布的模擬

本文系統(tǒng)利用預處理模塊和空間分布實現(xiàn)模塊實現(xiàn)網(wǎng)絡實體空間分布的模擬。流量空間分布主要從以下2個方面實現(xiàn):

1)一方面是基于鏈路層的客戶端IP分布。在模擬網(wǎng)絡流量時,IP并不能設置為測試時的少量真實IP,而是要進行虛擬化。虛擬IP不應是隨機或均勻分布,而應依據(jù)樣本流量中的IP頻率分布進行放大模擬,以貼近實際場景?？臻g分布實現(xiàn)模塊完成了數(shù)據(jù)包IP等字段的修改,本質(zhì)上充當個性化網(wǎng)橋的功能。其實,LoadRunner本身也提供IP欺騙功能,但它需DHCP服務器分配真實局域網(wǎng)地址,操作繁瑣,申請地址有限,于性能有損耗,且無法生成外部地址,只適用于簡單的IP欺騙場景。本文系統(tǒng)拋棄這種方式,改用自定義模塊實現(xiàn),且實現(xiàn)思路為:在網(wǎng)關處攔截所有數(shù)據(jù)包,而對業(yè)務相關數(shù)據(jù)包,根據(jù)客戶端IP和端口號進行IP替換,再重放修改后的數(shù)據(jù)包。該操作需修改各負載生成機器的默認路由,使其指向網(wǎng)關機器,并需在網(wǎng)關機器上獲得管理員權限。當數(shù)據(jù)包到來時,提取IP和端口信息,并在內(nèi)存中的轉(zhuǎn)換表中(類似NAT)查找對應條目,找到則替換IP,修改TTL、checksum等字段,否則添加一條轉(zhuǎn)換記錄。同時,結(jié)合轉(zhuǎn)換表規(guī)模大小與數(shù)據(jù)吞吐量,設置每條轉(zhuǎn)換記錄的有效時間,過期則刪除該記錄。

2)另一方面是用戶級別的空間分布,由預處理模塊負責,主要基于用戶活躍度不同,如不同客戶端與服務器端的交互頻繁程度以及傳輸數(shù)據(jù)大小等。預處理模塊基于樣本體現(xiàn)在上傳量或IP等方面的用戶活躍度分布,度量并擬合模型及參數(shù)。在流量生成參數(shù)配置階段,依照用戶活躍度進行資源配置,表現(xiàn)為虛擬用戶數(shù)量分布、數(shù)據(jù)配置差異等方面,從而使負載生成器生成流量時,完成用戶級別空間分布的刻畫。

2.3.4 網(wǎng)絡流量中異構(gòu)化內(nèi)容的隨機生成

利用負載生成工具實現(xiàn)按需生成流量是亟待解決的問題之一,即如何向大量重復操作和請求添加實際流量特征生成異構(gòu)化內(nèi)容。異構(gòu)化內(nèi)容的隨機生成在系統(tǒng)中主要由流量分析模塊、輸入模塊、預處理模塊與LoadRunner核心控制模塊協(xié)作完成,且主要由以下3個方面實現(xiàn):

1)利用與用戶相關的特異性特征來實現(xiàn),如用戶思考時間加權參數(shù),它表征一個用戶完成不同業(yè)務操作的穩(wěn)定平均思考時間與人群總平均思考時間的比值,用戶思考時間加權參數(shù)在測試中影響不同用戶的思考時間計算生成。再如用戶操作偏好,它表現(xiàn)為用戶對不同業(yè)務的操作頻率差異等。將思考時間設計為用戶各異的變量值,以此仿真實際用戶操作。思考時間分布可來自2個輔助參數(shù)的共同作用,一個是平均操作思考時間T,另一個是用戶思考時間加權參數(shù)W。對于每一種典型操作都有平均操作總思考時間T[action],由于一個操作內(nèi)部通常有多個思考時間,因此定義操作內(nèi)部第i個思考時間占比為R[action],i。各操作的平均時間依賴對樣本中實際操作事件測量的參數(shù)進行統(tǒng)計和平均來獲得。用戶思考時間加權參數(shù)W(W>0)表征一個用戶思考時間長短在人群中的水平,假設此值在一定時間內(nèi)是穩(wěn)定的,W=1表示用戶思考時間與人群中平均值相當,W>1表示思考時間大于平均值。在測試時,用戶i的action操作的第j個思考時間的取值為Wi×T[action]×R[action],j。

2)利用可從用戶中獨立出來的普遍特征,如利用典型業(yè)務操作請求序列、業(yè)務人均思考時間、各操作占比、網(wǎng)站不同入口或板塊分流比例、客戶端不同瀏覽器標志等來實現(xiàn)。實現(xiàn)時,如論壇入口分布是對論壇各入口板塊流量不均衡分布情況進行統(tǒng)計分析后,模擬其分布情況向各入口發(fā)送流量。瀏覽器標志隨機化是在HTTP協(xié)議請求頭中控制User-Agent字段,以此給負載測試腳本增加更多隨機性等。同時,對一些主要操作為瀏覽或內(nèi)容發(fā)布的被測網(wǎng)站,還可設計諸如按熱度/最近/隨機瀏覽、按熱度/最近/隨機回復等人性化操作。針對不同的Web協(xié)議,HTTP與WebSocket都可根據(jù)協(xié)議的具體特點盡量多地擴展異構(gòu)。另外,由于系統(tǒng)在同一臺物理機上模擬多個虛擬用戶,因此為了避免用戶間的干擾而導致流量失真,處理cache時需要更加謹慎。

3)利用內(nèi)容的異構(gòu),特別是對于一些用戶上傳內(nèi)容的網(wǎng)站,流量攜帶數(shù)據(jù)的形式和占比都較為重要。在測試時,顯然不能簡單地以隨機數(shù)字或隨機文本填充正常場景中具有實際內(nèi)容的字段。針對該類網(wǎng)站,可通過爬蟲爬取目標或相似網(wǎng)站的內(nèi)容直接作為模擬流量的數(shù)據(jù)來源,或?qū)υ擃惥W(wǎng)站的內(nèi)容分布進一步分析與學習,采取其他方式生成內(nèi)容數(shù)據(jù)。以論壇為例,需要填充的字段主要為發(fā)帖內(nèi)容和回復內(nèi)容兩類。其中,回復內(nèi)容應與被回復帖子有一定的相關性,發(fā)帖內(nèi)容也需要符合該論壇的主題等特點,可對回帖內(nèi)容進行相關化處理,即針對被回復帖子,截取部分作為回復內(nèi)容。發(fā)帖內(nèi)容來源可以是利用爬蟲爬取正常活躍用戶的發(fā)帖內(nèi)容。

2.3.5 基于容器的分布式流量發(fā)送陣列

實現(xiàn)大規(guī)模異構(gòu)網(wǎng)絡的流量模擬,應當具備可擴展的流量生成系統(tǒng)。因此,本文系統(tǒng)的負載生成模塊選擇基于容器的分布式發(fā)送陣列來實現(xiàn)。系統(tǒng)運用容器技術是將一個負載生成器(Load Generator)打包成鏡像,部署時直接拉取即可以容器形式(如docker)[19]運行。

系統(tǒng)的網(wǎng)絡拓撲如圖3所示。局域網(wǎng)內(nèi)主要為控制器端、分布式負載生成器和一個作為網(wǎng)橋存在的轉(zhuǎn)換器,在最右端有與轉(zhuǎn)換器相連的服務器端。當然,服務器端也可以是一個集群。

圖3 系統(tǒng)架構(gòu)拓撲Fig.3 System architecture topology

分布式負載生成器集群架設在局域網(wǎng)內(nèi)的多臺物理機上,所有負載生成器在邏輯上是相同且平等的。分布式除了帶來更高的性價比之外,也使系統(tǒng)產(chǎn)生了一些單個處理器不會產(chǎn)生的問題,如同步和一致性處理問題。根據(jù)LoadRunner設置,參數(shù)文件在Controller啟動之初同步到各負載生成器,也就是說每個負載生成器容器擁有一個參數(shù)文件副本。而用戶群在分布式客戶端上的分布是根據(jù)用戶活躍度權重隨機安排的,由于虛擬用戶扮演的真實用戶的唯一性,用戶參數(shù)文件的多個副本不能支持同時處理同一條記錄。當用戶數(shù)量有限以及用戶選擇沖突可能性較大時,需要給整個系統(tǒng)維護一個登陸用戶列表,以保證互斥的用戶選擇。

2.3.6 系統(tǒng)的檢查與反饋機制

本文的定制化業(yè)務背景流量生成系統(tǒng)設計包括檢查與反饋機制,負責處理運行時數(shù)據(jù),具有記錄服務器反饋、實時流量監(jiān)控以及自適應調(diào)節(jié)等功能。檢查與反饋機制主要依賴實時監(jiān)測模塊、反饋調(diào)節(jié)模塊和同步模塊共同協(xié)作。檢查系統(tǒng)的主要職能是監(jiān)測和結(jié)果評估,監(jiān)測的結(jié)果一部分作為中間生成信息,交由反饋系統(tǒng)處理,一部分作為結(jié)果評估原始數(shù)據(jù),以日志形式記錄下來,供測試完成后查看分析。檢查系統(tǒng)的實現(xiàn)主要考慮以下2個方面:

1)檢查系統(tǒng)作為生成流量最后的出口總監(jiān)控,可以利用類似Wireshark、tcpdump或等包捕獲工具,或其自身編程完成截獲。最基本的代碼結(jié)構(gòu)也應該至少實現(xiàn)2個進程/線程,一個專注于截獲,另一個處理數(shù)據(jù)。此處監(jiān)測的原始數(shù)據(jù)為單個數(shù)據(jù)包,需整理提取會話流信息,這可能會產(chǎn)生一定的時延,若作為反饋調(diào)節(jié)信號,則需考慮過大的時延帶來的影響。

2)在LoadRunner核心控制模塊中,編寫腳本時,對關鍵請求/事務/操作的response等信息進行檢查,主要分為2種方式,第1種方式可利用LoadRunner內(nèi)置的檢查函數(shù)(如Web_reg_find()函數(shù))對報文進行包含性檢查,并返回布爾值,可提示返回信息錯誤或其他錯誤情況。第2種方式則是對第1種方式的補充,對于其他一些內(nèi)置檢查函數(shù)不能覆蓋的特征檢查,需要自身實現(xiàn)檢查邏輯,如關鍵操作的超時檢查、思考時間的偏差計算等。檢查系統(tǒng)在此處的實現(xiàn)是從流量生成的源頭進行檢查,更適合一些基于邏輯結(jié)構(gòu)完整性的檢查,如事務、操作的檢查等。

反饋系統(tǒng)向流量生成系統(tǒng)提供自適應調(diào)控功能,提高了其準確性、穩(wěn)定性和表現(xiàn)力。反饋系統(tǒng)也基于以下方面實現(xiàn):

前2個方面同檢查系統(tǒng)類似,在得到總出口的截獲結(jié)果后,對于反饋系統(tǒng)應當敏感的指標,在對數(shù)據(jù)進行處理后,將反饋指令傳遞給同步模塊,對負載生成集群實現(xiàn)實時調(diào)控。在LoadRunner核心控制模塊中,自檢函數(shù)提供對下一步起決定作用的檢查信息,然后依照確定流程分支執(zhí)行不同代碼路徑,如檢查關鍵操作是否成功,若沒有成功是否重做,或檢查關鍵資源加載是否完成,若失敗如何處理等。

前文提到,反饋系統(tǒng)從檢查系統(tǒng)處獲取數(shù)據(jù)到最后反饋指令得到正確執(zhí)行,可能帶來附加的時延。反饋系統(tǒng)在處理數(shù)據(jù)時應盡可能簡潔,且模塊或設備之間的通信也應盡量迅速。首先,認真篩選重要參數(shù)指標,篩除一些反饋無意義或無法進行實時監(jiān)控的指標(如ON/OFF時間分布模型的實現(xiàn)等),通?？蛇x擇思考時間粗略分布、用戶活躍度分布和內(nèi)容分布等作為反饋關注指標。反饋系統(tǒng)網(wǎng)絡通信部分的實現(xiàn)可基于Socket或RPC或其他方式。Socket的主要優(yōu)點是開發(fā)簡單,不同平臺、不同語言甚至不同庫對于Socket的支持都十分完備。但若是系統(tǒng)復雜且規(guī)模較大,則需要更高級別的安全和結(jié)構(gòu)分類功能,特別是分布式系統(tǒng)需要更高效的通信,則RPC是一個更好的選擇,流行的RPC框架有:由Java實現(xiàn)阿里巴巴開發(fā)的流行RPC框架Dubbo,對多種語言支持更好的由Google開發(fā)的RPC框架gRPC[20]等。

3 系統(tǒng)實現(xiàn)與驗證

3.1 開發(fā)、部署及運行環(huán)境

基于上文中設計的定制化業(yè)務背景流量生成系統(tǒng),本文實現(xiàn)了一個以論壇網(wǎng)站為被測業(yè)務系統(tǒng)的具體實例。系統(tǒng)至少由局域網(wǎng)內(nèi)的4臺機器實現(xiàn):1)安裝LoadRunner 12.60版本的完整套件和輸入模塊、預處理模塊等;2)為承載空間分布實現(xiàn)模塊和實時監(jiān)測模塊等的網(wǎng)關物理機;3)為裝有多個虛擬機的預置負載生成器,并裝有相應版本的Docker;4)搭建有目標業(yè)務系統(tǒng),即論壇網(wǎng)站,用來充當服務端。論壇網(wǎng)站利用XAMPP 3.2.2集成Apache、MySQL和FileZilla,更便捷地建立了站點后端相關配置軟件,并采用基于PHP的Discuz!開源代碼實現(xiàn)論壇前端與主要邏輯部分,論壇網(wǎng)站的主要網(wǎng)絡協(xié)議為HTTP。開發(fā)和運行環(huán)境為Windows Server 2016和Ubuntu 16.04 LTS等。開發(fā)語言主要使用ANSI C和Python 3.5.0。開發(fā)過程中使用的工具主要包括LoadRunner各部件、Docker、Wireshark與tcpdump等,使用的庫主要包括Python前端庫PyQt5,數(shù)據(jù)計算與分析庫Numpy、Scipy,相關網(wǎng)絡編程的Scapy、Winsock和Linux下核心函數(shù)等。

3.2 樣本業(yè)務分析與特征參數(shù)計算

系統(tǒng)使用Wireshark 截獲樣本流量,獲得樣本流量后,選擇與業(yè)務相關的數(shù)據(jù)字段,采用統(tǒng)計或機器學習等方式進行通信模式的識別,并提取具有代表性的業(yè)務模版。業(yè)務模版后續(xù)將邏輯化為LoadRunner腳本,并控制流量的生成。在分析流量樣本時,首先對樣本進行過濾和分離。過濾是除去原始數(shù)據(jù)中的部分噪音,過濾的依據(jù)通常是服務器IP及端口。然后需要對流量進行分離,分離的標準是一次用戶登錄的完整事件,這也是基本分析單位,包括用戶的該次登錄以及登錄活躍期間的操作。最后,可能以登出操作、cookie過期或覆蓋登陸結(jié)尾。流量分離后,得到一次用戶登陸的完整事件的流量集合。

當對一次登陸進行業(yè)務識別時,在一般場景下,使用聚類可分類各流量隱藏的典型業(yè)務操作。但對于該論壇網(wǎng)站和該樣本來說,業(yè)務種類易于區(qū)分且種類簡單,基于文本匹配和統(tǒng)計即可完成。該論壇的業(yè)務操作可基本分為6種,即登陸(log in)、登出(log out)、瀏覽(scan)、發(fā)帖(post)、回帖(reply)和刪除(delete)。

由此則可進一步對樣本流量的數(shù)據(jù)包按照操作進行劃分,得出各操作的占比結(jié)果如表1所示。從樣本流量中提取高頻時序操作序列,則可得到業(yè)務系統(tǒng)的業(yè)務模版,高頻時序操作序列如表2所示。

表1 各操作的占比結(jié)果Table 1 Percentage result of each operation %

表2 高頻時序操作序列Table 2 High-frequency sequential operation sequence

分析樣本流量的空間分布特性,空間分布特性主要基于IP隨機化和用戶活躍度分布。后者分析時主要針對不同IP(表現(xiàn)為不同用戶)對網(wǎng)站流量的貢獻分布進行研究。由于原樣本容量過小,因此通過爬蟲爬取相似論壇發(fā)帖和回復情況,對其中的用戶活躍度進行調(diào)查,取用戶發(fā)布內(nèi)容的數(shù)量作為流量貢獻的重要依據(jù),并以文本字數(shù)作為統(tǒng)計對象,最終得到用戶對網(wǎng)站的貢獻分布,如圖4所示。用戶活躍度近似服從偏態(tài)分布,考慮到樣本量的局限性,最終修正為均值為1.0、方差為12.5的正態(tài)分布。

圖4 用戶活躍度Fig.4 User activity

為實現(xiàn)流量異構(gòu)化內(nèi)容的隨機生成,流量仿真還增加了以下維度的模擬。首先,思考時間的分布,也是基于用戶角度的時間分布。通過統(tǒng)計得到各操作平均思考時間及內(nèi)部思考時間分布,具體如表3所示。根據(jù)目標論壇各入口熱度統(tǒng)計得到不同操作的論壇入口分布,具體如表4所示。另外爬取相似論壇發(fā)帖內(nèi)容作為測試時發(fā)帖數(shù)據(jù)。

表3 各操作平均思考時間及內(nèi)部分配比值Table 3 Average thinking time and internal allocation ratio of each operation

表4 論壇入口分布Table 4 Forum entrance distribution %

3.3 主要功能模塊的開發(fā)實現(xiàn)

流量生成系統(tǒng)功能代碼在運行與部署安排上,主要分為3個部分進行開發(fā)。一是與LoadRunner Controller協(xié)作的部分,包括前端輸入、預處理功能代碼、同步功能代碼、可擴展腳本代碼與為腳本開發(fā)的自定義庫等。二是跟隨Load Generator打包為鏡像的同步代碼和反饋調(diào)節(jié)代碼,后者主要根據(jù)反饋指令修改重要參數(shù)和參數(shù)文件。三是空間分布實現(xiàn)模塊的截獲、修改與轉(zhuǎn)發(fā)代碼,以及對數(shù)據(jù)包的實時監(jiān)測統(tǒng)計代碼。

預處理階段系統(tǒng)接受用戶輸入,并對參數(shù)和參數(shù)文件進行預處理,主要包括參數(shù)檢查、參數(shù)生成、重要配置文件生成及重要數(shù)據(jù)生成。初始化控制通路的連接發(fā)送重要指令和參數(shù)文件,直至所有設備準備完全,再開啟監(jiān)測進程,最后觸發(fā)LoadRunner Controller準備發(fā)送流量。

可擴展腳本的開發(fā)為腳本和操作的分布控制、流量內(nèi)容的異構(gòu)等功能提供支持?？蓴U展腳本的實現(xiàn)方式主要有以下3種:與預處理中指定分布參數(shù)生成相結(jié)合的參數(shù)化機制;編寫并載入自定義C庫,實現(xiàn)更多自定義功能函數(shù);其他異構(gòu)代碼,包括不同操作邏輯的重復類型與重復次數(shù)的參數(shù)化設計,思考時間的參數(shù)化實現(xiàn)等。

檢查與反饋機制主要依賴2個線程。一個是空間分布實現(xiàn)模塊的截獲、修改與轉(zhuǎn)發(fā)線程,它會截獲數(shù)據(jù)包并定量轉(zhuǎn)發(fā)給另一個分析線程,觸發(fā)實時分析。分析線程對數(shù)據(jù)包集合中的感興趣指標進行統(tǒng)計分析后,會將所有計算結(jié)果作為日志保存在文件中。若數(shù)據(jù)達到一定量且偏移達到一定閾值,則發(fā)送反饋指令給同步模塊上監(jiān)聽的線程,等待其對生成參數(shù)和參數(shù)文件進行調(diào)整。

3.4 運行測試與結(jié)果評估

系統(tǒng)部署完成之后,測試時先啟動各機器,在負載生成器上運行各容器,接著啟動用戶輸入端。輸入YAML配置文件形式的用戶需求和相關參數(shù),配置文件說明用戶思考時間加權參數(shù)服從均值為1、方差為0.5的截斷正態(tài)分布,空間分布用戶活躍度指標符合均值為1、方差為12.5的截斷正態(tài)分布,并輸入各操作的平均思考時間、操作內(nèi)部思考時間分布、腳本和操作比例分布、入口分布以及其他參數(shù)文件路徑等。場景文件Scenario.lrs規(guī)劃了系統(tǒng)虛擬用戶的分配與負載生成器分配等內(nèi)容。測試時,選擇20個虛擬用戶并按照腳本比例進行分配,計劃每15 s初始化一個新的虛擬用戶,當全部虛擬用戶初始化完成,則持續(xù)執(zhí)行腳本20 min,最后每隔10 s終止一個虛擬用戶。提交輸入后系統(tǒng)進入流量生成狀態(tài),自動生成流量并實時自行調(diào)整,直至運行規(guī)定時間截止。最后,流量生成的結(jié)果以實時圖表的形式呈現(xiàn),還有分布式日志可供查詢,測試結(jié)果如圖5、圖6所示。其中,流量時序圖表示單位時間轉(zhuǎn)發(fā)數(shù)據(jù)包個數(shù),由此可得測試結(jié)果符合網(wǎng)絡流量自相似性?？臻g分布圖符合正態(tài)分布,根據(jù)思考時間運行日志得出其按既定參數(shù)執(zhí)行,腳本中操作重復次數(shù)為213、50、109與20,符合樣本提取的比例。從論壇網(wǎng)站流量/發(fā)帖量/回復量來看,結(jié)果符合Url入口分布規(guī)律,其他性能指標也基本與預期相符。

圖5 流量時序圖Fig.5 Flow timing chart

圖6 空間分布圖Fig.6 Spatial distribution chart

4 結(jié)束語

本文提出一個基于Web的定制化業(yè)務背景流量生成系統(tǒng),并實現(xiàn)一個以論壇網(wǎng)站為被測系統(tǒng)的系統(tǒng)實例。該系統(tǒng)的設計基于LoadRunner核心功能的使用,利用基于容器的分布式流量發(fā)送陣列以及流量內(nèi)容的異構(gòu)等技術與方法實現(xiàn)了流量的深度仿真。實驗結(jié)果表明,系統(tǒng)實例具有較好的模擬效果,能正確還原實際網(wǎng)絡流量的重要特性。但是在測試過程中也存在不足,如未添加圖片參數(shù)化支持,檢查反饋機制對于加密協(xié)議中的內(nèi)容不能完全截獲分析等。下一步將圍繞多樣化場景及性能提升進行研究。