简介面向C#网络编程学习者与开发者的数据包捕获解析完整项目基于Socket编程实现指定端口的IP、TCP、UDP报文监听与解析可辅助网络排错、协议学习和安全分析。压缩包共82个文件、约1.12MB以24个C#源代码和3个可执行程序为主体附带界面资源、图标图片、项目配置及升级报告可在Visual Studio中直接打开编译。项目完整演示了从创建Socket、绑定本地端点、持续接收数据到逐层解析IP头、TCP头与UDP头的流程提取源/目标地址、端口号、序列号、确认号、窗口大小等关键字段并以可读形式展示还提供过滤设置对话框方便按端口或协议筛选流量。整个工程结构清晰主界面、过滤设置、关于对话框等模块划分明确适合希望从套接字层面深入理解网络协议的开发者参考。目前已有741人下载学习既适合作为课程设计也可作为自定义抓包工具的二次开发基础。1. C# 抓包从哪儿入手一张网卡、三层解析、无数次踩坑如果你用 C# 做过网络调试迟早会遇到一个需求想看看某个端口上到底跑了什么协议、什么 IP 在发包、TCP 还是 UDP。很多人第一次上手就直接开搞原始套接字SocketType.Raw结果发现要么收到一堆残缺帧要么数据包里的端口和 IP 对齐不上玄学问题频发。我在拆这个 C# 抓包项目时最终选的是 SharpPcap 抓底层帧、PacketDotNet 解析协议配合 BPF 过滤器来定位指定端口。这套组合把最难的网卡驱动适配和协议拆包都封装好了剩下要做的只是把回调里的数据拿过来分析。适合做端口监控、协议调试、局域网数据流分析但又不想从零写协议栈的开发者。2. 选型与原理为什么是 SharpPcap 而不是原始套接字2.1 原始套接字能抓包吗边界和限制原始套接字确实能捕获 IP 层的数据尤其在 Linux 上socket(AF_INET, SOCK_RAW, IPPROTO_TCP)配合setsockopt(IP_HDRINCL)可以拿到带 IP 头的原始报文。但在 Windows 平台上这条路走得非常别扭。Windows 对原始套接字的限制是出了名的TCP 流量基本收不到被系统协议栈直接处理掉了UDP 也只能收收入站数据出站包要到很后面才可能抓到而且抓到的数据往往已经被重组或修改过。实际排查中更麻烦的是原始套接字只能抓到本机进程收发的那部分数据根本满足不了「监控网段内其他设备通信」这类诉求。比如你写了一个服务要监视某个设备往 22443 端口发的 UDP 心跳包原始套接字方案直接把范围卡死了。它不需要网卡驱动支持混杂模式不像包捕获库那样能把网卡上流通的每一个帧都拷贝一份出来。混杂模式是个关键点只有让网卡把不是发给自己的包也收上来才能在交换机的镜像口或者无线监听场景里拿到完整的链路流量这一层逻辑原始套接字做不到。所以我的结论很直接如果只是抓自己进程的收发数据用原始套接字凑合但凡是「抓整个网卡上的包」「按端口/协议过滤」「要还原 IP、TCP、UDP 头信息」老老实实走驱动级抓包。SharpPcap 封装的是 libpcap 那套接口在 Windows 上背后是 Npcap 驱动在 Linux 上是 libpcap 本身跨平台逻辑一致。2.2 SharpPcap PacketDotNet 的分工和运行时链路SharpPcap 和 PacketDotNet 是两件事很多人搞混。SharpPcap 管的是抓包动作本身枚举网卡、打开设备、设置混杂模式、设置过滤器、启动/停止捕获、把原始帧通过回调抛出来。它不负责解析数据包内容你从回调里拿到的是一个RawCapture对象里面是LinkLayerType和原始字节数组。看到一堆字节直接懵的是 PacketDotNet 出场的地方。PacketDotNet 负责把字节解析成结构化的包对象以太网帧、IPv4 包、IPv6 包、TCP 包、UDP 包、ICMP 包等。它提供了Packet.ParsePacket入口传入链路层类型和原始字节返回一个Packet对象然后可以用ExtractT()在协议栈里逐层抽取你关心的协议头。运行时链路大概是这样的网卡收到帧后驱动在混杂模式下先复制一份交给 Npcap 的过滤引擎BPFBerkeley Packet Filter过滤器在这里决定这个帧是放行还是丢掉放行的帧被送入 SharpPcap 的接收缓冲接着触发OnPacketArrival事件回调。你在回调里拿到的包已经是驱动和过滤器处理过之后的结果。理解这条链路对排查问题至关重要——你设置的端口过滤条件不生效或者抓到的包数量对不上八成问题出在这条链路的某个环节。2.3 环境准备工作Npcap 驱动与软件包引入多数人第一次跑起来失败不是代码问题是环境没准备好。SharpPcap 在 Windows 上依赖 Npcap 驱动这个驱动需要在官网单独安装。安装时有个选框「Support loopback traffic」建议勾上不然回环127.0.0.1流量抓不到。装完之后在设备管理器里能看到对应的「Npcap Loopback Adapter」或叫「Npcap Loopback Adapter」的虚拟网卡这就是后面抓回环包时要选的那个网卡。VS 工程里引入包很简单我用 NuGet 搜索 SharpPcap 装上它依赖的 PacketDotNet 会被自动带下来。注意版本问题老版本的 API 命名和参数跟我下面写的可能略有差异代码里如果标了DeviceModes.Promiscuous或者Open方法编译不过说明 SharpPcap 版本大版本换了这个坑在第 5 章专门讲。提示代码里用到的 API 名称在不同小版本之间基本稳定但大版本如 4.x 到 5.x有过打断性变更主要影响Open()方法的参数和GetPacket()的返回值类型。安装 NuGet 包时看一眼版本号按我代码里的写法不会有大问题。3. 实战捕获 IP/TCP/UDP 数据包并解析3.1 枚举网卡并打开设备第一步永远是查看机器上有哪些网卡设备。SharpPcap 的CaptureDeviceList.Instance会列出所有可用的捕获设备包括物理网卡、虚拟网卡、回环适配器。这一步跑通了才能谈后续。我一般先把列表全部打印出来确认当前用的是哪一块网卡而不是直接闭着眼睛拿devices[0]。如果列表为空那几乎可以肯定 Npcap 驱动没装好或者装了但没生效。using System; using SharpPcap; class Program { static void Main() { var devices CaptureDeviceList.Instance; if (devices.Count 0) { Console.WriteLine(未检测到任何网卡请确认已安装 Npcap 驱动); return; } for (int i 0; i devices.Count; i) { var dev devices[i]; Console.WriteLine($序号 {i}: {dev.Name} | {dev.Description}); } } }这段代码是最小验证跑通了说明环境没问题。dev.Name是类似\Device\NPF_{GUID}的设备标识dev.Description是网卡的人类可读名称比如「Realtek PCIe GbE Family Controller」。多网卡机器上Description 能帮你快速分辨哪块是物理网卡、哪块是虚拟机的虚拟网卡。3.2 注册回调并启动捕获拿到网卡设备对象之后核心玩法是订阅OnPacketArrival事件。这个事件是异步触发的网卡每收到一个符合过滤条件的帧回调就会执行一次。回调代码执行得越快越好因为它是阻塞式的——你的逻辑耗时太长后面来的包就会堆积在缓冲里导致抓包丢失。using System; using SharpPcap; class Sniffer { static void Main() { var device CaptureDeviceList.Instance[0]; device.OnPacketArrival OnPacketArrival; device.Open(DeviceModes.Promiscuous, 1000); Console.WriteLine(开始抓包回车停止...); device.StartCapture(); Console.ReadLine(); device.StopCapture(); device.Close(); } static void OnPacketArrival(object sender, PacketCapture e) { var raw e.GetPacket(); Console.WriteLine($收到数据包: 长度 {raw.Data.Length} 字节); } }Open(DeviceModes.Promiscuous, 1000)的两个参数分别是抓包模式和读取超时毫秒数。混杂模式前面说过了——如果你只想抓本机收发可以不开但要捕获局域网内其他设备的通信混杂模式是必须的。第二个参数是ReadTimeout影响接收超时时间1000毫秒是常见值一般业务场景不用改。StartCapture()启动后台线程持续抓包StopCapture()停止。这里有个容易忽略的点OnPacketArrival回调里不能做耗时操作写数据库、复杂计算都要谨慎。回调是同步派发的你卡一秒钟其他包就在缓冲排队。第 6 章的异步队列方案就是专门解决这个问题的。3.3 从原始帧里解析出 IP、TCP、UDP 信息这一节是核心中的核心——把原始字节变成人可读的协议信息。e.GetPacket()拿到的RawPacket包含链路层类型和原始数据要交给 PacketDotNet 的Packet.ParsePacket()来解析。链路层类型通常是LinkLayerType.Ethernet所以解析结果先是一个EthernetPacket但一般不用关心以太网头细节直接用ExtractIPv4Packet()去拿 IP 层信息再拿 TCP 或 UDP 层。using System; using SharpPcap; using PacketDotNet; class Sniffer { static void Main() { var device CaptureDeviceList.Instance[0]; device.OnPacketArrival OnPacketArrival; device.Open(DeviceModes.Promiscuous, 1000); device.StartCapture(); Console.WriteLine(开始抓包...); Console.ReadLine(); device.StopCapture(); device.Close(); } static void OnPacketArrival(object sender, PacketCapture e) { var rawPacket e.GetPacket(); var packet Packet.ParsePacket(rawPacket.LinkLayerType, rawPacket.Data); var ipv4 packet.ExtractIPv4Packet(); if (ipv4 null) return; var tcp packet.ExtractTcpPacket(); var udp packet.ExtractUdpPacket(); if (tcp ! null) { Console.WriteLine( $[TCP] {ipv4.SourceAddress}:{tcp.SourcePort} - ${ipv4.DestinationAddress}:{tcp.DestinationPort}); } if (udp ! null) { Console.WriteLine( $[UDP] {ipv4.SourceAddress}:{udp.SourcePort} - ${ipv4.DestinationAddress}:{udp.DestinationPort}); } } }这段代码实际上已经是一个可用的基础抓包器了。ExtractT()的作用是从解析好的协议栈里逐层寻找指定类型的协议包——比如一个 TCP SYN 包它的链路层是 Ethernet网络层是 IPv4传输层是 TCPExtractTcpPacket()会从已经建立好的协议链上把这个 TCP 头取出来。没有对应协议类型时返回null所以判空是必要的。注意一个细节IP 协议版本。这里只处理了IPv4Packet如果你要抓 IPv6 流量需要换成IPv6Packet或者写两套分支逻辑。实际网络环境里 IPv6 已经大量存在只抓 IPv4 的话会漏掉不少流量。第 4 章的过滤器里我会给出过滤 IPv6 的写法代码侧只需要把ExtractIPv4Packet()换成ExtractIPv6Packet()逻辑完全一样。4. BPF 过滤器指定端口和协议的精确定位4.1 BPF 表达式语法与常用组合在回调里写一堆条件判断去筛端口是新手最容易干的事情但性能很差。正确的做法是使用 BPF 过滤器——它在驱动层面就把不想要的包过滤掉只把符合条件的包送进回调。SharpPcap 在ICaptureDevice上有一个Filter属性设置之前只需要简单一句赋值。过滤表达式语法是 libpcap 风格的下面这张表是我平时最常用到的表达式。过滤目标BPF 表达式说明抓所有 TCP 包tcp只看 TCP 协议抓所有 UDP 包udp只看 UDP 协议抓指定端口port 22443TCP 或 UDP 都命中抓指定 TCP 端口tcp port 22443只匹配 TCP 端口抓指定 UDP 端口udp port 22443只匹配 UDP 端口抓指定源 IPsrc host 192.168.1.10来源地址限定抓指定目的 IPdst host 192.168.1.10目标地址限定指定 IP 和端口组合host 192.168.1.10 and tcp port 80组合条件用and连接排除某端口not port 53去掉 DNS 流量干扰抓 IPv6 流量ip6协议关键字换掉端口、IP、协议三者的组合是最常用的场景。比如你要排查某台设备往 22443 端口发的 UDP 心跳包写udp and port 22443就够了。如果设备 IP 固定再加一层限制udp and host 192.168.1.50 and port 22443。4.2 在 C# 中应用过滤器SharpPcap 里应用过滤器非常简单只需要在打开设备后设置Filter属性的字符串值。但这个属性有个特点它必须在设备打开之后设置而且不同网卡类型上生效的时机略有差异。最稳妥的做法是Open之后立即设置这样可以保证StartCapture之前过滤已经就绪。device.Open(DeviceModes.Promiscuous, 1000); device.Filter udp and port 22443; device.StartCapture();这一行过滤器写好之后OnPacketArrival回调里收到的包全部是「UDP 且端口为 22443」的流量。此时回调里不需要再写任何协议判断逻辑数量急剧下降CPU 消耗也小很多。设置过滤器本身也会花费一定的时间所以我一般在Open和StartCapture之间做这个操作不建议在回调里动态修改 Filter。4.3 抓包场景示例锁死 UDP 22443 端口可以把 3.3 的代码改造一下直接在开头就把过滤器限定死。这种写法在端口监控场景里很实用——比如某个视频监控平台或物联网网关会周期性地往组播或指定地址发送 UDP 包端口固定为 22443你需要验证它是不是在正常工作static void OnPacketArrival(object sender, PacketCapture e) { var rawPacket e.GetPacket(); var packet Packet.ParsePacket(rawPacket.LinkLayerType, rawPacket.Data); var ipv4 packet.ExtractIPv4Packet(); var udp packet.ExtractUdpPacket(); if (ipv4 null || udp null) return; Console.WriteLine( $UDP {ipv4.SourceAddress}:{udp.SourcePort} - ${ipv4.DestinationAddress}:{udp.DestinationPort}, $Payload {udp.PayloadData?.Length ?? 0} 字节); }过滤器已经处理了协议和端口回调里就不用再写协议分支。这里PayloadData是 UDP 包的数据部分?.Length做了空值防御因为极端情况下 UDP 包可能没有负载数据。看到源端口是 22443 说明是对端主动发包看到目的端口是 22443 说明是你这边收到的。日志格式建议加上时间戳和包序号后面排查丢包时才有依据。提示BPF 表达式里port关键字同时匹配源端口和目的端口注意这一点。只关心目的端口时用dst port 22443只关心源端口时用src port 22443。很多人在这一步只写了port 22443结果抓回来一堆反向流量还以为是程序 bug。5. 避坑数据包捕获的常见误区与排错5.1 现象设备列表为空或者打开设备时报「找不到设备」设备列表为空说明 Npcap 驱动程序没有正确加载。常见于两种情况一是装了 WinPcap 而不是 Npcap新版本 SharpPcap 对 WinPcap 的兼容性已经不太好了二是安装 Npcap 时没有勾选「Install Npcap in WinPcap API-compatible Mode」导致 SharpPcap 调用的 API 接口找不到。解决办法是卸载干净后重装 Npcap安装时两个选项全勾上。装完重启一下终端或者 VS让环境变量生效。另一种现象是devices.Count 0但Open抛异常。这时候先看异常信息里是不是包含「The interface is not up」——说明这块网卡处于禁用状态。在 Windows 的网络适配器设置里启用这块网卡或者换一块在用的网卡测试。虚拟机上尤其常见VMware 或 Hyper-V 的虚拟网卡有时候状态不稳定。5.2 现象过滤表达式写入后回落不一致我记得一次把udp port 22443写成udp port 22443结果 Filter 属性设置完没有任何报错回调里一个包都不来。原因就是 BPF 表达式用的是 libpcap 语法逻辑与是and不是 C# 的。更别提还有人写udp || port 22443这个表达式的含义和直觉完全不同——||在 BPF 里是或运算整条表达式的语义变成了「所有 UDP 包以及所有端口 22443 的包」范围反而变大了。解决办法先在命令行用 tcpdumpWindows 上装 Npcap 自带windump或者用 Wireshark 的过滤器调试窗口验证表达式语法。Wireshark 的显示过滤器语法跟 BPF 不完全一样但 BPF 语法在 Wireshark 的抓包过滤器里可以直接试试对了再拷回 C# 代码。我自己后来养成一个习惯任何复杂的过滤器表达式先拿 Wireshark 试一轮再落代码。5.3 现象抓不到 127.0.0.1 回环流量用 SharpPcap 监听本机进程之间的通信比如两个本地服务通过端口 8080 交互结果一个包都抓不到。原因是回环流量走的是虚拟的回环适配器Npcap 默认不抓它。安装 Npcap 时必须勾选「Support loopback traffic」选项之后设备列表里会出现一个叫「Npcap Loopback Adapter」的网卡选中它才能抓到本机回环包。如果已经装了 Npcap 但当时没勾选项不用卸载重装在控制面板的「网络适配器」里看一眼有没有「Npcap Loopback Adapter」这个虚拟网卡。没有的话就要重新跑一遍 Npcap 安装包安装界面勾选 Loopback 支持。这个坑很隐蔽因为设备列表里其他网卡都好好的唯独回环流量静默失效。5.4 现象回调里的包总是被截断成固定长度有阵子抓包发现所有回调里的rawPacket.Data.Length都是 65535还以为是程序 bug。真实原因是 SharpPcap 的抓包快照长度snapshot length默认给的是 65535网卡驱动层面就把超过这个长度的帧直接截断。普通以太网帧最大也就 1514 字节或者 9000 字节巨型帧所以默认值一般够用。但如果你在抓巨型帧Jumbo Frame或者光纤链路的高 MTU 流量65535 不够用。解决办法是在Open之前而不是之后设置快照长度。通常做法是先拿到设备再创建一个DeviceConfiguration对象去配置。这个配置项放的位置不对设置不生效而且不会报错——这又是让人抓狂的点。我后来固定写法就是统一用DeviceConfiguration构建参数再Open不去动那个传统重载。5.5 现象混杂模式设置了但依然抓不到别人的流量网卡开了混杂模式不代表就能抓到所有广播域内的流量。现在的网络设备基本都支持端口镜像Port Mirroring但默认是不开的。你要抓别的设备的流量要么在网络交换机上把这个端口配成镜像口把目标端口流量复制过来要么在无线场景下确保同一个信道。如果什么网络侧配置都不动开了混杂模式也只能抓到本机收发和广播包别的设备单播流量照样见不到。还有一种情况虚拟机的虚拟网卡在桥接模式下的混杂模式行为很奇怪某些虚拟化平台默认会过滤掉非本机 MAC 的帧。如果虚拟机里开了混杂模式但收不到广播域内其他设备的包去虚拟化平台的安全设置里找「允许混杂模式」的选项打开之后才能正常。6. 进阶异步队列化处理把抓包从工具变成服务第 3 章的代码在包量小的时候没毛病但流量一大比如几十 Mbps 以上的抓包回调里那个Console.WriteLine就成了瓶颈。OnPacketArrival是同步派发的——回调返回之前新的包只能在缓冲里等着。如果你的分析逻辑涉及组合、聚合、持久化回调里跑这些操作丢包率会直线上升。我的做法是把回调设计成「只进队列立刻返回」真正耗时的分析逻辑放到独立消费者线程里跑。这样回调的执行时间从几毫秒降到微秒级抓包缓冲不会被拖垮。思路拆解如下回调里queue.Enqueue(packet)消费者线程循环queue.TryDequeue再处理。using System; using System.Collections.Concurrent; using System.Threading; using SharpPcap; using PacketDotNet; class QueueSniffer { private static readonly ConcurrentQueueRawPacket PacketQueue new(); private static readonly int MaxQueueSize 10000; static void Main() { var device CaptureDeviceList.Instance[0]; device.OnPacketArrival OnPacketArrival; device.Open(DeviceModes.Promiscuous, 1000); device.Filter udp or tcp; device.StartCapture(); for (int i 0; i 4; i) { var thread new Thread(ConsumerLoop) { IsBackground true }; thread.Start(); } Console.WriteLine(抓包进行中回车退出); Console.ReadLine(); device.StopCapture(); device.Close(); } static void OnPacketArrival(object sender, PacketCapture e) { if (PacketQueue.Count MaxQueueSize) { return; } PacketQueue.Enqueue(e.GetPacket()); } static void ConsumerLoop() { while (true) { if (PacketQueue.TryDequeue(out var rawPacket)) { ProcessPacket(rawPacket); } else { Thread.Sleep(1); } } } static void ProcessPacket(RawPacket rawPacket) { var packet Packet.ParsePacket(rawPacket.LinkLayerType, rawPacket.Data); var ipv4 packet.ExtractIPv4Packet(); var tcp packet.ExtractTcpPacket(); var udp packet.ExtractUdpPacket(); if (ipv4 null) return; string protocol tcp ! null ? $TCP:{tcp.DestinationPort} : udp ! null ? $UDP:{udp.DestinationPort} : OTHER; Console.WriteLine(${DateTime.Now:HH:mm:ss.fff} {ipv4.SourceAddress} - {ipv4.DestinationAddress} {protocol}); } }队列用ConcurrentQueue线程安全且性能不错。消费者线程开了 4 个并行处理数据包配合Thread.Sleep(1)防止空转吃满 CPU。MaxQueueSize不为别的就是防止内存被撑爆——如果消费者处理不过来宁可丢包也不能把内存打满这是生产级抓包器必须做的取舍。之后如果要做一个常驻在服务器上的抓包工具可以在这个基础上加三样东西一是把ProcessPacket里的信息批量写入文件用MemoryStream缓存一批再一次写别一条一条写二是加一个统计窗口每 10 秒打印一次捕获速率用来观察是否丢包三是对 IP 包做一个简单的计数表用ConcurrentDictionarystring, long按源 IP 聚合流量排名看看谁在占用带宽。从那以后我每次做抓包工具都强制自己先过一遍这五件事确认驱动版本和安装选项、用 Wireshark 验证 BPF 表达式、区分物理网卡和回环适配器、打开设备前配好快照长度、回调里绝不放耗时操作。这套流程帮我避掉了至少一半的「灵异问题」希望也能帮到你。本文还有配套的精品资源点击获取
简介面向C#网络编程学习者与开发者的数据包捕获解析完整项目基于Socket编程实现指定端口的IP、TCP、UDP报文监听与解析可辅助网络排错、协议学习和安全分析。压缩包共82个文件、约1.12MB以24个C#源代码和3个可执行程序为主体附带界面资源、图标图片、项目配置及升级报告可在Visual Studio中直接打开编译。项目完整演示了从创建Socket、绑定本地端点、持续接收数据到逐层解析IP头、TCP头与UDP头的流程提取源/目标地址、端口号、序列号、确认号、窗口大小等关键字段并以可读形式展示还提供过滤设置对话框方便按端口或协议筛选流量。整个工程结构清晰主界面、过滤设置、关于对话框等模块划分明确适合希望从套接字层面深入理解网络协议的开发者参考。目前已有741人下载学习既适合作为课程设计也可作为自定义抓包工具的二次开发基础。1. C# 抓包从哪儿入手一张网卡、三层解析、无数次踩坑如果你用 C# 做过网络调试迟早会遇到一个需求想看看某个端口上到底跑了什么协议、什么 IP 在发包、TCP 还是 UDP。很多人第一次上手就直接开搞原始套接字SocketType.Raw结果发现要么收到一堆残缺帧要么数据包里的端口和 IP 对齐不上玄学问题频发。我在拆这个 C# 抓包项目时最终选的是 SharpPcap 抓底层帧、PacketDotNet 解析协议配合 BPF 过滤器来定位指定端口。这套组合把最难的网卡驱动适配和协议拆包都封装好了剩下要做的只是把回调里的数据拿过来分析。适合做端口监控、协议调试、局域网数据流分析但又不想从零写协议栈的开发者。2. 选型与原理为什么是 SharpPcap 而不是原始套接字2.1 原始套接字能抓包吗边界和限制原始套接字确实能捕获 IP 层的数据尤其在 Linux 上socket(AF_INET, SOCK_RAW, IPPROTO_TCP)配合setsockopt(IP_HDRINCL)可以拿到带 IP 头的原始报文。但在 Windows 平台上这条路走得非常别扭。Windows 对原始套接字的限制是出了名的TCP 流量基本收不到被系统协议栈直接处理掉了UDP 也只能收收入站数据出站包要到很后面才可能抓到而且抓到的数据往往已经被重组或修改过。实际排查中更麻烦的是原始套接字只能抓到本机进程收发的那部分数据根本满足不了「监控网段内其他设备通信」这类诉求。比如你写了一个服务要监视某个设备往 22443 端口发的 UDP 心跳包原始套接字方案直接把范围卡死了。它不需要网卡驱动支持混杂模式不像包捕获库那样能把网卡上流通的每一个帧都拷贝一份出来。混杂模式是个关键点只有让网卡把不是发给自己的包也收上来才能在交换机的镜像口或者无线监听场景里拿到完整的链路流量这一层逻辑原始套接字做不到。所以我的结论很直接如果只是抓自己进程的收发数据用原始套接字凑合但凡是「抓整个网卡上的包」「按端口/协议过滤」「要还原 IP、TCP、UDP 头信息」老老实实走驱动级抓包。SharpPcap 封装的是 libpcap 那套接口在 Windows 上背后是 Npcap 驱动在 Linux 上是 libpcap 本身跨平台逻辑一致。2.2 SharpPcap PacketDotNet 的分工和运行时链路SharpPcap 和 PacketDotNet 是两件事很多人搞混。SharpPcap 管的是抓包动作本身枚举网卡、打开设备、设置混杂模式、设置过滤器、启动/停止捕获、把原始帧通过回调抛出来。它不负责解析数据包内容你从回调里拿到的是一个RawCapture对象里面是LinkLayerType和原始字节数组。看到一堆字节直接懵的是 PacketDotNet 出场的地方。PacketDotNet 负责把字节解析成结构化的包对象以太网帧、IPv4 包、IPv6 包、TCP 包、UDP 包、ICMP 包等。它提供了Packet.ParsePacket入口传入链路层类型和原始字节返回一个Packet对象然后可以用ExtractT()在协议栈里逐层抽取你关心的协议头。运行时链路大概是这样的网卡收到帧后驱动在混杂模式下先复制一份交给 Npcap 的过滤引擎BPFBerkeley Packet Filter过滤器在这里决定这个帧是放行还是丢掉放行的帧被送入 SharpPcap 的接收缓冲接着触发OnPacketArrival事件回调。你在回调里拿到的包已经是驱动和过滤器处理过之后的结果。理解这条链路对排查问题至关重要——你设置的端口过滤条件不生效或者抓到的包数量对不上八成问题出在这条链路的某个环节。2.3 环境准备工作Npcap 驱动与软件包引入多数人第一次跑起来失败不是代码问题是环境没准备好。SharpPcap 在 Windows 上依赖 Npcap 驱动这个驱动需要在官网单独安装。安装时有个选框「Support loopback traffic」建议勾上不然回环127.0.0.1流量抓不到。装完之后在设备管理器里能看到对应的「Npcap Loopback Adapter」或叫「Npcap Loopback Adapter」的虚拟网卡这就是后面抓回环包时要选的那个网卡。VS 工程里引入包很简单我用 NuGet 搜索 SharpPcap 装上它依赖的 PacketDotNet 会被自动带下来。注意版本问题老版本的 API 命名和参数跟我下面写的可能略有差异代码里如果标了DeviceModes.Promiscuous或者Open方法编译不过说明 SharpPcap 版本大版本换了这个坑在第 5 章专门讲。提示代码里用到的 API 名称在不同小版本之间基本稳定但大版本如 4.x 到 5.x有过打断性变更主要影响Open()方法的参数和GetPacket()的返回值类型。安装 NuGet 包时看一眼版本号按我代码里的写法不会有大问题。3. 实战捕获 IP/TCP/UDP 数据包并解析3.1 枚举网卡并打开设备第一步永远是查看机器上有哪些网卡设备。SharpPcap 的CaptureDeviceList.Instance会列出所有可用的捕获设备包括物理网卡、虚拟网卡、回环适配器。这一步跑通了才能谈后续。我一般先把列表全部打印出来确认当前用的是哪一块网卡而不是直接闭着眼睛拿devices[0]。如果列表为空那几乎可以肯定 Npcap 驱动没装好或者装了但没生效。using System; using SharpPcap; class Program { static void Main() { var devices CaptureDeviceList.Instance; if (devices.Count 0) { Console.WriteLine(未检测到任何网卡请确认已安装 Npcap 驱动); return; } for (int i 0; i devices.Count; i) { var dev devices[i]; Console.WriteLine($序号 {i}: {dev.Name} | {dev.Description}); } } }这段代码是最小验证跑通了说明环境没问题。dev.Name是类似\Device\NPF_{GUID}的设备标识dev.Description是网卡的人类可读名称比如「Realtek PCIe GbE Family Controller」。多网卡机器上Description 能帮你快速分辨哪块是物理网卡、哪块是虚拟机的虚拟网卡。3.2 注册回调并启动捕获拿到网卡设备对象之后核心玩法是订阅OnPacketArrival事件。这个事件是异步触发的网卡每收到一个符合过滤条件的帧回调就会执行一次。回调代码执行得越快越好因为它是阻塞式的——你的逻辑耗时太长后面来的包就会堆积在缓冲里导致抓包丢失。using System; using SharpPcap; class Sniffer { static void Main() { var device CaptureDeviceList.Instance[0]; device.OnPacketArrival OnPacketArrival; device.Open(DeviceModes.Promiscuous, 1000); Console.WriteLine(开始抓包回车停止...); device.StartCapture(); Console.ReadLine(); device.StopCapture(); device.Close(); } static void OnPacketArrival(object sender, PacketCapture e) { var raw e.GetPacket(); Console.WriteLine($收到数据包: 长度 {raw.Data.Length} 字节); } }Open(DeviceModes.Promiscuous, 1000)的两个参数分别是抓包模式和读取超时毫秒数。混杂模式前面说过了——如果你只想抓本机收发可以不开但要捕获局域网内其他设备的通信混杂模式是必须的。第二个参数是ReadTimeout影响接收超时时间1000毫秒是常见值一般业务场景不用改。StartCapture()启动后台线程持续抓包StopCapture()停止。这里有个容易忽略的点OnPacketArrival回调里不能做耗时操作写数据库、复杂计算都要谨慎。回调是同步派发的你卡一秒钟其他包就在缓冲排队。第 6 章的异步队列方案就是专门解决这个问题的。3.3 从原始帧里解析出 IP、TCP、UDP 信息这一节是核心中的核心——把原始字节变成人可读的协议信息。e.GetPacket()拿到的RawPacket包含链路层类型和原始数据要交给 PacketDotNet 的Packet.ParsePacket()来解析。链路层类型通常是LinkLayerType.Ethernet所以解析结果先是一个EthernetPacket但一般不用关心以太网头细节直接用ExtractIPv4Packet()去拿 IP 层信息再拿 TCP 或 UDP 层。using System; using SharpPcap; using PacketDotNet; class Sniffer { static void Main() { var device CaptureDeviceList.Instance[0]; device.OnPacketArrival OnPacketArrival; device.Open(DeviceModes.Promiscuous, 1000); device.StartCapture(); Console.WriteLine(开始抓包...); Console.ReadLine(); device.StopCapture(); device.Close(); } static void OnPacketArrival(object sender, PacketCapture e) { var rawPacket e.GetPacket(); var packet Packet.ParsePacket(rawPacket.LinkLayerType, rawPacket.Data); var ipv4 packet.ExtractIPv4Packet(); if (ipv4 null) return; var tcp packet.ExtractTcpPacket(); var udp packet.ExtractUdpPacket(); if (tcp ! null) { Console.WriteLine( $[TCP] {ipv4.SourceAddress}:{tcp.SourcePort} - ${ipv4.DestinationAddress}:{tcp.DestinationPort}); } if (udp ! null) { Console.WriteLine( $[UDP] {ipv4.SourceAddress}:{udp.SourcePort} - ${ipv4.DestinationAddress}:{udp.DestinationPort}); } } }这段代码实际上已经是一个可用的基础抓包器了。ExtractT()的作用是从解析好的协议栈里逐层寻找指定类型的协议包——比如一个 TCP SYN 包它的链路层是 Ethernet网络层是 IPv4传输层是 TCPExtractTcpPacket()会从已经建立好的协议链上把这个 TCP 头取出来。没有对应协议类型时返回null所以判空是必要的。注意一个细节IP 协议版本。这里只处理了IPv4Packet如果你要抓 IPv6 流量需要换成IPv6Packet或者写两套分支逻辑。实际网络环境里 IPv6 已经大量存在只抓 IPv4 的话会漏掉不少流量。第 4 章的过滤器里我会给出过滤 IPv6 的写法代码侧只需要把ExtractIPv4Packet()换成ExtractIPv6Packet()逻辑完全一样。4. BPF 过滤器指定端口和协议的精确定位4.1 BPF 表达式语法与常用组合在回调里写一堆条件判断去筛端口是新手最容易干的事情但性能很差。正确的做法是使用 BPF 过滤器——它在驱动层面就把不想要的包过滤掉只把符合条件的包送进回调。SharpPcap 在ICaptureDevice上有一个Filter属性设置之前只需要简单一句赋值。过滤表达式语法是 libpcap 风格的下面这张表是我平时最常用到的表达式。过滤目标BPF 表达式说明抓所有 TCP 包tcp只看 TCP 协议抓所有 UDP 包udp只看 UDP 协议抓指定端口port 22443TCP 或 UDP 都命中抓指定 TCP 端口tcp port 22443只匹配 TCP 端口抓指定 UDP 端口udp port 22443只匹配 UDP 端口抓指定源 IPsrc host 192.168.1.10来源地址限定抓指定目的 IPdst host 192.168.1.10目标地址限定指定 IP 和端口组合host 192.168.1.10 and tcp port 80组合条件用and连接排除某端口not port 53去掉 DNS 流量干扰抓 IPv6 流量ip6协议关键字换掉端口、IP、协议三者的组合是最常用的场景。比如你要排查某台设备往 22443 端口发的 UDP 心跳包写udp and port 22443就够了。如果设备 IP 固定再加一层限制udp and host 192.168.1.50 and port 22443。4.2 在 C# 中应用过滤器SharpPcap 里应用过滤器非常简单只需要在打开设备后设置Filter属性的字符串值。但这个属性有个特点它必须在设备打开之后设置而且不同网卡类型上生效的时机略有差异。最稳妥的做法是Open之后立即设置这样可以保证StartCapture之前过滤已经就绪。device.Open(DeviceModes.Promiscuous, 1000); device.Filter udp and port 22443; device.StartCapture();这一行过滤器写好之后OnPacketArrival回调里收到的包全部是「UDP 且端口为 22443」的流量。此时回调里不需要再写任何协议判断逻辑数量急剧下降CPU 消耗也小很多。设置过滤器本身也会花费一定的时间所以我一般在Open和StartCapture之间做这个操作不建议在回调里动态修改 Filter。4.3 抓包场景示例锁死 UDP 22443 端口可以把 3.3 的代码改造一下直接在开头就把过滤器限定死。这种写法在端口监控场景里很实用——比如某个视频监控平台或物联网网关会周期性地往组播或指定地址发送 UDP 包端口固定为 22443你需要验证它是不是在正常工作static void OnPacketArrival(object sender, PacketCapture e) { var rawPacket e.GetPacket(); var packet Packet.ParsePacket(rawPacket.LinkLayerType, rawPacket.Data); var ipv4 packet.ExtractIPv4Packet(); var udp packet.ExtractUdpPacket(); if (ipv4 null || udp null) return; Console.WriteLine( $UDP {ipv4.SourceAddress}:{udp.SourcePort} - ${ipv4.DestinationAddress}:{udp.DestinationPort}, $Payload {udp.PayloadData?.Length ?? 0} 字节); }过滤器已经处理了协议和端口回调里就不用再写协议分支。这里PayloadData是 UDP 包的数据部分?.Length做了空值防御因为极端情况下 UDP 包可能没有负载数据。看到源端口是 22443 说明是对端主动发包看到目的端口是 22443 说明是你这边收到的。日志格式建议加上时间戳和包序号后面排查丢包时才有依据。提示BPF 表达式里port关键字同时匹配源端口和目的端口注意这一点。只关心目的端口时用dst port 22443只关心源端口时用src port 22443。很多人在这一步只写了port 22443结果抓回来一堆反向流量还以为是程序 bug。5. 避坑数据包捕获的常见误区与排错5.1 现象设备列表为空或者打开设备时报「找不到设备」设备列表为空说明 Npcap 驱动程序没有正确加载。常见于两种情况一是装了 WinPcap 而不是 Npcap新版本 SharpPcap 对 WinPcap 的兼容性已经不太好了二是安装 Npcap 时没有勾选「Install Npcap in WinPcap API-compatible Mode」导致 SharpPcap 调用的 API 接口找不到。解决办法是卸载干净后重装 Npcap安装时两个选项全勾上。装完重启一下终端或者 VS让环境变量生效。另一种现象是devices.Count 0但Open抛异常。这时候先看异常信息里是不是包含「The interface is not up」——说明这块网卡处于禁用状态。在 Windows 的网络适配器设置里启用这块网卡或者换一块在用的网卡测试。虚拟机上尤其常见VMware 或 Hyper-V 的虚拟网卡有时候状态不稳定。5.2 现象过滤表达式写入后回落不一致我记得一次把udp port 22443写成udp port 22443结果 Filter 属性设置完没有任何报错回调里一个包都不来。原因就是 BPF 表达式用的是 libpcap 语法逻辑与是and不是 C# 的。更别提还有人写udp || port 22443这个表达式的含义和直觉完全不同——||在 BPF 里是或运算整条表达式的语义变成了「所有 UDP 包以及所有端口 22443 的包」范围反而变大了。解决办法先在命令行用 tcpdumpWindows 上装 Npcap 自带windump或者用 Wireshark 的过滤器调试窗口验证表达式语法。Wireshark 的显示过滤器语法跟 BPF 不完全一样但 BPF 语法在 Wireshark 的抓包过滤器里可以直接试试对了再拷回 C# 代码。我自己后来养成一个习惯任何复杂的过滤器表达式先拿 Wireshark 试一轮再落代码。5.3 现象抓不到 127.0.0.1 回环流量用 SharpPcap 监听本机进程之间的通信比如两个本地服务通过端口 8080 交互结果一个包都抓不到。原因是回环流量走的是虚拟的回环适配器Npcap 默认不抓它。安装 Npcap 时必须勾选「Support loopback traffic」选项之后设备列表里会出现一个叫「Npcap Loopback Adapter」的网卡选中它才能抓到本机回环包。如果已经装了 Npcap 但当时没勾选项不用卸载重装在控制面板的「网络适配器」里看一眼有没有「Npcap Loopback Adapter」这个虚拟网卡。没有的话就要重新跑一遍 Npcap 安装包安装界面勾选 Loopback 支持。这个坑很隐蔽因为设备列表里其他网卡都好好的唯独回环流量静默失效。5.4 现象回调里的包总是被截断成固定长度有阵子抓包发现所有回调里的rawPacket.Data.Length都是 65535还以为是程序 bug。真实原因是 SharpPcap 的抓包快照长度snapshot length默认给的是 65535网卡驱动层面就把超过这个长度的帧直接截断。普通以太网帧最大也就 1514 字节或者 9000 字节巨型帧所以默认值一般够用。但如果你在抓巨型帧Jumbo Frame或者光纤链路的高 MTU 流量65535 不够用。解决办法是在Open之前而不是之后设置快照长度。通常做法是先拿到设备再创建一个DeviceConfiguration对象去配置。这个配置项放的位置不对设置不生效而且不会报错——这又是让人抓狂的点。我后来固定写法就是统一用DeviceConfiguration构建参数再Open不去动那个传统重载。5.5 现象混杂模式设置了但依然抓不到别人的流量网卡开了混杂模式不代表就能抓到所有广播域内的流量。现在的网络设备基本都支持端口镜像Port Mirroring但默认是不开的。你要抓别的设备的流量要么在网络交换机上把这个端口配成镜像口把目标端口流量复制过来要么在无线场景下确保同一个信道。如果什么网络侧配置都不动开了混杂模式也只能抓到本机收发和广播包别的设备单播流量照样见不到。还有一种情况虚拟机的虚拟网卡在桥接模式下的混杂模式行为很奇怪某些虚拟化平台默认会过滤掉非本机 MAC 的帧。如果虚拟机里开了混杂模式但收不到广播域内其他设备的包去虚拟化平台的安全设置里找「允许混杂模式」的选项打开之后才能正常。6. 进阶异步队列化处理把抓包从工具变成服务第 3 章的代码在包量小的时候没毛病但流量一大比如几十 Mbps 以上的抓包回调里那个Console.WriteLine就成了瓶颈。OnPacketArrival是同步派发的——回调返回之前新的包只能在缓冲里等着。如果你的分析逻辑涉及组合、聚合、持久化回调里跑这些操作丢包率会直线上升。我的做法是把回调设计成「只进队列立刻返回」真正耗时的分析逻辑放到独立消费者线程里跑。这样回调的执行时间从几毫秒降到微秒级抓包缓冲不会被拖垮。思路拆解如下回调里queue.Enqueue(packet)消费者线程循环queue.TryDequeue再处理。using System; using System.Collections.Concurrent; using System.Threading; using SharpPcap; using PacketDotNet; class QueueSniffer { private static readonly ConcurrentQueueRawPacket PacketQueue new(); private static readonly int MaxQueueSize 10000; static void Main() { var device CaptureDeviceList.Instance[0]; device.OnPacketArrival OnPacketArrival; device.Open(DeviceModes.Promiscuous, 1000); device.Filter udp or tcp; device.StartCapture(); for (int i 0; i 4; i) { var thread new Thread(ConsumerLoop) { IsBackground true }; thread.Start(); } Console.WriteLine(抓包进行中回车退出); Console.ReadLine(); device.StopCapture(); device.Close(); } static void OnPacketArrival(object sender, PacketCapture e) { if (PacketQueue.Count MaxQueueSize) { return; } PacketQueue.Enqueue(e.GetPacket()); } static void ConsumerLoop() { while (true) { if (PacketQueue.TryDequeue(out var rawPacket)) { ProcessPacket(rawPacket); } else { Thread.Sleep(1); } } } static void ProcessPacket(RawPacket rawPacket) { var packet Packet.ParsePacket(rawPacket.LinkLayerType, rawPacket.Data); var ipv4 packet.ExtractIPv4Packet(); var tcp packet.ExtractTcpPacket(); var udp packet.ExtractUdpPacket(); if (ipv4 null) return; string protocol tcp ! null ? $TCP:{tcp.DestinationPort} : udp ! null ? $UDP:{udp.DestinationPort} : OTHER; Console.WriteLine(${DateTime.Now:HH:mm:ss.fff} {ipv4.SourceAddress} - {ipv4.DestinationAddress} {protocol}); } }队列用ConcurrentQueue线程安全且性能不错。消费者线程开了 4 个并行处理数据包配合Thread.Sleep(1)防止空转吃满 CPU。MaxQueueSize不为别的就是防止内存被撑爆——如果消费者处理不过来宁可丢包也不能把内存打满这是生产级抓包器必须做的取舍。之后如果要做一个常驻在服务器上的抓包工具可以在这个基础上加三样东西一是把ProcessPacket里的信息批量写入文件用MemoryStream缓存一批再一次写别一条一条写二是加一个统计窗口每 10 秒打印一次捕获速率用来观察是否丢包三是对 IP 包做一个简单的计数表用ConcurrentDictionarystring, long按源 IP 聚合流量排名看看谁在占用带宽。从那以后我每次做抓包工具都强制自己先过一遍这五件事确认驱动版本和安装选项、用 Wireshark 验证 BPF 表达式、区分物理网卡和回环适配器、打开设备前配好快照长度、回调里绝不放耗时操作。这套流程帮我避掉了至少一半的「灵异问题」希望也能帮到你。本文还有配套的精品资源点击获取
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
