尧图网页设计 
简介面向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 字节的头包含目标 MAC6 字节、源 MAC6 字节、上层协议类型2 字节0x0800 是 IPv40x86DD 是 IPv60x0806 是 ARP。C# 里做抓包大部分库拿到的就是从这个位置开始的原始字节。换句话说你看到的第一个字节不是 IP 头而是 MAC 地址。这一点新手最容易懵代码里明明写了“取第 13 字节判断协议类型”结果抓到的和预想不一致多半是把链路层头忘了。链路层头后面才是三层头。IPv4 头的固定部分是 20 字节里面有版本、首部长度、总长度、标识符、分片偏移、TTL、协议号6 是 TCP17 是 UDP、源地址和目的地址。TCP 头在 IPv4 头之后固定部分 20 字节包含源端口、目的端口、序号、确认号、标志位和窗口大小。UDP 头只有 8 字节源端口、目的端口、长度、校验和。C# 抓包程序的活说白了就是拿着一块 byte[]按这些偏移量把字段切出来。2.2 选型为什么我选 SharpPcap 而不是自己 P/InvokeC# 做抓包市面上能做底层抓包的方案其实不多。最主流的是 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 支持给设备设置 BPFBerkeley 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 502modbus 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.50ortcp 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.ExtractIPPacket(); if (ipPacket ! null) { Console.WriteLine($IP层: {ipPacket.SourceAddress} - {ipPacket.DestinationAddress}, 协议: {ipPacket.Protocol}); } var tcpPacket packet.ExtractTcpPacket(); if (tcpPacket ! null) { Console.WriteLine($TCP层: {tcpPacket.SourcePort} - {tcpPacket.DestinationPort}, Flags: {tcpPacket.Flags}); } var udpPacket packet.ExtractUdpPacket(); 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.ExtractIPPacket(); 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 排序拼接等最后一个分片MF0到达后重组。这个逻辑不复杂但很容易漏某些情况下重传包的分片也会再次到达需要加超时清理。4.2 UDP 载荷提取从 UdpPacket 到业务字节UDP 是无连接的一个 UDP 数据报在 IP 层就是一个完整的独立单元未分片时。取载荷是在抓包之后做业务解析的主要入口。var udpPacket packet.ExtractUdpPacket(); 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($字段10x{field1:X8}, 字段20x{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.ExtractTcpPacket(); 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(三次握手第二次握手 [SYNACK]); else if (ack !syn !fin) Console.WriteLine(三次握手第三次握手 [ACK]连接建立成功); else if (fin) Console.WriteLine(连接释放FIN 包); else if (rst) Console.WriteLine(连接异常重置RST 包);TcpFlags 的值按位定义Fin0x01Syn0x02Reset0x04Push0x08Ack0x10Urg0x20。用位与做判断能同时识别组合标志包——比如第二次握手是 SynAck 两个位同时为真。排查“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.ExtractIPPacket(); if (ipPacket null) return; bool isTargetSrc ipPacket.SourceAddress.ToString() targetIp; bool isTargetDst ipPacket.DestinationAddress.ToString() targetIp; if (!isTargetSrc !isTargetDst) return; var udpPacket packet.ExtractUdpPacket(); 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 ConcurrentQueueRawCapture(); 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 这一组合已经足够覆盖绝大多数场景了。希望这篇笔记能帮你在抓包这条路上少走几段弯路。本文还有配套的精品资源点击获取 C# 抓包实战：用 SharpPcap 解析 IP/TCP/UDP 数据包与避坑指南
简介面向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 字节的头包含目标 MAC6 字节、源 MAC6 字节、上层协议类型2 字节0x0800 是 IPv40x86DD 是 IPv60x0806 是 ARP。C# 里做抓包大部分库拿到的就是从这个位置开始的原始字节。换句话说你看到的第一个字节不是 IP 头而是 MAC 地址。这一点新手最容易懵代码里明明写了“取第 13 字节判断协议类型”结果抓到的和预想不一致多半是把链路层头忘了。链路层头后面才是三层头。IPv4 头的固定部分是 20 字节里面有版本、首部长度、总长度、标识符、分片偏移、TTL、协议号6 是 TCP17 是 UDP、源地址和目的地址。TCP 头在 IPv4 头之后固定部分 20 字节包含源端口、目的端口、序号、确认号、标志位和窗口大小。UDP 头只有 8 字节源端口、目的端口、长度、校验和。C# 抓包程序的活说白了就是拿着一块 byte[]按这些偏移量把字段切出来。2.2 选型为什么我选 SharpPcap 而不是自己 P/InvokeC# 做抓包市面上能做底层抓包的方案其实不多。最主流的是 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 支持给设备设置 BPFBerkeley 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 502modbus 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.50ortcp 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.ExtractIPPacket(); if (ipPacket ! null) { Console.WriteLine($IP层: {ipPacket.SourceAddress} - {ipPacket.DestinationAddress}, 协议: {ipPacket.Protocol}); } var tcpPacket packet.ExtractTcpPacket(); if (tcpPacket ! null) { Console.WriteLine($TCP层: {tcpPacket.SourcePort} - {tcpPacket.DestinationPort}, Flags: {tcpPacket.Flags}); } var udpPacket packet.ExtractUdpPacket(); 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.ExtractIPPacket(); 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 排序拼接等最后一个分片MF0到达后重组。这个逻辑不复杂但很容易漏某些情况下重传包的分片也会再次到达需要加超时清理。4.2 UDP 载荷提取从 UdpPacket 到业务字节UDP 是无连接的一个 UDP 数据报在 IP 层就是一个完整的独立单元未分片时。取载荷是在抓包之后做业务解析的主要入口。var udpPacket packet.ExtractUdpPacket(); 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($字段10x{field1:X8}, 字段20x{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.ExtractTcpPacket(); 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(三次握手第二次握手 [SYNACK]); else if (ack !syn !fin) Console.WriteLine(三次握手第三次握手 [ACK]连接建立成功); else if (fin) Console.WriteLine(连接释放FIN 包); else if (rst) Console.WriteLine(连接异常重置RST 包);TcpFlags 的值按位定义Fin0x01Syn0x02Reset0x04Push0x08Ack0x10Urg0x20。用位与做判断能同时识别组合标志包——比如第二次握手是 SynAck 两个位同时为真。排查“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.ExtractIPPacket(); if (ipPacket null) return; bool isTargetSrc ipPacket.SourceAddress.ToString() targetIp; bool isTargetDst ipPacket.DestinationAddress.ToString() targetIp; if (!isTargetSrc !isTargetDst) return; var udpPacket packet.ExtractUdpPacket(); 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 ConcurrentQueueRawCapture(); 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 这一组合已经足够覆盖绝大多数场景了。希望这篇笔记能帮你在抓包这条路上少走几段弯路。本文还有配套的精品资源点击获取