简介：原创 MFC+WinpCap 网络嗅探器源码包，面向具备 C++ 与 Windows 开发基础、希望理解抓包原理并动手实践桌面网络工具的学生与开发者。项目以 VS+MFC 组织界面，界面友好，借助 WinpCap 完成数据捕获与协议解析，支持 IPv4、IPv6、ARP、ICMP、TCP、UDP、HTTP 等协议，覆盖网络层、传输层与应用层的常见分析对象，可用于课程设计、协议分析练习以及小型嗅探工具的二次开发参考。压缩包共 22 个文件，约 1.92MB，其中有 7 个 h 头文件、4 个 cpp 源文件，并配有 sln/vcproj 工程配置、rc/rc2 资源脚本、ico/png 图标及少量配置说明文件，源码、界面资源与工程结构相对完整，便于直接打开编译并按模块阅读。已有 5406 人学习下载，适合参考其 MFC 界面组织、WinpCap 调用流程、协议字段解析和捕获结果展示方式，快速建立从抓包到界面呈现的整体实现思路，对课程设计选题与网络协议教学演示也有一定参考价值。

1. 从一次抓包翻车说起：MFC 加 WinpCap 到底能做什么

很多人对网络嗅探器的第一印象，是黑客电影里那种把整块网卡流量全部显示到屏幕上的工具。我当年也信了这个说法，于是用 MFC 手工搭了一套看起来很像样的界面，结果第一次在自己的机器上运行就出了错：界面上一个包都不显示，日志区里全是空记录。回来后我逐段排查才明白：嗅探器真正难的部分并不是“抓到包”，而是把自己的网卡调到混杂模式、把驱动层交给它的字节流正确地解析成以太网帧、IP 头和 TCP/UDP 段，再稳定地送到界面上而不让 UI 卡死。这套原创的 MFC 与 WinPcap 网络嗅探器，正好把这几个关键步骤完整地演示了一遍：用 VS 建立工程、挂上 WinPcap 的库头、选网卡、开抓包回调和协议解析都在里面。下面我就按自己实际对比过的几个实现思路，讲透它适合谁用、哪几个地方最容易出错，以及新手照着做时该按什么顺序推进。

2. 选型先看边界：MFC 与 WinPcap 组合的四个判断维度

做网络嗅探这件事，市面上能选的技术路径不少：WinPcap 或 Npcap 这类抓包驱动层、Raw Socket 原生套接字、WinDivert 这类中间层过滤方案，界面也有 MFC、Qt、控制台几种做法。这份资源选的是 MFC 与 WinPcap 的组合，这不是唯一解，但在“Windows 桌面学习型嗅探器”这个具体目标下，它的取舍逻辑是清晰的。我一般会从四个维度去比：底层能力是否足够、开发成本是否可控、调试信息是否可见、跨版本兼容是否省心。把这几项摆开来看，比笼统地说“哪个好”有用得多。

2.1 抓包能力对比：WinPcap、Raw Socket 与中间层方案

第一个维度是底层能拿到什么。WinPcap 走的是 NDIS 中间层驱动，装好之后由驱动把网卡收到的原始帧直接递到用户态，所以它拿得到完整的以太网帧首部，也能主动把网卡设成混杂模式（promiscuous mode），看到的不只是发给本机的包。Raw Socket 则是系统协议栈留给应用层的接口，SOCK_RAW 加上 IPPROTO_IP 能收到 IP 层以上的数据，但以太网帧头通常拿不到，混杂模式的设置在 Windows 上也不那么直接，很多场景只能看到进出本机的内容。WinDivert 更偏“拦截加改包”，它的强项是防火墙式的过滤与重写，用来做纯监听嗅探有点重。

如果你要做的是“看清楚一个包从头到尾长什么样”，WinPcap 这条路的性价比最高；如果你只是想在应用层收几个自定义报文，Raw Socket 足够而且不用额外装东西。这份资源的目标显然是前者，所以选 WinPcap 是对的。

2.2 界面选型对比：MFC、Qt 与控制台的取舍

