Java抓包实战：jpcap设备枚举、BPF过滤与pcap落盘避坑指南

简介：面向Java开发者、网络安全初学者与协议分析爱好者的Jpcap入门资料包，围绕「如何在Java中完成网络数据包抓取与分析」这一问题展开。核心包含Jpcap 0.01.16开发文档与jpcap.jar实现包两部分：文档依次讲解安装配置、类路径与权限设置、API说明、实例代码以及常见错误处理与调试技巧；jar包则封装了JpcapCaptor、JpcapSender、Packet等类，支撑数据包捕获、基于BPF语法的过滤、协议解析与自定义数据包发送等操作。压缩包共112个文件，以106个html文档页面为主，配合2个jar包、样式表与索引等辅助文件，整体约351KB，体积轻巧，便于离线查阅API与随手引入工程。已有693人学习下载，适合希望快速跑通抓包示例、理解TCP/UDP/ICMP报文结构，或为网络监控与安全研究搭建原型的中级读者对照实践。

1. 为什么一个 jar 包能省下抓包环境的折腾：jpcap 的定位与适用边界

手上有一份 jpcap 使用文档和 jpcap.jar，想用 Java 直接抓包时，最省事的路径不是从零配 libpcap 再翻 API，而是先把设备枚举、过滤器、落盘这三步跑通。jpcap 是 Java 侧的抓包库，底层依赖 libpcap/WinPcap，能把链路层帧解析成 IP/TCP/UDP/ARP 对象，适合把抓包能力嵌进排查工具、协议解析小工具或教学 Demo。它不适合替代 Wireshark 做长时间全流量分析，也不适合高吞吐生产网关。适合会写 Java、需要程序化收包、愿意先装本地库的开发者。文档和 jar 包的价值在于把 API 和运行环境一次对齐，少走“代码能编译但本地库找不到”的弯路。抓包只在授权环境和自己的实验流量里做，这一点先立住，后面所有代码才有意义。

2. 把 jpcap 跑起来：本地库、设备枚举与第一个回环抓包

2.1 依赖对齐：JDK、jpcap.jar 和 libpcap/WinPcap 不是一回事

jpcap 的坑大多不是 Java 代码写错，而是三层依赖没有对齐。第一层是 JDK，负责跑 Java 代码；第二层是 jpcap.jar，提供JpcapCaptor、Packet这些 API；第三层是本地库，常见是 Windows 下的 WinPcap/Npcap 兼容驱动加 jpcap 的 DLL，Linux 下的 libpcap 加 jpcap 的.so。jar 包只负责编译期和运行期的 Java 类加载，真正去网卡收包的是本地库。很多人把 jar 丢进 classpath 就运行，结果报UnsatisfiedLinkError，本质是第三层没接上。

我一般先做一个最小检查：确认 JVM 位数和本地库位数一致，再把本地库目录显式传给java.library.path。Windows 下用分号分隔 classpath，Linux 下用冒号。下面两条命令只是示例，目录按你实际解压位置改，不要硬抄路径。

# Linux/macOS 风格：jar 和当前目录都在 classpath，本地库目录单独指定 java -Djava.library.path=./lib -cp "jpcap.jar:." DeviceListDemo # Windows 风格：classpath 分隔符是分号 java -Djava.library.path=.\lib -cp "jpcap.jar;." DeviceListDemo

参数说明：-Djava.library.path告诉 JVM 去哪里找 JNI 本地库，不是找 jar；-cp里的jpcap.jar是 Java API，.是当前目录，方便加载你自己编译的 class。如果本地库放在系统 PATH 里，也可以不传这个参数，但调试阶段显式指定更容易定位问题。另一个常见误区是把 DLL 放进 jar 内部，JNI 默认不会从 jar 里解压加载，除非你自己写解压逻辑，所以别在这上面绕。

2.2 用 JpcapCaptor.getDeviceList() 确认网卡和链路类型

