流式應(yīng)用層協(xié)議載荷封裝交付算法優(yōu)化

張潤滋，王勁林，陳 曉，葉曉舟

1(中國科學(xué)院聲學(xué)研究所 國家網(wǎng)絡(luò)新媒體工程技術(shù)研究中心，北京 100190)2(中國科學(xué)院大學(xué)，北京 100190)

1 引 言

隨著互聯(lián)網(wǎng)爆發(fā)式的發(fā)展，網(wǎng)絡(luò)流量規(guī)模日益增長.伴隨而來的，是對網(wǎng)絡(luò)處理設(shè)備的高性能需求.無論是網(wǎng)絡(luò)安全的數(shù)據(jù)分析、取證[1]，還是網(wǎng)絡(luò)流量的深度解析、管理[2]，越來越多的網(wǎng)絡(luò)設(shè)備涉及到IP層和TCP層以上的數(shù)據(jù)處理，面向應(yīng)用層的網(wǎng)絡(luò)流量分析隨處可見.以TCP/IP網(wǎng)絡(luò)四層模型為例，絕大多數(shù)的傳輸層及以下的網(wǎng)絡(luò)功能都有較為成熟的處理和加速套件，如協(xié)議棧[3].這使得開發(fā)者能夠從復(fù)雜的底層協(xié)議處理中解脫出來，來面對更為關(guān)鍵的面向應(yīng)用的業(yè)務(wù).與底層(TCP/IP及以下)協(xié)議的處理方式不同，應(yīng)用層協(xié)議分布更廣泛，任務(wù)也更復(fù)雜.

一個典型的網(wǎng)絡(luò)流量實時審計采集系統(tǒng)的模塊架構(gòu)如圖1所示.數(shù)據(jù)流輸入到系統(tǒng)以后，經(jīng)過濾操作，需要采集的數(shù)據(jù)流被TCP/IP協(xié)議棧處理，進而提交到數(shù)據(jù)流管理模塊.為了提取數(shù)據(jù)流應(yīng)用層的數(shù)據(jù)內(nèi)容，需要完成后續(xù)的協(xié)議解析操作，并將解析后的有效字段載荷內(nèi)容進行提取，并封裝到日志中保存或者發(fā)送出去.本文將針對虛線中的三個相關(guān)模塊及其流程，提出一種優(yōu)化的載荷封裝交付算法，通過優(yōu)化各個環(huán)節(jié)處理方法，提升系統(tǒng)的處理性能.

圖1 一個典型的網(wǎng)絡(luò)流量審計采集系統(tǒng)模塊架構(gòu)Fig.1 A typical network traffic audit acquisition system module architecture

2 相關(guān)研究

為了高并發(fā)、高吞吐的實現(xiàn)應(yīng)用層協(xié)議解析及內(nèi)容提取，已有研究在許多方面提出優(yōu)化策略與算法.其中，文獻[4]提出了基于狀態(tài)機的HTTP Chunked流式解析算法.該算法從解析算法入手，減少了HTTP報文處理中的內(nèi)存拷貝開銷，能夠有效降低處理時間和內(nèi)存占用.文獻[5,6]在有包間依賴關(guān)系的情況下，對聚合數(shù)據(jù)流緩存策略進行了優(yōu)化.其中，文獻[6]建立了緩沖串及緩沖模型，并以最小化交付時延為目的，提出了緩存管理算法OBMG.該算法以貪心的策略優(yōu)化了數(shù)據(jù)載荷的拷貝過程，實現(xiàn)了交付延遲的大幅度降低.

不同于以上相關(guān)工作，本文針對高層協(xié)議載荷的封裝及交付過程，在緩存策略、封裝策略、發(fā)送策略三個方面進行了優(yōu)化，能夠充分提高載荷提取發(fā)送的性能.

3 高層協(xié)議載荷封裝交付模型及算法

3.1 模型建立

