综述
大量为网络操作和网络管理提供网络监视、统计、安全、流量分析和预警服务等功能的设备需要对在网络上流动数据进行直接并且有效的实时存取。其中软件工具常因为它们低费用和高兼容性而倍受偏爱。然而，考虑到这些工具通常在高速网络环境下表现不佳。尽管人们普遍认为，实时网络分析软件受限于网络环境因而远不能达到理想性能，但我们将证实在有限的硬件支持下，网络分析软件性能仍能有所增进。本文将针对广泛应用于网络分析软件的WinPcap库，讨论它的瓶颈，并提出增效方案。以在高速网络环境下推广基于软件的网络应用工具。
1 .介绍
伴随着带宽的增加，调制解调网络发展迅速，同时网络也变得更加复杂。想要实现象监视、问题解答、网络安全等应用功能，需要高水准、专业化的设备。这些工具有如网络分析器、防火墙和设备监视等都是基于硬件的。然而，硬件解决方案通等常是昂贵的，难以发布（例如，硬件不能被复制且不便移动），并且它们与软件解决方案相比灵活性不高。
到目前为止，基于软件的解决方案通常作为标准操作系统的扩展得以实现，通过它们向应用程序提供原始网络实时数据。象著名的libpcap[1]和WinPcap[3]，都已应用在众多操作系统（OSes）上。这些库（library）输出一套原语，允许应用程序在没有任何另外中介层参与的情况下实现网络应用操作。软件部件发布便利且灵活性强:一个简单的包捕获部件能提供底层数据给应用程序（例如，防火墙、NAT、嗅探器、联网监视器等等）。而且它们升级方便，花费便宜。正因为这些，许多提供网络监视和分析的专业软件都是使用这种方式来实现的。然而，性能问题是软件工具的致命弱点，当处理高速网络时，使用硬件设备成为首选。尽管当前的CPU已很强大，但在倍速比特速率下仍然无法仅通过软件来实现实时流量分析。
目前世界各地的研究小组（如[10]，[13]）正从事这方面的工作，提升网络分析工具整体性能是一个公开的话题。当前他们把精力集中于一些特定的流量分析部件（例如包过滤器），并通过各种途径改进这些功能部件的性能。然而用户只对整体流量分析性能感兴趣，而非某个单一部件。因而研究工作的成果并未能有效地被个人用户所接受。明确地说，这项工作权衡分析各种组件在网络分析工具中的比重。一套针对WinPcap库的优化方案在试验版本中配置应用，后将以定量法测试改进后的效能。从检测数据显示，部件优化导致系统性能仅百分之几的提升，并不能改变最终用户的观点。
本文由以下几部分组成。第2节，对相关研究成果的概述。第3节，将Winpcap作为典型的系统扩展部件，描述它的构造。第4节，呈现对各个部件（如包截获组件、系统应用层组件）详尽性能评估的结果。第5节，介绍一些优化方案，权衡组件比重，检测它们对整体性能的影响效果。最后，在第6节做总结。
2 .领域发展
CMU/Stanford斯坦福包过滤器[14]（或CSPF）可谓元老级包过滤器，它是最早发布的实现从应用层存取数据链路层数据的可行系统。它还介绍了虚拟过滤机的概念：一个基于虚拟CPU（含有寄存器等）与精简高效指令集的包过滤机。过滤器则是能工作在虚拟机的可执行程序。
McCanne和Van Jacobson是该领域另两名杰出贡献者，他们在1993年发布了（BPF）包过滤器[2]。它通过限制拷贝包的数量并定义了一个新的、更加高效的、基于寄存器的虚拟处理器完整指令集（即，含有load、store、compare和jump等基本指令）来改进CSPF。目前BSD操作系统仍然提供BPF，作为缺省的包捕获工具;其它一些操作系统也有类似的实现工具。BPF虚拟处理器还是libpcap库偏爱的底层实现。
Mach Packet Filter马赫包过滤器（MPF）[9]，PathFinder[12]，DPF[11]，BPF+[10]都是一些以提升过滤处理器来增进流量分析性能的过滤器。Packet classification[15]是另一个概念上类似于包过滤器的流量分析组件，同时因为其在路由设备中的应用角色得到了很多关注。
在另一方面，还有极小一些研究是针对其他形式的包捕获技术，如缓冲拷贝。NFR小组使用一个更大缓冲区来升级BPF的版本性能，并通过检验共享缓冲区来阻止重复拷贝[13]。WinPcap[3]，是一个公开代码的Windows库。它通过记忆占有实现一个更高效的缓冲系统来改进libpcap。然而，先前的工作没有关注总体分析过程的性能，这便是本文的目的。试验结果将呈现为什么现有的优化措施仅能将捕获过程所花费的执行时间节省百分之几的原因。
3 .包捕获模型
本小节定义用于包截获和流量分析组件的典型结构模型。特别地，我们参照数据包从在网卡（NIC）被接受，接着被传递到工作站的主存，然后通过设备驱动和操作系统等中介应用于程序这条完整路径来作详细说明。其中NPF（NetGroup Packet Filter）[3]是由BPF驱动，并已植入到WinPcap库中。本文将其作为特例经常提及，应当指出的是NFP同其它过滤器一样，它们的基本原理是相同的。图1和图2所展示的是WinPcap处理一个被接受的数据包并把它传给应用程序所涉及的具体步骤及相关组件。
3.1.网卡和NIC适配驱动器
调制解调NIC板载存储器通常只有几Kbytes。独立于主工作站的存储容量，NIC存储器被用来全速接收、发送数据包。此外，NICs施行一些初步的检查，例如CRC校验和检测是否满足以太网短帧要求。当数据包存储在NIC上时，坏帧将被及时丢弃。
当NIC收到一个有效的数据包后，网卡向系统总线控制器请求总线控制权以传输数据。这时，NIC获得总线控制权并向工作站主存传输NIC缓冲区的数据（看见图2），释放总线后，NIC向高级程序中断控制器芯片（Advanced Programmable Interrupt Controller_APIC）生成硬件中断。APIC接着唤醒操作系统中断处理程序，进而触发NIC设备驱动器的中断服务程序（Interrupt Service Routine_ISR）。
高效设备驱动的中断服务程序（ISR）将完成其份内职责。最基本的，如它会检测与本设备相关的中断（由于在x86机器中允许多个设备共享同一个中断）并给予确认。然后，ISR 预置一个低优先级的函数（称作Deferred Procedure Call or DPC），它会在收到数据包后处理硬件请求并通报上层驱动（即协议层驱动、包截获驱动等）。在完成所有等待队列中的中断请求任务后，CPU启动DPC程序。由于一次只能处理一个数据包，故NIC设备驱动处理数据包时，源于NIC的中断将会被暂时禁用。另外，中断产生是一个很耗系统资源的过程，现在新型的NICs允许在一次中断中传输一个以上的数据包，使得上层驱动程序在被激活时有能力同时处理若干个数据包。
3.2 包捕获驱动
包捕获部件类似协议栈，通常透明于其它软件模块，这将不影响标准系统的工作。它们只是在系统中插入一个“钩”以便能通过调用返回函数-tap（）-及时了解数据包到达的情况。在win32系统上，包捕获部件通常以网络协议驱动的形式被实现。
tap（）的第一反映便是过滤数据包，即探测它们是否为使用者所感兴趣的。NPF过滤引擎演化自BPF，是一个整合有简单指令集的虚拟处理器，它能对通用缓冲器（数据包栈）执行一些简单字节操作。WinPcap（还有libpcap）提供的是一个用户层API，转递高级语言表达式（例如，"提取所有UDP包"）进入一套伪指令（例如，"if以太网字段头是IP且协议字段头的IP等于17，那么返回ture"），后将它们送到过滤机，并激活该指令。上述结构体系在数据包位于NIC缓冲区时就应用于包的过滤，以便减少不匹配的无用拷贝。尽管如此，这仍将占用总线资源，因为它们已被送入系统内存。
过滤器收到数据包的同时，也得到了一些相关的物理层信息系，例如长度和时间戳，这将有利于今后应用程序对它们的处理。然后数据包被拷贝进一个缓冲区，通常称作核心缓冲区，在那里数据包等候被传输至用户层（看见图2）。对包截获进程来讲，这个缓冲区的大小和体系结构设计是否合理直接影响到整体性能的表现。例如一个容量大且设计科学的缓冲系统能弥补在突发繁杂期间用户层应用程序迟缓的速度，并能减少从包截获驱动（即，核心缓存区）向应用程序传输调用数据的请求次数。
用户层应用程序通过类似于系统调用的方式从核心缓冲区得到数据包。当NPF就绪时，系统调用触发"钩"函数-read（）（参见图1），它负责检查NPF核心缓存区:当缓冲区不空时，缓冲区的内容将被传输到用户程序分配指定的内存中（在图1中被标志为"用户缓冲区"）。当数据被复制到用户层时，应用程序立即被唤醒，并开始处理数据。
4 .性能评估
在这一节里，我们将呈现对网络分析系统详尽测量的结果。目的在于测定包截获进程的效能。对第3节中提到过的组件，我们都将统计它们具体消耗资源的准确数目。
按照常规，我们以CPU时钟周期的消耗量来统计。事实上，这样的好处是为了更加客观公正，因为这种测量方法透明于具体系统的绝对时间和CPU速度。
4.1 试验平台
图3所展示的是试验平台:两台PC机通过高速以太网直接连接。一台PC充当通信发生器。另一台则用于实际测试，在它上面安装了改良版的Winpcap，里面有用于测试的扩展插件。要特别说明的是，该扩展能调用Pentium系列微处理器的性能监视计数器[5][6]。该系列微处理器都含有内置的计数器（其类型和数量取决于微处理器的型号和版本）。这些计数器能被用于追踪事件，比如已编译的指令数目、中断请求的数目、加载缓存的数目等。再例如，CPU的CLK UNHALTED计数器统计的是CPU在特定时间间隔内有效的钟周期数。并且，该计数器还能识别消耗在用户级的数量与消耗在核心级的数量。具体地，程序可通过rdpmc指令来得到该计数器的数值。
另外，扩展插件还使用特定动态链接库（DLL），核心驱动利用它们测量特定代码需要的CPU时钟。这些库使用的是x86 rdtsc（Read Time-
