基于DPI不對稱流量的同源同宿解決方案

潘潔，高峰，劉棟，董昭，侯慧芳

（1.中國移動通信集團設計院有限公司，北京 100080；2.中國移動通信集團采購共享服務中心，北京 100053）

基于DPI不對稱流量的同源同宿解決方案

潘潔1，高峰2，劉棟2，董昭1，侯慧芳1

（1.中國移動通信集團設計院有限公司，北京 100080；2.中國移動通信集團采購共享服務中心，北京 100053）

在當前互聯網應用分析領域，為了獲得更加準確的基礎數據，流量采集時需要保證每次會話流量的完整性。通過對流量不對稱的起因及影響進行分析，結合業務分析的實際需要，提出同源同宿流量歸并基本思路和解決方案。

不對稱；同源同宿；散列算法

1 引言

在互聯網絡工程建設中，出于負載均衡、路由安全保護等考慮，運營商一般按網狀、多出口的結構進行設計和建設，導致互聯網絡中較多完整端到端會話（session）的上行流、下行流分布在不同的物理鏈路中，當不同的鏈路接入不同的流量采集設備時將會造成會話數據不完整，因此需要在數據分析之前對非對稱流量進行同源同宿處理。同源同宿處理是深度分組解析 （deep packet inspection，DPI）應用的重要基礎。

2 網絡流量不對稱原因

目前造成會話不完整的主要原因是網絡路由不對稱，這是由網絡中路由器的工作特點決定的：路由器在接收到數據分組時，會根據路由協議對下一跳路由度量值（cost）進行計算，并選定一個最優路由進行數據轉發，源、宿兩端的路由器在路由選擇時可能各自選擇一條最優但不重合的路由。最典型的情況是兩個相鄰路由器間有多條等價的最優路由，A→B發送數據時選擇第一條路由；B→A發送數據時選擇另一條路由，從而造成路由不對稱。當前大部分城域網采用雙出口的結構建設，兩個出口流量負荷盡量均等。網絡結構和數據流向如圖1所示。

圖1 多節點出現的流量不對稱

圖1以HTTP Web訪問行為為例。當用戶訪問遠端的Web服務器時，其上行請求數據由A路由器進入骨干網（路由如圖1中左側實線①），服務器做出響應時其數據經骨干網另一入口并由B路由器返回到用戶（路由如圖1中右側虛線②）。此時部署在A出口的采集設備只能獲得上行數據，部署在B出口的采集設備只能獲得下行數據，各自將數據傳遞給分析系統時二者無法直接關聯，數據分析結果自然不全面、不準確。

對于同一個路由器，如圖1中A路由器轉發端口有4個，通過該路由器的上行數據可能從1#端口發出，下行數據雖然回到A路由器但可能從4#端口接收，若采集設備按照端口分開部署，則各自所采集的數據仍然不全面，如圖2所示。

圖2 單節點出現的流量不對稱

在網絡節點配置路由器的時候可以采用基于數據分組（packet）或者數據流（flow）的負載均衡方式進行數據轉發，當前各運營商主要采用基于數據流的方式進行負載均衡，而基于分組的方式則更加復雜，故本文均按照基于數據流的負荷分擔部署方式分析。

3 流量不對稱影響分析

當存在流量不對稱時，基于數據流的分析應用將受到嚴重影響。

（1）IDC/ISP信息安全監控

當監控上行（相對終端用戶來說，訪問IDC資源的請求為上行）鏈路的采集系統發現寬帶用戶訪問了違規網站時，信息安全系統必須在下行鏈路中對違規關鍵字內容信息進行封堵，并告知上行鏈路對此URL進行封堵，建立訪問日志、封堵日志。若流量不對稱，上下行數據流關聯不上，則上行發現違規時無法直接匹配下行封堵，封堵日志中“訪問URL”字段無法填充。

（2）僵木蠕檢測控制

當監控上行鏈路的采集系統發現用戶訪問了有僵木蠕代碼的網站時，系統需要在下行鏈路對代碼數據進行掃描、還原形成病毒樣本，若判定為病毒則需要告知上行鏈路封堵訪問URL。若流量不對稱，則根本無法觸發還原和有效封堵。

（3）流量流向分析

當監控的流量不對稱時，理論上可以對入網流量和出網流量進行單獨統計，然后進行全域的合并歸類分析。但這樣會給分析系統造成繁重的運算壓力，網絡規模較大時，需要配置龐大的存儲計算資源。故一般在采集系統部分就將上下行流量進行關聯，然后報送分析系統。

（4）網絡感知分析

網絡感知需要獲取一個會話中完整的信息，以確定TCP建立連接的過程中各個環節的時延。當監控的流量不對稱時，只能獲取請求報文的信息，無法獲得回應報文信息，因此TCP時延無法計算。

目前部分運營商基于業務需要和成本考慮，在省網出口部署的DPI（深度分組解析）一般只監控上行鏈路，故無需對下行流量進行檢測，也無需進行同源同宿處理。在此部署環境下，可開展的業務應用包括用戶行為分析（PV等）、HTTP get報文獲取、信息推送等，而對流量有關的統計、控制等不太關注。