设备枚举是 jpcap 的第一道门槛。JpcapCaptor.getDeviceList()返回NetworkInterface[]，每个元素包含网卡名、描述、地址列表和链路层类型。链路类型很关键：以太网、回环、无线网卡的链路头不一样，后面拆包时不能默认所有包都是以太网。先把设备列表打出来，确认你要抓的是哪一块网卡，比一上来就写过滤器靠谱得多。

import jpcap.JpcapCaptor; import jpcap.NetworkInterface; import jpcap.NetworkInterfaceAddress; public class DeviceListDemo { public static void main(String[] args) throws Exception { NetworkInterface[] devices = JpcapCaptor.getDeviceList(); if (devices == null || devices.length == 0) { System.out.println("没有枚举到网卡：先查本地库、驱动和抓包权限"); return; } for (int i = 0; i < devices.length; i++) { NetworkInterface dev = devices[i]; System.out.println("[" + i + "] " + dev.name + " | " + dev.description); System.out.println(" datalink_type=" + dev.datalink_type + " datalink=" + dev.datalink_description); if (dev.addresses != null) { for (NetworkInterfaceAddress addr : dev.addresses) { System.out.println(" ip=" + addr.address + " mask=" + addr.subnet + " broadcast=" + addr.broadcast); } } } } }

这段代码不抓包，只做枚举，所以不需要管理员权限也能先跑一部分环境检查。getDeviceList()是静态方法，返回的是当前系统能识别的链路层设备；datalink_type用来判断链路类型，常见以太网是DLT_EN10MB，回环设备不一定是这个值；addresses可能为null，不要直接遍历。设备描述在不同系统上差异很大，调试时以name和 IP 为准，不要靠描述猜。若列表为空，先别怀疑代码，去看 4.1 和 4.2 的排查顺序。

2.3 最小可运行的实时抓包循环与参数含义

设备列表能打出来之后，打开设备只需要四个参数：设备对象、抓取长度、是否混杂模式、读超时。openDevice返回JpcapCaptor，之后用setFilter下 BPF 过滤器，再用loopPacket进入回调。回调里不要做重操作，先打印五元组和 payload 长度，确认链路通了再谈业务。

