“DPI (Deep Packet Inspection) 抛砖引玉”有68个回复

1. Apple 于 2010-07-02 8:16 下午

   谈谈我的理解,
   首先DPI的理解狭义和广义范围不同,当然本身对DPI业界并没有很标注的定义,
   但是狭义的DPI一般把协议识别,协议解析作为其中的一部分,有时也包含L7协议规则匹配,广义的DPI大家也会把报表等也包含近来.

   对于基于特征码的协议识别,用DFA或正则算法的比较少,因为特征码一般不需要通配符,但是常用到偏移量,可能会用到改造过的多模算法来支持偏移量.
   其实协议识别大家的做法都差别不大,但是行文分析的识别确实是大家能力高下的一个重要对比,但是实际上必须需要行为识别的协议的种类很少,并且基于行为识别的本身特性,实际应用的范围很有限,skype是行为识别的主要原因.加密协议也是可以分析出特征吗的,不是所有的加密协议都不能用特征码的.

   DPI现在基本是网关设别的必备功能,应用的范围很广发.

2. multithreaded 于 2010-07-02 10:32 下午

   >对于基于特征码的协议识别,用DFA或正则算法的比较少,因为特征码一般不需要通配符,但是常用到偏移量,可能会用到改造过的多模算法来支持偏移量.

   L7-filter 用的就是正则表达式和很多通配符。 协议识别的难点就在于域的偏移量无法确定。 不知你说的多模算法是指什么？

3. Apple 于 2010-07-03 6:59 上午

   L7-filter这种东西坦白说实在太烂了,前端的DPI 厂家都支持将近1000种协议,就靠他那个东西实在拿不出来,我记得以前他用的那个正则库还有Bug,不太明白的事这个东西居然被允许放在了kernel里, 如果你对相关的算法比较熟悉的话就会知道在协议识别上用正则那就大材小用了.

4. 知迷不悟 于 2010-07-03 5:45 下午

   凑个热闹。

   做DPI相关的事情，那个L7-filter的想法还是可以借鉴的，问题当然也是很多啦，正则库里那个内嵌编译过程里tolower就不太美，还有那个skbuf字符转换操作…当然好处是有开源，大家可以学习借鉴之，因而我看这个l7-filter比之厂家吹嘘可做上千种协议支持库倒是更让人放心一点。

   DPI里的识别不是简单地特征比较，所谓的“正则式大材小用”我倒不认同，反而是正则式经常不够用。

   另外纠正一下原作者的概念，DPI并非只是针对协议特征分析，而是逐步关注网络应用特征分析，还有就是DPI里面比较热的是加密应用类的识别。

5. IPO 于 2010-07-03 6:51 下午

   Layer 7 First to Launch Fifth-Generation XML Acceleration Technology。看新闻稿里LSI同时有DPI和XML processing芯片，这两种处理过程的区别在什么地方？

6. Andy 于 2010-07-03 9:08 下午

   DPI包含ACL么?
   ACL只分析包头就可以，这个普通交换机能做到。
   DPI应该是要分析Header+Payload，行为复杂些，多核CPU实现吧

7. multithreaded 于 2010-07-03 11:04 下午

   说了半天， 还是没有讲明白什么是多模算法？ 是否用英文注释一下呢？

   As for the relationship between regular expressions and DPI, please read INFOCOMM and SIGCOMM releated papers.

8. 陈怀临 于 2010-07-04 4:01 上午

   多线程兄没事就让人读INFOCOM：-）。这个世界上能达到你要求的人不多。。。您的要求，。。。有点。。。

9. skywalker 于 2010-07-04 8:29 上午

   多模匹配，简单的说，就是一次可以同时查找多个模式串。 Protocol Identification 是DPI 里面的第一步，比如，要识别出HTTP流量。
   Application Identification 是 DPI里面第二步，比如，识别HTTP访问的是视频，还是语音，还是普通网页，还是数据库查询。
   这两个都需要结合 模式规则库和行为分析。 因为应用协议的版本经常在变化，而且，世界各个地区的同样应用可能还有差别，比如，第一个包的长度由于编码问题，可能有区别， 所以，是需要很大的人力和资源去维护，去更新这个识别库。 从这个意义上说，L7 Filter是不能产品化，只能看看而已。