4 同源同宿的基本原理

為了解決流量不對稱造成的影響，就要對鏈路流量進行同源同宿處理。

同源同宿是基于散列算法來實現的。散列算法又叫散列表（hash table），通過把關鍵碼值（key value）映射到表中一個位置來快速查找。這個映射函數叫做散列函數，存放記錄的數組叫做散列表。同源同宿的散列算法中關鍵碼值是每條流的五元組信息（源IP地址、源端口、目的 IP地址、目的端口、協議號），同樣的五元組得出的散列算法結果是一樣的。當對上行流量、下行流量進行標記，將下行的源IP地址、源端口地址、目的IP地址、目的端口對調之后，就能獲得同樣的散列值。在流量匯總輸出時，只需將同樣散列值的流量通過同一端口輸出，即能實現上、下行流的關聯歸并。在實際的散列值計算時常用除留余數法，對所有散列值用總的輸出口數進行取模，得到的余數決定了由哪個端口輸出。

舉例說明。設置輸出組里包含N個輸出端口，某個會話 （以五元組信息來標記一個會話，上下行需要標記、調換）通過散列算法算出散列值為A，用A對N進行取模運算，算出值是a。那么這個會話（相同五元組信息的所有數據分組）將會從N個端口中的第a個輸出。

匯聚分流設備在同源同宿處理時將接收的所有流量通過散列算法將數據分組歸并、關聯后轉發到不同的輸出端口，達到將同一個會話的數據從同一個輸出端口輸出的效果。由于散列算法是基于所有流量的運算，所以對同源同宿處理的不同設備、插板必須取定相同的散列算法以保證同步。

同時匯聚分流設備在同源同宿處理時還要同步支持多個相關功能，包括：

·支持按照五元組的任意組合（如一元、二元、三元、四元）進行散列計算；

·能調整不同端口的輸出量權重，從而調整不同端口的輸出流量比例；

·在某輸出端口出現故障（link down）時能夠自動將負載分擔到其他幾個端口；

·正確匹配并轉發IP碎片報文，使屬于同一數據分組的碎片能發送到同一端口。

不同匯聚分流器廠商的散列算法在上述基礎上略有不同。

5 同源同宿解決方案

同源同宿解決的目的是將會話的上下行數據集中在一臺設備采集，保證數據采集的關聯性和完整性。目前處理同源同宿主要有4種環境：單板、單機箱、單機房多機箱/跨機房、異廠商間的同源同宿。本文按照雙向并接部署方式進行舉例說明。

5.1 單板同源同宿

當鏈路數量較少、可以接入分流設備同一塊單板時，只需在該接口板上配置散列算法，將多條鏈路中同一散列值的流數據在同一端口輸出即可，如圖3所示。

圖3 單板同源同宿解決方案

5.2 單機箱同源同宿

當鏈路數量較多、需接入分流設備多塊單板時，一條會話的上行流數據可能在1#接口板接入、下行流數據在3#接口板接入，則此時兩塊單板配置相同的散列算法，通過交換板的調度將不同接口板接入的同一散列值的流數據全部集中在一個端口輸出，如圖4所示。

5.3 單機房多機箱/跨機房同源同宿

5.3.1 單機房多機箱

當監控鏈路數量繼續增加，需多個分流機箱接入時，將全部分流設備配置完全一致的散列算法和端口輸出方式，將相同散列值的數據輸出給同一個采集設備進行處理，DPI采集設備再做一次同源同宿（類似單板）處理，如圖5所示。

圖4 單機箱同源同宿解決方案

圖5 單機房多機箱同源同宿解決方案（單級）

當單個機房內總流量超大時，采用上述方式將導致DPI采集系統端口受限，無法單臺設備接入全部分流機箱時，需要采用二級分流模式。第一級分流設備接入鏈路流量然后采用同樣的算法輸出到第二級分流設備，第二級分流設備會將第一級同樣算法的流量再進行同源同宿輸出到DPI設備，如圖6所示。

圖6 單機房多機箱同源同宿解決方案（多級）

5.3.2 跨機房

當監控鏈路分布在不同機房，而又需要全部鏈路做上下行數據關聯時，即需要跨機房的同源同宿。可將兩個機房的接入流量完全復制到一個機房后，在單個機房完成同源同宿處理和采集。但往往由于監控鏈路過大，采用此種方式調度需要消耗大量傳輸資源。故可根據實際上下行鏈路情況，將本機房較少的上行流量轉接到另一機房，從而保證單個機房均能監控到上行和下行數據，進而進行同源同宿處理。具體方案如圖7所示。

圖7 跨機房同源同宿解決方案

5.4 異廠商DPI設備同源同宿

