简介面向高校毕业设计与网络安全入门实践的一套网络数据包深度解析与可视化系统采用 PHP 开发覆盖数据包捕获、协议解析、数据处理与前端图表展示的完整链路。系统可实时监听网络流量按协议标准提取 IP 地址、端口号、协议类型与传输内容再通过清洗、聚合和分析以图表、时间线和树状结构呈现便于理解网络行为、识别异常流量并观察性能变化。压缩包约 626KB以 PHP 源代码和配套论文文档为主上游未列出具体文件总数与格式明细源码对应监听模块、解析引擎、处理算法和可视化组件论文则说明架构设计、模块划分、性能瓶颈与优化策略并给出实际场景应用分析。目前已有 75 人学习适合作为毕设选题参考、课程设计原型或协议分析练手项目帮助读者建立从抓包到展示的完整实现思路并据此完成功能扩展与答辩材料整理。1. 用 PHP 解析网络包瓶颈从来不在语言本身看到「PHP 写的网络数据包深度解析与可视化系统」很多人的第一反应是语言选错了——解包这种活不该交给 C 吗先把结论摆在前面在离线文件回放和中小流量在线场景下PHP 用unpack()逐层剥离一个以太网帧只要几微秒一个 CLI 进程跑到每秒几万个包并不稀奇真正拖垮这类系统的是字节序判断、首部长度字段、会话表只增不减这些与语言无关的机制问题。这也是这份毕业设计值得拆开看的原因它把一个网络黑匣子拆成「取数 → 逐层剥离 → 会话还原 → 聚合 → 可视化」五段流水线每一段都有自己的机制和坑PHP 只是把这些坑暴露得更早、更直白。搞懂这条流水线换成任何语言都能照着搭一遍而只看懂怎么跑起来遇到线上一错位就完全无从下手。2. 取数链路一个字节从网卡到 PHP 数组要过几道手在讨论解析之前得先弄清楚“包”是怎么进入进程的。这一段决定了后面所有数据的可信度取数环节丢掉的包解析器写得再漂亮也补不回来取数环节截断的字节可视化出来的流量永远偏低。分成两条路径来看机制差别比想象中大。2.1 两条取数路径在线原始套接字与离线文件回放在线路径靠原始套接字直接向内核要链路层帧。在类 Unix 环境里创建一个地址族为AF_PACKET、类型为SOCK_RAW的套接字协议号填0x0003表示接收所有以太网类型随后socket_recv()拿到的就是一个完整的以太网帧字节串从目的 MAC 开始一个字节都不少。这条路径要求进程有足够权限否则socket_create()直接返回false第一次跑就在权限上栽的人不在少数。离线路径则是读抓包文件结构非常简单24 字节全局头后面跟着一串「16 字节记录头 帧数据」。它不需要任何特权答辩演示、问题复现、回归测试都靠它。两条路径最终要归一到同一个数据结构帧字节串 一个微秒级时间戳 可选的原始长度。这个归一化很关键后面的解析器只认字节串不关心数据来自网卡还是文件。工程上常见的做法是把在线结果先落盘成抓包文件再统一走离线解析等于给实时链路加了一层可回放的后悔药线上解析崩了原始文件还在重跑一遍就能定位到底是哪一帧、哪个偏移出了问题。2.2 unpack() 的格式码与字节序n、v、N 用错就全盘皆错PHP 里做二进制解析只有一套核心工具unpack()。它按格式码把字节串切成字段宽度由字母决定字节序由字母的大小写决定。网络协议头一律使用网络序也就是大端所以端口、窗口、长度这类 16 位字段用nIP 地址、序列号、确认号这类 32 位字段用N单字节字段版本号、协议号、TTL用C。反过来抓包文件头里的字段是按抓包主机的字节序写的小端机器存出来的文件就得用v和V读。格式码宽度字节序典型用途C1 字节无版本号、IHL、协议号、TTLn2 字节大端以太网类型、端口、TCP 窗口v2 字节小端小端抓包文件里的 16 位字段N4 字节大端IPv4 地址、序列号、确认号V4 字节小端小端抓包文件里的时间戳、长度H*变长无MAC 地址转十六进制串判断文件字节序靠文件头的前 4 个字节。它有两种写法上的变体一个是大端落盘的a1b2c3d4一个是大端落盘的a1b23c4d纳秒精度版本对应到磁盘上的实际字节就是d4c3b2a1和4d3cb2a1。只要把读到的 4 个字节转成十六进制串去比对就知道整个文件该用哪套格式码。?php // 以二进制只读方式打开抓包文件先取 24 字节全局头 $fp fopen($path, rb); $gh fread($fp, 24); if (strlen($gh) 24) { throw new RuntimeException(文件不足一个全局头可能不是抓包文件); } // magic 的落盘顺序决定整个文件的字节序 $magic bin2hex(substr($gh, 0, 4)); $littleEndian in_array($magic, [d4c3b2a1, 4d3cb2a1], true); $u32 $littleEndian ? V : N; // V 小端 32 位N 大端 32 位 $u16 $littleEndian ? v : n; // 16 位字段同理 $head unpack( $u32 . magic/ . $u16 . major/ . $u16 . minor/ . $u32 . thiszone/ . $u32 . sigfigs/ . $u32 . snaplen/ . $u32 . linktype, $gh ); // 用生成器逐条吐出内存只驻留一帧 function readFrames($fp, string $u32, int $snaplen): Generator { while (!feof($fp)) { $rh fread($fp, 16); // 记录头时间戳 长度 if (strlen($rh) 16) { break; // 文件尾被截断安全退出 } $r unpack($u32 . sec/ . $u32 . usec/ . $u32 . incl/ . $u32 . orig, $rh); if ($r[incl] 0 || $r[incl] $snaplen) { fseek($fp, $r[incl], SEEK_CUR); // 长度异常跳过而不是硬读 continue; } $frame fread($fp, $r[incl]); if (strlen($frame) ! $r[incl]) { break; // 帧数据不完整 } // 统一成秒级浮点时间戳后面切时间桶直接用它 yield [$r[sec] $r[usec] / 1e6, $frame, $r[incl], $r[orig]]; } }这段代码里有三个容易被忽略的判断。第一是magic必须先读、先判断再决定后面所有字段用哪套格式码顺序反了整份数据就是乱码。第二是incl的上界校验损坏文件和拼接错误的文件经常在这里给出一个天文数字不做校验就会fread一个几百 MB 的块把内存打满。第三是末尾用了yield而不是返回数组——一个几百 MB 的文件可能有上百万条记录一次性展开成 PHP 数组内存立刻爆掉生成器让内存占用几乎与文件大小无关这是整套实现里最值钱的一个决定。$snaplen来自全局头它表示抓包时每个帧最多保存多少字节。拿它做上界判断比硬编码一个数字可靠得多。2.3 环形缓冲与丢包为什么统计出来的流量总比实际少在线抓取时统计值比实际偏小八成不是解析算错了而是包压根没到用户态。内核给每个抓包套接字维护一个环形缓冲区网卡把帧塞进环用户态进程慢慢recv取走如果消费速度跟不上生产速度环满了新帧直接丢弃丢了多少只有内核计数器知道PHP 这一层看不见任何异常。这就是脚本语言做在线抓取时第一件要设计的事是「先落盘、后解析」而不是「边抓边解析」的原因。第二个更难发现的杀手是截断。抓包时如果没有显式放大保存长度记录头里的incl实际保存长度会小于orig原始长度说明这个帧只保留了前若干字节。此时如果拿incl去计算 IP 载荷长度一个 1400 字节的 TCP 段会被算成几十字节应用层解析全部落空而错误表现只是“HTTP 请求体为空”。判断方法非常直接只要orig incl这个包就是被截断的应用层必须放弃解析并在结果里打上truncated标记否则可视化出来的字节总数会一直偏低且找不到原因。还有一层是抓取位置决定的视野。绑在回环接口上只看得到本机进程间通信绑在物理网卡上看不到同机容器内部的流量接在镜像口上才能看到整条链路的双向数据。这类“抓不到”的问题十有八九是抓取点选错了而不是代码写错了。3. 逐层剥离与会话还原一个请求被切成 7 个包之后取到字节流之后真正的解析才开始。这一层的核心不是“认识协议”而是“算对偏移”每一层的首部长度都可能变化任何一个偏移算错后面所有字段都会跟着漂。更麻烦的是TCP 把一条业务请求切成了多个段包级别的信息没法直接回答“这次请求返回了多少字节”必须做会话还原。3.1 以太网与 VLAN偏移量从第一层就开始漂以太网帧的头 14 个字节是固定的6 字节目的 MAC、6 字节源 MAC、2 字节类型。类型字段0x0800是 IPv40x86dd是 IPv60x0806是 ARP。到这一步偏移是 14上层载荷从第 15 个字节开始——前提是帧里没有 VLAN 标签。带 802.1Q 标签的帧会把类型字段变成0x8100后面插入 4 个字节2 字节标签控制信息 2 字节内层类型真正的上层协议类型藏在这 4 个字节的最后两位。更麻烦的是双层标签类型会变成0x88a8还能再套一层。所以偏移量不能写成常量 14必须写成循环只要当前类型还是0x8100或0x88a8就再往后跳 4 个字节继续判断。?php // 返回 [以太网信息, 上层协议起点偏移]解析失败返回 [null, 0] function parseEthernet(string $frame): array { if (strlen($frame) 14) { return [null, 0]; // 连基本头都不够直接放弃 } $eth unpack(H12dst/H12src/netype, $frame); // 恰好消费前 14 字节 $offset 14; $type $eth[etype]; // 循环剥离 VLAN 标签一层或多层 while ($type 0x8100 || $type 0x88a8) { if (strlen($frame) $offset 4) { return [null, 0]; // 标签被截断 } $type unpack(n, substr($frame, $offset 2, 2))[1]; $offset 4; } return [[dst $eth[dst], src $eth[src], type $type], $offset]; }这个函数的价值在于把“偏移计算”收敛到一个地方。很多实现图省事直接在全局用substr($frame, 14, 20)取 IP 头一旦网络里出现 VLAN所有字段集体错位而且错得很隐蔽——版本号还能读出 4协议号却变成了随机值。把偏移交给一个函数返回后面每一层都用返回值而不是常量是这类解析器唯一能长期维护的写法。3.2 IP 首部与 IHL后面所有字段的位置由它决定IP 首部的第一个字节是双面字段高 4 位是版本号低 4 位是首部长度IHL单位是 32 位字。IHL 等于 5 表示 20 字节、没有选项等于 6 表示 24 字节、多了 4 字节选项。这意味着 IP 载荷的起点等于 IP 起点加上 IHL 乘以 4不是固定的“帧起点 34”。首部里还有几个字段直接决定后续解析策略。总长度字段在偏移 2、宽 2 字节、网络序它比帧长度可靠得多因为以太网最小帧长是 60 字节短包会在尾部补零用帧长度减首部长度会多出几个字节的垃圾数据。协议号在偏移 96 表示 TCP17 表示 UDP1 表示 ICMP。源和目的地址分别在偏移 12 和 16。分片是必须处理的边界情况。标志位里的 MF更多分片和 13 位片偏移单位 8 字节说明这个包可能只是完整报文的一段。最小可行的处理是只要 MF 置位或片偏移不为 0就把这个包标记为分片不参与应用层解析。否则你会把半截 JSON 丢给解析器得到一堆莫名其妙的语法错误而真正的元凶在传输层下面。IPv6 是另一套结构40 字节定长头后面跟着链式的扩展首部上层协议号在“下一个首部”字段里得一路跳过去才能找到传输层。如果只做 IPv4遇到 IPv6 流量要显式标记为未支持而不是让解析器走进错误的偏移。3.3 TCP data offset载荷起点不是固定的 54 字节TCP 首部的第 13 个字节从 TCP 起点算藏着数据偏移量占高 4 位单位同样是 32 位字。等于 5 就是 20 字节裸头大于 5 说明带了选项——MSS、窗口扩大因子、时间戳、SACK 允许这些在网络里非常常见。载荷起点等于 TCP 起点加上数据偏移乘以 4。?php // 假定 $ipOffset 已是 IPv4 首部起点且已确认协议号为 6 $vihl ord($frame[$ipOffset]); $ihl ($vihl 0x0f) * 4; // 首部长度字节 $total unpack(n, substr($frame, $ipOffset 2, 2))[1]; // IP 总长度 $proto ord($frame[$ipOffset 9]); $srcIp inet_ntop(substr($frame, $ipOffset 12, 4)); $dstIp inet_ntop(substr($frame, $ipOffset 16, 4)); $tcpOff $ipOffset $ihl; // 传输层起点 // 一次取 14 字节源端口、目的端口、序列号、确认号、标志位 $tcp unpack(nsport/ndport/Nseq/Nack/nflags/nwin, substr($frame, $tcpOff, 14)); $dataOff (($tcp[flags] 12) 0x0f) * 4; // 高 4 位单位 32 位字 $payload substr($frame, $tcpOff $dataOff, max(0, $total - $ihl - $dataOff));最后一行值得单独说明。载荷长度用的是$total - $ihl - $dataOff也就是 IP 总长度减去 IP 首部再减去 TCP 首部而不是用strlen($frame)去减。理由就是上一节说的以太网填充一个 40 字节的纯 ACK 包会被补到 60 字节用帧长度减出来会多出 8 到 10 个字节的零这些零一旦混进载荷应用层判断“这个段有没有数据”就会出错重组逻辑会把纯 ACK 当成携带数据的段序列号推进也跟着错。UDP 简单得多8 字节定长头长度字段在偏移 4载荷从第 9 个字节开始不需要算偏移量所以后文讨论重组时只针对 TCP。3.4 四元组归一化与序列号重组本文还有配套的精品资源点击获取 
长河君 · 2026/10/29 22:41:28 · 阅读 1.2k PHP网络数据包解析与可视化：从抓包取数到TCP会话还原
简介面向高校毕业设计与网络安全入门实践的一套网络数据包深度解析与可视化系统采用 PHP 开发覆盖数据包捕获、协议解析、数据处理与前端图表展示的完整链路。系统可实时监听网络流量按协议标准提取 IP 地址、端口号、协议类型与传输内容再通过清洗、聚合和分析以图表、时间线和树状结构呈现便于理解网络行为、识别异常流量并观察性能变化。压缩包约 626KB以 PHP 源代码和配套论文文档为主上游未列出具体文件总数与格式明细源码对应监听模块、解析引擎、处理算法和可视化组件论文则说明架构设计、模块划分、性能瓶颈与优化策略并给出实际场景应用分析。目前已有 75 人学习适合作为毕设选题参考、课程设计原型或协议分析练手项目帮助读者建立从抓包到展示的完整实现思路并据此完成功能扩展与答辩材料整理。1. 用 PHP 解析网络包瓶颈从来不在语言本身看到「PHP 写的网络数据包深度解析与可视化系统」很多人的第一反应是语言选错了——解包这种活不该交给 C 吗先把结论摆在前面在离线文件回放和中小流量在线场景下PHP 用unpack()逐层剥离一个以太网帧只要几微秒一个 CLI 进程跑到每秒几万个包并不稀奇真正拖垮这类系统的是字节序判断、首部长度字段、会话表只增不减这些与语言无关的机制问题。这也是这份毕业设计值得拆开看的原因它把一个网络黑匣子拆成「取数 → 逐层剥离 → 会话还原 → 聚合 → 可视化」五段流水线每一段都有自己的机制和坑PHP 只是把这些坑暴露得更早、更直白。搞懂这条流水线换成任何语言都能照着搭一遍而只看懂怎么跑起来遇到线上一错位就完全无从下手。2. 取数链路一个字节从网卡到 PHP 数组要过几道手在讨论解析之前得先弄清楚“包”是怎么进入进程的。这一段决定了后面所有数据的可信度取数环节丢掉的包解析器写得再漂亮也补不回来取数环节截断的字节可视化出来的流量永远偏低。分成两条路径来看机制差别比想象中大。2.1 两条取数路径在线原始套接字与离线文件回放在线路径靠原始套接字直接向内核要链路层帧。在类 Unix 环境里创建一个地址族为AF_PACKET、类型为SOCK_RAW的套接字协议号填0x0003表示接收所有以太网类型随后socket_recv()拿到的就是一个完整的以太网帧字节串从目的 MAC 开始一个字节都不少。这条路径要求进程有足够权限否则socket_create()直接返回false第一次跑就在权限上栽的人不在少数。离线路径则是读抓包文件结构非常简单24 字节全局头后面跟着一串「16 字节记录头 帧数据」。它不需要任何特权答辩演示、问题复现、回归测试都靠它。两条路径最终要归一到同一个数据结构帧字节串 一个微秒级时间戳 可选的原始长度。这个归一化很关键后面的解析器只认字节串不关心数据来自网卡还是文件。工程上常见的做法是把在线结果先落盘成抓包文件再统一走离线解析等于给实时链路加了一层可回放的后悔药线上解析崩了原始文件还在重跑一遍就能定位到底是哪一帧、哪个偏移出了问题。2.2 unpack() 的格式码与字节序n、v、N 用错就全盘皆错PHP 里做二进制解析只有一套核心工具unpack()。它按格式码把字节串切成字段宽度由字母决定字节序由字母的大小写决定。网络协议头一律使用网络序也就是大端所以端口、窗口、长度这类 16 位字段用nIP 地址、序列号、确认号这类 32 位字段用N单字节字段版本号、协议号、TTL用C。反过来抓包文件头里的字段是按抓包主机的字节序写的小端机器存出来的文件就得用v和V读。格式码宽度字节序典型用途C1 字节无版本号、IHL、协议号、TTLn2 字节大端以太网类型、端口、TCP 窗口v2 字节小端小端抓包文件里的 16 位字段N4 字节大端IPv4 地址、序列号、确认号V4 字节小端小端抓包文件里的时间戳、长度H*变长无MAC 地址转十六进制串判断文件字节序靠文件头的前 4 个字节。它有两种写法上的变体一个是大端落盘的a1b2c3d4一个是大端落盘的a1b23c4d纳秒精度版本对应到磁盘上的实际字节就是d4c3b2a1和4d3cb2a1。只要把读到的 4 个字节转成十六进制串去比对就知道整个文件该用哪套格式码。?php // 以二进制只读方式打开抓包文件先取 24 字节全局头 $fp fopen($path, rb); $gh fread($fp, 24); if (strlen($gh) 24) { throw new RuntimeException(文件不足一个全局头可能不是抓包文件); } // magic 的落盘顺序决定整个文件的字节序 $magic bin2hex(substr($gh, 0, 4)); $littleEndian in_array($magic, [d4c3b2a1, 4d3cb2a1], true); $u32 $littleEndian ? V : N; // V 小端 32 位N 大端 32 位 $u16 $littleEndian ? v : n; // 16 位字段同理 $head unpack( $u32 . magic/ . $u16 . major/ . $u16 . minor/ . $u32 . thiszone/ . $u32 . sigfigs/ . $u32 . snaplen/ . $u32 . linktype, $gh ); // 用生成器逐条吐出内存只驻留一帧 function readFrames($fp, string $u32, int $snaplen): Generator { while (!feof($fp)) { $rh fread($fp, 16); // 记录头时间戳 长度 if (strlen($rh) 16) { break; // 文件尾被截断安全退出 } $r unpack($u32 . sec/ . $u32 . usec/ . $u32 . incl/ . $u32 . orig, $rh); if ($r[incl] 0 || $r[incl] $snaplen) { fseek($fp, $r[incl], SEEK_CUR); // 长度异常跳过而不是硬读 continue; } $frame fread($fp, $r[incl]); if (strlen($frame) ! $r[incl]) { break; // 帧数据不完整 } // 统一成秒级浮点时间戳后面切时间桶直接用它 yield [$r[sec] $r[usec] / 1e6, $frame, $r[incl], $r[orig]]; } }这段代码里有三个容易被忽略的判断。第一是magic必须先读、先判断再决定后面所有字段用哪套格式码顺序反了整份数据就是乱码。第二是incl的上界校验损坏文件和拼接错误的文件经常在这里给出一个天文数字不做校验就会fread一个几百 MB 的块把内存打满。第三是末尾用了yield而不是返回数组——一个几百 MB 的文件可能有上百万条记录一次性展开成 PHP 数组内存立刻爆掉生成器让内存占用几乎与文件大小无关这是整套实现里最值钱的一个决定。$snaplen来自全局头它表示抓包时每个帧最多保存多少字节。拿它做上界判断比硬编码一个数字可靠得多。2.3 环形缓冲与丢包为什么统计出来的流量总比实际少在线抓取时统计值比实际偏小八成不是解析算错了而是包压根没到用户态。内核给每个抓包套接字维护一个环形缓冲区网卡把帧塞进环用户态进程慢慢recv取走如果消费速度跟不上生产速度环满了新帧直接丢弃丢了多少只有内核计数器知道PHP 这一层看不见任何异常。这就是脚本语言做在线抓取时第一件要设计的事是「先落盘、后解析」而不是「边抓边解析」的原因。第二个更难发现的杀手是截断。抓包时如果没有显式放大保存长度记录头里的incl实际保存长度会小于orig原始长度说明这个帧只保留了前若干字节。此时如果拿incl去计算 IP 载荷长度一个 1400 字节的 TCP 段会被算成几十字节应用层解析全部落空而错误表现只是“HTTP 请求体为空”。判断方法非常直接只要orig incl这个包就是被截断的应用层必须放弃解析并在结果里打上truncated标记否则可视化出来的字节总数会一直偏低且找不到原因。还有一层是抓取位置决定的视野。绑在回环接口上只看得到本机进程间通信绑在物理网卡上看不到同机容器内部的流量接在镜像口上才能看到整条链路的双向数据。这类“抓不到”的问题十有八九是抓取点选错了而不是代码写错了。3. 逐层剥离与会话还原一个请求被切成 7 个包之后取到字节流之后真正的解析才开始。这一层的核心不是“认识协议”而是“算对偏移”每一层的首部长度都可能变化任何一个偏移算错后面所有字段都会跟着漂。更麻烦的是TCP 把一条业务请求切成了多个段包级别的信息没法直接回答“这次请求返回了多少字节”必须做会话还原。3.1 以太网与 VLAN偏移量从第一层就开始漂以太网帧的头 14 个字节是固定的6 字节目的 MAC、6 字节源 MAC、2 字节类型。类型字段0x0800是 IPv40x86dd是 IPv60x0806是 ARP。到这一步偏移是 14上层载荷从第 15 个字节开始——前提是帧里没有 VLAN 标签。带 802.1Q 标签的帧会把类型字段变成0x8100后面插入 4 个字节2 字节标签控制信息 2 字节内层类型真正的上层协议类型藏在这 4 个字节的最后两位。更麻烦的是双层标签类型会变成0x88a8还能再套一层。所以偏移量不能写成常量 14必须写成循环只要当前类型还是0x8100或0x88a8就再往后跳 4 个字节继续判断。?php // 返回 [以太网信息, 上层协议起点偏移]解析失败返回 [null, 0] function parseEthernet(string $frame): array { if (strlen($frame) 14) { return [null, 0]; // 连基本头都不够直接放弃 } $eth unpack(H12dst/H12src/netype, $frame); // 恰好消费前 14 字节 $offset 14; $type $eth[etype]; // 循环剥离 VLAN 标签一层或多层 while ($type 0x8100 || $type 0x88a8) { if (strlen($frame) $offset 4) { return [null, 0]; // 标签被截断 } $type unpack(n, substr($frame, $offset 2, 2))[1]; $offset 4; } return [[dst $eth[dst], src $eth[src], type $type], $offset]; }这个函数的价值在于把“偏移计算”收敛到一个地方。很多实现图省事直接在全局用substr($frame, 14, 20)取 IP 头一旦网络里出现 VLAN所有字段集体错位而且错得很隐蔽——版本号还能读出 4协议号却变成了随机值。把偏移交给一个函数返回后面每一层都用返回值而不是常量是这类解析器唯一能长期维护的写法。3.2 IP 首部与 IHL后面所有字段的位置由它决定IP 首部的第一个字节是双面字段高 4 位是版本号低 4 位是首部长度IHL单位是 32 位字。IHL 等于 5 表示 20 字节、没有选项等于 6 表示 24 字节、多了 4 字节选项。这意味着 IP 载荷的起点等于 IP 起点加上 IHL 乘以 4不是固定的“帧起点 34”。首部里还有几个字段直接决定后续解析策略。总长度字段在偏移 2、宽 2 字节、网络序它比帧长度可靠得多因为以太网最小帧长是 60 字节短包会在尾部补零用帧长度减首部长度会多出几个字节的垃圾数据。协议号在偏移 96 表示 TCP17 表示 UDP1 表示 ICMP。源和目的地址分别在偏移 12 和 16。分片是必须处理的边界情况。标志位里的 MF更多分片和 13 位片偏移单位 8 字节说明这个包可能只是完整报文的一段。最小可行的处理是只要 MF 置位或片偏移不为 0就把这个包标记为分片不参与应用层解析。否则你会把半截 JSON 丢给解析器得到一堆莫名其妙的语法错误而真正的元凶在传输层下面。IPv6 是另一套结构40 字节定长头后面跟着链式的扩展首部上层协议号在“下一个首部”字段里得一路跳过去才能找到传输层。如果只做 IPv4遇到 IPv6 流量要显式标记为未支持而不是让解析器走进错误的偏移。3.3 TCP data offset载荷起点不是固定的 54 字节TCP 首部的第 13 个字节从 TCP 起点算藏着数据偏移量占高 4 位单位同样是 32 位字。等于 5 就是 20 字节裸头大于 5 说明带了选项——MSS、窗口扩大因子、时间戳、SACK 允许这些在网络里非常常见。载荷起点等于 TCP 起点加上数据偏移乘以 4。?php // 假定 $ipOffset 已是 IPv4 首部起点且已确认协议号为 6 $vihl ord($frame[$ipOffset]); $ihl ($vihl 0x0f) * 4; // 首部长度字节 $total unpack(n, substr($frame, $ipOffset 2, 2))[1]; // IP 总长度 $proto ord($frame[$ipOffset 9]); $srcIp inet_ntop(substr($frame, $ipOffset 12, 4)); $dstIp inet_ntop(substr($frame, $ipOffset 16, 4)); $tcpOff $ipOffset $ihl; // 传输层起点 // 一次取 14 字节源端口、目的端口、序列号、确认号、标志位 $tcp unpack(nsport/ndport/Nseq/Nack/nflags/nwin, substr($frame, $tcpOff, 14)); $dataOff (($tcp[flags] 12) 0x0f) * 4; // 高 4 位单位 32 位字 $payload substr($frame, $tcpOff $dataOff, max(0, $total - $ihl - $dataOff));最后一行值得单独说明。载荷长度用的是$total - $ihl - $dataOff也就是 IP 总长度减去 IP 首部再减去 TCP 首部而不是用strlen($frame)去减。理由就是上一节说的以太网填充一个 40 字节的纯 ACK 包会被补到 60 字节用帧长度减出来会多出 8 到 10 个字节的零这些零一旦混进载荷应用层判断“这个段有没有数据”就会出错重组逻辑会把纯 ACK 当成携带数据的段序列号推进也跟着错。UDP 简单得多8 字节定长头长度字段在偏移 4载荷从第 9 个字节开始不需要算偏移量所以后文讨论重组时只针对 TCP。3.4 四元组归一化与序列号重组本文还有配套的精品资源点击获取