简介基于 Visual C 编写的网络流量监控系统完整源代码包面向 Windows 平台 C 开发者、网络运维人员及希望掌握数据包捕获与流量统计原理的初学者。项目利用 WinPCap 库实现底层数据包捕获、协议解析、流量统计与界面展示可帮助读者理解从抓包到实时监控的完整实现链路。资源共 24 个文件以 8 个头文件与 5 个 C 源文件为核心配合对话框资源、图标、工程配置等文件包体仅 67KB结构紧凑便于直接编译学习。已有 596 人学习下载。通过阅读源码可掌握 pcap_open_live、pcap_loop 等关键函数的使用以及 MFC 界面下多线程刷新、阈值报警和日志记录等实用设计适合作为课程设计或入门网络监控开发的重要参考。1. 网络流量监控系统的 Visual C 源码包解压只是开始编译才是分水岭拿到一个网络流量监控系统的 Visual C 源码包很多人的第一反应是解压、打开工程、按 F5然后被一连串报错劝退。这个系统的本质是用 C 把网卡抓包、协议解析、统计展示串成一条完整链路抓包线程从网卡读取原始字节解析出协议和五元组界面线程定时刷新速率和分布。它之所以常被当作课程设计和毕业设计的选题是因为涵盖面广但每一环都有成熟模板可以参照。这篇文章从拆包开始讲清怎么判断源码完整度、怎么配置环境跑起来、核心代码每一段在干什么以及编译和运行阶段最常踩的坑。适合初次接触抓包编程的新手也适合想快速接手旧代码做改造的工程师。下面所有操作按 Windows 平台、Visual C 系列开发环境展开你可以照着一步步复现。2. 先看清技术骨架抓包库、界面线程和代码文件布局2.1 抓包 SDK 是底座WinPcap 与 Npcap 的取舍Visual C 本身不提供抓包能力必须挂一个抓包 SDK 才能读到网卡上的原始数据帧。这类源码包里最常出现的是以 WinPcap 为后端的旧写法代码里 include 的是 pcap.h链接的是 wpcap.lib运行时依赖系统里装的 wpcap.dll 和内核驱动。但 WinPcap 那套驱动在新系统上经常出现签名问题装不上、跑不了导致老代码直接瘫痪。现在的通行做法是装 Npcap安装时勾选兼容 WinPcap 的选项让老工程的 API 调用方式保持不变底层驱动换成新实现。判断一个包用的是哪代 API不用通读代码看两点就够第一include 语句是pcap.h还是pcap/pcap.h后者是新 SDK 的推荐写法第二有没有调用pcap_findalldevs_ex这类带远程抓包能力的新接口。老代码通常只有pcap_findalldevs和pcap_open_live这两个函数在新驱动下仍然可用只是行为细节有差异。拿到包先做这个判断你就能预估后面要做多少适配工作纯老接口的包环境配好基本能原样跑混用了新接口的包反而要小心库版本不匹配。选型上我的习惯是只要能跑就优先用新驱动配兼容模式不要为了迁就老代码去找老驱动安装包。老驱动在新系统上装不上的问题比代码里的兼容问题难缠得多。还有一类包写的是 Raw Socket 方案不依赖抓包 SDK直接用 Winsock 的 SOCK_RAW 接收 IP 包。这类包的问题很明显Windows 上 Raw Socket 收不到以太网头只能看到 IP 层以上而且环回流量往往收不全。如果源码包里没有 pcap 相关函数而是满屏 socket它的能力边界和 pcap 方案完全不同别用抓包工具的标准去要求它。2.2 压缩包里的文件布局一眼看出源码完整度一个完整的 Visual C 工程源码包里最少要有解决方案文件.sln 或 .vcproj / .vcxproj、一堆 .h 和 .cpp、以及一个 .rc 资源文件。如果只有孤零零几个 .cpp 而没有工程文件说明对方只贴了代码片段你需要自己新建工程把文件拉进去如果 .sln 存在但引用的第三方库目录缺失编译时会以头文件找不到的形式报出来。我拿到包的习惯动作是先用压缩工具看文件列表不急着全部解压重点确认三样东西——有没有工程入口、有没有抓包 SDK 的头文件目录、有没有说明文档。再往下看要留意工程文件里引用的相对路径。老工程喜欢写..\..\..\WpdPack\Include这种链路很长的相对路径压缩包在别人机器上解压位置固定换到你机器上目录层次一不对路径就全部失效。所以文件列表里看到 SDK 目录存在还不够解压后还要确认它的实际位置和工程里写的是否一致。养成先看包内结构、再动手解压的习惯能省掉至少一半的打开就报错。文件完整度判断还有一个细节看主窗口实现文件和抓包逻辑文件的大小。界面文件里如果只有控件初始化和按钮事件抓包文件里却没有pcap_open_live和回调函数那这包大概率是个半成品——画了界面核心逻辑没写。反过来抓包文件占了很大体积且包含协议解析结构体定义说明作者在解析层下了功夫这类包的可学习价值高值得逐行读。2.3 线程与数据流为什么抓包必须独立于界面流量监控系统的线程模型决定了它会不会在抓到第一个包时就卡死。常见做法是开一个专门的抓包线程线程里循环等待数据包到达界面主线程只负责绘制窗口和处理用户操作。两条线程通过一组统计变量通信抓包线程往变量里累加计数界面线程用定时器定时读取并刷新显示。这个模型是几十年来流量监控工具的通行结构任何一个能长期稳定运行的包内部必然是这么分工的。反过来如果源码里在按钮点击事件里直接调pcap_loop或者把pcap_next写进消息循环那就等着出事。抓包是阻塞操作一旦放进 UI 消息循环窗口会直接失去响应拖拽、关闭、点击全部无效。拿到包先定位线程创建代码的位置CreateThread 或者 _beginthreadex 出现在初始化函数里是健康的信号压根没有线程相关代码就要怀疑它到底怎么跑起来的。确认线程模型成立再往下读代码才有意义。3. 从 RAR 到可运行程序环境配置与最小验证3.1 解压与工程导入先查两个容易忽略的文件解压 RAR 时有两个文件最容易出问题。第一个是工程入口文件本身如果压缩包带了密码或者包内有多个相同名字的 .sln 散落在不同子目录里直接双击很可能打开错的那个编译时一堆源文件不在工程中的怪问题。先列出包内所有 .sln / .vcproj / .vcxproj 的完整路径选择目录结构最浅、且与源码目录同层的那一个。第二个是被嵌套的目录很多包解压出来是网络流量监控系统/网络流量监控系统/xxx.sln这种两层同名嵌套如果直接把第一层文件夹当成工程目录去配路径后面所有相对路径都会偏一层。解压完成后做一次完整性检查确认 .cpp 和 .h 是否成对出现缺了头文件的编译会报无法打开包含文件缺了实现文件的链接会报无法解析的外部符号。还要看第三方 SDK 目录里有没有 pcap.h 和 .lib 文件这是整个系统编译的前提。这些检查用资源管理器的搜索功能几分钟就能做完但多数人跳过了这一步直接打开工程然后在报错堆里绕了一两小时才发现是文件缺失。顺序反了效率天差地别。用新版 Visual C 打开老工程时IDE 会弹是否升级工程的对话框。我的建议是只求跑通看逻辑就选不升级用原工程格式打开能保留原始配置少踩平台工具集迁移的坑确定要长期改代码再升级并且升级后立刻检查一遍项目属性因为升级过程偶尔会丢掉自定义的 include 路径和预处理器定义。3.2 工具集、字符集、平台位数三个必查的工程属性老工程在新环境里编译报错十有八九出在三个属性上平台工具集、字符集、平台位数。属性项老工程常见值新环境默认值不一致时的典型症状平台工具集v120 / v140新版工具集报找不到生成工具或大量语法告警字符集使用多字节字符集使用 Unicode 字符集中文字符串乱码、C4566 告警、CString 拼接报错活动解决方案平台Win32x64链接 32 位 lib 失败或函数调用约定冲突工具集不对编译前就会报错解决方式是去项目属性 → 配置属性 → 常规里切换工具集版本或者补装对应的旧工具组件。字符集问题最隐蔽代码里所有直接写中文字符串字面量的地方在 Unicode 工程下都可能变成类型不匹配的告警。平台位数则直接关系到链接32 位工程必须配 32 位的抓包 SDK 库如果你下载的是 64 位 SDK 包链接时会有明确的格式错误提示反过来也一样。新手最常犯的错是在 x64 配置里链 32 位 lib报错又说不出所以然。三个属性逐一核对完编译环境的基本盘才算稳。3.3 链接抓包库include、lib、预处理器一次配齐抓包 SDK 的接入配置分布在三处缺一不可。第一处是项目属性 → C/C → 常规 → 附加包含目录写成 SDK 的 Include 文件夹绝对路径目的是让编译器找到 pcap.h。第二处是链接器 → 常规 → 附加库目录写成 SDK 的 Lib 文件夹路径注意按平台位数选对应的子目录别把 x86 配置指到 x64 库上。第三处是链接器 → 输入 → 附加依赖项这里要手动加上wpcap.lib和ws2_32.lib后者是 Winsock 的基础库解析 IP 地址和字节序转换的函数都从里面来。预处理器定义也不能漏。老代码里经常出现这两个宏WPCAP表示启用 wpcap.dll 的接口HAVE_REMOTE启用远程抓包功能。工程属性里没定义它们编译到 SDK 头文件的某些分支时会报函数未声明。我一般会单独建一个属性表文件把这三类配置集中管理include 路径、lib 路径、预处理器宏。换机器时只改属性表不碰任何源码。属性表在项目属性管理器的添加属性表里创建保存为 .props 文件可以跨工程复用。配置完成后做最小验证写一个十行左右的枚举函数调用pcap_findalldevs打印本机网卡列表编译运行能输出设备名就算环境通了。这一步通过之前不要编译整个系统。完整工程和最小验证同时报错时你没法区分是 SDK 没配好还是源码本身有坑排查效率会低一个量级。3.4 管理员权限与网卡枚举最小的启动自检抓包 SDK 打开网卡设备需要管理员权限这是新手最容易忽略的运行前提。老代码从 IDE 里按 F5 启动时如果 IDE 本身不是管理员身份pcap_open_live会返回 NULL错误信息是权限不足。解决方式是右键开发环境图标选择以管理员身份运行再重新打开工程并启动调试。已经编好的 exe 也要右键属性里勾选以管理员身份运行。网卡枚举是最直接的启动自检手段代码很简单#include pcap.h #pragma comment(lib, wpcap.lib) #pragma comment(lib, ws2_32.lib) void ListDevices() { char errbuf[PCAP_ERRBUF_SIZE] { 0 }; pcap_if_t* allDevs NULL; // 枚举本机所有网卡失败时 errbuf 会写入原因 if (pcap_findalldevs(allDevs, errbuf) 0) { printf(枚举失败: %s\n, errbuf); return; } // 遍历设备链表打印名称和描述 for (pcap_if_t* d allDevs; d ! NULL; d d-next) { printf(设备名: %s\n, d-name); if (d-description ! NULL) printf(描述: %s\n, d-description); } // 用完必须释放链表否则内存泄漏 pcap_freealldevs(allDevs); }这段代码里值得注意的有两点。pcap_findalldevs返回的链表是动态分配的用完后必须pcap_freealldevs释放漏掉它程序退出时会泄漏内存。另外设备名是\Device\NPF_{GUID}这种内核路径描述才是人能读懂的网卡名称判断网卡类型要结合描述字段很多老源码包里写死的设备名到了新机器上根本不存在枚举输出就是你换设备名的最佳依据。运行这段代码能看到网卡列表说明 SDK 驱动和权限两个前提都已满足可以进入系统级调试了。4. 核心代码解读抓包、解析、统计的完整链路4.1 抓包线程与回调pcap_loop 的正确用法系统的数据源头在一个独立的抓包线程里线程内调用pcap_loop或pcap_dispatch把回调函数地址传进去驱动每收到一包就调用一次回调。回调的本质是每包通知你在这里做的工作量直接决定抓包吞吐上限。// 抓包回调每收到一个数据包就执行一次 void packet_handler(u_char* user, const struct pcap_pkthdr* header, const u_char* pkt_data) { // user: 传入的自定义参数用于把统计结构体带到回调里 // header: 包含时间戳、真实长度 len 和捕获长度 caplen // pkt_data: 以太网帧的起始字节解析从它开始 TRAFFIC_STATS* stats (TRAFFIC_STATS*)user; stats-dwPackets; stats-dwBytes header-caplen; } // 抓包线程入口 unsigned __stdcall CaptureThread(void* param) { pcap_t* handle (pcap_t*)param; // 第二个参数 -1 表示一直抓直到出错或被 breakloop 打断 int result pcap_loop(handle, -1, packet_handler, (u_char*)g_stats); if (result 0) { // 设备被关闭、驱动出错、权限被收回都会走到这里 fprintf(stderr, 抓包线程退出: %s\n, pcap_geterr(handle)); } return 0; }回调里最先要区分header-len和header-caplen前者是网卡上原始包长后者是真正拷贝到缓冲区、你能安全访问的长度。如果抓包时设的快照长度小于实际包长caplen 会比 len 小解析包内字段时按 caplen 判断是否越界否则拿到的是不完整的数据。pcap_loop的第二个参数传 -1 是无限循环适合一直采集的场景传 0 表示每次取一批就返回适合需要频繁检查退出标志的程序。我在实际工程里更常用pcap_next_ex配合独立线程加 do-while 循环线程退出时能立刻在干净位置做清理比阻塞在pcap_loop里好收尾。4.2 协议解析从以太网帧到 IP 头的偏移量流量监控系统里最常出玄学 Bug的地方就是协议解析明明抓到包了显示出来的协议全乱。乱的原因几乎都是偏移量算错。以太网帧头固定 14 字节前 6 字节目的 MAC、6 字节源 MAC、2 字节类型字段。类型字段是网络字节序0x0800 表示 IPv40x0806 表示 ARP。只有类型为 IPv4 时后面才跟 IP 头IP 头的长度不是固定 20 字节而是由首字节的低 4 位决定单位为 4 字节。#define ETHERNET_HEADER_LEN 14 typedef struct _ETH_HEADER { BYTE dstMac[6]; // 目的 MAC BYTE srcMac[6]; // 源 MAC WORD etherType; // 上层协议类型网络字节序 } ETH_HEADER; typedef struct _IP_HEADER { BYTE iphVerLen; // 高4位版本号低4位IP头长度 BYTE iphTOS; // 服务类型 WORD iphTotalLen; // IP 总长度 WORD iphID; // 标识 WORD iphFragOffset; // 分片偏移 BYTE iphTTL; // 生存时间 BYTE iphProtocol; // 上层协议6TCP 17UDP 1ICMP WORD iphChecksum; // 头校验和 DWORD iphSrcAddr; // 源 IP DWORD iphDestAddr; // 目的 IP } IP_HEADER;const BYTE* ParsePacket(const BYTE* pktData, DWORD caplen, DWORD* srcIp, DWORD* dstIp, BYTE* protocol) { if (caplen ETHERNET_HEADER_LEN 20) return NULL; // 以太网类型字段是网络字节序必须转成本机序再比较 ETH_HEADER* eth (ETH_HEADER*)pktData; if (ntohs(eth-etherType) ! 0x0800) return NULL; // 只处理 IPv4 IP_HEADER* ip (IP_HEADER*)(pktData ETHERNET_HEADER_LEN); int ipHeaderLen (ip-iphVerLen 0x0F) * 4; // 低4位乘4 if (ipHeaderLen 20) return NULL; // 非法头长度 *srcIp ip-iphSrcAddr; *dstIp ip-iphDestAddr; *protocol ip-iphProtocol; // 返回传输层起始位置供后续解析端口使用 return pktData ETHERNET_HEADER_LEN ipHeaderLen; }这段代码集中了几个经典坑。eth-etherType是网络字节序直接拿它和 0x0800 比较会永远不相等必须用ntohs转成本机序反过来往 IP 地址上填端口或比较时又要把本机序转回网络序方向搞反是高频失误。IP 头长度取的是低 4 位常见错误是把整个iphVerLen拿来乘 4得到 0xA0 这种离谱值解析位置直接偏到十万八千里。还有 ARP 包没有 IP 头它后面的数据是 MAC 地址和 IP 地址的映射信息要专门判断类型字段再决定是否走 IP 解析。如果网卡在带 VLAN 的网络里以太网头后还夹着 4 字节的 802.1Q 标签偏移量要整体加 4老代码通常不处理这个抓回来后部分包解析错乱很正常。4.3 端口与连接统计TCP/UDP 解析的字节序陷阱拿到传输层起始位置后下一步就是解析 TCP 和 UDP 端口。TCP 头前 20 字节是固定部分源端口在第 0、1 字节目的端口在第 2、3 字节都是网络字节序必须ntohs转换。UDP 头只有 8 字节前 4 字节同样分布着两个端口。端口解析本身不难难在你要先检查总长度是否够到传输层头防止越界读内存。void AnalyzeTransport(const BYTE* transport, DWORD remainLen, BYTE protocol, WORD* srcPort, WORD* dstPort) { // 判断剩余长度能否撑起最小的传输层头 if (protocol 6 remainLen 20) // TCP 最小头 20 字节 { *srcPort ntohs(*(WORD*)(transport 0)); // 网络序转主机序 *dstPort ntohs(*(WORD*)(transport 2)); } else if (protocol 17 remainLen 8) // UDP 头 8 字节 { *srcPort ntohs(*(WORD*)(transport 0)); *dstPort ntohs(*(WORD*)(transport 2)); } else { *srcPort 0; *dstPort 0; } }这段代码有个值得注意的细节用(WORD*)(transport 0)这种强转读取端口在内存对齐要求高的环境下可能触发未对齐访问但 x86/x64 上通常无事。更稳妥的写法是用移位手工组装字节序高字节在前是网络序(transport[0] 8) | transport[1]就是正确的主机序端口。如果你要做的系统统计连接数就得把源 IP、目的 IP、源端口、目的端口、协议这五个要素拼成一个键放进哈希表去重这才叫连接表否则只能叫包计数。很多教学源码只做到四元组显示不做连接跟踪你要清楚自己的系统边界在哪。4.4 界面刷新与线程同步别在回调里碰 UI新手最常见的灾难性写法是在抓包回调里直接调用SetDlgItemText或UpdateData刷新界面。回调运行在抓包线程里它和界面线程是两个不同的执行序列直接从回调操作窗口控件轻则界面刷新错乱重则窗口消息队列被挤爆整个界面假死。正确模型是回调只写统计变量界面线程用定时器定时来取。// 统计结构体抓包线程写界面线程读 typedef struct _TRAFFIC_STATS { volatile LONG dwPackets; // 总包数 volatile LONG dwBytes; // 总字节数 volatile LONG dwTcpPackets; // TCP 包数 volatile LONG dwUdpPackets; // UDP 包数 } TRAFFIC_STATS;// 界面定时器1 秒触发一次 void OnTimerRefresh(HWND hDlg) { // 原子交换取数同时把计数清零得到这一秒的增量 LONG packets InterlockedExchange(g_stats.dwPackets, 0); LONG bytes InterlockedExchange(g_stats.dwBytes, 0); TCHAR buf[64] { 0 }; wsprintf(buf, TEXT(速率: %.2f Kpps), packets / 1000.0); SetDlgItemText(hDlg, IDC_STATIC_RATE, buf); wsprintf(buf, TEXT(流量: %.2f KB/s), bytes / 1024.0); SetDlgItemText(hDlg, IDC_STATIC_BYTES, buf); }这里用InterlockedExchange而不是直接赋值清零是有讲究的。抓包线程随时可能在写dwPackets界面线程直接把它清零会丢掉中间写入的计数原子交换保证读和清零在一条线上完成不会丢增量。你要是用 C11 之后的版本也可以换成std::atomic加exchange语义等价。界面定时器的周期不用太短1 秒一次足够目视观测设成 10 毫秒反而会让界面刷新频繁抢占 CPU。回调里累加的开销只有一次原子自增对抓包速率的影响可以忽略这就是这套模型能长期稳定运行的底气。5. 避坑指南编译与运行中的 5 个高频问题5.1 编译报错找不到 pcap.h 与 wpcap.lib现象工程一编译就报 fatal error C1083: 无法打开包含文件: pcap.h: No such file or directory或者编译通过但链接阶段报 无法打开文件 wpcap.lib。原因工程配置里没加抓包 SDK 的 include 路径或 lib 路径写的是老机器上的相对路径压缩包换目录解压后路径全部失效。另一种常见情况是工程属性里配置的是 x64 库而活动平台是 Win32位数不匹配也会让链接器找不到库文件。解决打开项目属性把附加包含目录改成 SDK 在你机器上的绝对路径把附加库目录改成对应活动平台位数下的 Lib 子目录同时在附加依赖项里保证有wpcap.lib和ws2_32.lib。改完后重新打开工程让设置生效编译一次确认报错消失再继续。需要远程抓包功能的代码还要求在预处理器里定义WPCAP和HAVE_REMOTE缺了它们会出现函数声明不匹配的怪状告警这一点经常被人漏掉。5.2 运行报错wpcap.dll 缺失与设备打开失败现象编译一路通过双击 exe 却弹找不到 wpcap.dll或者程序启动后网卡列表为空pcap_open_live返回 NULL错误信息类似 No such device exists。原因可执行文件运行时需要抓包驱动提供 DLL 和内核服务。新系统默认没装老驱动所以 wpcap.dll 不存在设备打开失败则是驱动服务没起来或者代码里写死的网卡名对应的是老机器上的设备路径。解决先安装新版抓包驱动安装时勾选兼容老接口的选项装完后重启一次让内核驱动生效。还提示缺 DLL 的话把 SDK 里的 wpcap.dll 复制到 exe 同目录。设备打开失败不要硬猜先把 3.4 节那段枚举代码跑一遍确认本机设备名再把代码里写死的设备名替换掉。很多老包里硬编码着\Device\NPF_{GUID}这类内核路径在另一台机器上根本不存在替换成枚举输出的真实设备名即可。5.3 界面卡死把 UI 操作写进了抓包回调现象程序一抓到包界面就无响应窗口拖不动、点不了任务管理器里 CPU 占用率不高但进程处于假死状态。原因抓包回调里直接调用了界面刷新相关的 API。回调运行在抓包线程上下文窗口控件的消息处理在界面线程跨线程操作 UI 会导致消息队列阻塞包来的越密集卡得越厉害最终界面彻底失去响应。解决把回调里所有控件操作删掉回调只做统计变量累加界面用定时器读取数据刷新。如果你的需求是逐包显示到列表控件不要直接在回调里插入列表项改为把包信息推进一个带锁的环形缓冲界面线程定期取出一批批量插入。按这个方式改造完抓包线程和界面线程彻底解耦卡的根源才真正消除。5.4 抓不到局域网其他设备的包混杂模式与无线网卡限制现象网卡列表里能看到多个适配器选择了物理网卡但抓到的只有本机自己收发或 127.0.0.1 环回的包局域网里其他主机的流量完全看不到。原因大概率是抓包时没开混杂模式也就是pcap_open_live的 promisc 参数传了 0驱动只把发给本网卡的包交上来。另一个可能原因是选错了设备枚举列表里排第一的往往是虚拟网卡或蓝牙设备而不是有线网卡。解决把pcap_open_live的 promisc 参数改为 1设备选择上按设备描述里的关键词过滤比如包含 Ethernet 字样的才纳入候选。另外要明白一个硬件限制很多 Windows 无线网卡驱动即使开了混杂模式也抓不到其他设备发给别人的无线帧这是网卡固件的限制不是代码能解决的。如果你要监控局域网内其他主机的流量最可靠的做法是用有线网卡配合交换机镜像端口这一点在设计整个系统之前就该想清楚。5.5 界面中文乱码字符集与源文件编码双重问题现象界面按钮文字、列表列名全是乱码或者编译时对中文字符串字面量频繁告警 C4566代码里写的是流量统计界面上显示的却是娴佹噏缁熻。原因两层因素叠加。第一层是工程字符集被新环境切到了 Unicode而老代码是用多字节字符集写的窄字符串两者在CString拼接和控件赋值时类型不匹配第二层是源码文件本身的编码问题老文件常见 GB2312 编码IDE 默认按 UTF-8 打开后文件里的中文字符常量整个变成了乱码字节。解决先确认工程属性里的字符集设置和源码原始工程一致如果要用 Unicode把所有字符串字面量用_T()或TEXT()宏包起来CString用带编码参数的构造函数显式转换。源文件编码导致的乱码用 IDE 的高级保存选项把文件按正确编码重新保存即可保存后界面文字恢复正常。这里最容易踩的误区是只顾着改工程属性忘了源文件本身的编码状态结果改了字符集界面反而更乱。6. 把 Demo 改成工具协议统计与 PCAP 落盘两个必加功能拿到一个能跑的源码包真正的价值在于改造成自己场景可用的工具。我最先加的两个功能一个是协议分布统计一个是抓包落盘。协议分布只需要在回调里按 IP 头的 protocol 字段分四类累加TCP、UDP、ICMP、其他界面定时器刷新时算比例。落盘则用抓包 SDK 自带的 dump 函数把原始帧连续写入文件抓完后可以用支持 PCAP 格式的离线分析工具打开做深度分析这两个功能加起来半小时能完成。// 打开 dump 文件返回值是写入句柄 pcap_dumper_t* dumper pcap_dump_open(handle, capture.pcap); void packet_handler(u_char* user, const struct pcap_pkthdr* header, const u_char* pkt_data) { // pcap_dump 把时间戳和数据帧写入标准 pcap 文件 pcap_dump((u_char*)dumper, header, pkt_data); // 顺带做统计累加注意这里不能做任何界面操作 g_stats.dwPackets; g_stats.dwBytes header-caplen; }pcap_dump_open的第一个参数是已打开的抓包句柄文件格式由它决定pcap_dump每次调用相当于一次内存写入高速抓包时也能扛住。注意 dump 文件的句柄是全局唯一的整条抓包线程共用所以不用加锁也不会串写。改造完一定要做三件事验证第一抓包速率与流量来源的量级对得上第二落盘文件能被离线分析软件正常打开帧长度和字段内容完好第三连续跑半小时以上内存和句柄数不持续上涨否则说明某处资源泄漏还挂着。我处理这类源码包的固定习惯就是每改一处单独编译一次绝不一口气改完全部再编译。错误分开出现时你能一眼定位是新增代码的问题还是老代码的坑堆在一起出现时你只会陷入它原来就这样吗的自我怀疑。先把环境跑顺再逐段读核心链路最后按自己的需求加功能这个顺序走下来源码包里的东西才真正变成你的。希望帮到你。本文还有配套的精品资源点击获取