以網(wǎng)絡(luò)流量審計采集系統(tǒng)為例，其主要任務(wù)是將指定數(shù)據(jù)流中的高層協(xié)議按照協(xié)議規(guī)范進行解析，然后提取需要的內(nèi)容字段并寫入日志，以供后續(xù)的分析處理[1].以HTTP協(xié)議的審計為例，所需提取的字段可能包括：URL、請求方法、協(xié)議版本、響應(yīng)狀態(tài)碼、Cookie、請求消息內(nèi)容、相應(yīng)消息內(nèi)容等等.每一條HTTP數(shù)據(jù)流，包括客戶端與服務(wù)端之間兩個方向的單向數(shù)據(jù)流，提取后的各個審計字段將記錄在一條日志當中.

圖2 緩沖串加法操作示意圖Fig.2 Buffer string addition operation schematic

需要注意的是，TCP協(xié)議采用流式發(fā)送的方法，即數(shù)據(jù)段與數(shù)據(jù)包之間沒有一一對應(yīng)關(guān)系.系統(tǒng)收到的數(shù)據(jù)包可能包含高層應(yīng)用的一個或多個完整字段，同時，也可能只包含字段內(nèi)容的一部分.因此，較長的字段內(nèi)容或被"割裂"，封裝在多個網(wǎng)絡(luò)數(shù)據(jù)包中傳輸.

字段的解析順序由應(yīng)用的交互決定，一般情況下字段間沒有交叉，按照到達順序逐個解析并寫入日志.本文所涉及的載荷封裝及交付過程，符合文獻[6]提出的緩沖模型.該模型定義了字串緩沖過程的加法運算、消除運算以及逆緩沖串,并提出了緩沖的ABD(arrival，buffering，deliver)過程.其中，對于緩沖串b，其對應(yīng)的字串和位置分別為s(b)和a(b)，則緩沖串b1、b2的緩沖串加法操作如圖2所示.

本文不關(guān)心高層協(xié)議解析的具體過程和方法，只涉及已提取出字段的日志封裝、緩存、發(fā)送過程.具體可描述為如下AED子流程：

1) Arrival：經(jīng)過協(xié)議解析，一個或多個字段，或者字段的一部分被解析出來；

2) Encapsulation：將當前字段內(nèi)容寫入指定格式的日志緩存中；

3) Delivery：將緩存的日志內(nèi)容提交，以發(fā)送到指定接收端，或者寫入磁盤.

如圖3(a)所示，AED過程是流式的處理過程，在多核系統(tǒng)中，同一個核心上可能同時處理交錯到達的多條應(yīng)用數(shù)據(jù)流.值得注意的是，AED子過程之間不是互相獨立的，前一個子過程決定了后一個子過程的最早觸發(fā)時機.只有存在Arrival狀態(tài)的字串，才會觸發(fā)Encapsulation進行封裝操作；一個完整的Encapsulation操作結(jié)束之后，才可能觸發(fā)Delivery操作.因此，緩沖池的狀態(tài)可以描述成一個狀態(tài)空間，表示為如圖3(b)所示的狀態(tài)轉(zhuǎn)移圖.其中S0,S1,S2,S3分別表示緩沖區(qū)無內(nèi)容、緩沖區(qū)非空但字段封裝不完整、緩沖區(qū)有且只有一個完整封裝字段、緩沖區(qū)有不止一個完整封裝字段.

圖3 AED過程示意圖(a)以及緩存狀態(tài)轉(zhuǎn)移圖(b)Fig.3 AED process diagram (a) and cache state transition (b)

顯然，載荷字段封裝以及交付過程中，緩存池狀態(tài)滿足馬爾科夫性質(zhì).即封裝交付過程中緩存池組裝日志的下一狀態(tài)只與當前狀態(tài)相關(guān)，與歷史狀態(tài)無關(guān).在高速處理環(huán)境下，狀態(tài)之間切換的觸發(fā)時機，直接影響著系統(tǒng)的內(nèi)存使用情況和日志傳輸效率.