10. 理客 于 2010-07-04 11:14 上午

    DPI的技术本身对软硬件系统的特殊需求是很有意思的事，同时DPI在实际IPIT中的应用也很有意思，比如QOS，QOS除了的几个简单队列的网络传输的QOS设计，其实是有很广泛的含义，抛开技术本身，QOS体现在用户对服务的体验上，而服务的体验对商人来讲要体现在投资回报上，当然，QOS要在有业务拥塞时才有意义，对于各种internet业务的区分处理，就非常重要，比如金融业务如果使用IP网络而不是optical网络，金融企业如何要求QOS/SLA？视频服务，如果要求QOS？比如在资源有限，而用户很多的情况下，云计算是一个选择，除了这个东西，那么是否要根据内容不同提供不同的QOS，比如点击率高的内容，要给高的QOS，点击率低的给予低的QOS，杀贫济富还是傻富济贫在商人眼里是需要仔细权衡利弊的问题，所以所有IT业务利用DPI得到更好的服务策略，这是DPI一个非常广泛的空间，也许DPI和netflow还可能做一些故事。IPIT发展到现在，其实还在少年，前途不是小好，是一片大好

11. droplet 于 2010-07-04 8:16 下午

    1）应用协议有没有可能用严格的语言描述？ip,tcp,udp之类的协议可以用严格的数据结构描述，但是http显然不能。

12. multithreaded 于 2010-07-04 9:39 下午

    >多模匹配，简单的说，就是一次可以同时查找多个模式串。

    多模匹配的算法无外乎有DFA和NFA两种，由于NFA是一种便于硬件实现地方法，DFA一般用于软件的实现上。

    不太理解APPLE的观点：”对于基于特征码的协议识别,用DFA或正则算法的比较少。“

13. multithreaded 于 2010-07-04 9:42 下午

    http 可以用BNF表示：

    http://en.wikipedia.org/wiki/Backus%E2%80%93Naur_Form

14. DPI PhD 于 2010-07-05 6:16 上午

    学校里面就是做这个的，当时用snort的3000个左右signature做了一个并行NFA，对，是NFA不是DFA。这个NFA有点tricky的地方在于只能使用固定字串构成，Regex只能老老实实使用DFA或者回溯。 陈首席，在心声论坛上经常看到你的发言，很想和你Notes交流。

15. multithreaded 于 2010-07-05 7:10 上午

    如果只能使用固定字串， 就变成了string（字符串）匹配的问题， 用NFA不太合适。

    不过你能把3000个左右signatures 放在一起， 也是一项和了不起的的工作。 如何解决空间爆炸的问题？好像能把SNORT的HTTP的100多条规则放在一起的工作也不多。

16. multithreaded 于 2010-07-05 7:13 上午

    》多线程兄没事就让人读INFOCOM：-）。这个世界上能达到你要求的人不多。。。您的要求，。。。有点。。。

    这里很多人有理想想当大牛，是对潜在的大牛人来说的。

17. Panabit 于 2010-07-05 7:57 下午

    牛人很多！但是最好的方法还是多看数据包，数据包看多了，就有感觉了。我们研究的东西往往只是某个领域的一个很小的子集，所以有很多地方都可以再具体化，提升算法和方法的针对性。描述特征最好的方法可能是代码，而不是什么数据模式。

18. up panabit 于 2010-07-05 9:06 下午

    sure~

19. droplet 于 2010-07-06 6:21 上午

    对于运营商来说，QoS能不能这样做：
    1）对于能够识别的应用，给予相应的优先级
    2）对于不能识别的应用，给予最低优先级，并对session有一定的控制。
    这样，开发应用的人就会遵守协议，而不是采用逃避的手段。DPI对于SP来说，只需要识别，而不像IDP那样，需要阻断。
    http的BNF对于协议验证来说还是不够，对于实现的要求太少，导致很多实现都不标准。比如基于XML的协议，就不行是符合一定的规则，而且语言的定义也很规范，不合规范的实现没法互通。这样就可以杜绝非法实现，增加网关识别和终端识别的难度。
    如果DPI也想病毒识别那样，更新快，signature库大，每家的效果都不能做到最好，最后就靠市场和营销来获得用户，这样的发展趋势不太妙啊。

20. Panabit 于 2010-07-06 7:24 上午

    droplet老兄，如果运营商这么干的话，首先他们的网管就会睡不着觉，呵呵。其它的问题就更不用说了。互联网是一个开放的系统，任何企业都不能这样做，也做不到。就一个简单的例子，游戏每天层出不穷，而游戏是互联网上最要保证其质量的应用，如果你对不能识别的游戏给予低优先级，那么肯定是不可用的。

