企业官网建设流程全解析

简介：jnetpcap 1.4.r1425-1 版本的完整源码包，面向需要在 Java 中调用 libpcap 完成网络封包捕获、协议解析、流量监控与安全分析的中高级开发者。它重点解决从源码构建 libjnetpcap.so 与 libjnetpcap-pcap100.so 时依赖版本不清、构建脚本难定位、cpptask.jar 兼容性不易判断等问题，也适合研究 JNI 封装、抓包底层实现或定制本地库的场景。压缩包共 1256 个文件，约 9.4MB，包含 285 个 java 源文件、62 个 C 头文件、27 个 cpp 实现、5 个 jar 构建依赖，以及 html 文档、class 产物、pcap/cap 抓包样例、properties 配置和少量 so 动态库，便于对照源码、示例与构建产物。已有 526 人学习。读者可从中获得完整工程目录、Ant 构建脚本和 cpptask 相关依赖线索，并借助样例抓包文件理解数据包解析流程，为排查 JDK 版本、JAVA_HOME 与 Ant 任务配置等常见编译障碍提供参照，包内 class 与 html 文档还可辅助核对 API 结构与示例组织，对网络监控工具开发、协议逆向与教学演示也有参考价值。

1. jnetpcap 源码包到底装在什么场景里：先分清源码包和成品 jar

手上有一份现成的 pcap 文件，业务侧说某个协议的解析偶尔会超时，让你复现。第一反应多半是把文件拖进抓包工具里点两下，人工看几屏。可真到要写自动化脚本、要在流水线里跑回归、要把解析结果灌进 Java 服务的时候，用图形界面点鼠标这条路就走不通了。jnetpcap 正是为这个场景存在的：它在 JNI 层把 libpcap 的能力搬进 JVM，让 Java 代码能枚举网卡、下发 BPF 过滤、逐包回调、按协议栈切分头部。这次拆的 jnetpcap-src-1.4.r1425-1.zip 是源码包，不是解压就能双击运行的成品，它的价值集中在三处：你能看清 JNI 边界在哪、能自己重编本地库匹配目标机器、能改协议绑定的解析逻辑。适合要在 Java 服务里做流量观测的后端、要给私有协议写用例的测试开发，以及被 native 库加载失败反复折腾过、想弄明白链路的人。源码包的门槛不在 Java，而在本地库那一段，后面几章会把这段拆开。

2. 从源码包到能跑起来：三段编译链路与一次冒烟验证

源码包最容易翻车的地方不是代码写错，而是「Java 编译过了、本地库没落地」，运行期才在System.loadLibrary那一行炸掉。所以顺序要反过来想：先确认本地库能不能被 JVM 找到，再谈抓包逻辑。这一章按「认目录 → 编 Java → 编 native → 冒烟」四步走，每一步都留一个可以自检的输出。

2.1 解压后先认三棵树：java、c、lib

不同批次的打包方式略有差异，目录名会变，但内容一定是三块：Java 源码树、C/JNI 源码树、预编译产物目录。别急着javac，先花两分钟把这三块对上号，后面所有命令都依赖这个判断。

判断预编译库能不能直接用，最快的一条命令是看它依赖什么：

# Linux 下看动态依赖，重点看 libpcap 是否解析成功、有没有 not found ldd lib/libjnetpcap.so # 看位数，输出里出现 elf64-x86-64 才是 64 位 file lib/libjnetpcap.so # 看 JNI 入口符号在不在，导出为空说明这个库不是给当前包用的 nm -D lib/libjnetpcap.so | grep -c "Java_org_jnetpcap"

三步的输出决定你走哪条路：ldd干净、位数和 JVM 一致、符号齐全，那就直接跳过 2.2 的 native 编译，只编 Java；只要有一步不对，就必须自己重编本地库，硬凑是凑不出来的。

2.2 Java 侧编译与本地库落地

Java 侧的编译本身没什么玄学，坑在于编码和依赖。老源码包里偶尔混着非 UTF-8 的注释，javac会在某一行莫名其妙报「非法字符」，加-encoding UTF-8基本能压住。

# 1. 收集源文件清单，避免命令行过长 mkdir -p out/classes out/jar find src/main/java -name "*.java" > sources.txt # 2. 编译，-encoding 必须显式给，否则默认平台编码会让中文注释报错 javac -encoding UTF-8 -source 8 -target 8 \ -d out/classes @sources.txt # 3. 打成 jar，注意把资源文件（如果有）一起塞进去 jar cf out/jar/jnetpcap.jar -C out/classes .