3.2 算法描述

3.2.1 PFED算法

基于上一節(jié)所描述的狀態(tài)轉(zhuǎn)移模型，首先分析樸素字段封裝交付算法PFED(Plain Field Encapsulation and Delivery Algorithm).該算法描述如下：

算法1.PFED

1.procedureFIELD ENCAPSULATION AND DELIVERY

2.encap_buffer←InitPerFlow()

3.whilecurrent_field←Arrival()do

4.encaplsulate_field←Encapsulation(encap_buffer,current_field)

5.status←EncapsulationStatus(encapsulate_field)

6.ifstatus=COMPLETEDthen

7.Delivery(encapsulate_field)

8.else

9.encap_buffer←encap_buffer⊕current_field

10.endif

11.endwhile

12.endprocedure

PFED算法順序的執(zhí)行載荷的封裝和交付操作.每當有新的載荷字段到達，PFED執(zhí)行封裝操作，如果緩沖區(qū)及新的載荷能夠組成完整的字段內(nèi)容，則直接交付該封裝字段；否則，將當前載荷內(nèi)容添加到緩沖區(qū)中，即與原緩沖區(qū)字串執(zhí)行緩沖串加法操作.在此，對于尚未完整到達的載荷字段，需要將不完整的封裝結(jié)構(gòu)緩存到與數(shù)據(jù)流相關(guān)的封裝緩沖區(qū)中.

該算法存在如下問題：

1)在一個處理核心上，如果當前處理的字段內(nèi)容較長，即"割裂"字段到達并分布在多個數(shù)據(jù)包內(nèi)，當前緩存池狀態(tài)將持續(xù)處于S1狀態(tài)，等待更多該字段內(nèi)容的到達，以實現(xiàn)完整的封裝，這意味著，在高并發(fā)、高吞吐的場景下，眾多處于該狀態(tài)的緩存池將占用較大的內(nèi)存空間，同時只有部分字段完成封裝和日志交付.

2)為了保證內(nèi)存的塊的使用效率，發(fā)揮多核處理器上內(nèi)存管理的優(yōu)勢，在交付過程中一般采用固定大小的消息緩沖塊來交付每一個封裝好的字段內(nèi)容.因此，"交付效率"(DE，Delivery Efficiency)就是一個值得關(guān)注的問題.交付效率是當前交付消息中，有效內(nèi)容的總長度與消息長度的比值.如果當前處理的字段大多數(shù)都比較小，對于每個有效字段內(nèi)容，都需要封裝一個固定大小的封裝頭和固定的封裝消息緩存塊，則有效內(nèi)容在交付的消息中所占長度比例相對較低，導(dǎo)致總體"交付效率"低.

3.2.2 SFED算法

為了克服以上狀態(tài)轉(zhuǎn)化模型及PFED算法的問題，本文進一步提出了流式字段封裝交付算法SFED(Streaming Field Encapsulation and Delivery Algorithm).該算法在的核心在于優(yōu)化了狀態(tài)轉(zhuǎn)換之間的觸發(fā)機制，主要有如下兩點：

1) 對于可能"割裂"的字段，不再等待收取完整才觸發(fā)交付；采用嵌套AVP(Attribute-Value-Pair)封裝結(jié)構(gòu)來保證協(xié)議任意字段的流式發(fā)送，而避免緩存不完整的字段內(nèi)容；

2) 當緩沖池中存在完整可發(fā)送的字段日志時，不再立即觸發(fā)交付流程；設(shè)置緩沖池的交付觸發(fā)閾值，只有緩存池中緩存的字段日志總長度達到一定值時，才觸發(fā)交付.

圖4 一個典型的AVP封裝結(jié)構(gòu)Fig.4 A typical AVP encapsulation structure