21. Multithreaded 于 2010-07-06 9:42 上午

    一直有两派之争：

    1。 用程序描叙， 类似recursive descendant parser, 自顶向下的搜索。
    2。 用DFA/NFA描叙，再用一个小的解释器作归纳。

    具体用哪个，取决于具体情况。

22. Apple 于 2010-07-07 4:56 上午

    关于协议识别用到的算法我来谈谈个人观点,仅供参考,
    为什么说用正则算法来做协议识别有些大材小用呢,这需要先看看基于特征库识别的特征串的特点是什么,首先业界支持的DPI设备是别的协议种类已经快到1000种了,好的到800了,差的600种了,而这些协议大多用特征码识别,而特征码大多用简单的字符串加上偏移就可以了,少部分必须用通配符,通配符的支持方法通用的是采用PCRE或者POSIX标注,具体的实现可以基于NFA也可以基于DFA,但是DFA对于通配符的膨胀,以及NFA空间不敏感,但性能要比DFA差,所以综合来说如果用正则又想照顾到性能,那么就需要结合NFA和DFA的长处了,结果就是各个不同厂家宣称的XXFA,名称各异.

    所以对于没有统配符的大多特征码,使用多模算法改造一下来支持偏移量,性能上是很可观的,当然你也可以考虑改造DFA支持偏移来支持,但是我确实没有看到有人这样做.

    当然正则算法也是很有用武之地的,在病毒库或者IDS/IDP的攻击库中都有较多的通配符,用正则算法正好,所以很多防病毒的设备或者IDS设别会集成一些正则的硬件引擎, 但是大家需要了解的是,从单台设别上来看,目前协议识别的流量规模往往大于防病毒设备,因为在一些核心的设备上目前也有很多部署的了协议识别的功能,但是防病毒设备还是主要集中在企业网环境, 所以目前对一些设备来说,协议识别的性能是一个必须考虑的因素,一个核心设备按照50G的流量,如果需要全流量识别,那么需要上送到识别模块的流量就在5G规模,按照1K种协议,每个协议按照3个特征子串,哪吗就需要匹配3K和特征串,这对性能的影响还是很大的,所以这一部分也需要用硬件加速,但是业界比较通用的硬件加速方案目前好像都不好使. 但是用ASIC的倒是不少.

    上面只是个人的一些粗浅认识,仅供参考.

23. Apple 于 2010-07-07 5:10 上午

    另外对DPI中的协议解析来说,
    协议解析用XML是业界的一个通用方式,实现也很有很多方法,但是协议解析的流量往往要超过识别的流量,所以性能更是以一个关键因素,所以个人认为未来对于DPI设备来说,协议解析的灵活性和性能是一个关键的技术能力.

24. multithreaded 于 2010-07-07 4:02 下午

    我好像知道你要说的了。终结一下，网络协议可以用

    1。 字符串 + 偏移量 来描述
    2。 用正规表达式来描述

    方法 1）在性能上有优势但维护起来有负担； 方法 2）便于描叙但在使用上用一定的问题需要解决。

    考虑到一条正规表达式可以取代10条字符串， 我比较看好方法2。 对于小公司来说， 我可没有HW式的人海战术，维护上千条规则成本太高。

    再有一条，正规表达式的写法很有讲究，写不好是容易造成空间爆炸的。 需要Panabit讲的，数据包看多了，就有感觉了。

25. multithreaded 于 2010-07-07 4:07 下午

    还没有听说“协议解析用XML”的。 应该使用Panabit的程序方法来解析。

    还有人试过 LEX+YACC

26. droplet 于 2010-07-07 6:28 下午

    所谓的协议解析是指协议状态机还是简单地匹配一些字符串？如果是协议状态机，这个状态机开发难度有多大？
    在分析的时候，有一个误判和漏判的问题。在这种情况下，缺省规则就很重要。比如QoS，误判或者漏判的流，放到哪个队列里面？缺省是低优先级，还是高优先级。不管高和低，都会是不公平的。

27. Apple 于 2010-07-08 5:49 上午

    multithreaded 谈到一些非技术问题,我没有能力回答你