對于不同廠商之間的匯聚分流設備處理流量歸并，最徹底的解決方案是運維部門將城域網路由器的流量策略歸并好，實現上行和下行走同一鏈路。但這個方案主要取決于現網路由規劃和實際運維條件，如果無法改動路由方式，則需要在各個分流器廠商之間打通流量歸并的接口來解決。有兩種思路可以選擇：

·采用流量散列策略把同源地址段的流量散列到同一廠商的設備里，保證同一用戶的上下行流量經由同一廠商設備進行處理；

·采用分級部署歸并方案，在兩個廠商的設備之后再部署一級服務器作為流同步服務器進行異廠商信息互通。

5.4.1 散列方式的異廠商設備流量歸并

本方案和同廠商之間的同源同宿類似，基于源地址段把用戶的上行和下行流量匯聚到一臺設備上。具體的處理方式是A廠商的設備把源地址段B的上行流量轉發給B廠商設備進行處理，B廠商設備把目的地址段是A的下行流量轉發給A廠商設備進行處理。這樣保證源地址段A的用戶一定在A廠商設備上處理、源地址段B的用戶一定在B廠商設備上進行處理，如圖8所示。

此方案的優點是當兩個廠商支持相同的散列策略時，可以把上下行流量匯聚在同一塊業務板進行處理，可以實現非常好的協議識別效果和準確的XDR話單處理。流量控制和智能鏡像功能也都非常完整。

此方案的挑戰在于進行流量歸并的兩個廠商是否能支持相同的散列算法。如果兩個廠商不能支持相同的散列策略，就無法實現同一用戶的流量歸并。這些散列策略包括源地址/目的地址散列方式，散列目標鏈路的數量和負載分擔選擇算法。如異廠商之間無法在前面的3個參數達成一致就無法實現有效的流量歸并。

圖8 基于散列方式的異廠商同源同宿解決方案

5.4.2 分級部署方式流量歸并

分級式部署方案在異廠商無法按照散列方式進行流量歸并時提出了另一種部署方案。通過引入一級流同步服務器來實現兩個廠商之間的信息互通，從而提升協議識別的準確率和話單輸出準確率。該方案如圖9所示。

圖9 基于分級流同步的異廠商同源同宿解決方案

流同步模塊在兩個DPI廠商設備之間同步自己設備上的每一個流的摘要信息和協議識別信息，從而提高協議識別準確度和話單。這個同步需要兩個廠商按照統一的格式開發消息結構。流同步服務器負責把兩個廠商的流信息進行實時和把DPI設備進行同步。這涉及兩廠商的深度開放，難度更大。

6 結束語

同源同宿處理是深度分組解析 （DPI）應用的重要基礎，處理的好壞將嚴重影響到協議識別、流量統計、XDR話單質量，進而影響運營商的各類數據分析應用，因此在相關DPI項目中需投入大量精力來解決同源同宿。

本文對多種場景下的同源同宿方案進行深入剖析，力求以更簡化的網絡結構和更少的成本投入達到更理想的處理效果，為運營商的互聯網流量分析系統建設提供參考。

[1]謝希仁.計算機網絡 （第6版）[M].北京:電子工業出版社, 2013. XIE X R.Computer network(6th edition)[M].Beijing:Electronic Industry Press,2013.

[2]張詩超.OptiWay T技術白皮書[R].[S.l.:s.n.],2013. ZHANG S C.The white paper OptiWay T technology[R].[S.l.:s.n.], 2013.

[3]LAWRENCE B.TCP/IP詳解卷1：協議[M].范建華,胥光輝,張濤,等譯.北京:機械工業出版社,2000. LAWRENCE B.TCP/IP volume 1:agreement[M].Translated by FAN J H,XU G H,ZHANG T,et al.Beijing:Mechanical Industry Press,2000.

潘潔，女，中國移動通信集團設計院有限公司工程師、高級咨詢設計師，主要研究方向為數據網絡。

高峰，男，中國移動通信集團采購共享服務中心高級工程師、采購四部副經理，主要研究方向為數據網絡。

劉棟，男，中國移動通信集團采購共享服務中心高級工程師、項目經理，主要研究方向為數據網絡。

董昭，男，中國移動通信集團設計院有限公司高級工程師、網絡所副所長，主要研究方向為數據網絡。

侯慧芳，女，中國移動通信集團設計院有限公司工程師、咨詢設計師，主要研究方向為數據網絡。

Homologous homoclinic solutions based on DPI traffic asymmetry

PAN Jie1,GAO Feng2,LIU Dong2,DONG Zhao1,HOU Huifang1
1.China Mobile Group Design Institute Co.,Ltd.,Beijing 100080,China 2.China Mobile Procurement Shared Service Center,Beijing 100053,China

In the field of current internet application analysis,in order to obtain more accurate basic data,traffic collection needs to ensure the integrity of each session traffic.The cause of traffic asymmetry and the impact analysis,combined with the actual needs of business analysis,homologous homoclinic flow merge the basic ideas and solutions were proposed.

asymmetry,homologous homoclinic,hash algorithm

TP913

A

10.11959/j.issn.1000-0801.2016306

2016-11-10；

2016-12-07