其中，一個典型的AVP封裝結(jié)構(gòu)如圖4所示.將可能"割裂"的字段封裝為嵌套結(jié)構(gòu)，外層AVP類型值指定為字段的類型值.作為外層AVP的內(nèi)容，封裝兩個內(nèi)層AVP結(jié)構(gòu)：第一個AVP指示本段分段內(nèi)容的編號，第二個AVP封裝實際的本段內(nèi)容，該AVP結(jié)構(gòu)由接收端負責解析和組裝.通過上述封裝結(jié)構(gòu)，雖然增加了部分冗余信息，但有效的避免了"割裂"字段內(nèi)容的緩存，實現(xiàn)了任意字段日志的流式發(fā)送.

基于以上分析SFED算法描述如下：

算法2.SPED

1.procedureFIELD ENCAPSULATION AND DELIVERY

2.deliver_buffer←InitPerThread()

3.whilecurrent_field←Arrival()do

4.avp_field,avp_size←AvpEncapsulation(current_field)

5.buffer_size←BufferPoolSize(deliver_buffer)

6.if(buffer_size+avp_size)≥THRESHOLDthen

7.Delivery(deliver_buffer)

8.Delivery(avp_field)

9.else

10.deliver_buffer←deliver_buffer⊕avp_field

11.endif

12.endwhile

13.endprocedure

值得注意的是，SFED不需要配置與數(shù)據(jù)流對應(yīng)的封裝緩沖區(qū)，取而代之配置的是與每個處理線程/核心對應(yīng)的交付緩沖區(qū).即，緩沖區(qū)塊的數(shù)目從數(shù)據(jù)流數(shù)目級別降低到線程/核心數(shù)級別.這大幅度減少了所需要的緩存空間，對于資源受限的邊緣設(shè)備有著重要的意義.另外，對于記錄有些長度沒有限制的字段內(nèi)容，SFED算法有著先天的優(yōu)勢.舉例來說，HTTP協(xié)議沒有規(guī)定URL的最大長度.如果瀏覽器或者其他客戶端發(fā)出了過長的URL請求，SFED亦能夠在不消耗大量內(nèi)存空間的情況下，流式完成封裝.此外，某些協(xié)議如果出現(xiàn)惡意攻擊，數(shù)據(jù)請求和響應(yīng)的內(nèi)容也可能長度超出設(shè)想.這種狀況下，PFED算法會無限制的緩存這些字段內(nèi)容，導(dǎo)致系統(tǒng)內(nèi)存耗盡，自動陷入"拒絕服務(wù)"的狀態(tài)當中.而SFED算法自然地避免了類似問題的發(fā)生.

相對于PFED算法，SFED算法通過嵌套的AVP封裝消除了對長字段內(nèi)容的緩存操作，實現(xiàn)了任意字段數(shù)據(jù)的流式發(fā)送；另一方面，針對連續(xù)到達的字段長度較小的字段內(nèi)容，SFED算法使用了固定大小的閾值緩沖池.類似于TCP的Nagle算法[7]，SFED算法能夠聚合發(fā)送長度較短的字段內(nèi)容.聚合發(fā)送的優(yōu)勢在于，在交付有效內(nèi)容總長度一致的情況下，更少的數(shù)據(jù)分塊能夠提升單個交付消息中的有效內(nèi)容長度，提升交付效率，即有效內(nèi)容的網(wǎng)絡(luò)發(fā)送效率和磁盤寫入速率.

4 性能測試

本文在基于Cavium OCTEON CN6645芯片[8]的多核網(wǎng)絡(luò)處理器上實現(xiàn)了網(wǎng)絡(luò)流量審計采集系統(tǒng).Cavium多核架構(gòu)相當于硬件多線程，軟件系統(tǒng)總體架構(gòu)如圖5所示.該系統(tǒng)運行在多核異構(gòu)操作系統(tǒng)上，部分核心運行實時系統(tǒng)，負責采集環(huán)節(jié)各個模塊的實現(xiàn)，日志發(fā)送模塊將采集的原始日志交付給Linux系統(tǒng)進行后續(xù)處理.實時系統(tǒng)與Linux系統(tǒng)之間，通過Cavium芯片的work消息機制完成通信.