28. Multithreaded 于 2010-07-08 10:18 上午

    涉计到了三个问题。

    1。 协议识别, 位移量+匹配一些字符串
    2。 协议解析，用程序分析到每个域，像HTTP parser or HTML parser or XML parser.
    3。 识别后如何做QoS

    以上想做到10Gbps还是很难的，是目前研究的重点问题。

29. Panabit 于 2010-07-08 4:31 下午

    协议识别做到10Gbps不是一件难事，用X86很容易做到。

30. Multithreaded 于 2010-07-09 6:55 上午

    如有可能， 能否介绍一下如何用X86解决的。

    是用多核X86? 如何把包分到多核上去？在做协议识别之前， 还要处理TCP/IP …

31. 陈怀临 于 2010-07-09 7:12 上午

    多线程，你最大的问题是没有忘记TCP/IP。。。换个念头：为什么需要TCP/IP stack？：-）

32. droplet 于 2010-07-09 7:32 上午

    对这个问题又有了一些新的思考。
    目前DPI技术主要是在网关上应用，网关需要通过分析数据流来确定这个流是哪个应用。这个过程就是一个分类，描述，然后识别的过程。比如人最初定义为“全身没毛，双腿直立”，后来有人用脱了毛的鸡来举反例来推翻这个定义。对协议的识别也是这样一个过程，总是在逐渐接近于准确的定义，但总有发展的空间。相对而言，人这个实体的变化少一点，而协议变化就多一点。
    网关识别应用有困难，但总有人知道应用是什么。客户端和服务器都知道。比如服务器如何知道连接它的客户端用的是什么协议？这里面就有一个协商的过程。比如识别HTTP协议，用”HTTP x.x GET xxx”这样简单的匹配能否就认定这个流是http协议哪？至少从协议定义上，需要区分出来。这个特征，在协议定义时就需要和其他协议区分开，否则服务器就不能区分出是什么协议，可能导致混乱。
    在端上，能够区分出什么协议是合法的，什么是非法的，应该为哪些请求服务。所以DPI技术应该借鉴端的协议实现，这样才能避免出错。

33. multithreaded 于 2010-07-09 1:03 下午

    为什么需要TCP/IP stack?

    Because one has to handle:

    1) IP Fragmentation
    2) TCP out of order

34. multithreaded 于 2010-07-09 1:06 下午

    droplet 没有想到有人在捣乱。 比如P2P协议的头一行和HTTP一样。

35. zhoul 于 2010-07-12 7:46 上午

    DPI，就是应用层的ACL，特征码也是通过人工获取，在流控上，使用比较广泛。

    DFI，刚才说的行为匹配，就是说每一种应用都用它的行为模型，可以通过一些函数表示，比较非常，主要用于一些加密的业务识别，用的不是很广泛

36. dicom1998 于 2010-07-31 5:14 下午

    DPI 到目前为止主要的应用似乎就是 Security 和 Server Load Balancing (HTTP cookie, SSL offloading). 这两个市场不大. QoS 的应用的市场更小.

    Internet protocol design 是 end-to-end principle. 当初没有考虑到中间截一刀, 做DPI. 我看到的code都有点ugly.

37. 理客 于 2010-08-01 7:29 下午

    IP设计本初确实如此，所以承载网络应该是没有带宽瓶颈问题的。但现实网络因各种因素影响，就不是都没有带宽瓶颈了，所有有网络扩容。实际上DPI的应用范围能有多大，决定于运营商和ICP有多少情况下需要知道网络内容分类？

38. Behemoth 于 2010-08-13 7:08 上午

    从目前实际应用看，协议识别率并不十分理想，Http的还可以，BT的就不行了，想做到真正的QoS控制很困难。做DPI的兄弟们，哪位能对发展方向做一下展望啊？
    转去做硬件识别提高速度？还是以牺牲传输效率达到更高识别率？还是干脆放弃QoS，只是去给ISP提供一个用户行为分析？

39. HJ 于 2010-08-13 2:00 下午

    现在有哪个厂家能够完美地识别skype吗？

40. zxtx 于 2010-08-13 7:35 下午

    to理客

    你有所不知，现在网络厂商拼的就是精细化，即DPI+PCC+用户行为，其他就是大容量，大吞吐，低功耗。

    精细化的动力来源就是运营商不想只做管道工。大家都玩P2P,玩Skype，不做精细化控制，运营商就只能喝汤了。