import jpcap.JpcapCaptor; import jpcap.NetworkInterface; import jpcap.PacketReceiver; import jpcap.packet.Packet; import jpcap.packet.TCPPacket; public class LiveCaptureDemo { public static void main(String[] args) throws Exception { NetworkInterface[] devices = JpcapCaptor.getDeviceList(); if (devices == null || devices.length == 0) { throw new IllegalStateException("没有可用网卡"); } // 先打印设备列表再替换下标，不要硬编码到生产代码里 NetworkInterface dev = devices[0]; int snaplen = 65535; // 抓完整帧；只想看头可改 96 boolean promisc = false; // 本机调试先关闭混杂模式 int timeoutMs = 50; // 读超时，影响 getPacket 的返回节奏 JpcapCaptor captor = JpcapCaptor.openDevice(dev, snaplen, promisc, timeoutMs); // 只抓 8080 端口 TCP；先确认有流量再收窄条件 captor.setFilter("tcp port 8080", true); captor.loopPacket(-1, new PacketReceiver() { @Override public void receivePacket(Packet packet) { if (packet instanceof TCPPacket) { TCPPacket tcp = (TCPPacket) packet; int payloadLen = tcp.data == null ? 0 : tcp.data.length; System.out.println(tcp.src_ip + ":" + tcp.src_port + " -> " + tcp.dst_ip + ":" + tcp.dst_port + " payload=" + payloadLen); } } }); } }

参数说明：snaplen是每个包最多抓多少字节，65535 表示尽量完整，96 只抓常见头部，能减少拷贝；promisc为true时网卡进入混杂模式，共享网络里可能看到非本机目的 MAC 的帧，实验环境先设false；timeoutMs是底层读超时，太小会增加系统调用频率，太大在停止抓包时响应变慢；loopPacket(-1, receiver)里的-1表示一直循环，回调收到的是已经过过滤器的包。抓包需要相应权限，Windows 上通常要管理员运行，Linux 上要用具备抓包权限的账户或能力配置；没有权限时常见表现不是抛异常，而是设备列表少、打开失败或收不到包。

2.4 抓包结果落盘：JpcapWriter 生成 pcap 文件

实时打印适合确认链路，真正做分析时我习惯先落盘，再用 Wireshark 打开比对。JpcapWriter.openDumpFile(captor, path)会写 pcap 全局头，writePacket(packet)写每条记录，最后必须close()刷盘。落盘路径用英文绝对路径，避免中文目录和权限问题；文件不要被 Wireshark 同时占用，否则 Windows 上容易出现写入失败或 0 字节文件。

import jpcap.JpcapCaptor; import jpcap.JpcapWriter; import jpcap.NetworkInterface; import jpcap.packet.Packet; public class DumpPcapDemo { public static void main(String[] args) throws Exception { NetworkInterface dev = JpcapCaptor.getDeviceList()[0]; JpcapCaptor captor = JpcapCaptor.openDevice(dev, 65535, false, 50); JpcapWriter writer = JpcapWriter.openDumpFile(captor, "capture-demo.pcap"); try { for (int i = 0; i < 200; i++) { Packet packet = captor.getPacket(); if (packet == null) { continue; // 超时返回 null，不代表没有包，继续等 } writer.writePacket(packet); } } finally { writer.close(); captor.close(); } } }

这里的循环 200 次不等于抓到 200 个包：getPacket()在超时后会返回null，所以要用continue继续等，而不是break。JpcapWriter依赖已打开的captor写文件头，因此openDumpFile要在openDevice之后调用。close()放在finally里，避免异常时留下半截 pcap。验证方法很简单：用 Wireshark 打开这个文件，看包数量和协议分布是否和预期一致；如果文件能打开但包数为 0，先查过滤器和网卡选择，而不是查写文件逻辑。

3. 拆包不是 toString：从 Packet 到 TCP/UDP/ARP 的字段读取

3.1 用 instanceof 分派协议，避免强转翻车

jpcap 返回的Packet是基类，真正有端口号的是TCPPacket、UDPPacket，ARP 是ARPPacket。很多人直接(TCPPacket) packet强转，遇到 UDP 或 ARP 就抛ClassCastException。正确顺序是先判断具体子类，再落到IPPacket，因为TCPPacket和UDPPacket都继承自 IP 层。回调里做协议分派时，先子类后父类，别反过来。

import jpcap.packet.*; public class PacketDispatchDemo { public static void handle(Packet packet) { if (packet instanceof TCPPacket) { TCPPacket tcp = (TCPPacket) packet; int payloadLen = tcp.data == null ? 0 : tcp.data.length; System.out.printf("TCP %s:%d -> %s:%d payload=%d%n", tcp.src_ip, tcp.src_port, tcp.dst_ip, tcp.dst_port, payloadLen); } else if (packet instanceof UDPPacket) { UDPPacket udp = (UDPPacket) packet; int payloadLen = udp.data == null ? 0 : udp.data.length; System.out.printf("UDP %s:%d -> %s:%d payload=%d%n", udp.src_ip, udp.src_port, udp.dst_ip, udp.dst_port, payloadLen); } else if (packet instanceof ARPPacket) { ARPPacket arp = (ARPPacket) packet; System.out.println("ARP " + arp.sender_protoaddr + " -> " + arp.target_protoaddr); } else if (packet instanceof IPPacket) { IPPacket ip = (IPPacket) packet; System.out.println("IP protocol=" + ip.protocol + " " + ip.src_ip + " -> " + ip.dst_ip); } } }

分派顺序不能乱：TCPPacket也是IPPacket，如果把IPPacket判断放在最前面，TCP 包会被当成普通 IP 包，端口号就丢了。data可能为null，尤其是只抓头部或某些控制包，先判空再取长度。ARP 包里sender_protoaddr和target_protoaddr是协议地址，不是 MAC；MAC 字段在链路层，需要另外读。这个分派函数可以放在回调里，但只做小样本打印，别把完整 payload 转成字符串塞日志，大包会拖慢回调。

3.2 读 IP 头、TCP 头与 payload 的边界处理

拆包时最常被忽略的是“payload 不是文本”。tcp.data是字节数组，可能是二进制协议、TLS 记录、图片分片，直接new String(data)会得到乱码，还会掩盖真实长度。我的习惯是先看 IP 层字段，再看 TCP 标志位，最后只在明确知道协议时解析 payload。IP 分片在 jpcap 这一层不一定自动重组，所以你不能假设一个TCPPacket.data就是完整应用层消息；做协议解析时要把“单包 payload”和“应用层消息”分开。

读 payload 的代码不要写成一行System.out.println(new String(tcp.data))。更稳的做法是先判空、限制打印长度、保留十六进制视图：

byte[] payload = tcp.data; if (payload != null && payload.length > 0) { int limit = Math.min(payload.length, 64); StringBuilder hex = new StringBuilder(); for (int i = 0; i < limit; i++) { hex.append(String.format("%02x", payload[i])); } System.out.println("payloadLen=" + payload.length + " head=" + hex); }

参数说明：limit限制打印长度，避免大包刷屏；%02x输出十六进制，不依赖字符编码；payload.length是当前包负载长度，不是应用层消息总长度。如果你要解析 HTTP，先确认端口和起始行，再考虑跨包拼接；如果你要解析私有二进制协议，先定长度字段和字节序，别靠猜。

3.3 用过滤器减少无效包：BPF 表达式在 setFilter 中的写法

jpcap 的过滤器是 BPF 语法，setFilter(condition, optimize)在底层编译，能在内核或驱动层减少无效包进入用户态。实时代码里先openDevice，再setFilter，最后loopPacket；顺序反了过滤器可能不生效。optimize传true让底层做编译优化，复杂表达式编译失败时会抛IOException，所以不要把它放在没有异常处理的地方。下面几个表达式够覆盖大部分调试场景。

try { boolean ok = captor.setFilter("tcp port 8080 and not host 192.168.1.1", true); if (!ok) { throw new IllegalStateException("过滤器未生效"); } } catch (IOException e) { // 先退回简单表达式，再逐段加条件定位语法问题 captor.setFilter("tcp", true); e.printStackTrace(); }

这段逻辑的重点不是“捕获异常就完事”，而是降级：复杂表达式失败时先退回tcp，确认抓包链路通，再把条件一段一段加回去。setFilter返回布尔值，不要只看有没有异常；返回false时说明过滤器没有按预期安装。另一个坑是过滤器写得太窄，导致loopPacket看起来“卡死”，其实是根本没有匹配包，先去掉过滤器用ping制造流量验证。

3.4 离线 pcap 回放：openFile 与循环读取

jpcap 不只能实时抓，还能打开 pcap 文件做离线回放。JpcapCaptor.openFile(path)返回 captor，之后可以setFilter再getPacket()循环读取，读到null表示文件结束。离线回放适合做回归测试：同一份 pcap，改过滤器、改解析逻辑，不用反复抓流量。注意离线模式下getPacket()的null是 EOF，不是超时，所以不要用实时抓包的continue逻辑。

import jpcap.JpcapCaptor; import jpcap.packet.Packet; public class OfflineDemo { public static void main(String[] args) throws Exception { JpcapCaptor captor = JpcapCaptor.openFile("capture-demo.pcap"); try { captor.setFilter("tcp", true); Packet p; int count = 0; while ((p = captor.getPacket()) != null) { count++; // 这里只计数，真实解析放到独立方法里，避免循环里做大对象 } System.out.println("matched=" + count); } finally { captor.close(); } } }

参数说明：openFile的路径是 pcap 文件路径，不是网卡名；setFilter在离线模式下同样生效，但过滤结果依赖 pcap 里的链路类型；getPacket()每次返回一个包，文件大时不要一次性读进内存。离线回放还有一个好处：可以拿 Wireshark 的过滤结果做对照。Wireshark 里过滤tcp.port == 8080，jpcap 里用tcp port 8080，两边计数应当接近；差太多时先查链路类型和 snaplen，再查过滤器语法。

4. 避坑与排查：jpcap 在 Windows/Linux 上最容易翻车的五个点

4.1 现象：UnsatisfiedLinkError，找不到 jpcap 本地库

现象很直接：代码编译通过，一运行就报java.lang.UnsatisfiedLinkError: no jpcap in java.library.path，或者提示找不到某个.dll/.so。原因通常不是 jar 没加，而是 JNI 本地库没有加载：java.library.path指向的目录里没有对应库，或者 JVM 位数和本地库位数不一致，32 位 JVM 加载 64 位库就会失败。Windows 上还可能是 WinPcap/Npcap 没装或兼容层没启用，Linux 上是 libpcap 运行库缺失。

解决顺序我一般固定成三步。第一步打印System.getProperty("java.library.path")，确认目录是不是你放库的目录；第二步确认本地库和 JVM 同为 32 位或 64 位；第三步用-Djava.library.path=...显式指定，而不是依赖系统 PATH。Windows 上安装抓包驱动时勾选兼容模式，Linux 上确认 libpcap 运行库存在。不要只把 DLL 放到 jar 同级目录就以为能加载，JNI 不会自动从 jar 旁边找。

public class LibPathCheck { public static void main(String[] args) { System.out.println("java.library.path=" + System.getProperty("java.library.path")); System.out.println("os.arch=" + System.getProperty("os.arch")); System.out.println("sun.arch.data.model=" + System.getProperty("sun.arch.data.model")); } }

这段检查代码不依赖 jpcap，可以先跑，把路径和位数打出来再排查。os.arch和sun.arch.data.model能帮你判断是不是位数不匹配。若路径里有中文或空格，调试阶段先换英文短路径，避免底层加载器解析异常。

4.2 现象：getDeviceList 返回空或只有回环

现象是JpcapCaptor.getDeviceList()返回空数组，或者只看到回环设备。原因有三种常见情况：当前账户没有抓包权限；Windows 上抓包驱动服务没启动或安装时没启用兼容层；Linux 上普通用户没有CAP_NET_RAW能力。设备列表为空时不要先改代码，先确认运行权限和驱动状态。另一个隐蔽原因是本地库加载了，但底层驱动版本和当前系统不匹配，表现也是枚举不到物理网卡。

解决方法是分层验证：先跑 2.2 的设备枚举，看有没有任何设备；再用系统自带工具确认网卡存在；然后提升权限重跑。Windows 上用管理员终端跑一次，Linux 上换成具备抓包权限的账户或配置能力。若只有回环，说明物理网卡没有被底层抓到，重点查驱动和权限，而不是查过滤器。设备列表里datalink_type也要看，回环和以太网的链路头不同，后续拆包不能套同一套偏移。

4.3 现象：loopPacket 卡死、收不到包

现象是程序进入loopPacket后没有任何输出，看起来像卡死。原因通常不是loopPacket本身，而是过滤器太窄、网卡选错、promisc不符合场景，或者根本没有流量经过选中的设备。比如你选了回环设备，却去访问外部地址；或者过滤器写了tcp port 8080，但服务实际跑在 9090。还有一种情况是回调里抛了异常被吞掉，循环还在，但你看不到结果。

排查时先做减法：去掉setFilter，换成tcp or udp or arp，用ping或访问本机服务制造流量；打印每次回调的包计数，确认回调有没有被调用；确认设备下标对应的是不是正在用的网卡。timeoutMs不要设得过大，调试阶段 50ms 到 100ms 更容易观察停止行为。回调里的try-catch不要把异常完全吞掉，至少打印一次堆栈，否则就是黑匣子。

4.4 现象：过滤器语法报错或过滤不生效

现象是setFilter抛IOException，或者不报错但过滤结果明显不对。原因包括 BPF 语法写错、optimize=true对复杂表达式编译失败、在loopPacket之后才设置过滤器，以及把port 8080误当成只抓 TCP。port 8080会同时匹配 TCP 和 UDP 的 8080 端口，想只抓 TCP 要写tcp port 8080。host表达式是双向的，别以为只匹配目的地址。

解决方法是逐段加条件：先tcp，再tcp port 8080，再tcp port 8080 and host 192.168.1.10，每加一段看计数。setFilter放在openDevice之后、loopPacket之前。复杂表达式失败时退回简单表达式，不要在一个长字符串里猜哪一段错了。离线回放时也要验证过滤器，因为 pcap 的链路类型可能影响过滤结果。

4.5 现象：中文路径/权限导致写出 pcap 失败

现象是JpcapWriter.openDumpFile抛异常，或者文件生成了但大小为 0，Wireshark 打不开。原因常见于目录不可写、路径含中文或特殊字符、文件被其他程序占用，以及异常时没有调用close()导致文件尾没刷盘。Windows 上 Wireshark 正打开同一个文件时，写入会失败；Linux 上目录权限不足也会失败。还有一种情况是openDumpFile成功，但后面writePacket抛异常，文件只写了头。

解决方法是使用英文绝对路径、确保目录可写、用try-finally保证close()，并在写入完成后检查文件大小是否大于全局头长度。调试阶段可以先写临时文件，成功后再改名。不要把JpcapWriter的close()只放在正常流程末尾，异常路径也要关。若文件能被 Wireshark 打开但包数不对，回到 2.4 检查getPacket()的null处理，不要用break提前结束。

5. 把抓包做进工具：线程模型、性能参数与 pcap 文件后处理

5.1 抓包线程与业务线程分离：用 BlockingQueue 传递 Packet 摘要

jpcap 的回调运行在抓包线程里，回调里做数据库写入、HTTP 请求、大量日志打印，都会拖慢收包，严重时内核缓冲区满就丢包。我的做法是回调里只做字段提取，拼一个轻量摘要对象，丢进ArrayBlockingQueue，再由独立消费线程做聚合和落库。队列满时选择丢弃摘要而不是阻塞抓包线程，因为抓包工具首先得保证“抓得到”，业务处理可以降级。这个模型不是 jpcap 官方强制的，但在实际工具里比在回调里写业务稳得多。

import jpcap.JpcapCaptor; import jpcap.PacketReceiver; import jpcap.packet.Packet; import jpcap.packet.TCPPacket; import java.util.concurrent.ArrayBlockingQueue; import java.util.concurrent.BlockingQueue; public class CapturePipelineDemo { static class Summary { final String flow; final int payloadLen; Summary(String flow, int payloadLen) { this.flow = flow; this.payloadLen = payloadLen; } } public static void main(String[] args) throws Exception { BlockingQueue<Summary> queue = new ArrayBlockingQueue<>(4096); JpcapCaptor captor = JpcapCaptor.openDevice( JpcapCaptor.getDeviceList()[0], 65535, false, 50); captor.setFilter("tcp", true); Thread consumer = new Thread(() -> { try { while (true) { Summary s = queue.take(); // 真实场景这里做批量聚合，别在回调里做 if (s.payloadLen > 0) { System.out.println(s.flow + " payload=" + s.payloadLen); } } } catch (InterruptedException e) { Thread.currentThread().interrupt(); } }); consumer.setDaemon(true); consumer.start(); captor.loopPacket(-1, new PacketReceiver() { @Override public void receivePacket(Packet packet) { if (!(packet instanceof TCPPacket)) { return; } TCPPacket tcp = (TCPPacket) packet; String flow = tcp.src_ip + ":" + tcp.src_port + "->" + tcp.dst_ip + ":" + tcp.dst_port; int len = tcp.data == null ? 0 : tcp.data.length; if (!queue.offer(new Summary(flow, len))) { // 队列满时丢摘要，不阻塞抓包线程 } } }); } }

参数说明：队列容量 4096 是经验值，太小容易丢摘要，太大内存上涨；offer不阻塞，适合抓包线程；消费线程设成守护线程，主线程结束后不会卡住 JVM。真实工具里可以把Summary换成更小的结构，只保留五元组、时间戳和长度，不要在队列里传完整Packet，否则内存压力会变大。回调里只做instanceof和字段读取，不做字符串拼接大对象，这是降低丢包的关键。

5.2 snaplen、promisc、timeout 怎么设：三个参数的经验值

这三个参数没有万能值，但可以按场景定。snaplen决定每个包抓多少字节：调试协议头用 96 到 128 就够，做完整 payload 分析用 65535，但拷贝量更大。promisc在共享网络或镜像口场景可能需要开，本机调试先关，避免收进来一堆不属于当前主机的帧。timeoutMs是读超时，实时抓包调试 50ms 到 100ms 比较跟手，长期运行可以放到 100ms 到 500ms，减少空转。不要把timeoutMs当成抓包间隔，它不是采样周期。

这些值要结合机器和流量调。判断是否需要调大snaplen，看你的解析是否依赖完整 payload；判断是否丢包，不要只看回调计数，要和发送端计数或 Wireshark 落盘结果对比。promisc打开后如果看到大量陌生 MAC，先确认是不是镜像口或共享网络，别把正常现象当异常。

5.3 用 Wireshark 做二次校验：pcap 落盘后的比对方法

jpcap 抓到的包和 Wireshark 抓到的包不总是一模一样，原因可能是抓包点不同、过滤器不同、snaplen 不同。落盘后做二次校验是最省时间的办法：先在 jpcap 里抓一小段，落成 pcap，用 Wireshark 打开看协议分布；再用相同过滤器在 Wireshark 里抓同一时间段，比较包数和五元组。不要一上来就抓几个小时，先用 ping 或本机 HTTP 请求做 10 秒样本。Linux 上也可以用tcpdump -nr做快速计数，但最终以 pcap 文件里的记录为准。

# 只读 pcap，统计 icmp 包数量，用于和 jpcap 的计数对照 tcpdump -nr capture-demo.pcap icmp # 统计 tcp 8080 流量，注意过滤表达式和 jpcap 的写法保持语义一致 tcpdump -nr capture-demo.pcap 'tcp port 8080'

命令里的-n禁止域名解析，-r读文件，过滤表达式和 jpcap 的 BPF 语义接近但不完全相同。对照时先看总数，再看时间戳范围，最后看具体五元组。若 jpcap 计数明显少，优先查回调是否阻塞、队列是否丢摘要、snaplen 是否截断；若 jpcap 计数多，查过滤器是否没生效或网卡选错。pcap 文件是黑匣子，比对是后悔药，抓完先落盘再分析，比在回调里猜靠谱。

5.4 常见误用：在回调里做重 IO 导致丢包

最典型的翻车场景是回调里直接写数据库或调用远程接口，抓包刚开始正常，流量一大就开始丢包，但程序不报错，只是计数对不上。原因是回调阻塞导致底层缓冲区堆积，满了之后新包被丢弃。jpcap 的公开 API 里没有直接调大内核缓冲的统一入口，所以常见做法是把回调做薄：只提取字段、入队、计数，重 IO 放到独立线程批量做。另一个误用是在回调里打印完整 payload，日志 IO 同样会拖慢抓包，调试时也要限制长度。

判断是不是回调阻塞，可以做一个简单实验：回调里只计数，不打印、不入库，跑同一段流量，看计数是否接近 Wireshark。如果只计数正常，加了业务就丢，问题就在业务处理。解决时不要简单把队列调得无限大，内存会涨；用有界队列加丢弃策略，或者按流量峰值估算容量。抓包工具的第一目标是稳定收包，第二目标才是业务处理，这个顺序不能反。

6. 从能跑到好用：jpcap 的进阶技巧与验证清单

6.1 用前后计数验证过滤器是否真的生效

过滤器写完不要只看“程序没报错”，要做前后计数。打开过滤器前抓 10 秒，记录回调总数；设置过滤器后再抓 10 秒，记录匹配数；同时用 Wireshark 或tcpdump对同一时间段做对照。如果两个计数差一个数量级，先查表达式语义，而不是查 jpcap。比如tcp port 8080和port 8080的差异，在 DNS 或自定义 UDP 服务上会非常明显。这个验证动作很小，但能省掉大量“为什么抓不到包”的争论。

import java.util.concurrent.atomic.AtomicLong; public class FilterCounter { private final AtomicLong total = new AtomicLong(); private final AtomicLong matched = new AtomicLong(); public void onPacket(boolean passedFilter) { total.incrementAndGet(); if (passedFilter) { matched.incrementAndGet(); } } public void print() { System.out.println("total=" + total.get() + " matched=" + matched.get()); } }

这段计数器本身不依赖 jpcap，放在回调里只做原子自增，开销很小。total可以用来对照底层收到的包，matched用来对照过滤器命中数。真实使用时不要在每个包上打印，定时打印一次即可。过滤器验证完再回到业务解析，顺序不要反。

6.2 落盘文件的完整性检查表

pcap 文件写完先做完整性检查，比直接丢给分析程序稳。检查项不用多，但每次都要走：文件是否存在且大小大于全局头，Wireshark 能否打开，包数是否和回调计数接近，时间戳是否单调，最后一条记录是否完整。下面这张表是我常用的检查顺序，异常时按行往下排。

这张表不是形式主义，尤其是“最后一条包完整”这一项，能抓出很多close()没走到的异常路径。pcap 是二进制格式，半截文件有时也能打开，但解析到尾部会出问题，提前检查比事后猜省事。

6.3 一个具体技巧：给回调加旁路开关，不停止抓包也能暂停解析

调试时经常需要临时停掉解析，但不想停止抓包。直接captor.close()再重开，会丢一段流量，也麻烦。我的做法是在回调里加一个AtomicBoolean旁路开关：开关关闭时只计数不解析，抓包循环继续跑；开关打开时恢复解析。这样既能保留抓包连续性，又能把有问题的解析逻辑摘出去。开关本身不改变过滤器，所以底层收包行为不变。

import java.util.concurrent.atomic.AtomicBoolean; public class ParseSwitch { private final AtomicBoolean parseEnabled = new AtomicBoolean(true); public void toggle() { parseEnabled.set(!parseEnabled.get()); } public void onPacket(byte[] payload) { if (!parseEnabled.get()) { return; // 只跳过解析，不跳过抓包 } // 这里放解析逻辑，异常时先把开关关掉 if (payload == null || payload.length == 0) { return; } // parse(payload); } }

AtomicBoolean保证多线程可见性，toggle()可以从控制台线程调用，回调线程只读。注意旁路开关只影响解析，不影响loopPacket，所以抓包计数仍然增长。解析逻辑抛异常时，先关开关、保留现场，再回到 6.1 的计数验证，不要直接改过滤器。

从那以后我每次接 jpcap 都先打印设备列表和datalink_type，再写过滤器，落盘后一定用 Wireshark 对一遍包数；这套顺序看着笨，但比在回调里猜问题快得多。希望帮到你。

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