nDPI
nDPI
目录
调研、比较DPI库
DPI、OpenDPI、nDPI
先来看一下与nDPI相关 的一些概念
DPI
DPI是Deep Packet Inspection的缩写，全称深度包检测，是对数据包负载进行实时分析的一类技术的总称，它的其中一种应用是对流量进行分类。
端口与协议的问题：
- 在互联网发展的早期，每一种协议或者应用都和一个端口关联。比如当我们说80端口时，我们指的就是HTTP协议。
- 但是，端口和协议的关联并不是强制性的，而只是大家约定的共识。
- 后来，许多新出现的协议都没有再和一个固定的端口关联，有的协议为了绕过防火墙的管控，会直接使用HTTP协议来传输。
对于网络的监控和管理来说，识别当前流量中有哪些应用和协议，从而采取进一步动作 —— 记录日志或者阻断连接 —— 就变成了一件非常困难的事情。
为了识别流量的类型，DPI技术应运而生，它有三种基本的实现思路：
基于特征的
这种方式主要是使用模式匹配来匹配协议中的关键字。比如，通过GET/POST关键字来匹配HTTP协议。
基于语义的
这种方式主要是通过尝试不同的协议规范来解码数据包，从而确定它是哪一种协议。其中又可以分为不同层级，因为有些协议是借助其它协议来传输的。比如，许多P2P协议通常会使用HTTP协议。
基于统计的
这种方式主要是针对加密数据，因为它能被观测到的信息只有数据包数、大小以及建立加密连接时的过程和参数。
基于特征的实现不能很好地应对协议中有编码的情况，从而造成漏报。基于统计的则有很高的误报率。所以，nDPI采用的是基于语义的实现方式。
OpenDPI
因为nDPI是在OpenDPI的基础上开发的，所以有必要先介绍一下OpenDPI。
OpenDPI是少有的几个开源DPI库之一，使用的是C语言，现在已经没有人维护。它由两个部分组成：
核心部分。负责处理数据包，解析IP层、tcp/udp层，然后提取出IP地址、端口等基本信息。
插件部分。每个插件就是一个解码器，负责解析对应的协议。
nDPI
nDPi是在OpenDPI代码的基础上修改的，它做出了两个比较大的改动：
通过端口来猜测真实的协议。这个设计基于一个前提，就是假设大部分协议仍然是和端口有关系的。
当使用和端口关联的协议解码器解码失败时，才会像OpenDPI那样尝试所有其它的解码器，直到解码成功。可以通过配置文件声明端口和协议以及关键字和协议之间的关系。解码时优先使用端口或者关键字对应的解码器。
nDPI的协议识别流程如下：
nDPI解码数据包的3层、4层部分。
如果有注册了和数据包协议、端口相对应的解码器，首先尝试使用这个解码器。
如果没有匹配，会尝试使用已经注册的和数据包协议（比如UDP）相关的所有解码器。当其中任何一个解码器失败时，有两种情况，要么是真的失败了，要么是还需要更多的数据包。当数据包到来时，后一种情况会继续尝试解码。
只有有任何一个解码器匹配了，协议识别就会结束。
通常来说，nDPI只要分析了前8个数据包，就能够识别出协议类型。
其他调研结果
开源DPI库非常少，Github上的结果就那么几个：（Star统计截止到23.07.31）反正几乎就只有nDPI是能用的
- 有效仓库
- ValidikSS/GoodbyeDPI， 9k， DPI实用工具（用于Windows），该软件旨在绕过许多互联网服务提供商的深度数据包检查系统，这些系统会阻止对某些网站的访问。
- ntop/nDPI， 3.3k， 开源DPI软件工具包
- bol-van/zapret，2.2k， 独立（无第三方服务器）DPI 规避工具。可能允许绕过 http(s) 网站阻止或速度整形，抵抗签名 tcp/udp 协议发现。该项目主要针对俄罗斯观众，对抗名为“Roskomnadzor”的俄罗斯监管机构。该项目的一些功能是针对俄罗斯现实的（例如获取 Roskomnadzor 屏蔽的网站列表），但大多数其他功能都是常见的。
- thomasbhatia/OpenDPI， 150， OpenDPI v.3.10（目前已停止维护）
- 无效仓库，注意有很多名字有
DPI但实际上是Dots Per Inch或其他缩写而不是Deep Packet Inspection的项目，这里列几个：- LeaVerou/dpi， 746， 这个是屏幕DPI
- strues/retinajs， 4.5k， JavaScript、SCSS、Sass、Less和Stylus助手，用于呈现高分辨率图像变体
- mgth/LittleBigMouse， 2.3k， DPI感知鼠标在屏幕上移动
- cszn/DPIR， 499， 即插即用深度去噪先验图像恢复(IEEE TPAMI 2021) (PyTorch)
- syscl/Enable-HiDPI-OSX