-source 8 -target 8不是随便写的。这份源码里大量使用匿名内部类实现回调接口，编译到高版本字节码在新一些的 JVM 上没问题，但如果你的运行环境还是 8，反向就不成立。我一般直接对齐运行环境的最低版本，省得后面为UnsupportedClassVersionError返工。

本地库重编的关键是 include 路径必须同时包含 JDK 的include和平台子目录，少一个就会在jni.h里报找不到jni_md.h：

# JAVA_HOME 必须是当前运行用的那个 JDK，不要用系统里另一个版本 gcc -O2 -fPIC -shared \ -I"$JAVA_HOME/include" \ -I"$JAVA_HOME/include/linux" \ -Isrc/main/c \ -o out/jar/libjnetpcap.so \ src/main/c/*.c \ -lpcap -lm

-fPIC -shared是生成可被 JVM 加载的动态库；-lpcap是必须的链接项，缺了会在加载时报 undefined symbol；-lm保险起见带上，C 实现里做校验和之类的运算会用到。Windows 侧思路一致，只是换成 MSVC 或 MinGW，并且要先把 pcap 的开发头文件和导入库装好——这一步在 Windows 上最容易卡住，因为运行时驱动和开发包是两个独立的东西，只装驱动是编不出来的。

库编出来之后，运行时用-Djava.library.path指过去，不要图省事往系统目录里拷：

java -Djava.library.path=./out/jar \ -cp "out/jar/jnetpcap.jar:out/classes" \ DevListSmokeTest

Windows 下 classpath 分隔符是;，java.library.path同样指向库所在目录。冒烟代码就是下面这段，它只做一件事：把网卡列表打出来。跑通它，说明 Java 层和 native 层的连接是完好的，后面所有问题都可以排除掉加载环节。

