NamanKejriwal/DPI-Engine
GitHub: NamanKejriwal/DPI-Engine
DPI 引擎是一款基于 Java 的深度数据包检测系统，用于网络流量分析和应用识别。
Stars: 0 | Forks: 0
# DPI 引擎
**高性能多线程深度数据包检测引擎**
[](#)
[](#)
[](#)
[](#)
一个基于 Java 21 开发的并发深度数据包检测 (DPI) 系统，用于离线网络流量分析、应用识别、自定义流量过滤、连接跟踪、分析导出和确定性的流生命周期管理。
## 目录
- [概述](#overview)
- [项目度量](#project-metrics)
- [为什么存在这个项目](#why-this-project-exists)
- [关键特性](#key-features)
- [系统架构](#system-architecture)
- [数据包处理管道](#packet-processing-pipeline)
- [应用分类管道](#application-classification-pipeline)
- [规则引擎架构](#rule-engine-architecture)
- [分析导出架构](#analytics-export-architecture)
- [流生命周期管理（v1.3）](#flow-lifecycle-management-v13)
- [并发模型](#concurrency-model)
- [项目结构](#project-structure)
- [支持的协议](#supported-protocols)
- [支持的应用](#supported-applications)
- [生成的报告](#generated-reports)
- [安装](#installation)
- [构建说明](#build-instructions)
- [使用方法](#usage)
- [示例终端输出](#example-terminal-output)
- [示例报告](#example-reports)
- [验证结果](#validation-results)
- [性能特征](#performance-characteristics)
- [设计决策](#design-decisions)
- [解决的技术挑战](#technical-challenges-solved)
- [发布摘要](#release-summary)
- [发布历史](#release-history)
- [路线图](#roadmap)
- [关键技术概念](#key-technical-concepts)
- [学习成果](#learning-outcomes)
- [许可证](#license)
## 概述
DPI 引擎是一个批处理网络流量分析工具，用于处理 `.pcap` 文件，重建有状态流，按应用分类流量，并生成有关网络行为的深度分析。
该引擎围绕多线程生产者-消费者管道设计，通过可配置的流生命周期管理和确定性的流淘汰提供有界连接状态内存。
## 项目度量
| 度量 | 值 |
|----------|----------|
| Java 版本 | 21 |
| 源文件 | 28 |
| 实现的发布 | 4 |
| 支持的应用 | 16 |
| 报告类型 | 9 |
| 规则类型 | 4 |
| 处理模型 | 多线程 |
## 为什么存在这个项目
传统的无状态数据包过滤器和企业级防火墙仅根据 IP 头和传输端口做出决策，提供了对网络使用的完整视图。DPI 引擎实现了第 7 层有效载荷分析，以确定确切的应用来源（例如，区分同一 IP 范围内的 YouTube 流量和 Google 搜索流量）。
该项目作为一个全面的系统，展示了协议解析、并发数据结构、有状态网络语义和内存安全的批处理范例。
## 关键特性
**核心分析**
- PCAP 输入和输出生成
- 以太网、IPv4、TCP 和 UDP 协议的原始字节解析
- 有状态五元组连接跟踪
**深度数据包检测**
- 被动 DNS 查询拦截和解析
- HTTP 主机头提取
- TLS 服务器名称指示 (SNI) 提取
**自定义过滤**
- 动态规则引擎配置
- L3-L7 阻止能力（IP、端口、域名、应用）
**可观察性**
- 高保真 CSV 和 JSON 报告
- 在流淘汰周期中完美保留分析
- 基于终端的系统可观察性
## 系统架构
```
graph TD
A[PCAP Reader] -->|Raw Bytes| B(Load Balancers)
B -->|Thread Affinity Hash| C1(Fast Path Worker 1)
B -->|Thread Affinity Hash| C2(Fast Path Worker 2)
B -->|Thread Affinity Hash| C3(Fast Path Worker N)
subgraph Fast Path Processing
C1 --> D1[Connection Tracking]
C1 --> E1[Rule Engine Evaluation]
end
E1 -->|Forwarded Packets| F(PCAP Writer)
D1 -->|Flow Statistics| G(Analytics Manager)
G -->|JSON/CSV Export| H[(Reports Directory)]
```
## 数据包处理管道
```
flowchart TD
Raw[Raw Packet Byte Array] --> Eth[Ethernet Parser]
Eth --> IPv4{Is IPv4?}
IPv4 -- Yes --> IP[Parse IPs & Protocols]
IP --> Trans{Protocol Type}
Trans -- TCP --> TCPParser[Parse Ports & Flags]
Trans -- UDP --> UDPParser[Parse Ports]
TCPParser --> Payload{Has Payload?}
UDPParser --> Payload
Payload -- Yes --> Extract[Extract L7 Metadata]
Extract --> TLS[TLS SNI]
Extract --> HTTP[HTTP Host]
Extract --> DNS[DNS Query]
TLS --> AppIdent[Application Identification]
HTTP --> AppIdent
DNS --> AppIdent
AppIdent --> Rule[Rule Engine]
Rule --> Forward{Action}
Forward -- DROP --> DropSink([Drop])
Forward -- FORWARD --> Writer([Output PCAP])
```
## 应用分类管道
```
flowchart TD
TCP_UDP[TCP/UDP Payload] --> PortCheck{Check Ports}
PortCheck -- Port 53 --> DNS[DNS Extractor]
PortCheck -- Port 80 --> HTTP[HTTP Host Extractor]
PortCheck -- Port 443 --> SNI[TLS SNI Extractor]
DNS --> AppDNS[AppType: DNS]
HTTP --> AppHTTP[AppType: HTTP]
SNI --> ClassifySNI{SNI String Matching}
ClassifySNI -- *.google.com --> Google[AppType: GOOGLE]
ClassifySNI -- *.facebook.com --> Facebook[AppType: FACEBOOK]
ClassifySNI -- *.youtube.com --> YouTube[AppType: YOUTUBE]
ClassifySNI -- Unrecognized --> HTTPS[AppType: HTTPS]
```
## 规则引擎架构
```
flowchart LR
RulesFile[(rules.txt)] --> Loader[RuleManager Parser]
Loader --> Map1[Domain Set]
Loader --> Map2[IP Set]
Loader --> Map3[App Set]
Loader --> Map4[Port Set]
subgraph Evaluation
Incoming[Analyzed Flow] --> Matcher{Match Found?}
Map1 --> Matcher
Map2 --> Matcher
Map3 --> Matcher
Map4 --> Matcher
end
Matcher -- Yes --> Block[Drop & Log]
Matcher -- No --> Forward[Allow]
```
## 分析导出架构
```
graph TD
subgraph Trackers [Thread-Local Connection Trackers]
T1[Tracker 1]
T2[Tracker 2]
end
subgraph AnalyticsCollector [Analytics Collector]
Map1[Global App Stats]
Map2[Global Domain Stats]
Map3[Global Top Talkers]
end
T1 -->|Flush Active & Evicted Data| AnalyticsCollector
T2 -->|Flush Active & Evicted Data| AnalyticsCollector
AnalyticsCollector --> JSON[JsonExporter]
AnalyticsCollector --> CSV[CsvExporter]
JSON --> summary[summary.json]
JSON --> dist[application-distribution.json]
CSV --> tcp[connections.csv]
CSV --> rules[rules.csv]
```
## 流生命周期管理（v1.3）
为了在不触发 `OutOfMemoryError` 的情况下处理大量文件，DPI Engine v1.3 实现了一个确定性的、PCAP 时间驱动的流淘汰模型。
### 为什么使用 PCAP 时间而不是系统时间？
传统的超时系统使用系统时钟计时器。对于离线数据包处理，这会产生不正确的行为，因为包含数小时流量的捕获可能在几秒钟内被处理。
因此，DPI 引擎使用从 PCAP 本身提取的数据包时间戳进行淘汰，确保无论处理速度如何，都能进行确定性和可重复的流管理。
```
sequenceDiagram
participant PCAP as Reader Thread
participant FP as Fast Path Thread
participant Tracker as ConnectionTracker
participant Analytics as Accumulator
PCAP->>FP: Packet Arrives (tsSec=100)
FP->>Tracker: Update local clock: max(current, 100)
FP->>Tracker: updateConnection(tuple, length, 100)
note right of FP: Packet-Driven Sweep Trigger
FP->>FP: Is (current_time - last_sweep) >= 10s?
alt Time Window Exceeded
FP->>Tracker: cleanupStale(current_time, timeout=300s)
Tracker->>Analytics: recordEvictedConnection()
Tracker->>Tracker: Prune Stale from Memory
end
```
## 并发模型
```
graph TD
Reader[Single Producer Thread] -->|Enqueues| Q1[LB Input Queues]
subgraph Load Balancing
LB1[Load Balancer Thread]
LB2[Load Balancer Thread]
end
Q1 --> LB1
Q1 --> LB2
LB1 -->|Five-Tuple Hash Affinity| Q2[Fast Path Input Queues]
LB2 -->|Five-Tuple Hash Affinity| Q2
subgraph Fast Path Processing
FP1[FP Worker 1]
FP2[FP Worker 2]
FP3[FP Worker 3]
FP4[FP Worker 4]
end
Q2 --> FP1
Q2 --> FP2
Q2 --> FP3
Q2 --> FP4
FP1 -->|Shared Concurrent Queue| Writer[Single Consumer Thread]
FP2 --> Writer
FP3 --> Writer
FP4 --> Writer
```
## 项目结构
```
src/main/java/com/packetanalyzer
│
├── analytics # Export frameworks, JSON/CSV generators
├── engine # Core threads (LB, FastPath, DpiEngine)
├── extractors # L7 Protocol logic (SNI, HTTP, DNS)
├── io # Byte manipulation, PCAP reading/writing
├── parser # Stateless packet header deserialization
├── rules # Dynamic rule loading and evaluation
├── tracking # Thread-local state and connection tables
└── types # Core data models (FiveTuple, ParsedPacket)
```
## 支持的协议
| 层 | 协议 |
|--------|----------|
| L2 | 以太网 |
| L3 | IPv4 |
| L4 | TCP、UDP |
| L7 | DNS、HTTP 主机、TLS SNI |
## 支持的应用
L7 提取管道原生分类针对以下目标的流量：
| 视频 & 流媒体 | 社交媒体 | 企业 & 工具 |
| :--- | :--- | :--- |
| YouTube | Facebook | GitHub |
| Netflix | Instagram | Zoom |
| Spotify | TikTok | Microsoft |
| Apple | Twitter/X | Amazon |
| - | Telegram | Cloudflare |
| - | Discord | Google |
## 生成的报告
在完成分析后，引擎将零依赖的分析结果导出到 `reports/` 目录。
| 报告文件 | 格式 | 目的 |
| :--- | :--- | :--- |
| `summary.json` | JSON | 高级数据包、字节、阻止和生命周期统计 |
| `report-metadata.json` | JSON | 引擎运行时配置和时间戳 |
| `application-distribution.json` | JSON | 应用流量百分比拆分 |
| `domain-distribution.json` | JSON | 顶级域名访问的百分比拆分 |
| `applications.csv` | CSV | 每个应用的原始数据包、字节和连接计数 |
| `domains.csv` | CSV | 每个唯一完全限定域名 (FQDN) 的访问计数 |
| `connections.csv` | CSV | 所有跟踪的 L4 连接的详尽列表 |
| `top-talkers.csv` | CSV | 按内部 IP 分组的流量计数 |
| `rules.csv` | CSV | 所有活动规则域的命中计数 |
## 安装
**先决条件：**
- Java 21+ JDK
- Maven 3.9.x
```
git clone https://github.com/NamanKejriwal/DPI-Engine.git
cd DPI-Engine/java-dpi
```
## 构建说明
使用 Maven 编译项目并运行所有测试：
```
mvn clean package
```
可执行 JAR 将位于 `target/dpi-engine-1.0-SNAPSHOT.jar`。
## 使用方法
**基本执行：**
```
java -jar target/dpi-engine-1.0-SNAPSHOT.jar input.pcap output.pcap
```
*注意：如果代码逻辑中进行了配置，则规则将自动从活动目录中的 `rules.txt` 加载。*
## 示例终端输出
```
╔══════════════════════════════════════════════════════════════╗
║ DPI ENGINE v1.3 ║
║ Deep Packet Inspection System ║
╠══════════════════════════════════════════════════════════════╣
║ CONFIGURATION ║
║ Load Balancers: 2 ║
║ FPs per LB: 2 ║
║ Total FP threads: 4 ║
╚══════════════════════════════════════════════════════════════╝
╔══════════════════════════════════════════════════════════════╗
║ RULE ENGINE INITIALIZATION ║
╠══════════════════════════════════════════════════════════════╣
║ Loaded from: rules.txt ║
║ Domains: 1 ║
║ IPs: 0 ║
║ Ports: 1 ║
║ Applications: 1 ║
╚══════════════════════════════════════════════════════════════╝
[DPIEngine] Processing: samples/traffic.pcap
[DPIEngine] Output to: out.pcap
╔══════════════════════════════════════════════════════════════╗
║ DPI ENGINE STATISTICS ║
╠══════════════════════════════════════════════════════════════╣
║ PACKET STATISTICS ║
║ Total Packets: 77 ║
║ Total Bytes: 11032 ║
║ TCP Packets: 73 ║
║ UDP Packets: 4 ║
╠══════════════════════════════════════════════════════════════╣
║ PIPELINE STATISTICS ║
║ LB Received: 77 ║
║ LB Dispatched: 77 ║
║ FP Processed: 77 ║
║ FP Forwarded: 77 ║
║ FP Dropped: 0 ║
╠══════════════════════════════════════════════════════════════╣
║ FILTERING STATISTICS ║
║ Forwarded: 77 ║
║ Dropped/Blocked: 0 ║
║ Drop Rate: 0.00% ║
╠══════════════════════════════════════════════════════════════╣
║ FLOW LIFECYCLE STATISTICS ║
║ Active Flows: 8 ║
║ Evicted Flows: 35 ║
║ Flow Timeout: 300 sec ║
╠══════════════════════════════════════════════════════════════╣
║ RULE STATISTICS ║
║ Loaded Rules: 3 ║
║ Hit - By Domain: 0 ║
║ Hit - By IP: 0 ║
║ Hit - By Port: 0 ║
║ Hit - By App: 0 ║
║ Total Blocked Flows: 0 ║
╠══════════════════════════════════════════════════════════════╣
║ EXPORT STATUS ║
║ Reports Directory: reports/ ║
║ CSV Files: 5 ║
║ JSON Files: 4 ║
╚══════════════════════════════════════════════════════════════╝
```
## 示例报告
**`reports/summary.json`**
```
{
"totalPackets": 77,
"tcpPackets": 73,
"udpPackets": 4,
"connections": 43,
"activeFlows": 8,
"evictedFlows": 35,
"blockedFlows": 0,
"flowTimeoutSec": 300,
"runtimeMs": 3410
}
```
**`reports/applications.csv`**
```
Application,Connections,Packets,Bytes,Percentage
Unknown,21,21,1134,48.84
DNS,4,4,300,9.30
HTTPS,2,4,368,4.65
Discord,1,3,243,2.33
Amazon,1,3,246,2.33
YouTube,1,3,247,2.33
```
## 验证结果
DPI 引擎使用包含 77 个数据包的代表性 PCAP 捕获进行了验证，这些数据包跨越多个 TCP 和 UDP 流、DNS 查询、TLS 握手和应用识别场景。
### 功能验证
| 度量 | 结果 |
|----------|----------|
| 处理的数据包总数 | 77 |
| TCP 数据包 | 73 |
| UDP 数据包 | 4 |
| 观察到的连接 | 43 |
| 识别的应用 | 16 |
| 生成的报告 | 9 |
| 构建状态 | 通过 |
| 分析导出 | 通过 |
| 规则引擎集成 | 通过 |
### 流生命周期验证
为了验证流淘汰行为，将流超时临时从生产值 **300 秒** 降低到 **1 秒**。
| 度量 | 结果 |
|----------|----------|
| 流超时 | 1 秒 |
| 总连接数 | 43 |
| 活跃流 | 8 |
| 淘汰流 | 35 |
| 分析保留 | 通过 |
### 验证摘要
测试确认：
- 在引入流生命周期管理后，数据包处理仍然完全正常。
- 使用 PCAP 时间戳而不是系统时钟时间成功淘汰了陈旧的连接。
- 在从内存中删除之前，淘汰的流在分析管道中得到了保留。
- 连接计数保持准确（`活跃流 + 淘汰流 = 总连接数`）。
- 在应用识别、规则处理、报告生成或分析导出中没有观察到回归。
## 性能特征
该引擎通过其并发管道最大化单节点硬件能力：
- **亲和哈希：** 五元组哈希确保任何单个流的双向 TCP/UDP 数据包始终落在同一个 FastPath 工作者上，从而消除了分布式连接锁的需要。
- **最小依赖：** 未导入任何第三方分析库。解析器直接在字节偏移量逻辑上操作。
## 设计决策
- **小端偏见：** 网络流量字节是大端序，但 PCAP 文件结构强制执行主机字节序假设。实现了一个集中的自定义字节解析器。
- **时间建模：** 传统的超时依赖于 JVM 系统时钟后台线程 (`System.nanoTime()` )。由于 3 小时的 PCAP 文件可能在 10 秒内被处理，因此该引擎将时间动态地相对于 PCAP 数据包时间戳进行抽象，强制执行完全独立于硬件处理速度的确定性生命周期。
- **淘汰钩子累积：** 内存受限的系统在删除陈旧的连接对象以释放 RAM 时会丢失分析数据。该引擎在清理生命周期期间使用拦截模式，将即将死亡的状态整数永久合并到线程局部累积器中。
## 解决的技术挑战
1. **多线程中的状态一致性：** 通过数学哈希亲和力处理，确保没有两个线程需要同时访问一个 `Connection` 对象。
2. **无限哈希表增长：** 通过直接集成到数据包轮询例程中的 PCAP 驱动的在线时间跟踪循环解决。
3. **淘汰期间的数据丢失：** 通过将活动连接状态与历史分析摘要解耦的专用累积映射架构克服。
## 发布摘要
| 版本 | 主要功能 |
|----------|----------|
| v1.0 | 核心DPI引擎 |
| v1.1 | 动态规则引擎 |
| v1.2 | 分析导出框架 |
| v1.3 | 流生命周期管理 |
## 发布历史
```
timeline
title DPI Engine Release Evolution
v1.0 Core Engine : Raw Bytes to Five-Tuple Flows
: Basic Multi-threading
v1.1 Rule Engine : External File Configuration
: Deep Protocol L7 Blocking
v1.2 Analytics : CSV/JSON File Generation
: App & Domain Tracking
v1.3 Lifecycle : PCAP-Time Flow Eviction
: Deterministic Flow Management
```
## 路线图
- **v1.4** QUIC / HTTP3 检测
- **v1.5** 增强应用识别
- **v1.6** 性能仪表板
## 关键技术概念
该项目展示了：
- 深度数据包检测 (DPI)
- 第 7 层流量分类
- 五元组流跟踪
- 生产者-消费者架构
- 并发数据包处理
- 流生命周期管理
- 基于规则的流量过滤
- 流量分析管道
## 学习成果
该项目展示了在以下方面的实践经验：
- 系统工程和网络架构
- 并发系统设计
- 网络协议解析
- 深度数据包检测 (DPI)
- 流跟踪系统
- 基于规则的流量过滤
- 内存感知网络处理
- 分析管道设计
## 许可证
该项目旨在用于教育和研究目的。标签：JS文件枚举, Maven, PCAP处理, 代码示例, 使用示例, 关键技术, 协议支持, 发布历史, 发布摘要, 域名枚举, 学习成果, 安装指南, 并发模型, 应用支持, 应用识别, 性能优化, 性能特性, 技术挑战, 数据分析, 构建指令, 检测绕过, 流量过滤, 深度包检测, 漏洞验证, 系统架构, 网络安全分析, 网络流量分析, 许可证, 设计决策, 路线图, 连接跟踪