第二个维度是界面。很多人觉得 MFC 已经是老技术，不该再用。这话在“做新产品”的语境下成立，在“学 Windows 桌面程序怎么和底层驱动交互”的语境下就不成立了。MFC 的文档视图、消息映射、控件封装虽然繁琐，但它和 VS 的调试器、资源编辑器结合得最紧，断点打在消息处理函数里能一步步看到控件状态，这对排查“为什么包抓到了却显示不出来”极其有用。

我的判断是：如果你的目标是先把抓包链路跑通、把解析逻辑写对，界面用什么其实次要，甚至可以先写一个控制台版本把回调跑起来，再套 MFC 壳。这份资源直接把 MFC 界面和抓包逻辑放在一起，好处是省掉了你自己搭框架的时间，坏处是初学者容易把界面问题和抓包问题混在一起排查，这就是后面要专门讲的坑。

2.3 判断依据：什么情况下这份资源真正合用

第三个维度要落到人身上。我把使用者分成三类，对应的价值点完全不同。第一类是刚学完计算机网络、想看看课本上的以太网帧和 IP 首部在真实流量里长什么样的学生，这类人最需要的是“能跑起来、能看到十六进制和字段对照”的完整工程。第二类是要在 Windows 上做小工具、需要快速拿到一份可编译的抓包骨架的开发者，这类人关心的是工程配置、库依赖、回调注册这几处能不能直接抄。第三类是已经会抓包、想研究 BPF 过滤表达式怎么写、怎么在回调里做初步筛选的老手，这类人看的是过滤逻辑和性能处理。

这三类人共用的判断标准是：资源是否把“驱动加载、设备枚举、回调注册、包解析、界面刷新”这条链完整串起来了。缺任何一环，新手都会卡住。反过来说，如果你的需求是跨平台、要高吞吐量或者要做深度协议重组，这份资源就不合适，那是另一个量级的事，别硬套。

2.4 前置条件清单：动手前必须确认的四件事

第四个维度是环境。WinPcap 这套东西对运行环境有硬性要求，动手前我建议先把这四件事确认掉，能省掉大量无效调试。

• 开发工具：Visual Studio 的 MFC 组件要在安装时勾选，默认安装往往不带，缺了会在建工程时报找不到 afxwin.h。
• 驱动运行时：目标机器要装 WinPcap 的运行时，否则 pcap_findalldevs 会返回空列表，程序看起来“没网卡”。
• 库与头文件：工程要额外配置 include 目录和 lib 目录，链接 wpcap.lib 与 ws2_32.lib，这两步漏一个就是一堆链接错误。
• 权限：枚举设备和打开适配器需要管理员权限，普通用户跑起来大概率在 pcap_open_live 处失败。

这四项里最容易被忽略的是 MFC 组件和权限，前者表现为编译期报错，后者表现为运行期静默失败，两者的排查方向完全相反。

3. 把链路跑通：从设备枚举到回调解析的完整步骤

选型讲完，进入能照着做的部分。这一章按真实执行顺序推进：先让程序找到网卡，再让驱动开始交付数据，然后把字节流解析成可读字段，最后把结果安全地送到界面上。每一步我都会说清楚失败时该看哪里，因为这套东西的报错信息很少，多数时候是“没反应”，只能靠判断。

3.1 设备枚举与适配器选择：第一步就不能想当然

WinPcap 的第一步是拿到本机所有可抓包的设备列表。这里有个细节很多人不知道：pcap_findalldevs 返回的列表里不只有物理网卡，还可能有回环适配器、虚拟网卡、甚至一些名字很怪的伪设备。直接取第一个往往抓不到你想看的流量。

pcap_if_t *alldevs = nullptr; pcap_if_t *dev = nullptr; char errbuf[PCAP_ERRBUF_SIZE] = {0}; // 枚举所有可抓包设备，失败时 errbuf 里有原因 if (pcap_findalldevs(&alldevs, errbuf) == -1) { // 常见原因：驱动未安装、权限不足 return false; } // 遍历并打印，让用户自己选，不要默认取第一个 int index = 0; for (dev = alldevs; dev != nullptr; dev = dev->next) { // 描述可能为空，名字一定有 printf("%d. %s", ++index, dev->name); if (dev->description) { printf(" (%s)", dev->description); } printf("\n"); }