import org.jnetpcap.Pcap; import org.jnetpcap.PcapIf; import java.util.ArrayList; import java.util.List; public class DevListSmokeTest { public static void main(String[] args) { // errbuf 必须可写，C 侧的错误信息会回填到这里，传 null 会直接抛异常 StringBuilder errbuf = new StringBuilder(); List<PcapIf> devs = new ArrayList<PcapIf>(); // 返回 0 成功，非 0 失败；失败原因一定在 errbuf 里，别只看返回值 int rc = Pcap.findAllDevs(devs, errbuf); if (rc != 0) { System.err.println("findAllDevs failed: " + errbuf.toString()); return; } for (PcapIf dev : devs) { // getName() 是后面 openLive 要传的设备名，getDescription() 只用于人看 System.out.println(dev.getName() + " | " + dev.getDescription() + " | flags=" + dev.getFlags()); } } }

这段代码里值得注意的是errbuf的生命周期。它是 JNI 回填错误的唯一通道，每调用一个可能失败的 native 方法都要新建或者清空，重复使用会读到上一次的旧消息，排查时能把人带偏。

2.3 最小抓包回路：openLive 到回调的七个参数

冒烟通过之后，下一步是抓真包。最小回路只有三个对象：PcapHandle、PcapPacketHandler、PcapPacket。

import org.jnetpcap.Pcap; import org.jnetpcap.PcapHandle; import org.jnetpcap.packet.PcapPacket; import org.jnetpcap.packet.PcapPacketHandler; public class LiveSniff { public static void main(String[] args) throws Exception { String dev = args[0]; // 用冒烟程序打出来的设备名 StringBuilder errbuf = new StringBuilder(); int snaplen = 64 * 1024; // 抓全包，截断会让后续协议解析错位 int promisc = Pcap.MODE_PROMISCUOUS; // 混杂模式，交换机镜像口场景通常需要 int timeout = 10; // 毫秒，控制内核缓冲区多久往用户态回吐一次 PcapHandle handle = Pcap.openLive(dev, snaplen, promisc, timeout, errbuf); if (handle == null) { System.err.println("openLive failed: " + errbuf.toString()); return; // 失败原因八成是权限或设备名 } PcapPacketHandler<String> handler = new PcapPacketHandler<String>() { @Override public void nextPacket(PcapPacket packet, String user) { // caplen 是实际抓到的长度，wirelen 是线上真实长度，两者不等说明被 snaplen 截了 System.out.printf("caplen=%d wirelen=%d ts=%d%n", packet.getCaptureHeader().caplen(), packet.getCaptureHeader().wirelen(), packet.getCaptureHeader().timestampInMillis()); } }; try { handle.loop(20, handler, "demo"); // 抓满 20 个包返回 } finally { handle.close(); // 必须放在 finally，异常路径也要释放 } } }

七个参数里，真正会影响结果的是三个：snaplen决定单包上限，timeout决定回调的实时性，promisc决定你能看到不属于本机的流量。snaplen设小了，caplen小于wirelen，TCP 载荷被截掉一截，解析出来的内容永远是缺失的——这个坑很隐蔽，因为回调照常触发，只是数据不完整。timeout设太大，loop在低流量环境下会长时间不回调，看起来像「卡住了」。

loop的第二个参数是回调，第三个是透传给回调的上下文对象，用泛型声明的类型必须和传入实参一致，否则运行期要做类型转换，容易在回调里炸出ClassCastException。loop的返回值是实际处理的包数，正常结束和提前退出的返回值可能一样，别拿它当成功标志，要判断是否被中断，看有没有异常抛出。

3. 协议解析层：JProtocol 绑定、偏移计算与 BPF 过滤的三处细节

抓包只是把字节搬进 JVM，真正有价值的是把这些字节切成有名字的字段。jnetpcap 的解析模型是「扫描器 + 协议绑定」：JScanner从链路层开始，按注册好的JProtocol依次判断下一层是什么，命中就生成一个 header 对象挂到包上。理解这套模型，才能解释为什么有些包解析出来是空的、为什么自定义协议要手动算偏移。

3.1 扫描器怎么把字节流切成一摞 header

扫描的起点是链路层类型，DLT_EN10MB表示以太网，之后靠 EtherType 判断上一层是 IPv4、IPv6 还是 ARP，IPv4 里再靠 protocol 字段判断 TCP、UDP、ICMP。每一跳都由JProtocol的绑定逻辑决定，绑定失败就停在上一层，后面的 header 全部为空——这就是「抓到包但拿不到 TCP 端口」的根因。

import org.jnetpcap.packet.JProtocol; import org.jnetpcap.packet.PcapPacket; // 判断某个 header 是否存在，用 hasHeader 而不是直接取字段 if (packet.hasHeader(JProtocol.IP4_ID)) { // IP4 里的 TCP 才会被继续解析，非 TCP 的 IP 包这里返回 false if (packet.hasHeader(JProtocol.TCP_ID)) { int srcPort = packet.getHeader(new org.jnetpcap.protocol.tcp.Tcp()).source(); int dstPort = packet.getHeader(new org.jnetpcap.protocol.tcp.Tcp()).destination(); System.out.println(srcPort + " -> " + dstPort); } }

这里有个容易忽略的成本：getHeader(new Tcp())每次都要新建一个 header 对象，放在回调里就是每包一次分配。高频场景下常见做法是把 header 对象声明成 handler 的成员变量复用，第二次调用时只做绑定不做分配。另外，hasHeader的判断顺序要和协议栈顺序一致，先判 IP 再判 TCP，反过来在非 IP 流量上会白跑一遍。

3.2 自定义头的手工偏移解析与长度校验

私有协议没有现成的JProtocol，两条路：一是用注解式头定义注册新的协议，二是老老实实按偏移取字节。前者适合协议固定、字段多的场景，后者适合快速验证和临时脚本，我一般先用后者把字段对齐确认下来，再考虑要不要固化成协议类。

import org.jnetpcap.packet.PcapPacket; /** * 假设私有头紧跟在 UDP 载荷之后： * magic(2) + version(1) + flags(1) + bodyLen(2) + body */ private static void parseCustom(PcapPacket packet) { int payloadOffset = packet.getHeader(new org.jnetpcap.protocol.network.Ip4()).getOffset() + packet.getHeader(new org.jnetpcap.protocol.network.Ip4()).size(); // 仅示意 // getUShort 返回 0..65535 的无符号值，不要用 getShort，高位会被符号扩展 int magic = packet.getUShort(payloadOffset); if (magic != 0xA5C3) { return; // magic 不对直接放弃，避免误判 } int version = packet.getUByte(payloadOffset + 2); int flags = packet.getUByte(payloadOffset + 3); int bodyLen = packet.getUShort(payloadOffset + 4); // 长度必须做边界校验，否则越界读会拿到 subsequent 包的字节，且不报错 int caplen = packet.getCaptureHeader().caplen(); if (payloadOffset + 6 + bodyLen > caplen) { System.out.println("truncated: need=" + (6 + bodyLen) + " caplen=" + caplen); return; } byte[] body = new byte[bodyLen]; packet.getByteArray(payloadOffset + 6, body); System.out.println("ver=" + version + " flags=" + flags + " len=" + bodyLen); }

两个细节必须说清楚。第一，getUShort是无符号读取，用getShort读到大于 32767 的值会变成负数，端口号这类字段最容易中招。第二，bodyLen是从报文里读出来的，属于不可信输入，不做边界校验就会越界读取；jnetpcap 的缓冲区是按 caplen 分配的，越界读不会立刻抛异常，而是读到相邻包的残留数据，表现为「同一个包偶尔解析出不同的 body」，这种问题靠日志几乎查不出来。

提示：偏移计算一定要基于payloadOffset这种相对量，而不是硬编码的绝对位置，否则 VLAN 标签、IP 选项一出现，整体就错位了。

3.3 BPF 表达式：写在哪、怎么编译、为什么值得单独编译

过滤放在内核里做，比在 Java 回调里if判断高效得多——不匹配的包根本不会进用户态。setFilter是最省事的写法，接受一个 BPF 表达式字符串：

// 三个参数分别是表达式、是否优化、网络掩码 // netmask 用于判断广播/多播，不确定就传 0，传错不至于报错但可能过滤不准 int rc = handle.setFilter("tcp port 8080 and host 10.0.0.5", Pcap.BPF_OPTIMIZE, 0); if (rc != 0) { System.err.println("setFilter failed: " + handle.getErrbuf()); }

需要复用的场景，用compile把表达式编成PcapBpfProgram，再反复setFilter(program)，比每次解析字符串省事，也方便在启动时就把写错的表达式暴露出来。

表达式写错时，setFilter返回非 0，错误信息要自己去取，不会自动打印。这就是很多人「设了过滤但好像没生效」的原因——其实压根没设上去，后面的抓包逻辑照常运行，只是过滤器一直是空规则。

4. 吞吐与内存：三种 open 方式、缓冲区参数与丢包统计

单包处理跑通之后，压力会从两个方向来：一是流量大，回调跟不上，内核缓冲区满了一个包都拿不到；二是跑得久，直接内存越用越多。这两个问题都不是 Java 代码能独立解决的，得回到 native 层看参数。

4.1 openLive / openOffline / openDead 的边界

三种打开方式的语义差别很大，混用会得到「不报错但结果不对」的诡异现象。

openDead是这三者里最容易被忽略的。它不需要权限也不需要网卡，专门用来验证过滤表达式对不对——把表达式在openDead句柄上compile一遍，就能在启动阶段发现语法错误，不用等到线上抓包时才看见返回 -1。

openOffline有个隐藏限制：离线回放的包长受文件里保存的 snaplen 约束，文件在采集时就被截断过的话，回放时无论怎么重编本地库都补不回来。所以离线复现的第一步是把caplen和wirelen对一遍，用tshark -r xxx.pcap -q -z io,stat,0之类的工具确认有没有截断包，有的话这份文件只能做「有无」级别的验证，做不了载荷内容断言。

4.2 snaplen、timeout、buffer 三个参数怎么配

snaplen的取值不是越大越好，但也不要为了省内存往小里压。64KB 基本能覆盖绝大多数场景，包括带 VLAN 标签和 IP 选项的包；压到 1500 左右时，小包没问题，一旦遇上大包的 TCP 分段，载荷会被截断，解析出来是残的。我在做协议字段核对时一律给 64KB，宁可让句柄多吃点内存。

timeout在实时抓包里是「内核多久往用户态送一次」的上限，不是精确的定时器。设 1ms 回调很密，CPU 占用高；设 100ms 以上，低流量时回调很久才触发一次，用「等三秒没输出」判断程序挂了就会误判。

缓冲区大小这一项，取决于你用的小版本有没有把对应接口暴露在 Java 层：

// 常见做法：打开句柄后、开始 loop 之前设置 // 不同版本的入口不同，可能叫 setBufferSize，也可能要通过 Pcap 上的静态方法 // 原则只有一条：必须在 loop 之前设，抓包开始后再设边界不生效也不报错 handle.setBufferSize(8 * 1024 * 1024); // 8MB，经验值，可按吞吐线性放大

这条注释不好看，但这是血泪经验：参数在错误时机设置，某些实现会静默忽略，返回值还是 0，你看着像是设上了。验证方式是抓包过程中读一次统计，看drop有没有下降，而不是相信设置调用的返回值。

4.3 用 pcap_stats 定位丢包发生在哪一层

丢包有三种来源，混在一起看就永远查不清：网卡/驱动在收包时丢、内核缓冲区满了丢、你的回调处理太慢导致内核侧丢。pcap_stats能区分前两种的分界，虽然不精细，但足够定位方向。

import org.jnetpcap.PcapStat; // 建议放在 loop 旁边起一个守护线程定时采样，不要每包都调 PcapStat stat = new PcapStat(); if (handle.getStats(stat) == 0) { System.out.printf("recv=%d drop=%d ifdrop=%d%n", stat.getNumPacketsReceived(), // 内核侧收到的包 stat.getNumPacketsDropped(), // 内核缓冲满被丢的 stat.getNumPacketsDroppedByIf() // 网卡/驱动侧丢弃的 ); } else { System.out.println("getStats failed"); }

读法是这样的：recv增长而drop也增长，说明你的回调跟不上，要么减负（下推过滤、减少每包分配），要么加缓冲；ifdrop增长而drop为 0，问题在采集侧，跟 Java 代码没关系，去查镜像口带宽和网卡队列；两个都为零但业务侧说缺包，那就是过滤表达式写窄了，或者你抓的网卡根本不通这条路径。

统计接口本身有成本，每包调用会让吞吐掉一个数量级，定时采样就够了，五秒一次是比较稳妥的节奏。

5. 避坑排查：五类现场与对应处置

这段是按「我见过最多的顺序」排的，从加载失败到资源泄漏，越往后越难查。每一条都按现象、原因、解决三段走，现象写得具体一点，方便你直接对号入座。

5.1 UnsatisfiedLinkError：库名、路径与位数三件事

现象：java.lang.UnsatisfiedLinkError: no jnetpcap in java.library.path，或者加载成功了但调用第一个 native 方法时抛UnsatisfiedLinkError: xxx（带具体方法名）。

原因：两种情况完全不同。不带方法名的那种，是 JVM 在java.library.path里根本没找到文件——库名少写了lib前缀、后缀不对、目录没传进去，都会走到这里。带具体方法名的那种，是文件找到了但符号解析失败，通常是本地库依赖的libpcap没装，或者位数和 JVM 不匹配（32 位库配 64 位 JVM）。

解决：先file libjnetpcap.so确认位数，再ldd确认依赖，最后确认java.library.path指向的是同一份文件：

# 打印 JVM 实际在哪些目录找库 java -XshowSettings:properties -version 2>&1 | grep -A2 "java.library.path" # 确认当前 java 是几位 java -version 2>&1 | head -1

Windows 上还有一个独有现象：加载时报找不到依赖模块。那是本地库依赖的 pcap 运行时 DLL 不在PATH里，跟java.library.path是两套查找规则，得单独把运行时 DLL 的目录加进PATH。

5.2 openLive 返回 null：权限和设备名各占一半

现象：Pcap.openLive返回null，errbuf里是That device is not up或You don't have permission to capture on that device之类。

原因：设备名写错是最常见的，尤其是 Windows 上设备名是一串 GUID 风格的标识，跟你在系统里看到的网卡名称完全对不上，必须用findAllDevs打出来的那个名字。其次是权限，实时抓包需要提升的权限，普通用户跑必然失败。

解决：设备名一律从冒烟程序的输出里复制，别手抄。权限问题按平台处理，Linux 侧给可执行文件加抓包能力比直接用高权限账户跑要干净；容器里跑则要注意容器默认没有这项能力，需要显式放开。判断是不是权限问题，最快的办法是拿一个不需要权限的openOffline跑同一份代码，能跑通就说明代码没问题，纯粹是权限。

5.3 setFilter 返回 -1：表达式、掩码与设备能力

现象：setFilter返回非 0，或者返回 0 但过滤明显没生效。

原因：三种。表达式语法错，比如把and写成&&、端口写成字符串；掩码传了非法值，某些实现会因此直接拒绝；表达式用了设备不支持的复杂偏移，在openDead上能编过，在真实网卡上编不过。

解决：把表达式拆短逐个试，tcp能过就说明是协议名之后的语法有问题。启动阶段用openDead先compile一遍，把语法错误挡在程序入口。掩码不确定就传 0，别传一个想当然的网段值。另外记得取错误信息，setFilter失败不会自动打印：

if (handle.setFilter(bpf, Pcap.BPF_OPTIMIZE, 0) != 0) { // 这一步不做，你只会看到一个 -1，完全没有线索 System.err.println("filter rejected: " + bpf + " | " + handle.getErrbuf()); }

5.4 回调里抛异常：loop 静默提前结束

现象：loop(1000, handler)本该抓一千个包，结果几十个包之后就不再有输出，也没有报错。

原因：回调里的异常被 JNI 边界吞掉了，或者被转成了loop的非正常返回。回调里干的事越多越容易中招：解析字段越界、getHeader拿到空对象、字符串编码转换失败，都会让当前包的回调中断，而外层看不到任何堆栈。

解决：回调体里包一层 try-catch，把异常连同包的关键信息（时间戳、caplen、前 32 字节的十六进制）一起记下来，然后继续处理下一个包。宁可丢一个包，也不要让整个loop死掉。另外注意loop返回后要判断返回值是否等于预期数量，不等就说明中间有中断。

5.5 句柄与直接内存泄漏：close 的位置决定一切

现象：跑几小时后进程 RSS 一路涨，或者打开几千次后开始报「too many open files」。

原因：PcapHandle是 native 资源，不close就不会释放，垃圾回收管不到它。PcapPacket背后的JBuffer用的是直接内存，loop里每包新建对象，回收不及时就会顶到上限。更隐蔽的是异常路径：openLive成功、setFilter失败直接return，句柄就这么漏了。

解决：close一律放finally，从openLive返回的那一刻起就进入 try 块。回调里复用 header 对象和PcapPacket实例，别每包 new。跑长任务时定时读一次统计顺便看下堆外内存，涨得快就先怀疑复用没做到位。

注意：调试阶段可以把-XX:MaxDirectMemorySize调小，让泄漏早点暴露成OutOfMemoryError: Direct buffer memory，比等着 RSS 慢慢涨要主动得多。

6. 离线回放做回归：把一次抓包变成可重复执行的用例

实时抓包只能证明「现在有流量」，证明不了「解析逻辑对不对」。真正能沉淀下来的是离线回放：把一份有代表性的 pcap 文件放进代码库，每次改解析逻辑都跑一遍，断言输出和预期一致。这件事的门槛比想象中低，openOffline加几行断言就够了。

StringBuilder errbuf = new StringBuilder(); PcapHandle handle = Pcap.openOffline("fixtures/private-proto.pcap", errbuf); if (handle == null) { throw new IllegalStateException("open offline failed: " + errbuf); } final int[] parsed = {0}; try { // 第二个参数传 -1 表示读完整个文件；传正数表示读到第 N 个包为止 handle.loop(-1, new PcapPacketHandler<Void>() { @Override public void nextPacket(PcapPacket packet, Void user) { if (packet.hasHeader(JProtocol.UDP_ID)) { parsed[0]++; } } }); } finally { handle.close(); } // 断言数量，数量变了说明过滤或解析逻辑被改动影响到了 if (parsed[0] != 37) { throw new AssertionError("udp packets expected 37, actual " + parsed[0]); }

回放用例的价值在于「快照」两个字。同一份 pcap 文件，只要解析逻辑没变，输出就必须逐字节一致；一旦变了，要么是修 bug、要么是引入回归，两种情况都值得停下来看一眼。我在做这类用例时会固定三张表：

三张表里第三张最容易被跳过，也最容易在线上出问题。原因是截断包在正常流量里占比很低，人工看几屏根本遇不上，但它恰恰是偏移计算和边界校验的唯一压力来源。构造方式很简单：用snaplen故意设小一点采一份文件，或者从已有 pcap 里裁掉尾部字节。

时间戳也要留意。timestampInMillis()返回的是采集时刻，回放时会保留原始值，不要拿它和当前时间比较来做超时判断，否则回放用例会全军覆没。要判断处理耗时，自己用System.nanoTime()在回调前后打点。

从那以后我每次动协议解析代码，都强制先跑一遍离线回放再谈上线，哪怕只改了一个偏移常量——因为偏移错一位不会报错，只会静默解析出错误的字段值，靠人眼看日志是看不出来的。希望帮到你。

本文还有配套的精品资源，点击获取