41. 理客 于 2010-08-13 8:08 下午

    关键是运营商感知了深层业务后，能提供哪些吸引它的客户的业务？目前看，这个问题的feasible的答案并不是很多？只有找到这些市场价值点，扩大DPI技术部署才有商用意义。这个问题，是carrier除了提供海量通用服务外，另外一个需要研究和实践的关键点，当然，vendor也有和carrier在这个领域合作的空间。DPI在移动中应用的价值，一个是carrier希望了解移动internet的业务分布，一个是控制不同类别业务的质量，控制质量的主要原因还是移动的无线接入部分容量限制导致。在固网部分，还缺乏明显的驱动力，在某些国家和地区，P2P是一个driver

42. Apple 于 2010-08-13 10:54 下午

    现在的网关很多都沦为了service edge,
    这也相应了cisco的那杆大旗:service enable
    那个路由器不支持ACL, 那个路由器不支持FW,那个网关不支持路由,那个网关不支持FW, 那个网关不能识别协议,那个路由器不能做ASPF, 众多的设备都在互相渗透,很多网关都开始支持越来越多的应用.当然这些业务不是都得到了很广泛的应用, 但是我们必须看到的是,不管从技术上和运营上,很多新的应用都是有亮点的, Qos这个东西就不谈了,
    如基本的URL 过滤,不同的客户需求就延伸出各种花样: 基于黑白名单的过滤(如国家层次,政治原因/防止网络钓鱼,..) 基于URL的类别过滤(如对小孩的保护,对非法站点/道德不允许的站点的封堵/对工作不相关内容的站点的禁止) , 又如P2P的防护,以前强调在Qos的控制,现在有很多的尝试,P4P, 本地分发网络,都有很多尝试. 再往上,现在那个运营商不希望自己有一个看穿一切的眼睛,于是网络可视的各种形态,涌现了,也得到了广泛的应用. 再网上, 可视的数据是一个宝库,这和google的强大有些相似之处, 职能广告, 职能的分发网络,甚至经营决策,在这个内容为网的世界,你有了数据你也就就可以印钞票了,哈哈

43. Apple 于 2010-08-13 10:56 下午

    这年头,你说你不知道什么是DPI,你都不好意思说你是做通讯的,哈哈!

44. Test 于 2010-08-13 11:01 下午

    to HJ
    对于Skype, 只要识别率到了90%,只要加一定的控制,你用起来就知道有多难用了

45. multithreaded 于 2010-08-18 3:15 下午

    知道是一回是，做是另一回事。 DPI用不起来， 一个重要的原因是速度上不去。

    简单来说，企业的服务器都用10G NIC了， DPI能做到10G的线速吗？ DPI的用途应该是很广的，现在好像有点有劲是不上的的感觉。

    FPGA在一定程度上可以缓解一下实现的问题， 但最终还是要开发基于多核的DPI解决方案。

46. starshift 于 2010-09-06 12:47 上午

    空谈误国

47. blade 于 2010-09-07 8:03 下午

    以前做过一些蠕虫检测，所谓的signature generation。

    感觉idea比较成熟，但在大规模环境下(运营商)效果怎样还不确定。效率是另外一个重要问题

48. 陈怀临 于 2010-09-18 8:36 下午

    请教一个问题： 目前在SMB或者说SOHO领域，网络安全系统的卖点，热点和难点是什么？江湖分账的布局是什么？

    思科？Juniper? Hillstone？ PAN？ NetGear？ WatchGuard？Sonicwall？

    市场有多大？

49. Eric 于 2010-09-19 5:19 上午

    目前所说的DPI泛指SPI,DPI,DFI,DPC
    SPI:L3/L4的识别,差不多就是路由器上ACL
    DPI:基于Packet特征码的识别
    DFI:对于一些加密的数据包,无法单纯通过packet特征码识别,要辅以流的行为,如Skype的的流行为是packet大小比较匀
    DPC:深度报文抓取,dpacket/wiki上都有注解,个人感觉包装的成份比较大

50. Eric 于 2010-09-19 5:48 上午

    DPI的应用最早应该是在上世纪末的第五代Firewall上,只不过很少冠以DPI的名字

    当前在SMB/固定/移动运营商用DPI兴起于2001年之后,主要驱动力来自于P2P分享软件的流行引起internet流量激增,当时运营商网络还是ATM网络,成本高,带宽小.有兴趣的可以网上查一下,DPI厂商在99年开始零星几家出现,大部分成立于2001年之后,基本和P2p软件发展差不多,napster在99年发布,01年因版权关闭,但其精神不朽,P2P软件开始流行

