简介：面向C#开发者和网络调试人员，这是一款可直接运行的网络数据包抓取工具，支持监听指定IP、端口并解析IP、TCP、UDP协议头部与字段信息。压缩包共82个文件，体积约1.12MB，以C#源文件（.cs）为主，搭配可执行程序（.exe）、图标与PNG界面素材、资源文件（.resx/.resources）以及项目工程文件，打开解决方案即可编译运行，适合学习套接字编程与TCP/IP协议栈。工具内置过滤选项、嗅探服务与主界面模块，能显示时间戳、源/目标地址、协议类型、端口号及数据大小，代码逻辑清晰，便于二次扩展。通过阅读源码，可掌握Socket接收网络数据、解析TCP标志位/序列号/窗口大小及UDP字段的方法，理解数据包从网卡到应用层的流转过程。已有734人学习下载，对想深入理解网络通信底层机制、提升抓包与分析能力的开发者而言，这是一份贴近实战的参考项目。
1. 为什么 C# 开发者总在抓包这件事上卡住
做上位机、做网络协议对接的 C# 工程师，迟早会遇到一个需求：现场的设备说“数据发了”，你这边没收到，两边吵起来，最后谁说了算？总不能靠猜。抓包是唯一能一锤定音的方案。C# 里抓取 IP、TCP、UDP 等网络数据包，听起来像是一个“装个库、写两行代码”的活儿，但真正动手会发现：设备列表是乱码的、抓到的包只有一个帧头、过滤条件写错了直接崩、UDP 包分片了拼不回来。这套东西不是调一个 API 那么简单，它牵扯到网卡工作模式、链路层到应用层的解析、内核缓冲区大小、BPF 过滤器的语义，还有 Windows 上绕不开的权限问题。
这篇文章要讲的，就是用 C# 在 Windows 环境下抓取并解析 IP、TCP、UDP 数据包的完整落地路径：选哪个库、最小代码怎么跑通、协议头怎么解析、哪些参数不改必翻车。适合的场景是 C# 上位机开发、工业以太网调试（比如抓 modbus tcp 报文）、UDP 分包组包问题的排查，以及任何人想搞清楚“网络包到底长什么样”的动手需求。读完你会得到一套能直接抄的抓包器骨架，以及一份用血泪经验换来的避坑清单。
2. 抓包到底在抓什么：先搞懂网卡、链路层和 BPF 过滤
2.1 普通 Socket 收不到的东西，才是抓包的目标
很多第一次做抓包的人会问：我开一个 TcpListener 不就收到了吗？为什么还要单独写抓包程序？这里有个根本差别：Socket 接收数据的前提是“这个包的目的地址和端口正好匹配本地”，而抓包要的是“不管发给谁、只要从网卡上经过，全部拿下来”。前者是协议栈的接收队列，后者是网卡的原始数据流。
抓包的本质是把网卡切到混杂模式（Promiscuous Mode），让网卡把物理链路上经过的每一个帧都交给上层。普通的以太网帧在链路层有个 14 字节的头，包含目标 MAC（6 字节）、源 MAC（6 字节）、上层协议类型（2 字节，0x0800 是 IPv4，0x86DD 是 IPv6，0x0806 是 ARP）。C# 里做抓包，大部分库拿到的就是从这个位置开始的原始字节。换句话说，你看到的第一个字节不是 IP 头，而是 MAC 地址。这一点新手最容易懵：代码里明明写了“取第 13 字节判断协议类型”，结果抓到的和预想不一致，多半是把链路层头忘了。
链路层头后面才是三层头。IPv4 头的固定部分是 20 字节，里面有版本、首部长度、总长度、标识符、分片偏移、TTL、协议号（6 是 TCP，17 是 UDP）、源地址和目的地址。TCP 头在 IPv4 头之后，固定部分 20 字节，包含源端口、目的端口、序号、确认号、标志位和窗口大小。UDP 头只有 8 字节：源端口、目的端口、长度、校验和。C# 抓包程序的活，说白了就是拿着一块 byte[]，按这些偏移量把字段切出来。
2.2 选型：为什么我选 SharpPcap 而不是自己 P/Invoke
C# 做抓包，市面上能做底层抓包的方案其实不多。最主流的是 SharpPcap，它是 WinPcap / Npcap 的 C# 封装，项目从 2004 年活到现在，API 风格稳定，网上能找到大量参考代码。它支持实时抓包和离线读取 .pcap 文件，也支持把抓到的包写成文件。另一个方案是自己用 P/Invoke 调 Npcap 的 C 接口 wpcap.dll，性能上确实更可控，但代价是要自己管理设备句柄、内存释放、回调函数的线程上下文，维护成本极高。给个结论：只要不是每秒百万包级别的定制场景，SharpPcap 足够。
安装方式很简单，NuGet 搜 SharpPcap 装最新稳定版即可，它会把 PacketDotNet 一起带进来。PacketDotNet 负责把原始字节解析成 EthernetPacket、IpPacket、TcpPacket、UdpPacket 这样的强类型对象，省掉手工按位拆包的痛苦。我一般会同时引入这两个库，SharpPcap 管“抓”，PacketDotNet 管“拆”。
设备列表这块有个前置知识：SharpPcap 拿到的设备列表来自 Npcap 的驱动层，每个设备有一个 FriendlyName（可读名称）、一个 Name（底层 GUID 名字）、Description 和 MacAddress。在工业现场常见的坑是：一台工控机上有好几个虚拟网卡（VMware、VirtualBox、Hyper-V 的虚拟交换机），列表一长串，抓包时选错了设备，什么都抓不到。后面避坑章节会专门讲怎么识别。
2.3 BPF 过滤器：效率的差距全在这一个字符串里
抓包程序最常用的场景不是把所有包都抓下来，而是“只抓某个 IP 的 TCP 80 端口”之类。SharpPcap 支持给设备设置 BPF（Berkeley Packet Filter）过滤器，它在内核态就完成过滤，只把匹配的包交到用户态。如果不设过滤器，所有包都会拷贝到应用层，高流量下 CPU 和内存都会被拖垮；设了过滤器，数据量可能直接下降几个数量级。
常见的 BPF 写法有这么几类。按协议：tcp、udp、icmp、arp 或 ip。按地址：host 192.168.1.100、src host 192.168.1.100、dst host 192.168.1.100。按端口：port 502（modbus tcp 默认端口）、portrange 8000-9000、src port 12345。按组合：tcp and port 502、host 192.168.1.100 and udp。按包特征：更细的可以写 tcp[13] & 2 != 0 抓带 SYN 标志的 TCP 包，但这要求你熟悉 TCP 头字节偏移，新手不建议上来就写这种。
给一个典型配置：
// 只抓来自 192.168.1.50 的 UDP 包，或者发往 502 端口的 TCP 包 string filter = "udp and src host 192.168.1.50 or (tcp and dst port 502)"; device.Filter = filter;这段代码的意思是把过滤表达式直接交给 Npcap 的驱动层，在内核里做匹配。注意“逻辑与或”的优先级：and 的优先级高于 or，所以如果不加括号，上面的表达式会被理解为“（udp and src host 192.168.1.50）or（tcp and dst port 502）”，结果完全不同。BPF 表达式写错了不会报异常，只会默默抓到一堆不合预期的包，这是排查时最耗费时间的坑之一。
2.4 设备打开模式：混杂模式不是默认值
device.Open(DeviceModes.Promiscuous | DeviceModes.DataTransferUnion, 1000);这行代码第二个参数是 read timeout，单位毫秒。在 SharpPcap 里，Open 方法接受两个参数：设备模式和读取超时。DeviceModes.Promiscuous 表示混杂模式，不加这个标志，网卡只会把发给本机 MAC 的帧交给上层，组播、广播之外的流量全丢。DeviceModes.DataTransferUnion 是 SharpPcap 在 Windows 上的一个兼容选项，建议加上，否则某些网卡驱动下会出现抓不到包或抓到的包时间戳异常的情况。
需要说明的是，抓包要抓的是“进出发送该网卡”的流量。如果目的 MAC 不是本机，也不在组播范围内，普通模式网卡硬件层就直接丢弃了，软件根本看不到。只有混杂模式才能看到这条链路上所有未被网卡驱动拒绝的帧。开启混杂模式的副作用是网卡 CPU 占用明显升高，如果机器是生产环境的工控机，需要评估影响。
3. 用 C# 跑通第一个抓包程序：最小可运行骨架
3.1 拿到网卡设备列表并过滤出物理网卡
先写一个能列出本机所有网卡的小程序。这一步的价值在于：你能看到系统的“真实网络视图”，顺便验证 Npcap 驱动有没有正确安装。
using SharpPcap; var devices = CaptureDeviceList.New(); if (devices.Count < 1) { Console.WriteLine("没有找到网卡，请检查 Npcap 是否安装。"); return; } foreach (var dev in devices) { Console.WriteLine($"名称: {dev.Name}"); Console.WriteLine($"描述: {dev.Description}"); Console.WriteLine($"MAC: {dev.MacAddress}"); Console.WriteLine($"支持抓包: {dev.SupportsCapture}"); Console.WriteLine("---"); }这段代码用 CaptureDeviceList.New() 拿到本机所有网卡。如果输出为空或者只有回环设备，十有八九是 Npcap 没装好。注意一个细节：SharpPcap 拿到的 Name 是一个长得像 \Device\NPF_{GUID} 的字符串，真正的设备名要看 Description 字段。在真实机器上，通常会出现很多虚拟网卡——比如安装了 Docker Desktop、VMware 或者 Wireshark 附带的 Npcap 就会注册多个设备。选哪块卡，核心看 Description 字段里有没有 Virtual、VMware、TAP 之类的关键字。做工业现场抓包，一般选连接 PLC 或仪表的那块物理网卡，它的 Description 通常是“Realtek PCIe GbE Family Controller”或“Intel I211 Gigabit Network Connection”这类字样。
3.2 抓取并逐层打印：从原始字节到 IP/TCP/UDP
下一个版本加上抓包循环和协议解析。先写一个能跑通的最小版本：抓 10 个包，用 PacketDotNet 把链路层、IP 层、TCP/UDP 层的关键字段打出来。
using SharpPcap; using PacketDotNet; var devices = CaptureDeviceList.New(); var device = devices.FirstOrDefault(d => d.Description.Contains("Realtek") || d.Description.Contains("Intel")); if (device == null) { Console.WriteLine("没有找到物理网卡，请检查设备列表。"); return; } device.OnPacketArrival += (sender, e) => { var packet = Packet.ParsePacket(e.GetPacket().LinkLayerType, e.GetPacket().Data); var ethernetPacket = packet as EthernetPacket; Console.WriteLine($"链路层: {ethernetPacket.SourceHwAddress} -> {ethernetPacket.DestinationHwAddress}"); var ipPacket = packet.Extract<IPPacket>(); if (ipPacket != null) { Console.WriteLine($"IP层: {ipPacket.SourceAddress} -> {ipPacket.DestinationAddress}, 协议: {ipPacket.Protocol}"); } var tcpPacket = packet.Extract<TcpPacket>(); if (tcpPacket != null) { Console.WriteLine($"TCP层: {tcpPacket.SourcePort} -> {tcpPacket.DestinationPort}, Flags: {tcpPacket.Flags}"); } var udpPacket = packet.Extract<UdpPacket>(); if (udpPacket != null) { Console.WriteLine($"UDP层: {udpPacket.SourcePort} -> {udpPacket.DestinationPort}, 长度: {udpPacket.Length}"); } }; device.Open(DeviceModes.Promiscuous | DeviceModes.DataTransferUnion, 1000); device.Filter = "ip"; device.StartCapture(); Console.WriteLine("开始抓包，按回车停止..."); Console.ReadLine(); device.StopCapture(); device.Close();这段代码的核心逻辑在 OnPacketArrival 事件回调里。Packet.ParsePacket 先把原始字节按链路层类型解析成 EthernetPacket，再通过 Extract () 从包中提取 IP 层。这一步不是简单的强制类型转换：Extract 会在包内部的对象图里逐层遍历，找到明确的 IP 层对象。如果用 as 转换拿不到，常见原因是包不是 IPv4/IPv6 的普通单播包（比如 ARP 包就没有 IP 层），所以代码里做了 null 判断。
几个参数值得说清楚。device.Filter = "ip" 表示只抓 IPv4 包，这一步就把 ARP、STP、LLDP 这些二层协议全部挡在外面，输出会干净很多。StartCapture 是在后台线程里循环抓包，主线程用 Console.ReadLine() 挂着等待停止，这是 SharpPcap 的典型用法：不要在回调里做耗时操作，因为回调线程和抓包缓冲是联动的，回调耗时长会导致内核缓冲区溢出丢包。
3.3 把流量保存成 pcap 文件：给 Wireshark 的后悔药
抓包器还有个刚需：把原始数据留存下来，事后用 Wireshark 慢慢分析。SharpPcap 封装了 pcap 文件写入，代码量很小。
device.OnPacketArrival += (sender, e) => { // 直接把原始数据帧写入文件，不做任何解析 captureFile.Write(e.GetPacket()); }; device.Open(DeviceModes.Promiscuous, 1000); device.Filter = "tcp port 502 or udp"; var captureFile = new CaptureFileWriter("capture_" + DateTime.Now.ToString("yyyyMMdd_HHmmss") + ".pcap"); device.StartCapture();CaptureFileWriter 的构造函数参数是文件路径。写入的是 e.GetPacket() 返回的原始包对象，SharpPcap 会自己处理好 pcap 全局头、每个包的时间戳和长度字段。这个文件可以直接拖进 Wireshark 打开，也可以被 tcpdump 用 -r 参数读取。我一般习惯把实时抓包和落盘两者都打开：一边打印关键字段做实时监控，一边写 pcap 文件留底。注意，CaptureFileWriter 必须在 StartCapture 之前创建，文件句柄要等 StopCapture 之后再 Dispose，否则文件尾部会有损坏风险。
3.4 最小骨架的局限与下一步
上面三段代码合起来，你已经有一个能用的“C# 抓取 IP TCP UDP 等网络数据包”的程序了。它能列出网卡、按 BPF 过滤抓包、解析三层协议头、存 pcap 文件。局限在于：没有解析应用层载荷，没有做 TCP 流的重组，也没有 UI。如果目标是排查某个具体协议（比如 modbus tcp），下一步要做的是在解析到 TcpPacket 之后，把 PayloadData 按协议格式拆解——这正好是下一章的内容。
4. 从帧到字段：拆解 IP、TCP、UDP 的关键代码与参数
4.1 IP 层的核心字段提取：版本、TTL、分片偏移
拿到 IpPacket 对象之后，PacketDotNet 已经把大部分常见字段帮你拆好了。但有几个字段需要自己算，最容易出错的是分片偏移和首部长度。
var ipPacket = packet.Extract<IPPacket>(); if (ipPacket == null) return; // 版本号：4 或 6 var version = ipPacket.Version; // IPv4 首部长度，单位是 4 字节，所以值 5 表示 20 字节 var headerLength = ipPacket.HeaderLength; // 总长度：IP 数据报整体长度，包含头部 var totalLength = ipPacket.TotalLength; // 分片偏移：单位 8 字节，需要乘以 8 才是真实字节偏移 var fragmentOffset = ipPacket.FragmentOffset * 8; // 标识符：同一个 IPv4 数据报分片后标识相同 var identification = ipPacket.Id; Console.WriteLine( $"IPv{version}, 头长度={headerLength * 4}, 总长={totalLength}, " + $"偏移={fragmentOffset}, 标识=0x{identification:X4}, TTL={ipPacket.TimeToLive}");分片是网络调试里最容易踩的坑。当 UDP 数据报大于 MTU（典型是 1500 字节）时，IP 层会把数据报切成多个分片，每个分片都是独立的 IP 包，有相同的 Id 字段，但 FragmentOffset 不同。抓包工具显示的可能是一个被拆成 3 到 5 段的 UDP 报文，如果只按包处理而不做分片重组，你会在业务层看到“数据不完整”。C# 想完整处理分片重组，需要自己维护一个字典，以 Id 为 key，把所有分片按 FragmentOffset 排序拼接，等最后一个分片（MF=0）到达后重组。这个逻辑不复杂，但很容易漏：某些情况下重传包的分片也会再次到达，需要加超时清理。
4.2 UDP 载荷提取：从 UdpPacket 到业务字节
UDP 是无连接的，一个 UDP 数据报在 IP 层就是一个完整的独立单元（未分片时）。取载荷是在抓包之后做业务解析的主要入口。
var udpPacket = packet.Extract<UdpPacket>(); if (udpPacket == null) return; var payload = udpPacket.PayloadData; if (payload.Length == 0) { Console.WriteLine("空 UDP 载荷"); return; } // 前 8 字节可能是业务协议头，这里按大端序解出两个 uint if (payload.Length >= 8) { uint field1 = (uint)((payload[0] << 24) | (payload[1] << 16) | (payload[2] << 8) | payload[3]); uint field2 = (uint)((payload[4] << 24) | (payload[5] << 16) | (payload[6] << 8) | payload[7]); Console.WriteLine($"字段1=0x{field1:X8}, 字段2=0x{field2:X8}"); }这段代码体现了一个在 C# 网络编程里的关键认知：网络字节序是大端序（Big-Endian），而 C# 的 BitConverter 在 Windows 上默认是小端序（Little-Endian）。直接把 BitConverter.ToUInt32(payload, 0) 用在网络数据上，得到的一定是反的。上面这段代码用移位方式手动完成大端序转换，是最不会出错的做法。
这里补一个和热词里“C# udp 发送 分包 组包”直接相关的场景：如果你写了一个 UDP 发送端，把一个大数组按 MTU 切成多包发送，接收端收齐后组包；抓包排查的时候，你要验证的是“每一个分片的 FragmentOffset 和总长度是否和发送端的分包逻辑一致”。用上面的代码把每个 UDP 包的载荷长度打出来，一眼就能看出发送端切包有没有越界。
4.3 TCP 头部标志与三次握手识别
TCP 和 UDP 的解析差异在于 TCP 是流协议还带连接状态。抓包时最常见的一个需求是验证“TCP 三次握手是否正常完成”。
var tcpPacket = packet.Extract<TcpPacket>(); if (tcpPacket == null) return; var flags = tcpPacket.Flags; bool syn = (flags & TcpPacket.TcpFlags.Syn) != 0; bool ack = (flags & TcpPacket.TcpFlags.Ack) != 0; bool fin = (flags & TcpPacket.TcpFlags.Fin) != 0; bool rst = (flags & TcpPacket.TcpFlags.Reset) != 0; if (syn && !ack) Console.WriteLine("三次握手：第一次握手 [SYN]"); else if (syn && ack) Console.WriteLine("三次握手：第二次握手 [SYN+ACK]"); else if (ack && !syn && !fin) Console.WriteLine("三次握手：第三次握手 [ACK]，连接建立成功"); else if (fin) Console.WriteLine("连接释放：FIN 包"); else if (rst) Console.WriteLine("连接异常重置：RST 包");TcpFlags 的值按位定义：Fin=0x01，Syn=0x02，Reset=0x04，Push=0x08，Ack=0x10，Urg=0x20。用位与做判断，能同时识别组合标志包——比如第二次握手是 Syn+Ack 两个位同时为真。排查“telnet ip 端口命令怎么看通不通”之类的问题时，你可以用这个逻辑直接确认目标端口是否响应了 SYN 并回 ACK。如果只看到 SYN 一直重传而没有回应，说明目的主机或中间防火墙把包丢了；如果收到 RST，说明端口是关闭的。
TCP 载荷的提取方式和 UDP 类似：tcpPacket.PayloadData 就是应用层字节流。区别在于 TCP 的 PayloadData 只是当前这一个段的载荷，不是完整的业务消息。要拿到完整消息，需要做流重组：用源 IP、源端口、目的 IP、目的端口做 key，把同一连接的所有段按序号排列拼接。这是一个不算小的话题，一般我会建议用现成的流重组库或者在 Wireshark 里通过 “Follow TCP Stream” 看。自己写流重组的复杂度主要在于处理重传、乱序和粘包。
4.4 一个完整案例：实时监控特定 IP 的所有 UDP 流量
把上面的解析逻辑整合起来，做成一个常见的实用工具：指定一个 IP，打印该 IP 所有 UDP 进出的源端口、目的端口和载荷长度。这是排查 UDP 网络调试问题最常用的工具。
string targetIp = "192.168.1.100"; device.OnPacketArrival += (sender, e) => { var packet = Packet.ParsePacket(e.GetPacket().LinkLayerType, e.GetPacket().Data); var ipPacket = packet.Extract<IPPacket>(); if (ipPacket == null) return; bool isTargetSrc = ipPacket.SourceAddress.ToString() == targetIp; bool isTargetDst = ipPacket.DestinationAddress.ToString() == targetIp; if (!isTargetSrc && !isTargetDst) return; var udpPacket = packet.Extract<UdpPacket>(); if (udpPacket == null) return; string direction = isTargetSrc ? "发送" : "接收"; Console.WriteLine( $"[{DateTime.Now:HH:mm:ss.fff}] {direction} " + $"{ipPacket.SourceAddress}:{udpPacket.SourcePort} -> " + $"{ipPacket.DestinationAddress}:{udpPacket.DestinationPort} " + $"| 载荷 {udpPacket.PayloadData.Length} 字节"); };这段代码用 Packet.ParsePacket 解析一次，然后分别 Extract 出 IP 层和 UDP 层，避免了对同一个包做两次完整解析的性能浪费。isTargetSrc 和 isTargetDst 分开判断，可以同时处理这个 IP 发出和接收两个方向的流量。方向判断放在 BPF 之后：BPF 里如果写了 host 192.168.1.100，所有进出该主机的包都会被过滤出来，方向可以在用户态代码里再分。
5. 抓包避坑：五大高频翻车点与排查方法
5.1 网卡列表刷出一堆虚拟网卡，选错设备什么都抓不到
现象：程序跑起来，OnPacketArrival 一次都不触发，或者只触发极少的包。原因：设备列表里排第一的往往是 VMware 或 VirtualBox 的虚拟网卡。这些虚拟网卡的流量是宿主机与虚拟机之间的，外部设备的数据包根本不经过它。解决：不要在代码里默认取 devices[0]，而是遍历之后根据 Description 做关键字匹配。如果 Description 是中文乱码，把 Name 字段也打印出来，对照 Windows 的网络连接面板，用 IP 地址来定位。一个辅助技巧：先跑一遍 ipconfig /all，记下目标网卡的 IPv4 地址，然后在 SharpPcap 里用 device.Addresses 找匹配的项。
另外一个更隐蔽的问题：Wireshark 自带的 Npcap 装在旧版本时，只有 Wireshark 安装目录下的 npcap 驱动是完整的；SharpPcap 通过 NuGet 引用的 wpcap.dll 和驱动版本不匹配时，会收到 “The version of Npcap is too old” 之类的错误。解决方法是重装最新版 Npcap，并在安装时勾选“Install Npcap in WinPcap API-Compatible Mode”，两者兼容模式必须一致。
5.2 混杂模式打开了，但交换机不配合
现象：在办公室网络里抓包，只能抓到自己本机的流量，抓不到同网段其他机器的包。原因：现代交换机是交换式的，端口之间的流量不会广播给所有端口。混杂模式只对共享式链路（集线器）或者本机进出的流量完全有效。解决：如果是现场调试，把抓包机接到和被测设备同一个傻瓜交换机上，或者用交换机端口镜像（Mirror/SPAN），把目标端口流量复制一份到抓包端口。这不是 SharpPcap 的锅，是网络架构的限制。很多新手在这里折腾几个小时，最后发现是物理层面的问题。
5.3 抓包丢包严重：内核缓冲区和回调耗时
现象：小流量下正常，一旦流量一大，程序解析出来的包数量明显少于 Wireshark 里看到的。原因有两层：第一，Npcap 的内核缓冲区默认只有 1MB，流量瞬时峰值高时直接溢出丢弃；第二，OnPacketArrival 回调里做了耗时操作（比如写数据库、打印大量日志），导致回调线程处理不过来，缓冲区又被填满。解决：打开设备后调用 device.SetKernelBufferSize(64 * 1024 * 1024) 把内核缓冲扩到 64MB；回调里只做“把原始包丢进并发队列”的轻量操作，解析和落盘放到另一个线程。这是 C# 抓包器稳定运行的关键调整，我见过太多程序在流量上来时丢包率超过百分之三十，改完缓冲区和回调结构之后恢复到千分之一以内。
5.4 BPF 表达式写错但又不报错
现象：设置了 Filter 之后，抓到的包不是想要的，或者数量为零。原因：BPF 表达式语法错误时，Npcap 会抛出 PcapException，但更常见的是语法对、逻辑不对——优先级问题、大小写问题、关键字拼写问题。比如很多人写 filter = "tcp and port 80 or udp"，内心想的是“(tcp and port 80) or udp”，但实际语义是“tcp and (port 80 or udp)”——因为 and 优先级高，这导致所有 TCP 包都被放进来。解决：凡是组合条件一律加括号；设置 Filter 之后打印 device.Filter 确认实际生效的表达式；先在 Wireshark 里用同样的表达式验证一下抓包结果，再搬到代码里。
5.5 IP 分片后的 UDP 包解析不完整
现象：抓到的 UDP 包很多，目标端口也对，但载荷长度明显小于业务层应该收到的字节数，业务程序也反馈收不全。原因：大于 MTU 的 UDP 数据报在 IP 层分片了，你看到的是分片后的某一个分片。PacketDotNet 的 UdpPacket 只存在于第一个分片上（它包含 UDP 头），后续分片只有 IP 头加数据，提取不到 UdpPacket。解决：代码里不要直接假设“一个 IP 包就是一个完整 UDP 数据报”，需要检测 ipPacket.FragmentOffset 和“更多分片”标志，做分片重组。给一个简单的判断写法：
bool isFragment = ipPacket.FragmentOffset > 0; // 某个分片不是第一个分片，跳过 UDP 解析 if (isFragment) return;分片重组要做完整，比上面这段复杂得多，要点包括：用 Id 字段分组、按 Offset 排序、设置超时清理未完成的分片组、考虑重叠分片攻击。但从业务排查角度，先确认这些分片的偏移是否连续、总长度是否一致，往往就能定位是发送端切包问题还是 MTU 设置问题。
6. 数据量上来之后：缓冲、线程与性能收尾技巧
抓包程序从“demo 能跑”到“现场能扛住”，差的不是解析逻辑，而是几个性能关键点。第一，内核缓冲区必须在 Open 之后、StartCapture 之前设置。SharpPcap 的 SetKernelBufferSize 方法参数是字节数，最小能设到 1MB，最大值取决于驱动和内存。现场流量平均几十兆时，64MB 是稳妥值；更高流量建议 128MB，但要观察内存占用。第二，OnPacketArrival 回调必须轻量化。推荐结构是回调里只做一件事：把 e.GetPacket() 放入 ConcurrentQueue ，然后立刻返回。后台一个独立线程负责队列消费、协议解析、按条件过滤需要记录的包。这样做的好处是抓包线程和解析线程解耦，瞬时流量尖峰时队列起到缓冲作用。
var queue = new ConcurrentQueue<RawCapture>(); device.OnPacketArrival += (sender, e) => { queue.Enqueue(e.GetPacket()); }; // 后台消费线程 Task.Run(() => { while (true) { if (queue.TryDequeue(out var raw)) { var packet = Packet.ParsePacket(raw.LinkLayerType, raw.Data); // 解析处理 } else { Thread.Sleep(5); } } });队列的无界增长是个隐患：如果消费线程跟不上，内存最终会被堆满。建议给队列加一个上限，比如超过 10000 条就丢弃最旧的包，并在控制台打印“抓包积压，已丢弃 N 个包”的告警，这样至少能在事后知道丢包发生在用户态而不是内核态。第三，大批量落盘时不要逐个包写，可以攒一批（比如每 100 个包或者每 200ms）批量写一次，减少频繁磁盘 IO。磁盘性能差是现场抓包的另一个隐形杀手。
还有一个细节：StopCapture 之后，内核缓冲里的包可能还有残留，要再调一次 device.GetNextPacket() 把剩余包取出来，否则会漏掉最后几百毫秒的数据。我习惯在停止后写一个循环，读到空为止。如果做的是长期运行的采集服务，建议加一个“按时间自动滚动”的 pcap 文件分包逻辑：每 10 分钟一个文件，或者每个文件最大 100MB，避免单个文件过大导致事后分析卡顿。
最后说一个我自己的血泪教训：所有抓包程序，第一版一定要先记录“丢包统计”和“起止时间”，不要只存包本身。否则你怎么知道抓到的这段数据是完整的还是残缺的？加两个计数器：内核丢包数可以通过 device.Statistics 拿到，用户态丢包数就是刚才队列丢弃的累计值。等你在现场对着一个“数据丢了”的结论排查到半夜，你会发现这两个数字比任何解析代码都有用。
这套方案的边界我也得说清楚：SharpPcap 适合做中小流量的抓包解析和协议调试，如果目标是百兆以上的持续采集，建议认真评估 C++ 实现或者把抓包逻辑下放到专用硬件。但就 C# 上位机开发和工业协议调试而言，SharpPcap 加 PacketDotNet 这一组合，已经足够覆盖绝大多数场景了。希望这篇笔记能帮你在抓包这条路上少走几段弯路。
本文还有配套的精品资源，点击获取