这段的关键在注释里那两行：errbuf一定要读，它是唯一会告诉你“为什么失败”的地方；列表一定要展示给用户选，因为设备顺序在不同机器上不固定。参数上PCAP_ERRBUF_SIZE是 WinPcap 规定的错误缓冲区长度，不要自己拍一个数字。遍历完之后记得在合适的地方调用pcap_freealldevs，否则每次刷新列表都会漏一点内存。如果你的界面上是用下拉框展示设备，就把description拼进去，纯name那一串\Device\NPF_{GUID}对用户毫无意义。

3.2 打开适配器与混杂模式：参数决定你看到什么

选定设备后要打开它，这一步的参数直接决定了抓包行为的边界。混杂模式、超时时间、缓冲区大小这三个参数最容易设错，也最容易被忽略。

pcap_t *handle = nullptr; // snaplen 设 65536 可覆盖绝大多数帧，promisc=1 开混杂模式 // 1000 是读超时毫秒数，决定回调多久被唤醒一次 handle = pcap_open_live(dev->name, 65536, 1, 1000, errbuf); if (handle == nullptr) { // 这里失败八成是权限问题，不是网卡问题 return false; } // 只抓 IPv4 的 TCP 流量，过滤在驱动层做，减少用户态负担 struct bpf_program fp; if (pcap_compile(handle, &fp, "ip and tcp", 1, PCAP_NETMASK_UNKNOWN) == 0) { pcap_setfilter(handle, &fp); pcap_freecode(&fp); }

pcap_open_live的第二个参数是快照长度，设小了会截断大包，解析时字段对不上；设成 65536 基本一劳永逸。第三个参数是混杂模式开关，设 1 才能看到不是发给本机的帧，这也是嗅探器和普通抓包工具的区别所在。第四个参数是超时，设太大会让你以为程序卡住了，设太小又会让回调被频繁唤醒，1000 毫秒是个稳妥的起点。最后的pcap_compile那几行是可选项，但强烈建议加上：过滤表达式在驱动层执行，比把全部流量搬到用户态再筛要省太多，PCAP_NETMASK_UNKNOWN是当你不确定子网掩码时的安全写法。

3.3 回调函数里的解析顺序：从以太网帧到传输层

回调是整份代码的心脏。WinPcap 把原始帧和一个时间戳交给你，剩下的全靠自己拆。解析顺序必须是自外向内：先以太网帧头拿类型字段，判断是不是 0x0800（IPv4），是的话跳过 14 字节进入 IP 头，从 IP 头里拿协议号和首部长度，再跳到 TCP 或 UDP 段。顺序错了后面全错。