51. Eric 于 2010-09-19 6:39 上午

    DPI在SME/固定/移动运营商的应用已炒作过两轮,第一轮是借助P2P在固网的发展来炒作的,大致原因在上面也简要提了一下,差不多在05/06年达

    到顶峰,第二轮是07起欧美移动数据业务的大发展,本质上还是因为带宽的限制

    典型的厂商如P-Cube,Sandvine,Allot, Procera, Arbor,
    P-Cube是一家以色列公司,04年被Cisco收购,当时主要有SCE1000/2000系列,1U的小盒子,只有几G的处理能力,串接在BRAS之后,在国内最大的一

    单在铁通,上100台,后来其它的运营商中好像没听说买过,08年推动框式的SCE8000,去年Cisco把DPI的人力裁了80%

    Sandvine加拿大一家300多人公司,属于厚积薄发型的,2001年成立,一直到06年才比较突出,主要原因是最早推出10GE端口产品,且容量较大,市场

    主要在北美的MSO市场,目前基本一半的收入来自于北美,当前单设备最大处理能力是60G,集群最大240G

    Allot, Procera比较像,很长一段时间内产品应该是定位在SME,产品端口都是低速接口,Procera去年的收入一半来自于校园网之类的SME

    Arbor主要侧重于IDS,还成立了指纹共享联盟,后来收购了ellacoya,也在做运营商运营商市场

    主要应用分4类网络可视化,带宽管理,安全,增值业务

    再来说说国内的,国内的厂商比较慢热,差不多是在04/05年之后成立,如南京信风/宽广电信/QQSG/金御/绿网/兆维晓通/阳光金网.DPI对网络的管控涉及到网络中立的问题,且固定宽带慢慢采用包月制.04年左右关于中立的共识是不能做限制(不过还是会偷偷限的),但国内VoIP是非法的,可以限,所以国内厂商最初的应用是网络可视,VOIP限制,共享接入检测

52. Panabit 于 2010-09-19 6:46 上午

    楼上了解不少，以前很多厂家将眼睛盯在运营商，其实现在只要有网络的地方，就需要不同形式的DPI。目前国内DPI用得最热的领域就是通过DPI识别应用，对网络流量进行合理管控（简称流控），这两年这个窄众领域发展也比较快。

53. Eric 于 2010-09-19 6:57 上午

    SME应用主要是
    可视,看专线中流量构成
    带宽管控,主要是一些应用的阻断,如P2p/IM限制
    URL过滤,过滤工作无关网站之类的

    DPI用于网络管控的市场目前差不多在0.8B USD,固定/移动运营商占大头,SME应该不是很大

54. 陈怀临 于 2010-09-19 8:30 上午

    NetGear（在国内叫网本），好像研发主力在南京。他们的产品如何？

55. 加菲猫 于 2010-12-28 12:40 上午

    因工作需要, 研究过很多DPI方法, 这里强调是方法~! 而非算法!

    个人感觉, 此领域, Panabit比较有发言权.
    楼上的多线程兄和apple, 基本上都是在YY.

    多模式匹配除了NFA/DFA一类基于状态机的算法, 之外还有MW(Wu-manber)算法之类, 基于预处理索引的字符串匹配算法~. 总之关键方向不再算法上~.

56. F22 于 2010-12-29 12:51 上午

    用DFA或者文法分析的方式需要解决维护成本的问题，这个的确不小，但是不是没有折中方案，比如自己构建一套稳定的特征描述语言和编译器，当然了这个不是一般人能有的实力，前期投入也很大。后期影响不可估计，写的好了维护成本和性能能达到很好的平衡，写不好，不如不写。

    正则表达式这个不错，但是协议的扩展能力很容易就达到瓶颈，性能也难以优化。但是也不是没有可能下出金蛋，当然方法也不是一般的，那就是放到硬件里面去。06年开始用FPGA实现KMP算法的论文就非常多了，用硬件实现多模匹配也不是什么难事。但是硬件不能解决全部问题，因为毕竟资源有限，最终比较平衡的版本可能是硬件+软件。即硬件匹配出一定特征，而软件在进行进一步的分析。当然这个成本也不是一般的高，不过如果玩的好，那性价比可够x86喝一壶的了。

