简介这是一份面向C#开发者与网络运维人员的网络抓包工具包基于SharpPcap开源库实现数据包的捕获与分析可用于网络故障诊断、实时流量监控、安全威胁排查等场景。资源共17个文件压缩包大小2.24MB内容包含可直接运行的exe可执行程序、核心的动态链接库dll、xml配置文件、png界面截图以及docx说明文档同时附带SharpPcap依赖包和WinPcap驱动安装程序方便快速搭建抓包环境。目前已有303人学习下载适合想要入手网络编程或进行流量分析的读者。通过研究源码可以系统掌握C#中调用SharpPcap完成网卡枚举、数据包捕获、协议解析等核心操作而“直接使用”目录下的可执行文件则让非开发人员也能一键启动工具配合截图与参考资料快速上手。整体而言这是一份兼顾学习与实战的轻量级C#网络编程案例既能作为初学者的实践教材也能为有经验的开发者提供可直接复用的抓包思路。 做工业上位机这几年我遇到过不少类似的场景设备说明书上写着Modbus TCP报文应该长成某个样子可真到联调那天设备就是不按套路回包。想确认问题到底是出在我解析代码写错了还是设备回包本来就不对第一反应肯定是开Wireshark抓包。但Wireshark抓的是整个网卡的全部流量几十上百条连接里翻一条目标报文全靠肉眼找更麻烦的是抓包和上位机自测是两套独立流程我没法在程序里自动比对抓到的字段、自动判断协议是否合规。后来我把SharpPcap的抓包逻辑直接集成进C#工具里把“抓包、解析、断言”做成一条链联调效率明显上来了。这篇文章就围绕这个C#网络抓包程序把核心思路、关键源码、还有实测踩过的坑一次讲清楚适合自己写上位机、做嵌入式联调、以及需要把抓包能力嵌进自动化测试工具的朋友参考。1. 动手之前先想清楚自己做抓包到底解决了什么1.1 Wireshark替你做不了的三件事Wireshark在单次问题分析上确实是神器界面、解码器、过滤表达式都很成熟可放到实际工程里有三类场景它帮不上忙。第一是自动化回归测试。固件发版前要批量验证协议字段是否符合规范靠人肉开Wireshark一包一包看既不现实又容易漏必须用代码读包、自动断言这只有程序化的抓包能力才能做到。第二是私有协议解析。不少设备厂商在标准Modbus TCP之上做了扩展字段偏移量、数据长度只有自己清楚。Wireshark不会为你的私有字段单独写解析器但自己的C#工具里写几十行解析代码就能把事务ID、功能码、寄存器地址这些关键信息直接抽出来。第三是长时间运行的统计口径。做稳定性压测时关心的往往不是某一条包而是心跳超时次数、平均响应延迟、异常重连频率这类指标。把SharpPcap接进程序统计直接在内存里完成比事后打开pcap文件分析要轻松得多还能在指标异常时实时告警。1.2 这个项目适合什么人直接用我做这个程序的直接原因是现场有一台PLC设备走Modbus TCP联调时需要对每一次请求-响应做耗时统计还要自动校验事务ID、功能码、寄存器数量。如果你也是做上位机开发、嵌入式联调或者网络设备测试的C#工程师下面这套代码基本可以抄到自己的项目里。它和Wireshark不是替代关系更像是一个自动化补充对比项WiresharkSharpPcap自制工具单次临时抓包非常方便需要写代码批量自动化测试不支持可集成到测试框架私有协议解析需要写插件C#代码直接解析长时间指标统计弱强部署到现场环境安装包大、难集成拷贝exe即可2. SharpPcap的抓包原理它比Socket低了半层2.1 数据是怎么“绕过”协议栈被拿出来的SharpPcap本质上是libpcap的.NET封装在Windows下底层依赖Npcap或老旧的WinPcap驱动。libpcap这套架构的高明之处在于它在网卡驱动层就把数据帧复制了一份到内核缓冲区应用层再通过环形缓冲逐包读取完全不干扰正常的协议栈收发。可以这样理解普通Socket就像在快递站等着取自己名下的包裹而libpcap是站在传送带旁边把所有经过的包裹都看一遍只看不拿走。开启混杂模式就是让网卡连“写给别人地址”的包裹也复制一份这是抓包工具能捕获大规模流量的基础。很多人以为抓包是“半路拦截”其实它从头到尾都没影响正常通信只是多抄了一份副本所以抓包程序崩溃也不会把网络搞挂。2.2 内核缓冲区、BPF过滤器和回调的关系一次完整的抓包流程是网卡收到帧 → 驱动按BPF过滤器判断是否留用 → 留用的帧写入内核缓冲区 → 应用层从缓冲区读出来触发回调。注意“是否留用”在内核态就决定了所以过滤器写得越靠前CPU负担越低。SharpPcap常用的接口是OnPacketArrival事件包到达缓冲区后自动触发本质上是事件驱动模型你不用自己轮询缓冲区这对写UI程序特别友好。在6.x版本里事件参数改成了PacketCapture结构代码里直接调用e.GetPacket()拿到原始包。这套模型和老的WinPcap时代相比变化不小如果你在网上搜到旧教程看到构造参数对不上基本就是版本差异导致的。2.3 为什么不用C#的Raw Socket有人会问C#里直接建一个Socket套上SocketOptionHeaderIncluded不也能收包吗Windows下的原始套接字天生受限而且经过系统的包在网络层、传输层会留下加工痕迹Ethernet头的很多细节拿不全回环包处理也麻烦。SharpPcap直接在链路层做原始拷贝头一个字节都不落后面自己写的解析代码才有完整依据。做工业通信调试差别往往就藏在这些底层字节里。3. 从装驱动到跑通Demo环境准备与核心代码骨架3.1 装驱动、装包跑通之前的两件小事写代码之前先确认两件事。第一安装Npcap驱动安装时记得勾选“Support loopback traffic”选项否则Windows本机进程之间的回环流量抓不到。第二在NuGet里安装SharpPcap它会自动把PacketDotNet作为依赖拉进来后面解析报文全靠这个库。提示项目平台架构建议明确选x64或x86不要图省事选AnyCPU。老版本SharpPcap对平台匹配很敏感AnyCPU在64位系统上偶尔会蹦出BadImageFormatException虽然新版适配好一些但踩一次坑的代价远大于提前指定平台。3.2 枚举网卡、打开设备的完整代码下面是最小闭环代码先跑通它再谈解析using SharpPcap; using PacketDotNet; var devices CaptureDeviceList.Instance; for (int i 0; i devices.Count; i) { Console.WriteLine($[{i}] {devices[i].Description}); } Console.Write(请选择网卡编号: ); if (!int.TryParse(Console.ReadLine(), out var idx) || idx devices.Count) return; using var device devices[idx]; device.OnPacketArrival (sender, e) { var packet Packet.ParsePacket(e.GetPacket()); Console.WriteLine(packet.ToString()); }; device.Open(new DeviceConfiguration { Mode DeviceModes.Promiscuous, ReadTimeout 1000, Snaplen 65535 }); device.Filter tcp port 502; device.StartCapture(); Console.ReadLine(); device.StopCapture();如果你的SharpPcap版本较老没有DeviceConfiguration这个类就用老写法device.Open(DeviceModes.Promiscuous, 1000)直接打开再通过device.KernelBufferSize属性调整内核缓冲区大小效果一样。3.3 事件回调和主动读取怎么选SharpPcap提供两种取包方式实际使用按场景选事件回调OnPacketArrival事件自动触发适合UI程序和大多数联调工具代码简单不容易漏包。主动读取在循环里调GetNextPacket逐个处理适合后台服务、需要严格背压控制的场景。我默认用事件回调因为上位机工具通常还要同时刷新界面、响应用户输入事件模型不会阻塞主逻辑。只有做高吞吐的协议转换服务时我才换成主动读取以便在流量高峰时自己决定丢弃哪些低优先级包。3.4 BPF过滤器语法最容易踩的隐性坑设置过滤器用的是BPFBerkeley Packet Filter语法不是Wireshark界面里那套显示过滤语法。很多新手把tcp.port 502直接填进Filter属性结果一个包都抓不到。正确的是raw版的tcp port 502中间没有点号也没有双等号。这俩一个是捕获过滤器、一个是显示过滤器作用阶段完全不同写混了要么抓不到包要么程序直接报语法错误。想抓的流量正确填写的Filter值所有Modbus TCP报文tcp port 502某个IP的全部通信host 192.168.1.100排除SSH的其他TCPtcp and not port 22一段端口范围portrange 2000-5000只想看ARParpUDP广播udp and broadcast4. 把字节变成看得懂的报文数据包解析实战4.1 PacketDotNet的解析链SharpPcap拿到的原始数据只是字节数组直接看是没法读的。PacketDotNet按协议栈的顺序把Ethernet帧、IPv4/IPv6包、TCP/UDP段一层层剥开。解析链的代码模式很固定而且能直接在官方包类型上做类型判断void OnPacketArrival(object sender, PacketCapture e) { var packet Packet.ParsePacket(e.GetPacket()); if (packet is not EthernetPacket eth) return; if (eth.PayloadPacket is not IPv4Packet ip) return; if (ip.PayloadPacket is not TcpPacket tcp) return; Console.WriteLine(${ip.SourceAddress}:{tcp.SourcePort} - ${ip.DestinationAddress}:{tcp.DestinationPort}); }注意这里用is not做类型守卫顺手避开空引用。很多教程喜欢把每层都new一个解析对象其实Packet.ParsePacket已经把嵌套关系建好了直接用PayloadPacket逐层取就行自己重新拼一堆解析类反而容易出错维护成本也高。4.2 解析Modbus TCP负载的例子拿到TCP报文后载荷在tcp.PayloadData里。以Modbus TCP为例前7个字节是MBAP头包括事务ID2字节、协议ID2字节、长度2字节、单元ID1字节第8字节开始才是功能码。这段解析逻辑在工业联调里非常常用var payload tcp.PayloadData; if (payload.Length 8) return; var transId (ushort)((payload[0] 8) | payload[1]); var funcCode payload[7]; if (funcCode 0x03) { var startAddr (ushort)((payload[8] 8) | payload[9]); var quantity (ushort)((payload[10] 8) | payload[11]); Console.WriteLine($事务ID0x{transId:X4} 功能码03(读保持寄存器) $起始地址{startAddr} 数量{quantity}); }大端字节序是Modbus的老规矩高位在前所以payload[0] 8再或上payload[1]拼出来的才是正确的事务ID。凡是碰工业协议字节序问题一定要在解析层统一处理否则后面每个功能码都要踩一遍。另外事务ID在请求和响应里必须一致这个字段是配对请求响应的关键联调时很多“设备没反应”的问题其实都是事务ID对不上导致的。4.3 顺手把原始包写成pcap文件调试过程中除了实时打印还经常要把原始包落盘方便后续用Wireshark离线分析。SharpPcap提供了CaptureFileWriterDevice用法很简单var writer new CaptureFileWriterDevice(D:\capture.pcap, FileMode.Create); ... writer.Write(e.GetPacket());我的经验是程序里同时开一条抓包事件通道实时解析、统计和一条文件通道原样写盘两边互不干扰。这样既不影响实时判断也留了事后细查的素材。很多问题当时看不出规律第二天导进Wireshark慢慢翻反而能发现异常。5. 实测踩坑记录跑不通往往就卡在这几处5.1 权限、平台、驱动先冒出来的三个坎第一个坑是权限。抓包必须在管理员模式下运行否则打开设备时会抛权限异常这个没有捷径VS里右键项目选择“以管理员身份运行”或者发布后用管理员身份启动exe。第二个坑是平台位数。Npcap驱动虽然同时提供32位和64位的wpcap.dll但如果项目平台不匹配或者机器上残留了老的WinPcap打开设备时就会出现各种莫名其妙的异常。新装机建议直接上Npcap别在WinPcap上纠结。第三个坑是驱动残留。一台机器上如果同时装过WinPcap和Npcap有时Npcap会装不上或者抓包明显变慢。我遇到过一次把WinPcap卸载干净、重装Npcap之后才恢复正常。这套组合拳打完90%的“打开设备失败”都能解决。5.2 本机回环流量抓不到是怎么回事用默认网卡列表抓本机两个进程之间的通信经常一个包都看不到。Windows上回环流量要靠Npcap专用的Loopback Adapter才能抓装Npcap时没勾loopback选项或者设备列表里没选这个适配器就会一直空着。判断方法很简单抓包前先在设备列表里找Description带“Adapter for loopback traffic capture”的项选中它再抓。这个小坑很容易让人怀疑人生其实是选错了网卡。5.3 高流量下丢包内核缓冲区要舍得给流量一大就开始连续漏包多半是内核缓冲区不够。SharpPcap的默认缓冲区在Windows上通常只有1MB跑Modbus这种低频协议够用但同一台电脑上如果还跑着文件传输、视频流之类的大流量缓冲区瞬间就会被冲掉。我一般会调到32MB甚至更大device.Open(new DeviceConfiguration { Mode DeviceModes.Promiscuous, ReadTimeout 1000, BufferSize 32 * 1024 * 1024 });注意缓冲区不是越大越好太大会拖慢读取延迟抓包和业务并发时建议先做一轮性能测试压出合适的值。另一个经验是过滤器一定要在Open之后、StartCapture之前设置让内核在入口就过滤掉不关心的包比全部收上来再丢弃效率高几个数量级。5.4 多网卡机器上选错网卡笔记本、工控机通常有有线、无线、虚拟网卡好几块枚举出来的列表不会直接告诉你哪块对应哪个业务。我的习惯是打印每块网卡的IPv4地址直接按IP选网卡比只看Description猜靠谱得多var ipv4 device.Addresses.FirstOrDefault(a a.Addr ! null a.Addr.type Sockaddr.AddressTypes.AF_INET_AF_INET6); Console.WriteLine($[{i}] {device.Description} - {ipv4?.Addr.ipAddress});不同版本的SharpPcap里地址类型枚举名略有差异如果编译不过把AF_INET_AF_INET6换成对应版本的常量就行。选错网卡几乎是每个第一次用SharpPcap的人都会遇到的错误列表里那个“Wireless”和你现场实际连的有线网口抓出来的结果天差地别。6. 源码拿到手之后模块怎么拆、往哪扩展6.1 项目里的模块划分参考写抓包程序最忌讳把所有逻辑堆在一个文件里。我整理的源码是按职责拆的结构大致如下PacketCapture/ ├── CaptureService.cs # 网卡枚举、打开、过滤、启停 ├── Parsers/ │ ├── EthernetParser.cs # 链路层解析 │ ├── ModbusTcpParser.cs # Modbus TCP载荷解析 │ └── HexDump.cs # 十六进制打印 ├── Writers/ │ └── PcapFileWriter.cs # pcap落盘 ├── Statistics.cs # 响应耗时、异常计数 └── Program.cs # 入口串起整个流程CaptureService对外只暴露Start、Stop和OnPacketParsed事件上层界面完全不用知道底层是SharpPcap还是别的驱动。这样哪天要换抓包实现界面代码一行都不用改只是替换一个服务类的事。6.2 再往前一步可以做什么这套代码的扩展空间其实很大。比如把解析层做成插件式每个私有协议一个独立dll按端口号分发或者把实时统计结果输出成CSV直接作为测试报告附件再或者接到数据库里把现场设备的通信质量长期记录下来做趋势分析。我在实际使用中最受益的一个改动是把请求-响应配对逻辑加上时间戳联调时一眼就能看出是设备回包慢还是自己发送端的调度慢了。这个项目里我唯一想强调的经验是抓包工具不要指望一步到位。我自己的习惯是先把最小闭环跑通——枚举网卡、打开设备、打印出第一个包确认环境和驱动都没问题再往上加协议解析和统计功能。很多朋友拿到源码第一件事就是打开整个工程编译结果版本不同、环境不同卡在底层半天出不来。最小闭环跑通之后每一步改动都有明确的验证点后面反而快。真到了要维护几百个设备通信协议的时候你会感谢当初把这个工具做得够扎实的自己。本文还有配套的精品资源点击获取