void packet_handler(u_char *param, const struct pcap_pkthdr *header, const u_char *data) { // 以太网帧头固定 14 字节：目的 MAC 6 + 源 MAC 6 + 类型 2 if (header->caplen < 14) return; const u_char *ip_ptr = data + 14; u_short eth_type = (data[12] << 8) | data[13]; if (eth_type != 0x0800) return; // 非 IPv4 直接跳过 // IP 首部前 20 字节是固定部分，首部长度在低 4 位，单位是 4 字节 int ip_header_len = (ip_ptr[0] & 0x0F) * 4; if (ip_header_len < 20) return; // 异常首部长度，丢弃 u_char protocol = ip_ptr[9]; const u_char *l4_ptr = ip_ptr + ip_header_len; // protocol == 6 是 TCP，17 是 UDP }

这段代码里最值钱的是(ip_ptr[0] & 0x0F) * 4这一句：IP 首部长度不是固定 20 字节，带选项时会变长，硬编码 20 在某些流量上必然解析错位。同理，以太网帧头也只在没有 VLAN 标签时才是 14 字节，带 802.1Q 标签的帧要多跳 4 字节，这一点资源里如果没处理，遇到带标签的流量就会显示乱码。还有header->caplen和header->len的区别：前者是实际抓到的长度，后者是帧的原始长度，两者不等说明包被截断了，解析前必须用caplen做边界检查，否则越界读取会直接崩。

3.4 线程与界面分离：别让回调阻塞 UI

MFC 程序里最容易翻车的地方，是把抓包回调直接和界面刷新绑在一起。回调跑在 WinPcap 的线程上下文里，一旦你在里面调用控件更新，轻则界面卡顿，重则消息队列死锁。正确的做法是回调只做两件事：拷一份数据、投递到队列，界面线程再从队列里取。

// 回调线程：只拷贝与入队，不碰任何控件 void packet_handler(u_char *param, const struct pcap_pkthdr *header, const u_char *data) { CSnifferDlg *dlg = reinterpret_cast<CSnifferDlg *>(param); if (!dlg) return; // 把帧拷进自定义结构，长度用 caplen dlg->PushPacket(data, header->caplen, header->ts); } // 界面线程：定时器里批量取出，一次性刷新 void CSnifferDlg::OnTimer(UINT_PTR nIDEvent) { std::vector<Packet> batch; if (m_queue.TryPopBatch(batch, 200)) { // 一次最多取 200 条 m_listCtrl.SetRedraw(FALSE); for (const auto &p : batch) { AppendRow(p); // 单条插入，最后统一重绘 } m_listCtrl.SetRedraw(TRUE); } CDialogEx::OnTimer(nIDEvent); }

这里有两个实用技巧。一是批量取出加SetRedraw(FALSE)，逐条插入列表控件再统一重绘，几千条包也不会让界面卡成幻灯片。二是队列要设上限，无界队列在高速流量下会持续增长直到内存耗尽，设个几万条的上限，满了就丢新包并计数提示，比拖垮程序强得多。传参用pcap_open_live之后pcap_loop的user参数把那边的 this 指针带过来，这是 MFC 里回调访问成员最省事的写法，注意生命周期，对话框销毁前必须保证回调线程已经退出。

3.5 抓包循环的启停控制：该停的时候要停得住

pcap_loop是阻塞的，它一直跑，直到抓够指定数量的包或者出错。抓包功能需要能随时启停，这里就必须用pcap_breakloop，而不是粗暴地结束线程。

// 工作线程里启动抓包，cnt 为 -1 表示不限数量 m_thread = std::thread([this]() { pcap_loop(m_handle, -1, packet_handler, reinterpret_cast<u_char *>(this)); }); // 停止时调用，让 pcap_loop 尽快返回 void CSnifferDlg::StopCapture() { if (m_handle) { pcap_breakloop(m_handle); // 异步打断，安全退出 } if (m_thread.joinable()) { m_thread.join(); // 等线程真正结束 } pcap_close(m_handle); // 最后才关闭句柄 m_handle = nullptr; }

顺序不能乱：先pcap_breakloop，再join，最后pcap_close。如果先关句柄再打断，回调线程可能正在使用已释放的内存，这是典型的崩溃来源。pcap_breakloop在多线程下是安全的，它只设置一个标志位，pcap_loop下一轮检查到就返回，所以不用加锁保护句柄本身，但要保证关闭动作发生在线程结束之后。这一套启停逻辑写对了，反复开关几十次都不会出问题，写错了就是随机崩。

4. 避坑清单：嗅探器开发中最常见的五个坑

这套组合能踩的坑，我基本都踩过一遍。下面五条按出现频率排序，每一条都按“现象 → 原因 → 解决”写清楚，遇到问题时对着查比翻文档快。

4.1 现象：设备列表为空，程序提示找不到网卡

原因通常有两个，按概率排：驱动运行时没装，或者程序没有管理员权限。pcap_findalldevs在驱动缺失时返回 -1，在权限不足时可能返回空列表而不报错，两种情况表现相似但根因不同。

解决：先确认目标机器装了 WinPcap 运行时，再右键以管理员身份运行。排查时把errbuf的内容打印出来，驱动缺失和权限不足给出的提示不一样。开发机上还要确认工程是以管理员权限启动的 VS 编译的，否则调试时同样是空列表。

4.2 现象：能抓到包，但解析出来的 IP 地址是乱的

原因多半是解析偏移算错了。最常见的是把 IP 首部长度硬编码成 20 字节，遇到带选项的包就整体错位；其次是没处理 VLAN 标签，帧头不是 14 字节而是 18 字节，后面全跟着偏。

解决：IP 首部长度一律从(ip_ptr[0] & 0x0F) * 4算，不要写死。以太网类型字段读到 0x8100 就说明有 802.1Q 标签，需要再跳 4 字节重新读类型。调试时把原始字节用十六进制打出来，和 Wireshark 里同一个包的字节对照，偏移错没错一眼就看出来了，这比单步调试快得多。

4.3 现象：抓包一开，界面就卡死，鼠标都动不了

原因是回调线程里直接操作了 MFC 控件。WinPcap 的回调不在 UI 线程，跨线程碰控件在 MFC 里是未定义行为，表现出来就是随机卡死或断言失败。

解决：回调里只做数据拷贝和入队，所有控件更新放到 UI 线程的定时器或自定义消息里。如果用了自定义消息PostMessage，注意别用SendMessage，后者会同步等待，等于把回调线程和 UI 线程绑死，流量一大就互相拖。

4.4 现象：抓到的包数量比 Wireshark 少很多

这是过滤器和缓冲区的问题。如果你在代码里设了 BPF 过滤表达式，那本来就只抓匹配的包；如果没设还少，多半是pcap_open_live的超时设得太短或者驱动缓冲区太小，高流量下丢包。

解决：先确认过滤表达式，临时注释掉pcap_setfilter对比数量。再检查打开适配器时的超时参数，适当调大缓冲区。还有一种情况是快照长度设小了导致大包被截断，caplen小于len的比例可以统计出来，比例高就说明快照长度不够。

4.5 现象：程序退出时报内存错误，或者抓几次就崩

原因是资源释放顺序错乱。pcap_close在回调线程还活着的时候被调用，或者pcap_freealldevs忘了调，都会导致退出时崩。反复启停的场景下，句柄没置空就再次打开，也会出问题。

解决：退出路径统一成“打断 → 等线程 → 关句柄 → 置空”四步，写成单独的函数，所有退出入口都走它。设备列表用完立即pcap_freealldevs。抓到一半崩溃的，重点查回调里有没有越界读，caplen的边界检查一条都不能省。

提示：这套东西的报错极少，绝大多数问题表现为“没反应”或“数据不对”。养成每次失败先打errbuf和原始字节的习惯，能省掉一半排查时间。

5. 收尾：一份能跑通的骨架，比十篇原理文章管用

回过头看，这份 MFC 与 WinPcap 嗅探器最值钱的地方，不是它抓了多少包，而是把一条容易断的链路完整接了起来：设备枚举、适配器打开、回调注册、协议解析、线程与界面分离、安全退出，每一环都是新手会卡住的地方。我在自己动手前也翻过不少讲协议的文章，以太网帧格式背得滚瓜烂熟，可一到实际工程就发现，真正拖住进度的是库依赖怎么配、errbuf为什么不读、回调为什么不能碰控件这些“不上台面”的事。这些恰恰是完整工程能直接给到的。

给不同人的使用顺序，我的建议是这样：

有三件事我想单独强调，它们决定你是在“用这份资源”还是“被这份资源拖着走”。

第一件，先跑通再读懂。拿到工程别急着逐行读代码，先按默认配置编译跑起来，看到列表里有包在滚，再回头读解析部分。反过来做，很容易在某个不理解的头文件包含上卡两天，信心先崩了。

第二件，把 Wireshark 当成对照工具而不是替代品。同一个网卡、同一时刻，两边同时抓，数量对不上就去查过滤器和缓冲区，字段对不上就去查偏移。这是最快的自检方法，比我见过的任何调试手段都直接。

第三件，改动从最小处开始。想加协议解析，先在回调里加一行打印，确认偏移对了再动界面；想改线程模型，先把启停测到连续开关五十次不崩，再往上加功能。这套代码的耦合点集中在回调和句柄生命周期上，动这两处的时候，心里要有“改完必须重测启停”的弦。

从那以后我每次碰这类抓包工程，都强制自己先走一遍“枚举设备 → 确认权限 → 抓十个包 → 和 Wireshark 对数”这条最小验证链，任何一步对不上就不往下写。这个习惯帮我省掉的返工，比任何技巧都多。希望这份骨架也能帮你把第一步迈稳。

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