DPI, Deep Package Inspection，不算是很新的技術，出現了有一段時間了，大概主要用於access control，QoS， 以及安全掃描等方面，所以很多做網絡設備和安全的廠商基本都會涉及到相關的技術。國內也有很多的廠商推出了相關的產品，比如針對上網行爲管理，可以分析出不同類型（IM, P2P, online game等）的網絡訪問佔用了多少的帶寬和流量，進一步可以做一些控制。
我之前在做的產品沒有直接涉及這方面的技術，但是一直對網絡比較感興趣（讀研時最喜歡的專業課就是計算機網絡），所以也順道study了一點。下面的link有些介紹和討論，
http://www.tektalk.org/2010/07/02/dpi-deep-packet-inspection-%E6%8A%9B%E7%A0%96%E5%BC%95%E7%8E%89/
wiki 上也有 對應 的介 紹 。
另外如果想practice的 話 也 有了 open source的engine可以用。
http://www.opendpi.org/
最近接觸了一些相關的產品，因爲工作的原因，比較focus在如何測試這樣的產品。因爲DPI會涉及到對很多不同的應用層協議的解析和處理，而且這些協議不是http, smtp等標準互聯網協議，而是qq, msn, warcraft這種廠家的私有但是有廣大用戶羣的協議，這就對我們的測試提出了新的挑戰，包括功能和系統測試方面。功能方面，我們需要去模擬使用這些協議的流量，真的也好fake的也好。而系統測試，比如性能和穩定性測試，則更進一步，需要把這些流量混合並且放大。這就對我們的測試方法，包括測試工具提出了更高的要求。
下面 說說最近的一些心得體會，希望和大家多交流，因爲在這一塊也是新手，所以希望不吝指教。
首先我 們 從需求 說起 。
和標準的協議相比，雖然也是針對協議的測試，但是要求其實不一樣。某種程度上，要求更低，這是因爲產品對協議處理的粒度更粗。例如一個以處理 SMTP協議爲主要功能的產品，它需要比較深入的介入到協議的不同的階段，包括連接的建立， greeting message，發信人地址，收件人地址，郵件頭等等。對於這樣的產品的測試，測試工具也需要對協議有相同的理解和支持。而目前來看對於 DPI相關的產品，大多不需要對於協議有這麼深的瞭解。比如對於 MSN,並不要求理解建立連接，認證，發好友名單，等等過程。只是要做到能識別相關的包是 MSN協議相關的，有些要求能識別裏面的內容，比如 string， url，或者傳的 file，然後可以做流量控制和過濾。
但是另一方面，雖然對於單個協議的粒度粗了，但是從廣度上講，協議的數量要大得多，通常要到幾百的量級，而且另一個方面，這些協議有很多是廠商的私有協議，不是業界標準，所以也是在不斷的升級變化中的。
很多時候，我們遇到的新問題都是這樣，在有些方面要求高了，但是在有些方面也變得簡單了，否則也太悲慘了。
接下來主要的問題就是我們如何模擬基於這些協議的流量，後面的討論也主要集中在這個方面，而且偏重於性能測試方面。
或者這樣的流量粗略來看大概有三種方法。
1. 安裝這樣的應用，連到真實的 server（通常很多協議是沒法搭建私服的）。
這種很容易想到，但是實際做起來比較困難，耗費很大，而且難以控制想要的流量和比例。對於功能性的驗證，倒是可以藉助 beta測試來這樣做。
2. 尋找能原生支持這些協議的測試工具。
現在也確實有一些測試工具宣稱支持很多非標準的應用協議，比如 BreakingPoint System推出的硬件工具，可以直接在工具裏面模擬出幾十上百種不同的類似上面提到的 popular的協議。不過我目前還沒有試用過這一部分，不瞭解能模擬到什麼程度，以後有機會接觸到再和大家分享。
3. 用 pcap包回放的方法。
這是一個變通的方法，結合上面提到的比較粗粒度的要求，這其實是一個比較取巧的方法。而且相比 1，是一個具有重複性的方法，可以一次把相應的包錄下來，然後在需要的時候重放，也比較容易控制。
其實這也是一種現在比較普遍使用的方法。後面我們針對這個方面來討論一下。
因爲了解有限，就說說我接觸到的方法，也許業界還有更多更好的工具，也希望大家指點。
接觸到的第一個工具是 tcpreplay，這時一個 linux上面 open source的測試工具集，主要的功能就是修改和回放 pcap包。和 tcpdump和 wiresharek這來抓包工具結合起來可以實現協議的存貯和回放。
經過自己的試用，以及與其他 team同事的交流， tcpreplay對於 DPI的測試主要有下面的特點。
1. 可以對 pcap包進行預處理，比如修改其中的 mac， ip和 port等信息，由單獨的 tcpwrite來完成。這是一個很重要的功能，因爲抓下來的包的這些信息並不一定適合回放的時候的環境。
2. 可以將 c/s兩端的流從兩個 NIC發出去，這個對於某些網關型的設備可能比較由幫助。
3. 可以在發送時指定網卡， IP等信息
4. 可以指定以多倍速來回放數據包，以產生更大的流量。
5. 可以選擇性的發部分包。
對於很多功能性的測試需求， tcpreplay應該能夠基本滿足要求。但是對於大流量的測試的時候也會發現一些侷限。比如下面幾個方面。
1. 無法直接 的 放大流量
目前來看， tcpreplay是通過加快回放速度的方法來加大流量，但是如果要很高的流量，比如接近 1Gbps，可能還是比較困難。
2. 無法 直接指定 多 IP, 如果要模擬大量的流量，來自不同的 client，可能做起來還是不太方便。
3. 無法直接混合多個 pcap 來同時回放， 或者將 pcap 和其它 協議混合 在一起來發。因爲對於性能測試來說，同時來發起混合的流量是很重要的。 tcprepaly目前是要求放到同一個 pcap文件裏面，而 爲了測試的靈活性，建議不同的協議放在不同的 pcap 裏面，而不要把多個 協議的抓到一起，這樣將來控制類型和比例都會比較困難 。
當然，上面的三個限制也可以部分的通過外面的 wrap up腳本來改善，通過腳本來起多個 tcpreplay來放大。不過沒有試過這樣可以起到多大的流量，已經穩定性如何。
針對這一方面的測試需求，目前商業的測試工具也有對應的解決方案。主流的幾家測試設備廠商都有對應的測試工具，包括 Spirent的 Avalanche ，和 IXIA的 IxLoad，以及前面提到的 BreakingPoint 都有自己的解決方案。就目前試用的情況來看，商業工具在這方面做得比開源工具要好，至少目前看到的差距要大一些，比 JMeter和 LoadRunner之間的差距要大。
比如最近用到的 Avalanche中的 SAPEE模塊，功能還是不錯的。
1. 可以導入多個 pcap包，然後在識別出中的 stream，顯示在 GUI中。
2. 由於是集成在 Avalanche中，每一個 pcap file中的流都是一個獨立的 action list，可以很方便的和其他 pcap，或者內建支持的標準協議自由的混合在一起。在網絡方面的配置，比如網段和 IP,以及 load curve等方面，都可以直接複用原來的測試配置，使得在很大程度上，這些被 import進去的 pcap包中的流量被當成了標準協議，只是少了一些細粒度的控制。
3. 可以很容易從外部放大，直接指定有多少個 virtual user，多少個連接。
4. 可以將 client的 IP參數話，和測試 config中的網絡設置結合起來，實現了放大。
5. 對一個 stream中 package的延遲，可以比較細的控制，比如使用錄製時的延遲，還是去掉延遲，或者加入我們想要的延遲。這一點和標準協議中 think time的控制比較像，但是因爲不理解應用層的協議，所以不能在應用層邏輯上的段落來添加。能做到這樣，測試工具本書就是 DPI設備了。
就目前來看，很大一部分需求都可以滿足。但是除了昂貴的價格之外，也可能有一些問題，比如：
1 . 如何區分正常和不正常，比如對於某些協議或者內容，被測設備就應該阻斷它，那麼這時回放的 session 會被打斷， client 是否會 認爲是不正常，然後重放？
2 。 穩定性的問題 。因爲 pcap包中的數據和工具原生支持的協議構造出來的數據相比要更難以控制，出錯的可能性根大，而且流量被很大的放大之後就難以控制，對測試工具的穩定性要求更高，更易出錯。