本文通過IXIA測試設(shè)備對HTTP流量進行測試，系統(tǒng)輸入交換機旁路鏡像流量.日志提取的HTTP字段包括：Host, URL, Method, Request/Response Content，以及IP地址、端口、關(guān)聯(lián)用戶、時間戳等信息.HTTP頁面大小分別為1B、20B、100B、1KB、3KB、16KB.采集實時系統(tǒng)運行在3個核心上，本文對比了PFED算法以及不同閾值參數(shù)的SFED算法的單核最大吞吐性能，最終結(jié)果如圖5所示.

圖5 字段日志發(fā)送吞吐測試Fig.5 Throughput test of field logs sending

流式發(fā)送的SFED算法在字段封裝交付過程中，由于能夠避免長字段緩存引起的內(nèi)存瓶頸，有效提升了系統(tǒng)的吞吐量，測試點吞吐量始終在PFED算法數(shù)值之上.隨著SFED算法閾值的提升，短字段內(nèi)容的聚合發(fā)送效率逐漸提升，系統(tǒng)吞吐性能隨之提升；在超過某個臨界點(在1024附近)以后，吞吐性能開始下降，這是因為設(shè)置較高的閾值，某些較長字段被拷貝到交付緩沖區(qū)，這些拷貝操作帶來的開銷超過了通過聚合發(fā)送帶來的性能提升收益，如果進一步增大閾值，系統(tǒng)性能會大幅度下降.

圖6 字段日志發(fā)送多核拓展吞吐測試Fig.6 Throughput extensibility test of field logs sending

本文同時測試了在HTTP頁面為16KB時，SFED和PFED算法的多核拓展性能.如圖6所示，SFED算法單核平均吞吐量始終高于PFED，隨著采集系統(tǒng)運行核心數(shù)目增加，吞吐量總體呈現(xiàn)下滑趨勢.導(dǎo)致下滑的因素主要有兩點：

1)多個核心在數(shù)據(jù)拷貝過程中，對多核之間的共享緩存等資源產(chǎn)生競爭，導(dǎo)致系統(tǒng)總體性能有所下降；

2)系統(tǒng)輸入數(shù)據(jù)的PPS(Packets per Second)大量增加，逐漸逼近了采集系統(tǒng)日志交付性能的限制.

圖7 字段日志發(fā)送多核拓展CPS測試Fig.7 CPS scalability test of field logs sending

在HTTP頁面大小為1B時，兩種算法的單核的平均CPS(Connections per Second)性能如圖7所示.在核心數(shù)較少時，PFED算法CPS略高，是由于SFED算法相對于PFED算法，引入了額外的數(shù)據(jù)拷貝計算開銷.但當核心數(shù)超過3個，PFED算法性能大幅下降.原因在于，在CPS測試過程中，大量的短字段內(nèi)容導(dǎo)致交付效率大幅降低，系統(tǒng)處理的數(shù)據(jù)包

PPS達到上限；相對來說，SFED算法有效聚合了大量載荷小的數(shù)據(jù)包，提高了總體的傳輸效率.

5 總 結(jié)

本文針對網(wǎng)絡(luò)處理設(shè)備中的應(yīng)用層載荷提取過程，提出了流式的載荷字段封裝交付算法SFED.相對于樸素字段封裝交付算法PFED，所提算法通過合理的嵌套AVP封裝，實現(xiàn)了長字段內(nèi)容的流式交付，避免了對字段內(nèi)容的緩存操作；同時，對短字段內(nèi)容應(yīng)用了聚合發(fā)送策略，有效提升了載荷的交付效率，提升了系統(tǒng)的總體性能.