深度数据包检测(DPI)
深度数据包检测(Deep packet inspection，缩写为 DPI)是一种特殊的网络技术，一般网络设备只会查看以太网头部、IP头部而不会分析TCP/UDP里面的内容这种被称为浅数据包检测;与之对应的DPI会检查TCP/UDP里面的内容，所以称为深度数据包检测。
DPI一般是一个硬件或者软件，一般用“旁挂”的方式接入到网络。它会对网络中的每个数据包进行检查，识别出应用层协议，根据识别的协议采取一定的措施(比如记录HTTP访问行为)。对于TCP协议它可以识别完整的TCP交互过程(比如HTTP请求从请求到响应中间会有多次TCP数据包发送)。
nDPI
nDPI是一个C语言编写的DPI库，用来实现软件DPI系统。它是从OpenDPI扩展而来，二者的架构和实现基本上差不多。https://github.com/ntop/nDPI此处是它的老巢，大家可以自己下载编译它。怎么编译，它的README写的非常清楚了我就不废话了(唯一一个文档~~囧)。
编译安装之后它生成/usr/local/lib/libndpi.(a，so)库文件(a静态库文件，so动态链接库);/usr/local/include/会安装相关的头文件。
我个人喜欢用 静态库文件，这样会把所有的二进制代码合并到一个可执行文件中运行的时候不需要安装一大堆库。另外我也不喜欢把东西放到/usr/local/lib下，所以我提供的代码是通过cmake做了一个“all in one”的编译。github上放到是1.6版本的，如果你想更新代码只要替换src文件夹就行了。
如何用nDPI
nDPI的代码写的很烂，也没有什么架构就是一团乱麻(其实稍微写写都要比这个好)。但是它至少还能正常工作而且是唯一一个“开放”的DPI库，所以无论什么原因你选择了它都必须忍受它的“丑陋”。
nDPI几乎没有文档说明，只带了一个“ndpiReader”的例子，写的“洋洋洒洒”如行云流水一般(就不吐槽了)。这就是我这篇文章的写作原因，希望能给使用nDPI的同学一点帮助。
初始化
nDPI最重要的一个数据结构是ndpi_detection_module_struct_t它通过ndpi_init_detection_module构造出来
***个参数用来计算nDPI分析协议的各种超时时间，一般精确到毫秒就可以了1000(nDPI协议分析部分和“全局部分”耦合非常紧，这个数据其实只有“协议分析模块”需要)
第二个、三个参数是封装过的“内存分配”函数;nDPI的内存管理非常乱，有些地方是我们自己申请内存而由nDPI内部帮我们释放。所以必须nDPI并不直接使用malloc、free之类的申请、释放内存而是交由程序员自己提供函数;
第三个参数是调试函数，如果定义了NDPI_ENABLE_DEBUG_MESSAGES那么nDPI会调用这个函数输出一些调试信息;
所有的nDPI API都是这种“鬼畜”风格，几乎是各种纠结。。。万幸我们只需要使用很少的API就可以完成任务了。
配置协议分析模块
nDPI支持多种协议，都在protocols文件夹中。编译的时候所有协议都会被放到nDPI库中。使用的时候我们可以自己设置需要开启那些分析模块
NDPI_PROTOCOL_BITMASK定义开启协议的“位图”，通过NDPI_BITMASK_ADD函数可以添加支持的协议，***调用ndpi_set_protocol_detection_bitmask2配置位图。
ndpi_set_protocol_detection_bitmask2函数的***个参数就是ndpi_detection_module_struct_t(上面我们初始化的那个数据结构);第二个参数是位图标志。
特别注意：开启的协议越多识别速度越慢;nDPI识别协议的时候是一个串行结构，无论是否被成功是被都会认认真真遍历完我们配置好的协议
子协议
子协议是某个协议的细分，比如我们想要分析所有“Google”的HTTP请求那么***步是分析出“HTTP”请求，第二步是判断HOST包含google.com。这里的第二步就是“子协议”。
nDPI唯一的一份“QuickStartGuide”对这个有进一步解释，子协议识别是以配置文件的方式提供给nDPI的。比如
它还支持端口的方式(TCP的81、8181直接被标记为HTTP不再做内容检测)
nDPI此处的实现使用了一个非常有名的算法—— Aho-Corasick。以***幅图为例子，里面配置了两条规则“Google”和“Veneer”，我们有一个字符串(HOST)，怎么判断这个字符串符合那个规则呢?最简单的办法是循环所有的规则，如果规则条目很多那么速度会非常慢。Aho-Corasick就是这样一种算法，它可以在O(n)中完成所有的匹配任务。
通过ndpi_load_protocols_file函数加载“子协议”。
开始识别
识别协议的API非常简单——ndpi_detection_process_packet函数。就是这个坑爹的函数，变态程度几乎可以说用令人发指来形容。
- ndpi_struct全局的结构体
- flow比较特殊，我们后面讲
- packet指向IP头部的指针
- packetlen数据包大小
- current_tick_l当前时间(精确到毫秒)用于判断“过期的TCP请求”
- src，dst其实没有什么用途，文档上说是跟状态机有关其实没有半毛钱关系。唯一的用途是更新“分析协议”的配置。一般设置为NULL就行了
TCP协议是一个流(flow)式的协议，经过从三次握手开始通讯双方都是“请求->响应”的结构。DPI可以跟踪其中的一个或者几个数据包，也可以实现全部跟踪(后续我会交叉使用TCP会话、会话、flow，三个名词其实是一样的)。
nDPI内部不会记录完整的TCP数据包，而是用一个定义非常模糊的ndpi_flow_struct类型来表示一个TCP会话(这个数据结构还包含了“协议分析”部分数据，所以定义非常模糊)。为了便于分析完整的TCP请求我们定义了一个自己的数据结构dpi_flow_t，ndpi_flow_struct作为它的一个成员。用伪代码表示分析过程：
落到代码上就是get_ndpi_flow函数;实现上我们会对目标、源端口排序再做hash;这是由于数据包是“相互通讯”的所以发送方、接收方是相对而言，否则识别到的可能是“一方”的数据。
一般我们用一个二叉树存放所有正在分析的TCP会话，nDPI移植了FreeBSD中的一组函数ndpi_tfind、ndpi_tsearch、ndpi_twalk、ndpi_tdelete等用来实现常用的数据结构操作。
完成分析
调用完ndpi_detection_process_packet函数后我们需要检查返回值，如果它不等于NDPI_PROTOCOL_UNKNOWN证明就找到了协议类型。
DPI分析一般分为三种情况：
- ***个数据包就能确定协议类型，这种情况下找到“协议类型”后续直接把flow从二叉树中删除
- 第N个数据包确定协议，flow数据包会一直存在在二叉树中，直到知道协议类型。这种情况下每次我们调用ndpi_detection_process_packet传递的flow其实是相同的数据
- 一直无法确定协议类型，flow经历过一段时间之后超时，我们认为无法识别出协议释放相关数据。
前两种情况可以合二为一，都是判断出协议类型后释放资源;第三种请比较特殊，我们需要遍历整个二叉树寻找“过期”的flow然后删除。这就是例子中***一部分的含义(遍历的时候我们每次寻找一个flow，用变量idle_scan_idx表示)。