57. sullybear 于 2010-12-29 9:29 下午

    单纯采用特征码只会陷入被动，因为端对端连接存在状态机制。因此，特征码只能对有限的应用连接进行识别，除了这些应用连接。对于大量的混杂的无序数据包没有处理办法。
    DFI目前来讲，可能更大程度上只是一个概念，是否有合适的算法模型还不一定。更何况流特征的获取不比特征码，更加消耗人力。如果采用DFI这种机制来应付目前互联网层出不穷的应用，是一种不可取的方式。
    真正有效的方法在于加大数据包识别的状态机制，减轻内核对于数据包识别的性能压力。如有效利用连接跟踪的方式，以及利用时间差内的四元组匹配机制。如skype，特征码无法识别skype的全部数据包，但是skype的数据包特征非常明显，因此提出合适的算法来匹配skype的udp包特征以及skpe的udp、tcp端口变化特征，还有skype的源、目的ip特征，根据算法模型来综合以上信息，以确定数据包是否属于skype。
    从性能上来讲，也有很积极的意义，毕竟内核不再需要分别对每个数据包都进行解包处理。

58. 天外有天 于 2010-12-29 11:21 下午

    dpi这东西扯起来没完，
    这两年通讯界的大热门嘛。。

    ips也算dpi的一种，
    虽然目前的ips检测都没那么深，
    能定义一套语言规则来描述ips,是比较好的，
    对识别率和速度都有提高，
    赛门铁克就这么干的。
    snort也有一套规则，它那个比较简单。

    正则表达式是dpi的核心数据了。
    目前规划的dpi芯片（netlogic,tarari）动不动就是上M的规则，上G的吞吐。

    协议识别目前已经很可靠了。很多地方电信都用了，也不是研究的重点，10G甚至更高的吞吐也不是问题。估计很多兄弟对当前的情况并不太了解。

    目前dpi主要做业务识别，卡卡bt的流量什么的。
    不过运营商已经开始试点业务运营，根据dpi的识别结果，推送业务什么的。

59. 天外有天 于 2010-12-29 11:27 下午

    dpi技术问题有，不过主要是法律问题。

    bt利用dpi搞过业务运营，
    后来被控告了。所以运营商现在都束手束脚，
    畏畏缩缩的
    不过这种情况下，也有很多地方试点。。

60. jiaruifu 于 2010-12-30 12:36 上午

    我就在研究ips产品做dpi的可行性。Apple兄、天外有天兄对dpi市场商业模式和定位有很多思考啊，同感。

61. jiaruifu 于 2010-12-30 12:42 上午

    首席前辈是否考虑给发帖者建个用户名，加强用户管理，发个邮箱最好，联系起来也方便啊。不知条件是否已经成熟。

62. sniper 于 2011-04-18 6:40 下午

    好像netlogic的NETL7可以做到perl的那一套正则匹配，并且查找的带宽上了20G，长远来看对于ISP等来说这玩意儿太重要了，吼钱利器。。

63. metal1011 于 2011-06-06 3:00 上午

    mark

64. zhuyihua 于 2012-07-26 2:14 上午

    请教各位大牛：
    简单对比了一下openDPI(nDPI)以及L7-filter， openDPI里面的模式匹配还是基于C代码，每个协议都要写一个识别函数，然后注册要识别引擎里。
    L7-filter是用正则表达式描述协议特征，这种易扩展，可以快速地增加协议，但是效率较openDPI满一点。

    但这两个都是一次比较注册的协议，无法做到同一份数据比较一边就能识别出协议(多模式匹配？)。请教各位大牛这种多模式的匹配如何实现呢？

    谢谢。

65. multithreaded 于 2012-07-27 7:29 下午

    把L7-filter的所有模式放在一起，不就行了吗？

    不过你要解决合并后指数爆炸的问题。

66. zhuyihua 于 2012-07-29 9:48 下午

    谢谢多兄的回复
    正如您所说模式合并1是指数爆炸的问题,2是匹配成功后我不容易知道到底是哪个协议匹配的阿

67. multithread 于 2012-08-04 12:11 下午

    如果你是学生，可以招你作Intern来学一下。 如果在公司任职，就得付咨询费了！

68. alrn 于 2012-09-04 1:10 上午

    请问，哪位朋友有DPI产业方面的信息，
    想交流一下alrn@163.com，多谢！