楊瑞光,劉玉軍,山秀明,喬杰華
(1.清華大學 電子工程系,北京100084;2.裝甲兵工程學院 信息工程系,北京100072)
多媒體在網絡傳輸中大量采用基于流媒體協(xié)議的數(shù)據(jù)傳輸服務。目前流媒體數(shù)據(jù)傳輸較多的是RTP/RTCP[1]。文獻[2]提出一種應用協(xié)議識別算法,根據(jù)網絡流概念,在網絡層建立應用協(xié)議特征的描述方法,采用主成分分析方法來確定網絡流特征屬性的主要成分,所提方法能夠準確識別目前網絡中常用的應用協(xié)議,識別準確率較高。文獻[3]設計了一個對多種協(xié)議具有可擴展性的應用層協(xié)議過濾系統(tǒng)。該系統(tǒng)在高速報文數(shù)據(jù)捕獲和報文過濾子系統(tǒng)基礎上,對捕獲的原始數(shù)據(jù)報文進行IP分組和傳輸層的重組,運用應用層協(xié)議識別技術對應用層數(shù)據(jù)包進行分析、識別。文獻[4]提出一種基于正則表達式的應用層協(xié)議識別方法。該方法也是一種基于內容的檢測方法,其采用正則表達式描述協(xié)議應用層數(shù)據(jù)的特征,然后再報文體內容中尋找匹配項以確定報文所屬的整個流所屬的應用類型。文獻[5]Nguyen等學者提出基于網絡流特征數(shù)據(jù)進行機器學習的方法來進行網絡流識別。文獻[6]研究表明即使傳輸層荷載被加密,基于網絡流特征數(shù)據(jù)進行機器學習的方法依舊能夠有效地進行網絡流識別。但是流識別需要參考數(shù)據(jù)流的全局信息。文獻[7]通過總結網絡流識別技術,并對RTP協(xié)議的特征進行具體分析,提出基于信令協(xié)議解析與協(xié)議特征兩種不同策略的識別算法,并用實驗的方式對此兩種算法進行對比與驗證。證明該兩種算法都能在一定精度要求和性能要求的前提下對RTP協(xié)議流進行識別,為本文識別算法研究提供了很好的參考依據(jù)。
上述文獻采用不同的方法實現(xiàn)了流媒體數(shù)據(jù)包的識別,但對數(shù)據(jù)包檢測識別準確率和轉發(fā)速率研究還有待于進一步提高,成為制約多媒體數(shù)據(jù)傳輸QoS的一個關鍵因素。
雖然通過Linux/Netfilter規(guī)則匹配可以識別RTP包,但是Netfilter只對地址和端口進行簡單的規(guī)則匹配,不能直接識別RTP流承載的信息,過濾結果粗略且不精確,甚至可能造成安全漏洞。Netfilter規(guī)則定制需要手工配置,靈活性較差。本文通過對RTP協(xié)議分析,設計相應的識別算法,在Netfilter框架中開發(fā)相應的專用匹配模塊來實現(xiàn)對UDP承載的RTP包進行自動檢測識別。
Netfilter在Linux內核中運行,優(yōu)先級較高,對提高檢測識別效率及數(shù)據(jù)包的轉發(fā)速度十分有利。Netfilter結構可實現(xiàn)數(shù)據(jù)包過濾、數(shù)據(jù)包處理、地址偽裝、透明代理、動態(tài)網絡地址轉換,以及基于用戶及媒體訪問控制地址的過濾和基于狀態(tài)的過濾、包速率限制等許多功能[8]。Netfilter/IPtables提供了一個功能擴展框架,允許開發(fā)人員按照其規(guī)定的接口開發(fā)程序并以模塊的形式加載到Netfilter體系中,通過它可以讓用戶編輯內核過濾規(guī)則,IPtables共有3張表(filter,nat,mangle)和5個鏈(INPUT,OUTPUT,F(xiàn)ORWARD,PREROUTING,POSTROUTING),每個鏈都有其特定的作用。
當網絡數(shù)據(jù)包進入協(xié)議棧后,將被交由Netfilter按序與其規(guī)則鏈中的規(guī)則逐一進行匹配,當某一條規(guī)則與數(shù)據(jù)包匹配成功后,則按規(guī)則所指定的方式來處理數(shù)據(jù)包。每一個規(guī)則由鏈名、匹配、目的等要素組成,用戶可通過IPtables來對規(guī)則進行添加、刪除、修改等配置操作,并將操作傳遞給Netfilter。
本文主要是根據(jù)Netfilter/IPtables程序開發(fā)規(guī)則,設計了針對RTP協(xié)議的匹配算法以及用于與用戶交互的控制模塊,插入在filter表的forward鏈。
在流媒體數(shù)據(jù)中,待傳輸?shù)穆曇艉鸵曨l數(shù)據(jù)被封裝在RTP數(shù)據(jù)包中,每個RTP數(shù)據(jù)包被封裝在UDP消息段中,然后再封裝在IP數(shù)據(jù)包中。
圖1 RTP包頭結構
RTP包頭結構如圖1所示,本算法關注的域如下[9]:
版本(Ver):2bit,RTP的版本,值是2。
負載類型(PT):7bit,定義了有效載荷的格式。其有效負載號對應相應的編碼名稱,部分負載號使用非RTP方式來動態(tài)定義,在同一RTP流當中,RTP負載類型是不變的。通過負載類型可以獲得流媒體數(shù)據(jù)的編碼方式,從而在接收端進行快速解碼。
序列號(SN):16bit,序列號初始數(shù)值一個隨機數(shù),但相鄰的RTP數(shù)據(jù)包SN有其變化規(guī)律,后前一包比前一包序列號加一,可以根據(jù)SN變化規(guī)律來判斷檢測丟包和重建包。
時間戳(TS):32bit,時間戳記錄RTP數(shù)據(jù)包的抽樣時間值。其初始值也是一個隨機數(shù),可以作為判斷RTP流的一個重要依據(jù)。
SSRC:32bit,用來標識RTP信息包流的起源,在RTP會話或者期間的每個信息包流都有一個清楚的SSRC,SSRC不是發(fā)送端的IP地址,而是在新的信息包流開始時源端一個隨機數(shù)。
對RTP協(xié)議的分析,可以總結的 “流特征”如下[10]:
(1)RTP的版本號Ver數(shù)值為2;
(2)在同一RTP會話中中,其有效載荷PT值為固定值;
(3)RTP會話中的SN值為遞增,后一包比前一包增加數(shù)值 “1”;
(4)RTP會話中Timestamp遞增數(shù)值有其變化規(guī)律;
(5)同一流媒體會話中RTP流的SSRC值為固定值。
RTP流的檢測識別是根據(jù)上述流特征分析展開,通過對數(shù)據(jù)包中特征字段的判斷來確定需要轉發(fā)的數(shù)據(jù)包,從而實現(xiàn)RTP數(shù)據(jù)包檢測識別和轉發(fā)。
對數(shù)據(jù)包的初步判定是利用RTP協(xié)議基本特性作為判斷依據(jù),通過對RTP包的特征屬性及特定位域數(shù)值的比對,初步過濾出可能的RTP報文。對于這些特性的判別基本上是靜態(tài)的數(shù)值檢測。
(1)UDP數(shù)據(jù)包類型檢測:RTP/UDP數(shù)據(jù)傳輸是流媒體數(shù)據(jù)傳輸?shù)闹饕绞?,由于本文設計的算法是針對基于UDP承載的數(shù)據(jù)傳輸,因此,首先判斷IP包是否承載UDP包。
(2)包長度有效性驗證:參照RTP數(shù)據(jù)包包頭,對于一個正常包含有VER、TS和SSRC等字段的有效RTP包來說,其UDP承載包的有效負載長度至少需要12個字節(jié)。
(3)VER字段匹配:這可以作為一條判別的標準,檢測UDP載荷數(shù)據(jù)前兩個比特是否是二進制 “10”,即是否與現(xiàn)行的RTP版本號相同(RTP的版本號是2)。
對RTP的精確識別是在對RTP包進行初步判定的基礎上對數(shù)據(jù)流中動態(tài)變化的數(shù)據(jù)字段分析,并從中尋找存在的變化規(guī)律。依據(jù)數(shù)據(jù)流變化的規(guī)律性,來檢測變化的相關值。在同一次的RTP通信中包類型、包長度和Ver數(shù)值具有固定特性,這對RTP包判別提供了依據(jù),但是僅僅判斷這些數(shù)值是不能準確識別RTP流。RTP包頭信息中SSRC、SN、TS的數(shù)值是在會話建立之初動態(tài)生成且有些在會話進行中將發(fā)生變化,但存在一定的規(guī)律性,能夠為更準確對RTP流檢測識別提供依據(jù),需建立針對RTP會話級(動態(tài))的信息可進行檢測的機制。
RTP會話特征信息對于不同的RTP會話連接完全獨立,僅在當次會話期間有效并存在一定的規(guī)律。檢測數(shù)據(jù)包是否滿足會話特征條件,首先需獲取其所在會話的相關狀態(tài)信息作為參照比對標準。開辟緩存并從處于同一會話連接的歷史數(shù)據(jù)包中抽取會話信息保存其中是獲取當前會話信息的有效途徑。
(1)檢測報文的地址和端口
一般情況下,流媒體應用程序在進行RTP會話時會使用一些特殊的端口(對)進行通信(如:5004和5005),如果僅利用這些簡單的通用特征作為判別標準顯然存在相當大的誤判概率。對于同一次RTP流會話,其數(shù)據(jù)報文應具有相同的源地址(端口)和目的地址(端口),還要RTP會話期的時效性進行判斷,可以將收到的數(shù)據(jù)包中這些相關信息暫存入緩存,作為后續(xù)數(shù)據(jù)包判別的標準。同時,這種對端口地址加會話時效的動態(tài)檢測處理方式能夠讓檢測程序更加準確,在使用時不必像大多數(shù)的過濾程序(包括Netfilter本身)那樣需提前根據(jù)特定情況來手工配置指定地址和端口的過濾規(guī)則。
(2)判斷PT、SSRC字段
通常,在同一個RTP會話中,負載類型PT值依賴于傳輸?shù)拿襟w數(shù)據(jù)類型且保持不變,即同一流媒體數(shù)據(jù)包RTP頭的9~15b值是恒定的。再者,對于同一次RTP會話雖然作為源標識符的SSRC是定值,但其值是在會話建立之初由發(fā)送方生成的隨機數(shù)。與地址端口相同,PT和SSRC具有會話期內的時效性,也應存入緩存,作為下一次檢測后續(xù)數(shù)據(jù)包對應的數(shù)值是否恒定的標準。
(3)檢測SN
從RTP的定義可知如果RTP數(shù)據(jù)包按順序接收,則相鄰的RTP數(shù)據(jù)包的SN應該以 “1”的步長線性增長,即:SNn-SNn-1=1,n>0??梢奡N具有動態(tài)延續(xù)性特征,需要利用緩存中的歷史數(shù)據(jù)進行檢測。
(4)檢測 TS
前后兩個數(shù)據(jù)包的timestamp也應該以時鐘分辨率(time resolution)線性增長,即;TSn+1-TSn=TSn-TSn-1=time resolution,n>1;TS的值與SN相同,其檢測也需要依據(jù)緩存歷史數(shù)據(jù)。
理想情況下數(shù)據(jù)包應當按照發(fā)送順序依次被接收,對應的SN、TS數(shù)值也應該是線性遞增的,且數(shù)值為 “1”。但是由于網絡傳輸?shù)脑颍跀?shù)據(jù)包接收時可能會出現(xiàn)RTP包的亂序和丟包。一旦出現(xiàn)數(shù)據(jù)包的亂序和丟包,就會在進行RTP檢查過程中因SN、TS的遞增數(shù)值可能不等于步長值而造成誤判。
針對RTP流中的亂序和丟包,對SN、TS的遞增數(shù)值采用閾值優(yōu)化。設置一個可以容忍的最大閾值,只要當前檢測的數(shù)據(jù)包與前一個數(shù)據(jù)包的SN、TS的遞增數(shù)值處于一個可以接受的最大閾值之內,則認為對SN和TS的檢測符合條件。即:︱SNn-SNn-1︱≤max_sn,n>0;︱TSn-TSn-1︱≤max_ts,n>1。
算法設計思路,對于收到的數(shù)據(jù)包,首先進行包類型、包長度等條件的快速初步判定,滿足條件后,再與緩存中的歷史數(shù)據(jù)進行比較驗證以作精確判定。
檢測判別算法基本流程如圖2所示,當數(shù)據(jù)包與緩存對象進行比對時,如果緩存對象與數(shù)據(jù)包的源地址、目的地址、源端口和目的端口不匹配,此時不是直接判斷RTP包,而是轉至緩存列表,再取一個緩存對象進行匹配檢查,因為緩存中的數(shù)據(jù)包源地址、目標地址、源端口和目標端口一般都不是唯一的。在檢查數(shù)據(jù)包PT、SSRC的數(shù)值和SN、TS遞增數(shù)值時,如果不匹配則是判斷非RTP包,此時對于同一真正的RTP流來說,其數(shù)值是不變的。由以上分析我們可以發(fā)現(xiàn),當?shù)谝粋€數(shù)據(jù)包到達時,緩存中沒有可取對象,從而生成新的緩存對象放入緩存,并且不認為它是一個RTP包,不對其進行匹配判斷。
除充分考慮RTP流識別的準確性外,還要提高算法的判別速度。設計上從以下3方面來考慮算法優(yōu)化:
(1)建立靜態(tài)緩存。緩存開辟通常有動態(tài)緩存和靜態(tài)緩存兩種方式。動態(tài)緩存雖然靈活性較好,但在程序運行時因需要對緩存區(qū)進行多次創(chuàng)建和銷毀,同時對緩存進行遍歷查找等操作時相比靜態(tài)方式運算量和開銷較大,復雜度較高。另一方面,從實際考慮,也不能無限制的開辟緩存,需要考慮開辟緩存區(qū)大小的問題。根據(jù)RTP流特征和實際需求,我們使用靜態(tài)緩存。
(2)判定過期緩存。因為選用的靜態(tài)緩存方式,其大小是恒定的。在緩存空間有限情況下,為了充分利用緩存空間,提高數(shù)據(jù)包的比對效率,實現(xiàn)RTP流的快速轉發(fā),我們在數(shù)據(jù)包存放緩存中時,標記一個時間戳,用以判定緩存數(shù)據(jù)數(shù)據(jù)是否有效以及是否為可用緩存。
(3)取消網絡字節(jié)序轉換。考慮到無需將數(shù)據(jù)包的地址和端口信息展現(xiàn)給用戶,同時不會影響比對效果,緩存中數(shù)據(jù)包的源地址、目的地址、源端口、目的端口數(shù)據(jù)直接以網絡字節(jié)序的方式存放,而不再轉換為主機字節(jié)序。直接以網絡字節(jié)序數(shù)值進行比對,可節(jié)省時間開銷。
圖2 RTP包檢測算法流程
依照上一節(jié)的識別算法的設計,下面定義兩個特定的數(shù)據(jù)結構存放可能的RTP數(shù)據(jù)包,作為后續(xù)數(shù)據(jù)包進行精確判定的依據(jù)。
struct_rtpbuffer{ /*緩沖區(qū)結構定義*/
unsigned long ul_prev_jiffy; /*數(shù)據(jù)包到達緩存的時間戳*/
在數(shù)據(jù)結構 “_rtpbuffer”中使用 “ul_prev_jiffy”成員表示緩存對象對應的數(shù)據(jù)包到達主機的時間截,該值取自Linux系統(tǒng)運行時間。當有新的數(shù)據(jù)包到達時,程序都將從系統(tǒng)取出一個時間值作為當前時間值,若該數(shù)據(jù)包滿足初步判定條件(靜態(tài)值判定)而需要與緩存對象進行逐一比對作精確判定時,首先將緩存對象的 “ul_prev_jiffy”與當前時間值進行比較,如果差值超過定義的閾值則認為該緩存對象已過期失效而繼續(xù)取出下一緩存對象直到找出有效對象再作匹配檢測。容易理解,過期的緩存空間即是處于空閑狀態(tài)的可用緩存,因而緩存區(qū)在初始化時應當將所有緩存對象的 “ul_prev_jiffy”值置為最小值 “0”。
此外,按照算法設計當數(shù)據(jù)包被判定為可能的RTP包時,應從緩存中取出一個空閑緩存以存放其對應的緩存對象(假設此時緩存區(qū)有空閑緩存),即需要再遍歷整個緩存區(qū)查找空閑緩存。實際上當發(fā)現(xiàn)緩存中沒有對象與數(shù)據(jù)包進行匹配時,程序已經完成了一次緩存的遍歷操作,因而在程序實現(xiàn)時為了提高程序運行效率,可以在做循環(huán)比對的同時,將發(fā)現(xiàn)的空閑緩存記錄下來以供后續(xù)操作使用,提高運行效率。
程序運行使用時,通過IPtables向Netfilter增加一個用于識別RTP流的規(guī)則,即讓Netfilter加載自行開發(fā)的規(guī)則模塊,模塊首先向Netfilter注冊并在內核中開辟相應的靜態(tài)緩存區(qū)。當一個新的數(shù)據(jù)包到達時,按照圖2的流程比對數(shù)據(jù)包中的特征數(shù)值,當檢查數(shù)據(jù)包的當數(shù)據(jù)包和程序的檢測規(guī)則匹配完成后,緩存區(qū)內數(shù)據(jù)包的prev_jiffy變?yōu)楫斍皶r間戳(now),rtphdr標識為rtp包頭,檢測程序提交Netfilter,識別出RTP流并快速轉發(fā)出去。
測試環(huán)境:一臺裝有Linux的計算機作為過濾網關(簡稱網關),本文設計程序部署在該網關上,通過IPtables配置相關規(guī)則讓Netfilter加載并運行針對RTP進行過濾的模塊程序。另有兩臺裝有Windows XP的臺式機來作為RTP流媒體數(shù)據(jù)發(fā)送和接收的終端。發(fā)送端組織RTP流,接收端記錄RTP數(shù)據(jù)包傳輸?shù)臄?shù)據(jù)包數(shù)目、傳輸時間等參數(shù)作為比對的標準數(shù)據(jù)。
測試步驟:
(1)使用兩臺終端計算機(Windows XP系統(tǒng))構建常規(guī)RTP數(shù)據(jù)包發(fā)送與接收環(huán)境,使用Winpacp抓包程序記錄5種不同編碼格式的媒體文件中RTP流傳輸?shù)臄?shù)據(jù)包數(shù)目、傳輸時間作為比對的標準數(shù)據(jù);
(2)將網關架設于兩臺終端之間,運用傳統(tǒng)識別算法檢測識別RTP流,傳統(tǒng)識別算法主要通過人工預設規(guī)則匹配發(fā)送端和接收端數(shù)據(jù)包地址、端口信息,同時匹配檢查RTP固定包頭中Ver、CC、PT、SN、TS、SSRC六個參數(shù)值,來判斷是否為RTP包。通過抓取識別到的RTP包記錄產生的誤判漏判和耗費時間;
(3)對網關使用的優(yōu)化識別算法,通過設計程序自動檢測識別數(shù)據(jù)包地址、端口以及RTP固定包頭中Ver、PT、SN、TS、SSRC五個參數(shù)值判斷RTP包,記錄誤判漏判和耗費時間。
依上述測試步驟,分別針對不同編碼格式的媒體文件進行5次實驗,測試結果對比見表1。
表1 實驗結果
從表1中測試結果數(shù)據(jù)可知,對不同編碼格式的媒體文件經RTP編碼后,使用兩種識別算法分別進行測試,流媒體數(shù)據(jù)包的誤判率和漏判率基本保持不變,而基于RTP流檢測識別優(yōu)化算法明顯降低了誤判和漏判的概率,縮短了檢測識別時間,從而使RTP流的識別更加準確和快速。
在Linux系統(tǒng)內核Netfilter模塊中加載匹配模塊來設計RTP優(yōu)化識別算法,優(yōu)化算法對數(shù)據(jù)流的識別率達到了一定的要求和精度。針對不同類型的流媒體文件進行實驗,更為準確地檢測識別出了流媒體數(shù)據(jù)包中的RTP流,誤判率和漏判率明顯降低,同時本文的優(yōu)化算法與現(xiàn)有算法相比明顯提高了識別速率。為網絡流媒體數(shù)據(jù)包快速準確識別提供了很好的判斷依據(jù)。
本文主要通過對流媒體協(xié)議RTP/RTCP的分析,在Linux系統(tǒng)Netfilter架構中設計了專用算法,通過檢測RTP包中的Ver、PT、SN、TS、SSRC的數(shù)值來識別RTP流,實現(xiàn)了RTP流自動檢測識別和快速轉發(fā),并通過實驗驗證了識別算法的有效性,對網絡流媒體的識別具有積極地意義。在下步工作中,將進一步根據(jù)RTP流負載類型識別音視頻數(shù)據(jù),對傳輸中音視頻數(shù)據(jù)進行優(yōu)先級控制,實現(xiàn)流媒體數(shù)據(jù)的QoS調控。
[1]WANG Yanli,CHEN Ming,CHEN Hua,et al.Design and implementation of a digital video surveillance system based on RTP/RTCP[J].Computer Engineering and Science,2009,31(3):58-65(in Chinese).[王彥麗,陳明,陳華,等.基于RTP/RTCP的數(shù)字視頻監(jiān)控系統(tǒng)的設計與實現(xiàn)[J].計算機工程與科學,2009,31(3):58-65.]
[2]XU Li,ZHAO Xi,ZHAO Qunfei,et al.Network application protocol identification based on statistical methods[J].Journal of Xi’an Jiaotong University,2009,43(2):43-47(in Chinese).[徐莉,趙曦,趙群飛,等.利用統(tǒng)計特征的網絡應用協(xié)議識別方法[J].西安交通大學學報,2009,43(2):43-47.]
[3]CHEN Xianqing.Design and implementation of the application layer protocol filtering system[D].Chengdu:University of E-lectronic Scinence and Technology,2010(in Chinese).[陳獻慶.應用層協(xié)議過濾系統(tǒng)設計與實現(xiàn)[D].成都:電子科技大學,2010.]
[4]LIU Junchao.Regular expression-based application layer protocol identification technology research[D].Changsha:National University of Defense Technology,2008(in Chinese).[劉俊超.基于正則表達式的應用層協(xié)議識別技術研究[D].長沙:國防科技大學,2008.]
[5]Nguyen T T,Armitage G.A survey of techniques for internet traffic classification using machine learning[J].IEEE Commun Surveys Tutorials,2008,10(4):56-76.
[6]Bernaille L,Teixeira R.Early recognition of encrypted applications[G].LNCS 4427:Passive and Active Network Measurement,2007:165-175.
[7]LIU Jiaxiang.Two approaches to RTP flow discriminator[J].Computer Knowledge and Technology,2011,7(4):880-882(in Chinese).[劉佳翔.RTP協(xié)議流媒體識別算法的設計與實現(xiàn)[J].電腦知識與技術,2011,7(4):880-882.]
[8]YANG Gang,CHEN Shuyu.Research on Linux firewall based on Netfilter/Iptables[J].Computer Engineering and Design,2007,28(17):4124-4132(in Chinese).[楊 剛,陳蜀宇.Linux中基于Netfilter/Iptables的防火墻研究[J].計算機工程與設計,2007,28(17):4124-4132.]
[9]RFC3550-2003.RTP:A transport protocol for real-time applications[S].
[10]SONG Xue,CAI Yibing,JIN Weixin,et al.Study and implementation of network streaming media recognition algorithm based on winpcap[J].Modern Electronics Technique,2010,(11):108-110(in Chinese).[宋雪,蔡一兵,金偉信,等.基于Winpcap的網絡流媒體識別算法研究與實現(xiàn)[J].現(xiàn)代電子技術,2010,(11):108-110.]