PHP解析pcap并可视化：网络数据包深度解析实战

简介面向计算机、网络工程与信息安全相关专业的毕业设计学生及网络安全初学者这套PHP版网络数据包深度解析与可视化系统以源代码加论文的形式服务于数据包捕获、协议解析、流量监控与可视化展示等课题。源码覆盖网络监听、协议解析引擎、数据处理算法及前端可视化组件可提取IP地址、端口号、协议类型和传输数据并以图表、时间线、树状结构呈现便于观察网络行为、识别异常流量和优化性能论文围绕系统架构、模块划分、性能瓶颈、优化策略及实际应用案例展开。资源包约626KB标题标明含源码与论文核心为PHP源码与论文文档页面文件总数显示为0且类型明细暂缺具体组成以压缩包目录为准。页面显示已有75人学习适合需要项目框架、论文素材和协议分析实现思路的读者参考。1. 网络数据包深度解析与可视化一套 PHP 毕业设计工程能跑成什么样如果你手上是一份「网络数据包深度解析与可视化系统」的 PHP 源码包打开目录能看到抓包文件、建表语句、一个能跑的统计页面那它能不能直接用关键其实就两件事pcap 怎么读进来图表怎么画出来。这个工程走的是 tcpdump 采集、PHP 解析二进制帧、MySQL 落库、ECharts 出图这条路线适合拿来做网络流量分析的课程设计也适合当小型流量审计面板的骨架。它不适合直接上高并发实时捕获抓包交给系统工具PHP 只负责解析和呈现这个分工必须先想清楚。下面按环境搭建、协议解析、可视化、排错、自测五段拆开讲坑在哪一步都写明白了。2. 从 pcap 到数据库整条数据链路的 PHP 环境搭建先别急着点开index.php。这类工程最容易翻车的地方往往就在第一公里环境版本对不上扩展缺一个跑起来就是白屏报错信息还被display_errors关掉了。稳妥的做法是先把链路拆成采集、解析、入库三段每段单独验证通过再串起来。2.1 运行环境与目录规划这个工程对运行时的要求并不高PHP 7.4 和 8.x 都能跑但有两个扩展必须确认到位pdo_mysql负责落库mbstring负责处理协议字段里的文本内容。MySQL 建议 5.7 以上8.0 更好因为后面要用到DATE_FORMAT做时间聚合低版本在ONLY_FULL_GROUP_BY模式下容易报错。php -v php -m | grep -E pdo_mysql|mbstring mysql --version三条命令各自对应一个失败面PHP 版本低于 7.4unpack处理二进制时的越界检查没现在严容易在畸形包上触发警告扩展缺失时new PDO(...)直接抛异常页面一片空白MySQL 版本过低第 4 章的按分钟聚合查询会卡在GROUP BY校验上。目录我一般整理成这样跟源码包里的结构基本能对应上只补了bin/和sql/netscope/ ├─ bin/ │ ├─ collect.sh # tcpdump 采集脚本 │ └─ import_pcap.php # pcap 解析入库 ├─ api/ │ ├─ stats.php # 趋势与协议分布接口 │ └─ topology.php # IP 会话拓扑接口 ├─ public/ │ ├─ index.php # 页面入口 │ └─ static/app.js # 前端图表逻辑 └─ sql/ └─ schema.sql # 建表语句提示源码包里很多页面是直接include相对路径的挪动目录前先用编辑器全局搜一遍require和include把路径改成基于__DIR__的写法否则部署到子目录就会 404。2.2 用 tcpdump 采集并按固定字段入库PHP 本身没有 libpcap 扩展指望它直接抓网卡是不现实的常见的做法是让 tcpdump 负责采集PHP 只读文件。采集脚本我一般写成这样# 只抓 TCP/UDP保留完整包长按 100MB 切文件最多保留 20 个 sudo tcpdump -i eth0 -n -s 65535 \ -w /data/cap/cap_$(date %Y%m%d_%H%M%S).pcap \ tcp or udp -C 100 -W 20-i eth0网卡名不确定就用ip link看一眼容器里常见的是eth0或者any。-n不做反向域名解析。开着它抓包每个包都要等一次 DNS抓包速率会被拖垮还容易丢包。-s 65535snaplen也就是每个包最多截取多少字节。这个参数设小了TCP 负载会被截断后面做应用层识别全是乱码属于典型的“后面所有分析都白做”。-C 100 -W 20单文件 100MB 轮转最多保留 20 个。毕业设计演示环境不设上限磁盘两天就满了。另一个容易想到的方案是用 tshark 直接导出 CSVtshark -r cap.pcap -T fields -E separator, \ -e frame.time_epoch -e ip.src -e ip.dst \ -e tcp.srcport -e tcp.dstport -e ip.proto -e frame.len cap.csv这条命令看着省事但它只导出字段原始负载被丢弃了。工程里要做 HTTP 报文识别、DNS 查询名提取就必须拿到tcp.payload这一段那还不如自己读 pcap。所以这条路我一般只用来做交叉验证真正的入库流程还是走 PHP 解析。入库表结构用下面这段字段是按“能支撑后续所有图表”倒推出来的CREATE TABLE packets ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, ts DATETIME NOT NULL, src_ip VARCHAR(45) NOT NULL, dst_ip VARCHAR(45) NOT NULL, src_port SMALLINT UNSIGNED DEFAULT NULL, dst_port SMALLINT UNSIGNED DEFAULT NULL, protocol TINYINT UNSIGNED NOT NULL COMMENT 6TCP 17UDP, length SMALLINT UNSIGNED NOT NULL, tcp_flags TINYINT UNSIGNED DEFAULT 0, payload_len SMALLINT UNSIGNED DEFAULT 0, app_proto VARCHAR(16) DEFAULT , KEY idx_ts (ts), KEY idx_src (src_ip), KEY idx_dst (dst_ip), KEY idx_proto (protocol) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;VARCHAR(45)是为了兼容 IPv6 地址长度虽然当前解析层只处理 IPv4但字段先留够以后补 IPv6 不用改表。protocol直接存 IANA 号而不是字符串聚合查询时SUM(protocol 6)比字符串比对快一个数量级。三个索引分别对应时间范围过滤、源 IP 排行、目的 IP 排行正好覆盖第 4 章的三类图表。2.3 为什么中间载体是 pcap 文件有人会问既然要落库为什么不边抓边写库中间还要落一次文件。这里有三条理由都是实际踩过之后才想明白的。第一是可回放。演示的时候网络状况不受控讲着讲着流量没了图表一片空白很尴尬。有 pcap 文件就能随时重放一遍把同一份数据反复导入讲课、答辩、写论文配图都方便。第二是解耦解析脚本只依赖文件格式不依赖网卡权限你在自己机器上开发的时候根本不需要 root。第三是可对比同一份 pcap 用 tshark 跑一遍统计再用自己的解析器跑一遍包数对不上就说明解析逻辑有问题这是最省事的自检手段。代价也有解析层必须先自己处理字节序。pcap 文件头有 magic number小端写法是d4 c3 b2 a1大端是a1 b2 c3 d4中间还夹着两种纳秒精度的变体。判断错了后面读时间戳全是天文数字这个坑在第 5 章还会提一次。3. 协议字段解析从以太网帧一路走到应用层报文这一章是整个工程里技术含量最高的部分也是答辩时最容易被追问的地方。PHP 不像 C 有 struct 可以直接映射内存也不像 Python 有 scapy 现成的解析器所有偏移量都得手算。好处是算过一遍之后以太网帧、IP 头、TCP 头长什么样你会记得比背教材牢。3.1 以太网帧与 IP 头的偏移量算法先看以太网帧头固定 14 字节目的 MAC 占 0~5源 MAC 占 6~11类型字段占 12~13。类型是0x0800表示里面装的是 IPv40x86DD是 IPv60x0806是 ARP。当前解析只处理 IPv4其他类型直接跳过——不要试图一把梭把所有协议都写了先把一条链路走通。?php /** * 解析单个以太网帧返回归一化字段不支持的协议返回 null * param string $f 原始帧二进制 */ function parse_frame(string $f): ?array { $len strlen($f); if ($len 14) { return null; // 帧头都不完整直接丢 } // 以太网类型字段大端两字节 $ethType (ord($f[12]) 8) | ord($f[13]); if ($ethType ! 0x0800) { return null; // 现阶段只认 IPv4 } $ip 14; // IP 头起点 if ($len $ip 20) { return null; } $vihl ord($f[$ip]); if (($vihl 4) ! 4) { return null; // 版本号不是 4 } $ihl ($vihl 0x0f) * 4; // IP 头长度单位 4 字节 if ($ihl 20 || $len $ip $ihl) { return null; // 头部长度异常或越界 } $totalLen (ord($f[$ip 2]) 8) | ord($f[$ip 3]); // IP 总长度 $proto ord($f[$ip 9]); // 上层协议号 $srcIp long2ip(unpack(N, substr($f, $ip 12, 4))[1]); $dstIp long2ip(unpack(N, substr($f, $ip 16, 4))[1]); $l4 $ip $ihl; // 传输层起点 $srcPort $dstPort null; $flags 0; $payloadStart null; $payloadLen 0; if ($proto 6 $len $l4 20) { // TCP $srcPort (ord($f[$l4]) 8) | ord($f[$l4 1]); $dstPort (ord($f[$l4 2]) 8) | ord($f[$l4 3]); $dataOff ((ord($f[$l4 12]) 4) 0x0f) * 4; // TCP 头长度 $flags ord($f[$l4 13]); // 标志位 $payloadStart $l4 $dataOff; $payloadLen max(0, $totalLen - $ihl - $dataOff); } elseif ($proto 17 $len $l4 8) { // UDP $srcPort (ord($f[$l4]) 8) | ord($f[$l4 1]); $dstPort (ord($f[$l4 2]) 8) | ord($f[$l4 3]); $payloadStart $l4 8; $payloadLen max(0, $totalLen - $ihl - 8); } $app guess_app($proto, $srcPort, $dstPort, $f, $payloadStart, $payloadLen); return [ src_ip $srcIp, dst_ip $dstIp, src_port $srcPort, dst_port $dstPort, protocol $proto, length $totalLen, tcp_flags $flags, payload_len $payloadLen, app_proto $app, ]; }这段代码里有三个参数点最关键值得逐个说清楚。$vihl 0x0f取的是 IP 头长度字段低四位单位是 4 字节所以乘 4 才是真实字节数。IP 头不是固定 20 字节有选项字段时可以到 60 字节硬编码 20 是新手最容易犯的错一旦遇到带时间戳选项的包后面全部错位。$dataOff同理TCP 头也不是固定 20 字节握手包和带选项的包会不一样。拿到偏移之后$payloadStart才能指对位置。$totalLen来自 IP 头是网络字节序的大端数所以拼的时候高位在前。有人图省事用unpack(n, substr(...))读两字节其实结果一样只是ord拼位移更直观也不依赖字符串切片。3.2 TCP/UDP 端口与应用层识别端口号只能给出线索不能给出结论因为 80 端口上跑的未必是 HTTP。所以识别逻辑要做两级先按众所周知的端口给个初判再用负载开头几个字节做二次校验。?php /** * 应用层协议猜测端口启发 负载前缀校验 */ function guess_app(int $proto, ?int $sp, ?int $dp, string $f, ?int $payloadStart, int $payloadLen): string { // 第一级知名端口 $portMap [ 53 DNS, 80 HTTP, 443 HTTPS, 22 SSH, 25 SMTP, 3306 MySQL, ]; foreach ([$sp, $dp] as $p) { if ($p ! null isset($portMap[$p])) { $guess $portMap[$p]; if ($guess ! HTTP) { // HTTP 需要二次校验 return $guess; } break; } } // 第二级负载前缀 if ($proto 6 $payloadStart ! null $payloadLen 0) { $head substr($f, $payloadStart, min(8, $payloadLen)); foreach ([GET , POST, HEAD, PUT , HTTP/1.] as $m) { if (strncmp($head, $m, strlen($m)) 0) { return HTTP; } } } return $portMap[$sp ?? 0] ?? ($portMap[$dp ?? 0] ?? UNKNOWN); }这段逻辑的取舍是端口命中非 HTTP 的协议直接返回因为 HTTPS、SSH、DNS 这类协议在应用层是加密或二进制格式再做前缀校验意义不大。HTTP 例外明文请求头一眼可辨校验一下能过滤掉大量驻留在 80 端口上的非 HTTP 流量。返回值统一用大写短名存进app_proto字段前端做颜色映射时不用再处理大小写。substr($f, $payloadStart, min(8, $payloadLen))这里的min不能省当负载不足 8 字节时substr会返回短串strncmp的第三参数比实际串长行为虽然不报错但对齐比较容易出错。3.3 pcap 流式读取与入库有了单帧解析函数剩下的就是按 pcap 文件格式一帧一帧往下读。文件头 24 字节之后每帧先来 16 字节的记录头里面包含时间戳秒、微秒、捕获长度和原始长度随后才是帧数据。?php // bin/import_pcap.php $pcap $argv[1] ?? capture.pcap; $fp fopen($pcap, rb); if (!$fp) { exit(无法打开 {$pcap}\n); } $gh fread($fp, 24); if (strlen($gh) 24) { exit(pcap 全局头不足 24 字节\n); } $magic bin2hex(substr($gh, 0, 4)); // 小端微秒: d4c3b2a1 | 小端纳秒: 4d3cb2a1 if (!in_array($magic, [d4c3b2a1, 4d3cb2a1], true)) { exit(暂不支持的 pcap magic: {$magic}\n); } $pdo new PDO(mysql:host127.0.0.1;dbnamenetscope;charsetutf8mb4, root, your_pass, [ PDO::ATTR_ERRMODE PDO::ERRMODE_EXCEPTION, PDO::ATTR_EMULATE_PREPARES false, ]); $sql INSERT INTO packets (ts, src_ip, dst_ip, src_port, dst_port, protocol, length, tcp_flags, payload_len, app_proto) VALUES (?,?,?,?,?,?,?,?,?,?); $stmt $pdo-prepare($sql); $n 0; $pdo-beginTransaction(); while (!feof($fp)) { $ph fread($fp, 16); if (strlen($ph) 16) { break; // 文件尾 } $h unpack(Vts_sec/Vts_usec/Vcaplen/Vlen, $ph); $data fread($fp, $h[caplen]); if (strlen($data) $h[caplen]) { break; // 包体被截断 } $pkt parse_frame($data); if ($pkt null) { continue; } $stmt-execute([ date(Y-m-d H:i:s, $h[ts_sec]), $pkt[src_ip], $pkt[dst_ip], $pkt[src_port], $pkt[dst_port], $pkt[protocol], $pkt[length], $pkt[tcp_flags], $pkt[payload_len], $pkt[app_proto], ]); if ($n % 1000 0) { // 每千条提交一次 $pdo-commit(); $pdo-beginTransaction(); fwrite(STDERR, 已入库 {$n} 条\n); } } $pdo-commit(); fclose($fp); echo 完成共导入 {$n} 条\n;unpack(Vts_sec/Vts_usec/Vcaplen/Vlen, $ph)里四个V都是无符号 32 位小端对应 pcap 记录头的固定布局顺序。PDO::ATTR_EMULATE_PREPARES false打开真实预处理批量插入时能省掉 PHP 侧的字符串拼接开销几千条以上差距就能看出来。$n % 1000提交一次是经验值太频繁事务开销吃掉性能太小长事务会撑大 undo log中途失败还得全部回滚。1000 条在普通机械盘上也就几十毫秒属于比较稳的区间。4. 可视化落地把解析结果做成交互图表数据进库之后页面怎么画图就是纯前端的事了。这个工程用 ECharts好处是配置项多、文档全坏处是配置项太多一不小心就把图表调成了说不清道不明的样子。这里给三类最常用的视图协议分布、流量趋势、IP 会话拓扑。4.1 协议分布与流量趋势的后端接口接口层要遵守一个原则后端不做任何格式化只吐结构化数据单位、精度、排序全交给前端决定。这样同一个接口能给多个图表复用也能被论文里的表格直接引用。?php // api/stats.php header(Content-Type: application/json; charsetutf-8); $pdo new PDO(mysql:host127.0.0.1;dbnamenetscope;charsetutf8mb4, root, your_pass, [ PDO::ATTR_ERRMODE PDO::ERRMODE_EXCEPTION, ]); // 近 1 小时按分钟聚合TCP / UDP / 总包数 $sql SELECT DATE_FORMAT(ts, %H:%i) AS minute, SUM(protocol 6) AS tcp, SUM(protocol 17) AS udp, COUNT(*) AS total FROM packets WHERE ts NOW() - INTERVAL 1 HOUR GROUP BY minute ORDER BY minute; $rows $pdo-query($sql)-fetchAll(PDO::FETCH_ASSOC); // 应用层协议分布 $dist $pdo-query( SELECT app_proto AS name, COUNT(*) AS value FROM packets WHERE app_proto GROUP BY app_proto ORDER BY value DESC LIMIT 10 )-fetchAll(PDO::FETCH_ASSOC); echo json_encode([ code 0, trend $rows, dist $dist, ], JSON_UNESCAPED_UNICODE);DATE_FORMAT(ts, %H:%i)直接按分钟归并比在 PHP 里遍历再分组快得多。SUM(protocol 6)是 MySQL 里“条件计数”的惯用写法等价于SUM(CASE WHEN protocol 6 THEN 1 ELSE 0 END)但短得多也更容易让优化器走索引。JSON_UNESCAPED_UNICODE必须加上否则中文字段在响应里会变成\uXXXX虽然浏览器能解但抓包调试的时候看着费劲。4.2 IP 会话拓扑与端口热力图拓扑图的数据结构和趋势图不一样需要把源、目的配对起来。GROUP BY src_ip, dst_ip之后取前 N 条节点和边就能直接喂给 ECharts 的 graph 系列。?php // api/topology.php header(Content-Type: application/json; charsetutf-8); $limit max(10, min(200, (int)($_GET[limit] ?? 50))); $pdo new PDO(mysql:host127.0.0.1;dbnamenetscope;charsetutf8mb4, root, your_pass, [ PDO::ATTR_ERRMODE PDO::ERRMODE_EXCEPTION, ]); $stmt $pdo-prepare( SELECT src_ip, dst_ip, COUNT(*) AS cnt FROM packets WHERE ts NOW() - INTERVAL 30 MINUTE GROUP BY src_ip, dst_ip ORDER BY cnt DESC LIMIT :lim ); $stmt-bindValue(:lim, $limit, PDO::PARAM_INT); $stmt-execute(); $edges $stmt-fetchAll(PDO::FETCH_ASSOC); $nodes []; $links []; foreach ($edges as $e) { foreach ([$e[src_ip], $e[dst_ip]] as $ip) { $nodes[$ip] [name $ip, symbolSize 10]; } $links[] [ source $e[src_ip], target $e[dst_ip], value (int)$e[cnt], ]; } echo json_encode([ code 0, nodes array_values($nodes), links $links, ], JSON_UNESCAPED_UNICODE);bindValue(:lim, $limit, PDO::PARAM_INT)这里的类型标注不能省。MySQL 的LIMIT后面不接受字符串绑成PARAM_STR在某些版本会直接语法报错。max(10, min(200, ...))是给外部参数加个护栏拓扑图节点超过两百个浏览器渲染就开始卡了。4.3 前端 ECharts 配置的关键参数前端只做两件事拉数据、套配置。下面这段是趋势图的骨架另外两个图表换series类型即可。// public/static/app.js const trend echarts.init(document.getElementById(trend)); trend.setOption({ tooltip: { trigger: axis }, legend: { data: [TCP, UDP] }, grid: { left: 48, right: 24, top: 40, bottom: 32 }, xAxis: { type: category, boundaryGap: false, data: [] }, yAxis: { type: value, name: 包数 }, series: [ { name: TCP, type: line, smooth: true, showSymbol: false, data: [] }, { name: UDP, type: line, smooth: true, showSymbol: false, data: [] } ] }); async function refresh() { const resp await fetch(api/stats.php); const json await resp.json(); if (json.code ! 0) return; trend.setOption({ xAxis: { data: json.trend.map(d d.minute) }, series: [ { data: json.trend.map(d Number(d.tcp)) }, { data: json.trend.map(d Number(d.udp)) } ] }); } refresh(); setInterval(refresh, 5000);几个参数值得单独说。boundaryGap: false让折线从 y 轴贴边开始视觉上更像连续时间序列不设的话首尾各空半格看着别扭。showSymbol: false关掉数据点圆圈几百个点的时候打开会让图表糊成一片。Number(d.tcp)不能省MySQL 的SUM在 PDO 里返回的是字符串ECharts 的折线遇到字符串会静默忽略这些点表现出来就是“数据明明有图就是平的”这个坑我在第 5 章还会再提一次。setInterval(refresh, 5000)的五秒间隔是经验值。低于三秒浏览器和数据库都扛不住高于十秒演示的时候观众会觉得卡。5. 避坑与排查五条踩过的坑这个工程我在不同机器上跑过几次有些问题反复出现基本可以当成清单直接排查。5.1 抓不到包权限和网卡名都没对上现象tcpdump命令敲下去没有任何输出CtrlC之后文件是 0 字节或者报Permission denied。原因通常有两个一是没有sudo普通用户没有原始套接字权限二是网卡名写错了默认写eth0但实际机器上叫ens33、enp0s3或者容器里的any。解决先ip link看清楚网卡列表再决定抓哪个。容器环境里抓any能把回环流量也带进来调试阶段很有用。权限问题别图省事直接chmod 777到网卡设备上标准做法是给tcpdump加CAP_NET_RAW能力或者干脆用sudo起一个专用脚本。5.2 数据包被截断snaplen 设小了现象入库之后app_proto大批量显示UNKNOWN用十六进制工具看负载HTTP 请求头只有半截。原因tcpdump的-s参数默认在某些发行版里是 96 或者 262144前者明显不够一个完整的 HTTP 请求头轻松超过 96 字节。另外-C轮转时如果磁盘写满最后一个文件也会被截断。解决采集时明确加-s 65535并且df -h确认目标磁盘至少留出 20% 余量。已经抓到截断的包重新采集是唯一办法解析层再怎么写都补不回来。5.3 时间戳错位时区和字节序两个坑叠在一起现象导入数据库后ts字段显示的时间是 1970 年或者 2038 年之后趋势图横轴全是乱码。原因两层。第一层是 pcap 的 magic number 判断错了小端当大端读秒数直接变成天文数字第二层是 PHP 的默认时区和 MySQL 的time_zone不一致date()出来是 UTC入库被当成东八区。解决magic number 一定要先判断再读d4c3b2a1和4d3cb2a1之外的值直接报错退出别硬着头皮读。时区问题在脚本开头加date_default_timezone_set(Asia/Shanghai)MySQL 那边建库时指定DEFAULT CHARSETutf8mb4并确认time_zone不是SYSTEM。两边对齐之后时间轴才可信。5.4 中文乱码编码链路里断了一环现象app_proto里出现乱码或者论文配图的标题、坐标轴中文变成问号。原因乱码从来不是单点问题而是链路里至少有一环没对上。常见的是数据库连接串里漏了charsetutf8mb4或者表本身建成了latin1再或者 PHP 文件存成了 GBK 而输出的 JSON 是 UTF-8。解决沿着“文件编码 → PDO 连接串 → 表字符集 → HTTP 响应头”四段逐一确认都改成utf8mb4。JSON 输出时加JSON_UNESCAPED_UNICODE。别用mb_convert_encoding到处转转来转去只会把问题藏起来。5.5 大流量卡死分页没做索引没建现象导入一个几百 MB 的 pcap 之后打开首页转圈半分钟MySQL 的 CPU 打到 100%。原因首页的统计查询没有时间范围限制COUNT(*)扫了全表同时ts字段上没有索引WHERE ts ...只能全表扫。拓扑查询的GROUP BY src_ip, dst_ip在没索引的情况下会走临时表加文件排序数据量一大就顶不住。解决所有图表查询强制带时间窗默认近 1 小时最大不超过 24 小时。索引按第 2 章那张建表语句补齐idx_ts、idx_src、idx_dst、idx_proto四个一个都别少。再不行就上汇总表定时把分钟级统计结果物化到另一张表里前端只读汇总表原始包表只在详情页查。这一条改完首页加载时间基本能压到一秒以内。6. 进阶验证拿一份真实流量自测这套系统工程跑起来只是及格线能不能信任它给的数据得靠对比验证。我一般会按下面这套流程走一遍花不了十分钟但能挡掉大部分“图好看但数不对”的问题。第一步先看包数。拿同一份 pcap分别用 tshark 和自己写的脚本统计总包数tshark -r cap.pcap -q -z io,stat,0 php bin/import_pcap.php cap.pcap mysql -uroot -p -e SELECT COUNT(*) FROM netscope.packets三个数字里tshark 的统计会把所有协议都算进去而 PHP 脚本只入库 IPv4 的 TCP/UDP所以后两个应该相等且小于第一个。差值是 IPv6、ARP 以及其他被跳过的流量。如果后两个对不上说明解析层在某类包上提前return null了下一步就是按协议号逐类排查。第二步抽查时间戳。从 pcap 里挑第一个包用tshark -r cap.pcap -c 1 -T fields -e frame.time_epoch拿到 epoch 值跟数据库里MIN(ts)对一下。允许的偏差只有时区那一档其他任何偏差都说明字节序处理有问题。第三步抽查应用层识别。SELECT app_proto, COUNT(*) FROM packets GROUP BY app_proto ORDER BY 2 DESC跑一下正常情况下 HTTP、HTTPS、DNS 应该占大头UNKNOWN比例不该超过三成。UNKNOWN太多要么是抓包时 snaplen 太小要么是端口启发表不全。补充端口映射时别一次加几十个每次加两三个改完重导一份 pcap 看比例变化效果更直观。第四步图表对账。趋势图横轴最后一分钟的总包数应该等于SELECT COUNT(*) FROM packets WHERE ts DATE_SUB(NOW(), INTERVAL 1 MINUTE)的结果。这一条过了说明接口的聚合逻辑和 SQL 没有对不上的地方。第五步也是我最后悔没早点做的一步故意喂一份畸形 pcap 进去。随便找个文件名改后缀或者用dd截断一个包文件看脚本是报错退出还是静默写入一堆垃圾数据。早期的版本里fread读不满时我没做长度校验结果一个被截断的包文件往表里写了上百万条0.0.0.0记录清理起来特别麻烦。从那以后我每次导入新 pcap 都会先跑一遍这套对比脚本包数、时间戳、协议分布三项对上了再去看图。数据链路这东西图表只是最后一公里的呈现前面的字节偏移和边界检查只要错一个后面全是玄学。希望帮到你。本文还有配套的精品资源点击获取