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包中的数据和工具原生支持的协议构造出来的数据相比要更难以控制，出错的可能性根大，而且流量被很大的放大之后就难以控制，对测试工具的稳定性要求更高，更易出错。