学校代码：10491 研究生学号：120080963
中国地质大学
硕士学位论文
基于 Linux 下的网络数据包捕获
及 WebMail 报文监测与重组技术的研究
硕 士 生：余波
学科专业：计算机科学与技术
指导教师：罗忠文 教授
二○一一年五月
A Dissertation Submitted to China University
of Geosciences for the Master Degree of Engineering
Study Of Linux_based Network Packet Caputuring
And WebMail Monitoring And Defragmentation
Master Candidate：Yu Bo
Major：Computer Science & Technology
Supervisor：Luo Zhongwen Professor
China University of Geosciences
Wuhan 430074 P. R. China
中国地质大学（武汉）研究生学位论文原创性声明
本人郑重声明：本人所呈交的硕士学位论文《基于 Linux 下的网络数据包捕
获及 WebMail 报文监测与重组技术的研究》，是本人在导师罗忠文教授的指导下，
在中国地质大学（武汉）攻读硕士学位期间独立进行研究工作所取得的成果。论
文中除已注明部分外不包含他人已发表或撰写过的研究成果，对论文的完成提供
过帮助的有关人员已在文中说明并致以谢意。
本人所呈交的硕士学位论文没有违反学术道德和学术规范，没有侵权行为，
并愿意承担由此而产生的法律责任和法律后果。
学位论文作者（签字）： 日期： 年 月 日
作者简介
余波，男，1979 年 8 月生于湖北襄阳，1998 年 9 月至 2002 年 7 月就读于哈
尔滨理工大学，本科专业是计算机及应用。2008 年 9 月考取中国地质大学（武
汉）信息工程学院计算机科学与技术专业的硕士研究生，主要研究方向为计算机
网络。
在攻读硕士期间，完成了专业规定的硕士英语（口语、阅读、听力、写
作）、自然辩证法、计算几何及现代图形学、计算机应用数学、算法设计与分析
等共计 11 门学位课程，同时学习了空间数据库、Windows 组件技术与编程、高
级管理学等共计 6 门选修课程，修满 个学分，成绩优秀，学位课平均分 84，
选修课平均分 80。
本人于 2009 年 12 月 27 日进入上海白虹武汉研发中心实习。参与了该公司
网络信息取证系统的研究和开发。主要从事底层协议解析工作，负责抓取网络数
据包，进行协议解析，获取 WebMail 的详细的通讯内容，供应用查询。
基于 Linux 下的网络数据包捕获
及 WebMail 报文监测与重组技术的研究
硕士生：余波 导师：罗忠文
摘 要
在当今这个信息化的社会，互联网在人们的生活和工作中起着越来越重要的作用。而利
用网络进行的犯罪活动也日益增多，资料泄密和非法信息的传播就是其中的一种。电子邮件
作为网络上一种广泛应用的信息交换工具，也成为了资料泄密和非法信息传播的一种渠道。
为了保障信息的安全，并对犯罪活动进行有效监控和取证，迫切需要对特定对象的网络的内
容进行监控。本文正是在这一背景下，着重研究了对 WebMail 的内容监控。
本文围绕 WebMail 网络内容监控系统的设计与实现，研究了数据包的捕获原理，详细
说明了不同网络环境下的监听方式，介绍了 Linux 下伯克利包过滤(BPF)机制和常用的数据
包捕获函数库 Libpcap，针对 Libpcap 在高速网络环境下的不足，提出了 PF_RING 这一解决
方案。
对数据包分析所需要的协议知识进行了详细的介绍，介绍了 TCP/IP 协议族的基本原理，
和帧数据的各个协议头部的数据结构，在应用层着重探讨了 WebMail 的应用层协议 HTTP。
并以此为基础，简介了数据包的协议分析技术。
针对 WebMail 内容监控的特点，介绍了监控系统的主体程序框架，详细说明了程序实
现中的几个技术要点：HTTP 报文重组、系统内存回收、HTTP 报文解压缩、利用正则表达
式和相应的函数进行内容的提取以及消息体的编码转换等。
本系统虽然主要是针对 WebMail 的内容监控，但系统具有良好的扩展性，可以根据不
同的需要加入其它应用层协议分析模块。
关键词：网络监控；WebMail；Libpcap；PF_RING; Linux 平台
Study Of Linux_based Network Packet Caputuring
And WebMail Monitoring And Recombination
Master Candidate：Yu Bo Supervisor：Luo Zhongwen
ABSTRACT
In the modern information society, the Internet plays a more and more important role in
people’s life. But criminal activities with the internet are increasing, for example data leakage and
illegal dissemination of information. Email， as a widely used network information exchange tool,
also becomes a channel to data leakage and illegal dissemination of information. In order to ensure
the security of information and monitor the criminal activities via the network for computer
forensics, it is urgent to monitor network flow content to certain object. This paper ， in this
context, detailed discusses the WebMail content monitoring.
This thesis designs and implements the WebMail monitoring system. It describes the the
principle of packet capturing, details the packet capturing way under different network
environment, introduces the berkeley packet filter (BPF) mechanism on the linux operation system,
then illustrates the common packet capturing function library Libpcap. As Libpcap does not work
well under high traffic network, this paper presents the solution of PF_RING.
The protocols needed for packet analysis are introduced, which includes the basic principles
of TCP / IP protocol family and the data structures for the protocol headset used in the network
frame data. The thesis talks about a lot the HTTP protocol which is a application layer protocol, as
the WebMail application is bases on the HTTP protocol. The protocol analysis technique is
introduced on the basis of the protocol knowledge.
According to the characteristics of WebMail content monitoring, this thesis gives the main
program frame for the monitoring system. Then it discusses the important parts for the
implementation, such as HTTP packets recombination, system memory recall, HTTP message
decompression, getting the content with regular expression and the corresponding function library,
and the code conversion of message body, etc.
Although this system is mainly aimed at WebMail content monitoring, the system has good
expansibility and can extended the application function by adding others application protocol
analysis modules.
Key Words: network monitoring; WebMail; Libpcap; PF_RING; Linux platform
目 录
第一章 绪论 ..................................................................................................................................1
§ 研究背景 ............................................................................................................................1
§ 研究内容 ............................................................................................................................2
第二章 数据包的捕获 ......................................................................................................................3
§ 数据包的捕获原理 ............................................................................................................3
§ 数据包的捕获方式 ............................................................................................................4
§ 数据包捕获机制 .............................................................................................................10
§ 数据包捕获函数库 .........................................................................................................14
Libpcap 函数库 .......................................................................................................15
PF_RING.................................................................................................................20
§ 本章小结 .........................................................................................................................21
第三章 网络协议分析 ....................................................................................................................22
§ TCP/IP 基本原理 .............................................................................................................22
基本原理概述 .........................................................................................................22
以太网首部 ............................................................................................................26
IP 首部.....................................................................................................................26
TCP 首部.................................................................................................................27
UDP 首部 ................................................................................................................29
HTTP 应用协议 ......................................................................................................30
§ 协议分析技术 ..................................................................................................................32
§ 本章小结 ..........................................................................................................................33
第四章 数据截获和分析模块的实现 ............................................................................................34
§ 主体程序设计 .................................................................................................................34
§ 程序实现中的几个要点 .................................................................................................36
HTTP 报文重组 ......................................................................................................36
内存回收 ................................................................................................................39
HTTP 报文解压缩 ..................................................................................................40
邮件内容的提取 ....................................................................................................41
消息体的编码转换 ................................................................................................42
§ 功能扩展 .........................................................................................................................44
功能延伸 ................................................................................................................44
协议扩展 ................................................................................................................45
§ 本章小结 .........................................................................................................................45
第五章 总结与展望 ........................................................................................................................46
§ 总结 .................................................................................................................................46
§ 展望 .................................................................................................................................46
致 谢 ..............................................................................................................................................47
参考文献 ..........................................................................................................................................48
第一章 绪论
§ 研究背景
随着英特网技术的不断发展，互联网与人们的生活联系越来越紧密。而在中国，经过
十几年的快速发展，互联网不仅在政府、企业，学校里得到大力应用，也早已走进千家万
户。截止 2010 年 12 月，中国网民规模达到 亿，互联网普及率攀升至 %[1]。互联
网的开发应用也不断增多。人们利用互联网的搜索引擎和网络新闻获取信息，使用网络购
物、团购、网上支付、旅行预订等进行商务交易，使用即时通信、博客、微博、电子邮件
进行信息沟通，使用网上游戏、网络视频等进行网上娱乐。
然而，互联网络也是一把双刃剑，在人们享受网络带给人们的种种便利的同时，一些
不法分子也利用网络进行各种违法犯罪活动，如利用计算机实施金融诈骗、进行盗窃、实
施贪污、挪用公款、窃取国家秘密、电子讹诈、网上走私、网上非法交易等等。因此，为
了遏制网络犯罪，保障国家信息安全和减少经济损失，必须对网络进行监管。事实上，绝
对的互联网自由并不存在，实施必要管理，引导互联网健康发展，这已成国际共识，任何
一个负责任的国家都不会对本国的互联网发展放任不管。作为国家利益和公众利益的代表，
各国政府积极介入互联网管理，成立专门机构对网络进行管理。网络信息内容监控是网络
管理的一个重要方面。
网络信息内容监控包括许多方面，比如上网监控、网页浏览监控、邮件监控等。由于
电子邮件的广泛应用，在给人们带来巨大方便的同时，某些不法分子也利用其传送非法信
息。在许多企业，电子邮件已渐渐具备正式公文的性质，企业档案资料的管理已不
仅限于各类纸张文挡，也包括各类来往的电子邮件。如果对电子邮件进行管理、备
份，企业可更有效地管理对内对外的档案。方便的 email，也可能被员工当作有意或
无意泄漏机密的主要管道。据调查，美国大约四分之三的大型企业，利用特殊软件，
检查员工的电子邮件，防止泄漏公司机密。电子邮件也正在变成调查犯罪的重要证
据，许多案件都追查过嫌犯的电子邮件，发现他们使用的讯息类型，以及在网络上
找到的讯息等。许多证券公司，都根据规定，将企业往来的电子邮件，储存一段时
间。基于此，对企业电子邮件进行备份已经相当必要。网络信息内容监控的一个重
点就是邮件监控。
电子邮件系统通常由用户代理系统和消息传输代理系统这两个子系统组成。用
户使用用户代理阅读和发送电子邮件，而消息从源端传送到目标端则依靠消息传输
代理完成。WebMail 是通过 Web 浏览器就可以访问的电子邮件客户端，是一个 web
应用程序，具有邮件用户代理功能。一般而言，WebMail 系统可以收发邮件，在线
服务用户以及提供系统服务管理功能等。使用 WebMail 比较简单，它的界面友好、
直观，不需要建立桌面邮件客户端，而像 Foxmail、Outlook 这样的 E-mail 客户软件
需要进行比较麻烦的配置。用户接受和发送邮件也比较方便，只要能上网就可以使
用 WebMail，随时随地快捷的转发邮件。正是由于 WebMail 的这些特性，E-mail 才
在 Internet 上有着广泛应用。本文将主要讨论 WebMail 的监控。
§ 研究内容
邮件监控需要获取一封邮件的信息，比如 IP 地址、收发时间、标题、发送方、接收
方、邮件正文等，它需要在应用层对信息内容进行监控。网络内容监控技术主要有
两个方面：
1. 获取网络信息内容。研究如何在各种复杂的网络环境中快速准确获取各种协
议的信息内容。数据包捕获是高速网络下内容监控系统发展的瓶颈。
2. 还原信息内容。还原截获到的数据包，并分析其中的信息内容。分析还原时，
需要提供会话重现功能，对捕获到的数据包进行重组、拼接，去除协商、应
答、重传、包头等网络信息，获取基于会话的完整记录。
本文从网络监控的特点入手，提出了 WebMail 监控系统的设计方案，重点讨论
了各种环境下数据包的捕获方式，并详细讨论了数据截获和分析中的几个技术难点。
全文共有五章，各章节组织如下：
第一章是绪论，介绍了本文的研究背景和意义，和论文的主要研究工作于整体结
构。
第二章主要针对数据包的捕获方式和捕获机制展开研究。作为 WebMail 监控系
统的基础，本章详细讨论了各种网络环境下数据包的捕获方式，重点介绍了 BPF 机
制，并描述了数据包捕获函数库 Libpcap 和 PF_RING 套接字。
第三章详细介绍了网络协议的底层协议 TCP/IP 协议和应用层协议 HTTP 协议。
第四章介绍了监控系统的主体程序框架，重点分析了监控程序实现中的几个关
键点：HTTP 报文重组、内存回收、HTTP 报文解压缩、邮件内容的获取和消息体的
编码转换，并提出了系统功能扩展的一些方面。
第五章总结和展望。
第二章 数据包的捕获
WebMail 监控系统先通过数据捕获模块捕获、初步过滤所有的网络数据包，定位模块进
行精确过滤,定位数据包所属邮箱，重组数据包则在具体邮箱分析模块进行，数据包重组后
就可根据具体的应用层协议恢复应用层的内容，最后再根据要求获得邮件的具体信息。监控
系统设计的一个主要环节就是包捕获与过滤技术，在大流量的高速网络监控中，选用高效率
的数据捕获与过滤技术是系统性能实现的良好基础。
§ 数据包的捕获原理
Internet 由大量的局域网所组成，这些局域网一般是以太网、令牌网结构。数据在这些
网络上是以帧为单位传输，帧通过特定的网络驱动程序进行成型，然后通过网卡发送到网线
上。以太网采用带冲突检测的载波帧听多路访问（CSMA/CD）机制。在同一个冲突域
中的以太网中节点都可以收到所有被发送的帧，因此，我们说以太网是一种广播网络。
而冲突域中的节点是否处理这些数据帧，需要看节点主机网卡的工作状态。当网络接
口处于正常状态时，根据数据帧的真实目的地址来决定是否处理，如果目的地址为本
机地址或为广播地址则接收。至于广播帧与广播通信是不同的概念。专门用于同时向
网络中所有工作站进行发送的地址就是广播地址。在使用 TCP/IP 协议的网络中，主机
标识段 host ID 为全 1 的 IP 地址为广播地址，广播的分组传送给 host ID 段所涉及的所有计
算机。简单的说，当网络接口处于正常状态时，下面两种数据帧会被一个网络接口（网卡）
响应：
(1) 数据帧匹配自己的 MAC 地址；
(2)发向网络内的所有主机的广播数据帧
网卡是计算机的一个组件，它工作在数据链路层。网卡，作为一个接口，在局域网中连
接计算机和传输介质，每个网卡都有一个唯一的网络节点地址，也叫硬件地址、物理地址，
是网卡生产厂家生产时烧入的，常叫做 MAC 地址，绝对不会重复。网卡的主要功能有：实
现与局域网传输介质之间的物理连接，进行电信号匹配，发送和接收帧，封装与拆封帧，控
制介质访问，对数据进行编码和解码和缓存数据等。网络中的电脑进行相互通讯时，数据不
是以流而是以帧的方式进行传输的。帧可以看做一个数据包，里面除了包含有数据信息外，
还包含数据的发送地址，接收地址和数据校验等信息。网卡的驱动程序安装在计算机的操作
系统中，接收数据时，驱动程序会控制网卡将局域网传送过来的数据存储在存储器的什么位
置。网卡的缺省接收模式包含广播模式和直接模式，可以通过网卡驱动程序将接收模式设为
混杂模式。网卡接收到数据帧后是这样处理的：网卡内嵌的处理程序检查数据帧的 MAC 地
址，根据接收模式判断是否接收该数据帧。正常情况下，只接收 MAC 地址匹配的数据帧和
广播帧，其余的帧会简单丢弃，而在混杂模式下，所有传来的数据帧都会被网卡接受。网卡
独立完成这个过程，主机操作系统并没有参与。接收数据和发送数据时，网卡通常会产生中
断信号通知 CPU，CPU 产生中断，操作系统调用网卡自己中断处理函数去调用驱动程序接
收数据，这个中断函数是由网卡驱动程序注册到操作系统的中断描述符表(IDT)和中断服务
程序(ISR)中。
总之，对于网卡来说，一般有一下四种工作模式：广播模式、组播模式、直接模式、混
杂模式。工作在广播模式下的网卡能接收广播帧。如果某个主机加入某个组，就可以收发同
一组内的数据，没有加入该组的主机则不能收发对应的数据，但如果将网卡设为组播模式，
该机器就可以接收所有的组播帧，不管该主机是否为组内成员。网卡在直接模式下只接收与
自己的 MAC 地址匹配的数据帧。混杂模式下就可以接收所有经过该网卡的数据帧。一般情
况下，前三种模式是网卡的缺省配置。
如果修改网卡让本机的网卡设为“混杂”模式，就可以处理所有收到的数据帧，从而可以
监听同一冲突域中其它网卡的数据。在本系统中，就是将网卡设为混杂接收模式，进行网络
监听。
§ 数据包的捕获方式
我们在上一节分析网卡的工作模式时了解到，即时网卡工作在混杂模式下，它也只能接
收到经过该网卡的数据包，对于不经过该网卡的数据包则不能监控。因此我们在对监控对象
进行监控时，必须要分析监控网络的拓扑形式。监控主机的工作环境必需同网络的组建方式
相适应。系统使用监听模式下，一般有以下几种连接方式。
1、 共享式网络
局域网内主机通过 Hub 集线器连接。这种情况将监听主机监控口连接到集线器任何一
个端口上。其网络拓扑形式如下所示：
图 集线器连接
在共享式网络中，一条通讯线路被所有机器共享。集线器是局域网中的基础设备，工作
在 OSI（开放系统互连）参考模型第一层，即物理层。它没有端口的概念，以“广播”的方式
发送数据。当集线器收到数据时，它向所有与它连接的每一个设备线路上发送数据。也就是
说，当主机向某个目标主机发送数据包时，尽管在数据包里已说明了目标主机的 MAC 地址，
但是集线器还是会将它收到的数据包发送到与它连接的每一个节点。而在集线器连接的局域
网中，一般情况下，其它主机在接收数据包时，会忽略掉与它 MAC 地址不匹配的数据包。
如果该网络中的某台主机想监听这个局域网的所有信息，可以简单的将它的网卡设为混杂模
式（promiscuous）就可以监听这个局域网了。
2、可网管交换式网络。
局域网内的微机通过智能交换机相连，且交换机支持端口镜像(带网管的交换机大多支
持端口镜像)，则只需将网络监听主机的监控口与网关设备或网关电脑连接在同一台交换机
上，且将网关设备所占端口的所有通信镜像到网络监听主机所接的端口，就可以实现监控。
其网络拓扑形式如下图所示：
被监测对象 被监测对
象
集线器
监控探测器
互联网
被监测对象
图 可网管交换机连接
通过交换机连接的网络叫做交换式局域网。交换机工作在数据链路层，交换机内存中有
一个地址对照表，交换机收到数据包后，处理端口会查找这个对照表以确定目的 MAC 的网
卡挂在那个端口上，然后将数据包传送到目的端口。在这种方式下，如果只将监听主机接到
交换机端口，然后将网卡设为混杂模式，也只能捕捉到进出监听主机的数据包，其它端口的
数据包并不能监听到。而可网管式交换机，具有端口镜像的功能。该功能可以让你将交换机
的一个端口指定为镜像端口，然后将其它希望镜像的端口关联到这个镜像端口上。经过这样
设置，经过被镜像的端口的网络数据也会复制一份到镜像端口上。当然简单的方法是将监听
设备和网管设备连接在同一个交换机上，然后将监听设备所在的端口设为镜像端口，将网管
设备所在的端口关联到镜像端口上，就可监听整个交换机网络。这种方式要求监听者有权限
物理接触目标网络并可以调整网络设置。
3、不可网管交换式网络。
局域网内的微机通过非智能交换机(傻交换)相连，且网关设备上也没有合适的安装点。
这时候我们需要人为的进行旁路设置，利用主机自带的一台网络流量镜像设备来实现。将内
网交换机的数据通过网络流量镜像设备镜像到网络监听主机上，组成的网络拓扑图如下。
被监测对象 被 监 测
对象
交换机
监控探测器
互联网
被监测对象
图 不可网管交换机连接
在许多交换机网络中使用的交换机，是不具有可网管功能的。要监听网络中所有的数据包，
可以使用 Cable Tap 接线盒的方式。作为一种网络连接设备，Cable Tap 的收发方式是独立进
行的，与交换机的带宽相似。Cable Tap 接入到网络中，并不影响网络的传输速度。上图就
是通过这种方式将嗅探器连入网络。这种方式也要求监听者有权限物理接触目标网络并可以
调整网络设置。
4、交换机直连网络。
在一定的特殊情况下，无法对机房总交换机进行接触，没有能够接到交换机镜像端口的
条件，这种情况只有通过交换机欺骗才能拿到数据。其网络拓扑如下：
被监测对象 被监测对
象
交换机
监控探测器
镜像设备
互联网
被监测对象
路由器
图 2—4 交换机直连网络
通过分析交换机的工作原理和 ARP 协议原理，可知它们都存在一些安全上的缺陷。利
用这些漏洞，进行交换机欺骗，就可使交换机根据 MAC 地址进行端口转发的功能不会影响
到网络监听。交换机的欺骗方法主要有三种：ARP 欺骗、MAC 复制、MAC 洪水。ARP 欺
骗的技术比较成熟，因此最常用。下面将详细说明这三种欺骗的原理：
MAC 洪水
交换机的工作方式是：帧在进入交换机时记录下 MAC 源地址，这个 MAC 地址与帧进
入的那个端口相关，因此以后通往该 MAC 地址的信息流将只通过该端口发送出去。这可以
提高带宽利用率，因为信息流用不着从所有端口发送出去，而只从需要接收的那些端口发送
出去。MAC 地址存储在内容可寻址存储器(CAM)里面，CAM 是一个 128K 大小的保留内存，
专门用来存储 MAC 地址，以便快速查询。如果向交换机发送大量含有虚假 MAC 地址和 IP
地址的 IP 包，使交换机无法处理如此多的信息而引起设备工作异常，也就是所谓的“失效”
模式，在这个模式里，交换机的处理器已经不能正常分析数据报和构造查询地址表了，然后，
交换机就会成为一台普通的集线器，毫无选择的向所有端口发送数据，这个行为被称作“泛
洪发送”，这样一来监听系统就能嗅探到所需数据了。不过使用这个方法会为网络带来大量
垃圾数据报文，对于监听者来说也不是什么好事，因此 MAC 洪水使用的案例比较少，而且
设计了端口保护的交换机可能会在超负荷时强行关闭所有端口造成网络中断，所以如今，人
们都偏向于使用地址解析协议 ARP 进行的欺骗性攻击。
MAC 复制
MAC 地址作为网卡的唯一标识在一般情况下是不能够随意修改的，任何一个网卡都有
被监测对象 被监测对
象
交换机
监控探测器
互联网
被监测对象
一个 MAC 地址，他的长度是 48 位，在初始时这个地址是由网卡制造商烧录进去的，理论
上 MAC 地址全球都是唯一的，不会出现冲突问题。不过由于操作系统的特殊性，我们可以
通过一些参数进行修改，让操作系统识别的网卡 MAC 地址呈现我们希望的数值，从而实现
了修改 MAC 地址的目的。在监控系统中，知道欲监控主机的 MAC 地址后，用这个 MAC
地址替换监听主机的 MAC 地址。这样，就会有两个端口对应同一个 MAC 地址，交换机就
会把目的地址与这个 MAC 匹配的数据包通过这两个端口发送出去。
ARP 欺骗
ARP 协议为 IP 地址到硬件地址提供动态的映射关系，实现将网络 IP 地址转化成机器
MAC 地址。如图所示：
图 IP 地址到硬件地址映射的 ARP 协议
ARP 的高速缓存维持这种映射关系，其中存放了最近 IP 地址到硬件地址的映射记录。
ARP 欺骗的实现方式与监听环境有关，有两种实现方式：局域网内 ARP 欺骗和 Internet
的 ARP 欺骗
在局域网里，计算机要查找彼此并不是通过 IP 进行的，而是通过网卡 MAC 地址，根据
协议规范，当一台计算机要查找另一台计算机时，它必须把目标计算机的 IP 通过 ARP 协议
（地址解析协议）在物理网络中广播出去，“广播”是一种让任意一台计算机都能收到数据的
数据发送方式，计算机收到数据后就会判断这条信息是不是发给自己的，如果是，就会返回
应答，在这里，它会返回自身地址，这一步被称为“ARP 寻址”。当源计算机收到有效的回应
时，它就得知了目标计算机的 MAC 地址并把结果保存在系统的地址缓冲池里，下次传输数
据时就不需要再次发送广播了，这个地址缓冲池会定时刷新重建，以免造成数据老旧和错误。
数据在发送之前需要进行封装，在网络层添加 IP 头（含有源 IP 地址，目的 IP 地址）形
成 IP 数据报，然后到达链路层，如果 IP 数据报长度大于一帧，数据链路层会将 IP 数据报分
割，然后添加以太网包头(含有源主机 MAC 地址，目标主机 MAC 地址)，再由网卡进行发
送。网卡工作在数据链路层，网卡只需要链路层 MAC 地址，不需要网络层的 IP 地址，就可
对数据包进行发送。而 MAC 地址就是通过前面提到的 ARP 寻址获得的。简单的说，数据
在局域网内的最终传输目标地址是对方网卡的 MAC 地址，而不是 IP 地址，IP 地址在局域
网里只是为了协助系统找到 MAC 地址而已。
当一台计算机要发送数据给另一台计算机时，它会以 IP 地址为依据首先查询自身的
ARP 地址表，如果里面没有目标计算机的 MAC 信息，它就触发 ARP 广播寻址数据直到目
标计算机返回自身地址报文，而一旦这个地址表里存在目标计算机的 MAC 信息，计算机就
直接把这个地址作为数据链路层的以太网地址头部封装发送出去。为了避免出现 MAC 地址
32位IP地址 48位硬件地址ARP
表保持着错误的数据，系统在一个指定的时期过后会清空 MAC 地址表，重新广播获取一份
地址列表，而且新的 ARP 广播可以无条件覆盖原来的 MAC 地址表。系统在指定的时期里，
计算机是不会再去广播寻址信息获取目标 MAC 地址的。利用这种机制，就可进行 ARP 欺
骗。
例如在以太网中有两台主机 A 和 B 进行通信，这两台主机通过交换机连接。监控主机 C
给 A 发送一个伪造的 ARP 应答包，告诉 A 它就是 B，同样再给 B 发送一个伪造的 ARP 应
答包，告诉 B 它就是 A。这样 A 和 B 都会误认为监控主机 C 的 MAC 地址是对方的 MAC
地址。这样，监控主机 C 就能同 A 和 B 建立活动连接，从而监听 A 和 B 传递的信息，而 A
和 B 却认为双方是在直接通信。只要监听主机在被监听的机器重新发送 ARP 查询包前及时
伪造虚假 ARP 应答包就能维持着这个通讯链路，从而获得持续的数据记录，同时也不会造
成被监听者的通讯异常。
Internet 并不采用 MAC 寻址，如果一个局域网内通过网关上网，那么连接外部的计
算机上的 ARP 缓存中就存在网关 IP-MAC 对应记录。ARP 协议的作用是将 IP 地址映射
到 MAC 地址,监听设备通过向目标主机发送伪造的 ARP 应答包,使目标系统更新自身的
ARP 缓存表,将目标系统的网关的 MAC 地址修改为监听设备的主机 MAC 地址,使数据包都
经由监听设备的主机,同时监听设备向网关发送伪造的 ARP 应答包,欺骗网关更新自己的
ARP 缓存表,网关发给目标主机的数据也都流经监听的主机,这样就实现了交换环境下的网
络监听。
在这两种监听方式中，由于监控的双方都直接将数据发送到起中转作用的监控主机上，
因此可以直接使用网卡的缺省工作方式，不必将其设为混杂模式。
§ 数据包捕获机制
通常网卡在接收到网络上传来的数据包后，经过 MAC 匹配后，产生中断信号，通知操
作系统调用网卡驱动程序进行接收，然后把这些数据交给上层的协议栈进行处理。在这个过
程中，根据系统设置的过滤条件，通常会丢弃一些不符合条件的数据包。对于监控系统来说，
由于监控环境的复杂性，特别是在高速网络中，如果处理速度跟不上，将严重影响监控系统
的性能。因此，为了提高效率，必须尽可能早的在底层截获数据包，设定过滤条件，丢弃监
控系统不需要的数据包。
捕获到的数据包先在操作系统的内核空间，然后再由内核空间拷贝到用户空间。因此监
控系统的程序架构大体分为两部分：捕获和过滤网络数据包的内核空间部分，进行协议分析、
设计用户界面的用户空间部分，在用户空间也可以设置过滤条件，在协议分析之前对数据包
进行过滤。图 展示了一个监听系统大体框架[2]：
图 简单监听系统框架
底层包的捕获机制与操作系统有关，但其实现方式大同小异。数据包有网卡接收，经操
作系统调用网卡驱动程序处理，然后到达数据链路层，经操作系统的协议栈进行处理，最后
交给应用程序。包捕获机制是在链路层对数据包进行旁路处理，过滤和缓冲发送和接收到的
数据包，然后拷贝到应用程序。操作系统对数据包仍然进行网络协议堆栈处理，并不受包捕
获机制的影响。
包捕获机制的设计在最底层需要考虑操作系统的特征，包过滤机制则处于设计的中间部
分，而在上层给用户程序提供了一个统一的接口，方便用户使用。包捕获机制中底层与操作
系统有关的部分，用户并不可见，用户程序只考虑调用接口函数，这样使得用户程序移植性
很好。
总而言之，包捕获机制与操作系统有关，操作系统不同，提供的包过滤器也不同。常用
的操作系统包捕获机制见表 [3]。
网络
物理层
网络层
传输层
过滤器 过滤器
缓冲区 缓冲区
内核层
用户层
用户程序其它监听程序
系统无关捕获
函数库
协议分析模块
用户交互模块
表 常用操作系统的包捕获机制
包捕获机制 系统平台 备注
BPF BSD 系列 Berkeley Packet Filter
DLPI
Solaris，HP-UX,
SCO Openserver
Data Link Provider
Interface
NIT SunOS3 Network Interface Tap
SNOOP IRIX
SNIT SunOS4 Streams Network Interface Tap
SOCK_PACKET Linux 基本类似 BPF
LSF >= Linux Socket Filter
Drain IRIX 用于窃听系统丢弃的包
Unix 上最常用的三种数据链路层访问方法为:BSD 的 BPF(分组过滤器)、Linux 的
SOCK_PACKET 接口和 SVR4 的 DLPI(数据链路提供者接口)。
SOCK_PACKET 类型的协议套接字工作在用户层，Linux 用它可以实现对链路层的访问
的部分功能，而通常要通过编写内核驱动程序，在 Linux 下才可对链路层进行访问。使用
SOCK_PACKET 建立的套接字，内核直接将网络数据交给用户而不进行处理，用户可以直
接从网卡的协议栈得到数据。使用如下方式来建立 SOCK_PACKET 类型的套接字：
socket (AF_INET,SOCK_PACKET, htons(0x0003))；
表示建立的因特网协议族类型的套接字，该套接字在物理层截取数据帧，数据不需要网
络协议栈处理，而且截取帧的类型为不确定，所有的数据包都需处理。
在使用此套接字进行监听的时候，要将监听主机的网卡模式设置为“混杂”模式，才能监
听到其它主机的数据。网卡的模式设置可以通过设备管理函数 ioctl（）来实现。其结构如
图 所示：
图 基于 SOCK_PACKET 的捕包机制
数据链路SOCK_PACKET套接口
收到的分组的拷贝
发送的分组的拷贝
协议栈
内核
用户空间
程序2程序1
Linux 的 SOCK_PACKET 方法主要存在两个方面的不足：1）没有内核缓冲功能，在内
核也不能进行过滤，它的套接口接收缓冲区一次只能接收一帧数据，每接收到一帧数据就需
要调用操作系统将其从内核拷贝，传递给应用进程。这样一来它的数据包接收过程需要频繁
的进行系统调用，使得系统开销很大。2）不能对设备过滤。套接口要接收来自以太网、PPP
链路、SLIP 链路等设备的数据，而不能只接收某一设备的数据，比如以太网设备。这就需
要在应用进程中进行过滤，丢掉不需要关注设备的数据，这就对高速网络的监视造成了影响。
以及源自 Berkeley 的许多其它实现都支持 BSD 分组过滤器（BSD Packet Filter,
简称 BPF）[4]。BPF 是包括 Libpcap 库在内的众多数据包截获系统的工作基础。目前,许多版
本 Unix 和 Linux 平台上多数嗅探器都是基于 BPF 开发的。BPF 工作机制如图 2—8 所示：
图 使用 BPF 捕获分组
使用 BPF 进行监听的每一个应用进程可以装载自己的过滤器，这个过滤器是通过基于
寄存器的过滤器机器作用于每一个数据包。过滤器程序可以通过这个伪机器的机器语言编写，
但有一种更简单的编写方式，就是使用 pcap_compile 函数接口，将应用进程设定的 ASCII
过滤字符串编译成 BPF 伪机器的机器语言。使用 BPF 在网络接口对数据链路层进行网络监
听时，对于到达的数据包，网络接口设备的驱动器先不将它传递给上层的协议栈进行处理，
而是先调用 BPF 进行数据包传递，由每个监控进程的过滤器对数据包进行过滤处理。如果
这个数据包被过滤器接收，它就会传到与过滤器相连的缓存中，最后由应用进程处理时再将
其从缓冲区拷贝到用户进程空间中。在数据包传到缓存后，控制权就交给链路层设备驱动程
序，由上层的协议栈处理被提交上来的数据包。
网络中的数据除了按内核协议栈流程传递处理，Linux 内核还提供了一种灵活修改网络
数据的机制，在网络数据流转经过多个地点设立检查点，用户可以在这些检查点设立处理方
法，数据流转这些地方的时候就会按照这些方法进行处理，然后再正常流转。Linux 内核中
的 netfilter 就是基于这种机制实现的。在 Linux 内核中，用 NetFilter 模块实现 BPF，在用户
数据链路BPF
收到的分组的拷贝
发送的分组的拷贝
IPv4/IPv6
内核
用户空间
应用进程应用进程
过滤器 过滤器
缓冲区 缓冲区
空间用 iptables 实现过滤。对于 IPV4、IPV6 等网络协议栈，netfilter 在 Linux 内核中都有相
应的实现。IPV4 在数据包的传递过程中设立了五个检查点，分别是 NF_IP_PRE_ROUTINE、
NF_IP_FOWARD、NF_IP_POST_FOUTINE、NF_IP_LOCAL_IN 和 NF_IP_LOCAL_OUT。
这五个点又称作五个钩子函数。内核通过这五个钩子函数完成包过滤过程[5]。
BPF 使用以下 3 个技术来降低开销[4]：
（1） BPF 过滤在内核进行，以此把从 BPF 到应用进程的数据拷贝量减到最小。
（2） 由 BPF 传递到应用进程的只是每个分组的一段定长部分。这个长度称为捕获长
度。大多数应用进程只需要分组头部而不需要分组数据。这个技术减少了由 BPF
拷贝到应用进程的数量。也可以根据应用的需要设置这个长度值。
（3） BPF 为每个应用进程分别拷贝数据，只有当缓冲区已满或读超时期满时该缓冲
区中的数据才拷贝到应用进程。如此缓冲，虽然还是相同数量的分组从 BPF 拷
贝到应用进程，但系统调用的次数大量减少，提高了数据包处理效率。每个应
用进程使用两个缓冲区，由 BPF 维护，当应用进程从一个缓冲区拷贝数据时，
接收的数据可以缓冲到另一个缓冲区。
§ 数据包捕获函数库
监控程序虽然在实际的监控应用中对监控的内容可能不同，但却常常需要检查、处理和
控制网络通讯的细节，比如查看通讯双方的地址，使用什么端口，服务类型是什么，有什么
样的传输控制机制等。通常在网络安全监控程序中必须实现以下功能：截获数据包，分析数
据报头，重写数据包甚至将通讯连接截断。对于这些常用功能和繁复的过程，一个好方法是
可以写一些函数将它们封装起来，这样安全监控程序的编写可以大大简化，其性能和健壮性
也可以提高。这些封装的函数以应用程序编程接口函数库的形式供开发人员使用。
这样的 API library 有很多，像 libpcap、libnet、libnids 等都是类 Unix 系统平台上比较流
行的网络开发工具，它们各有不同的特点。Libpcap 是平台独立的分组捕获函数库，主要支
持读入分组；而 libnet 则支持构造任意协议的分组和数据链路分组的写出；libnids[7]的开发
是基于 libpcap 和 libnet 的，除了能够捕获网络数据包，还能重组 ip 碎片，重组 TCP 数据流，
监测端口扫描攻击等。使用这些函数库，可以屏蔽网络底层编程在不同操作系统的差别，可
以使开发人员集中解决开发应用中的主要问题上[6]。本文所论述的系统是监控系统，故下面
将详细讨论 libpcap.
Libpcap 函数库
1．Libpcap 概述
Libpcap[8]的英文意思是 Packet Capture Library，是一个开源的数据库，向网络抓包系统
提供一个高层接口。它由 McCanne,Leres 和 Jacobson 在 1994 年设计，是一个独立于系统的
用户层包捕获的 API 接口。虽然几乎每一个操作系统都有自己的抓包机制，但是应用程序使
用 libpcap 就可以消除依赖于系统的包捕获模块，这样就为底层网络监控编程提供了一个易
于移植的应用框架。libpcap API 可以在 C 和 C++语言里使用，然而它有许多包装方法，使
得它也可以在 Perl、Java、Python 等语言里使用。几乎所有的类 Unix 操作系统都可以运行
libpcap，当然也包括 Linux.
的使用[9]
使用 libpcap 进行网络监听，首先需要知道监听的网络接口。我们可以在程序里指明或
者使用 libpcap 进行查找。查找网络接口的函数是 char* pcap_lookupdev(char *errbuf),这个函
数返回一个字符串指针，这个指针所指的字符串含有适合包捕获的第一个网络设备。如果终
端用户未指明任何网络接口，就需要调用这个函数。指明网络接口，在 Linux 中我们可以这
样说明，比如 eth0，一个错误的做法是使用硬编码的接口名字，这是因为它们不是跨平台可
移植的。这个函数的 errbuf 参数所使用的缓冲空间由用户提供，在错误发生时，库函数用这
个缓冲空间存储错误消息。Libpcap 的许多函数需要这个参数，我们必须小心分配这个缓冲
空间，因为这个缓冲空间必须至少能容纳 PCAP_ERRBUF_SIZE 个字节，目前定义为 256.
一旦知道了网络设备的名称，我们需要打开它。函数 pcap_t *pcap_open_live（const char
*device， int snaplen， int promisc， int to_ms， char *errbuf）用来打开网络设备。这个函
数返回 pcap_t 类型的接口句柄，当调用 libpcap 的其它函数时，就需要使用这个句柄。这个
函数的第一个参数是一个字符串，它含有想要打开的网络设备的名称。第二个参数是要捕捉
的最大字节数。当我们仅需要捕获数据包头或者对内存有重要限制的嵌入式系统进行编程时，
将这个参数设定一个较低的值比较好。通常，以太帧最大长度为 1518 个字节，但是其它的
链路类型可能有更大的长度。但是 65535 这个值能够容纳任何网络上的任何一个数据包。参
数 to_ms 规定了将捕捉的信息从内核空间拷贝到用户空间时，内核应该等待多长时间（单位
是毫秒）。上下文的改变的代价是比较大的。如果我们在高速网络上捕捉数据，最好让内核
让内核先把一些包缓冲在一起，然后再一起从内核空间拷贝到用户空间。如果将 to_ms 设
为 0，在没有足量的数据包到达网络设备之前，读取操作会一直等待。Libpcap 的文档并没
有对这个数值提供任何建议。但是我们可以参考一些嗅探器设定的值，比如 tcpdump 使用的
值为 1000，而 dsniff 使用的值为 512.参数 promisc 是一个标记参数，它的数值决定了网络设
备是否用 promiscuous 模式，设为 0，则网络设备是非 promiscuous 模式，非 0 数值则设定网
络设备为 promiscuous 模式。注意，如果我们让 libpcap 以 non-promiscuous 模式监听，但接
口的工作方式之前已经是 promiscuous 模式，接口可能仍然保持该模式。我们不能想当然的
认为，此时网卡不会接收目的地址是其它主机的数据包。对于这种情况最好使用 libpcap 提
供的过滤功能。
一旦我们打开网络设备进行数据包的捕捉，我们实际上告诉 pcap 开始获得数据包。要
获得数据包，我们有几个选择：
1） 函数 const u_char *pcap_next(pcap_t *p, struct pcap_pkthdr *h),这个函数需要一
个由 pcap_open_live 返回的 pcap_t 句柄，和一个 pcap_pkthdr 类型的结构指针，
该函数返回到达网络设备的第一个数据包。
2） 函数 int pcap_loop（pcap_t *p，int cnt， pcap_handler_callback, u_char* user）用
来采集数据包并进行处理。这个函数在没有捕捉到 cnt 个数据包之前，不会返
回。如果将 cnt 的值设为负值，这个函数会一直运行下去，只有错误发生的情
况下才会返回。
函数 pcap_loop（）返回的是一个整数值，并没有返回捕捉到的数据包，而是每当有一
个数据包准备读取时，就调用一个用户定义的函数进行处理。这样我们就可以使用一个
独立的函数去处理数据包。如果使用 pcap_next（）函数，就必须进行循环调用，但对
包的处理过程也得放在循环里。使用 pcap_loop()调用用户定义的函数时，有一个问题是
如何向用户定义的函数传递参数。使用全局变量并不是一个好方法。Libpcap 的解决方
法是使用用户参数。每次调用时，这个指针就会被传递指针类型是 u_char，因此当调
用 pcap_loop()函数时，我们需要根据需要改变其类型，另外在用户定义的函数内部时，
也应根据需要进行相应的类型转换。用户定义的包处理函数必须符合具体的函数规范，
否则 pcap_loop()就不知道如何使用这个函数。这个包处理函数应该按下面的方式声明：
void function_name （ u_char *userarg, const pcap_pkthdr * pkthdr, const u_char
*packet）；
第一个参数是我们传递给 pcap_loop（）的用户指针，第二个参数是含有捕捉包信
息的结构体指针，这个结构体定义是：
struct pcap_pkthdr{
struct timeval ts； /*捕捉时间戳*/
bpf_u_int32 caplen; /*存储的字节数*/
bpf_u_int32 len; /*数据包的总长度*/
}；
这个结构体的数据成员 caplen 的数值通常与成员 len 的数值相同，除非捕获包的大
小超过了 pcap_open_live()里规定的 snaplen。
函数 pcap_dispatch（pcap_t *p， int cnt，pcap_handler_callback, u_char *user）与函数
pcap_loop（）的功能相似，但是当在 pcap_open_live()规定的 to_ms 时间超时时，这个函数
也会返回。
当我们得到数据包时，我们的应用程序得到的只是一串字节。通常网卡驱动程序和协议
栈会对这些数据处理，但是在我们应用程序里捕捉的数据包，必须由我们自己进行分析，而
要进行分析，我们必须了解一些相关的协议，这些知识将在第三章进行论述。
当然，在没有设定过滤条件的情况下，上文的几个获得的数据包函数获得的包是所有流
经该网卡的数据包，这会降低整体性能甚至可能导致内核丢包。这是因为抓包过程发生在内
核，而应用程序发生在用户空间，而从内核空间拷贝到用户空间会消耗掉大量的 CPU 时间。
通常我们只对某种类型的数据包感兴趣，我们就可以让内核对进来的数据包过滤，这样就只
能得到匹配过滤表达式的数据包的拷贝。内核的系统包过滤器提供过滤功能。包过滤器基本
上是用户定义的程序，每接收一个包，网卡驱动就会调用它。Linux 操作系统支持 BPF 架构。
Libpcap 对基于 BPF 的包过滤器提供完全的支持。设定一个过滤器需要三个步骤：构造一个
过滤表达式，将表达式编译到 BPF 程序中，最后应用这个过滤器。
BPF 程序是用类似汇编的语言写的。但是，libpcap 和 tcpdump 使用一个高级语言对过
滤器进行定义。这个高级语言的具体语法可以在 tcpdump 手册里看到。这里举写例子：src host
返回 IP 地址是 的数据包；tcp[13] == 0x02 and (dst port 22 or dst
port 23) 返回设定了 SYN 标志位并且目的端口是 22 或 23 的数据包。
一旦有了过滤表达式，我们需要对它翻译成一个 BPF 程序，使内核能够明白。函数 int
pcap_compile（pcap_t *p， struct bpf_program *fp， char *str， int optimize， bpf_u_int32
netmask）将 str 所指的过滤表达式编译成 BPF 代码。参数 fp 是 bpf_program 类型的结构体指
针，在使用 pcap_compile（）之前，我们应先声明一个 bpf_program 的结构变量。参数 optimize
是个标记参数，控制过滤程序是否为了效率而进行优化。最后一个参数是捕包网络的网络掩
码，我们可以将这个参数设为 0，除非我们想测试广播地址。然而，如果需要决定网络掩码，
函数 pcap_lookupnet(const char *device， bpf_u_int32 *netp bpf_u_int32 *maskp, char *errbuf)
可以做到这一点。
有了编译的 BPF 程序，我们需要将它插入到内核中，可以调用函数 pcap_setfilter（pcap_t
*p, struct bpf_program *fp）来进行插入。插入之后，就可以调用函数 pcap_loop()或 pcap_next
（）开始抓包。
当然在程序结束前，使用函数 void pcap_close（pcap_t *p）关闭会话，释放资源。
3．Libpcap 数据包捕获应用程序框架
Libpcap 库函数有很多，在 Linux 下并不是所有的 libpcap 库函数都会用到。Libpcap 应
用程序从形式上看很简单。基于 BPF 和 Libpcap 的简单的数据包捕获应用程序系统框架如图
所示 所示：
图 基于 Libpcap 的包捕获系统框架图
4．Libpcap 缺陷和改进方法
尽管 libpcap 函数库在不同的平台上提供相同的 API，但 libpcap 的性能在不同的平台上
则差别很大。在低流量的环境下，性能没有明显的不同，因为所有的包都会被捕捉，然而在
高速环境下，情况就会有很大的不同，在使用标准的 libpcap 下，Linux 花费大量的时间用于
将捕获的数据包从网卡移动到内核，却只有少量的时间用于将数据包从内核移到用户空间，
导致丢包严重。每次数据包到达时，网卡就会产生一个中断，由于中断任务较其它任务优先
权高，操作系统会调用网卡驱动进行处理。在高速大流量的网络下，会频繁产生中断，导致
开始
指定要监视的网络设备
查找可用网络设备
（）
打开网络设备作为包捕获描述符()
判断与网络设备相关的网络号及掩码()
编译过滤规则为内核过滤码()
设置过滤器()
捕包并处理()或()
关闭并返回()
是
否
操作系统花费大量时间处理中断，而没有时间处理其它任务，不能及时对捕获的数据包进行
处理，从而导致大量的丢包。这个问题也叫中断活锁[10]。
对于中断活锁的一个解决方法是采用“设备轮询”[11]，轮询是处理各种设备（包括网卡）
的技术，它的工作方式如下所述：
当网络设备收到一个数据包时，它产生一个中断去引发内核操作。操作系统对中断进行
如下操作，它首先屏蔽由网卡产生的中断，这样网卡就不能中断内核，然后调度一个任务去
定期轮询网卡，为需求服务，一旦驱动器完成了网卡的处理，网卡中断就又再次激活。设备
轮询技术可以让操作系统控制设备，并且阻止设备在高速大流量的网络下对内核的控制。设
备轮询有利于高负荷网络下改善包的捕获性能和系统响应。Linux 将设备轮询技术引入到
NAPI 中。
对数据包捕捉来说，内核设备轮询并不足以应付各种情况，比如使用了设备轮询的 linux
系统，对高速网络中有大量较小数据包的情况下，捕获效果就很低。
通过分析抓包程序中数据包的流向可知，数据包需要从网卡拷贝到内核，然后又从内核
拷贝到用户空间，两次拷贝都会对系统有较大的消耗。
零拷贝被提出来解决数据多次拷贝问题。零拷贝指的是一些计算机操作，使用这些操作
可以让 CPU 不执行将数据从内存的一个地方拷贝到另一个地方的任务。创造零拷贝的技术
包括使用基于 DMA 的拷贝技术和通过内存管理模块进行的内存映射技术。这些特征需要具
体的硬件支持并且通常涉及到特别的内存校正要求[12]。图 对传统报文的数据处理和零
拷贝数据的处理做了比较。
图 传统报文处理与零拷贝的对比
用户进程
内核空间
网卡
系统
调用 拷贝
拷贝
用户进程
缓冲区
网卡
mmap
DMA
PF_RING
综合上面的分析，PF_RING 这种新的解决方案被提出来。PF_RING 是一个高速网络数
据包捕捉解决方案，它可以使用商用硬件改善标准的 Linux 内核捕捉性能。PF_RING 能够
利用可识别 NAPI 的驱动器，并且不需要任何特别的硬件，因此它能在由标准 linux 内核支
持的每一个网络接口卡上使用[13]。
PF_RING 定义了一种用于包捕获的新型套接字。该套接字使用内存映射的缓冲区，该
缓冲区被实现为一个环状 FIFO 缓冲，由内核和用户应用程序共享。而且，为了完全绕过标
准的协议处理部分，内核的网络核心部分做了修改。因此，内核包的旅程大量减少。PF_RING
提供了一个内核补丁和一个用户空间库。内核补丁提供了一个可卸载的内核模块，ring 模块，
有了这个模块才可以使用 PF_RING 类型套接字。环状缓冲区得大小可以用两个不同的模块
参数定制：bucket_len 和 num_slots。第一个参数表示换种缓冲区得长度，而第二个参数表示
捕获包的最大长度。如果数据包的长度大于 bucket_len，该数据包的前 bucket_len 个字节存
储在 slot（槽）。将 bucket_len 的长度降低到最大传输单元（MTU）以下导致花费在拷贝上
的时间的减少。改变 bucket_len 的长度是因为有些监控应用只需要每个包的少量字节。
PF_RING 的用户空间库是 libpfring，利用该库可以对数据包捕获应用程序进行快熟开发。
该库的详细使用方法，可以参考它的用户手册。libpcap 也有一个 PF_RING 加强的版本，因
此用 libpcap 用户接口编写的监控应用程序也能直接受益于 PF_RING。图 清晰的描述
了 PF_RING 的逻辑结构[14]。
图 PF_RING 逻辑结构图
PF_RING 极大的增加了标准 Linux 操作系统的数据包捕获性能。它被研究人员和监控
行业认为是不需要昂贵硬件设备就能进行极其有效的数据包捕获的一种优秀的解决方案。
网卡
Socket
（ring）
Socket
（ring）
insert
slot
insert
slot
WriteWrite
remove
slot
remove
slot
内核空间
用户空间
应用程序1 应用程序2
mmap() Read Read mmap()
§ 本章小结
本章着重介绍了监控系统的数据包捕获方式，然后重点介绍了在内核部分操作系统提供
的数据包捕获机制 BPF，在用户空间部分对目前最常用的系统无关捕获函数库 Libpcap 进行
了介绍，并给出了它的简单应用框架。考虑到监控系统的监控环境的复杂性，特别是在高速
复杂的网络环境中的性能要求，标准 libpcap 存在的一些不足，又介绍了新的数据包捕获套
接字模型 PF_RING，使用 PF_RING 接口的 libpcap 的性能得到极大的增强。
第三章 网络协议分析
网络内容监控系统捕捉到数据包后，常常需要从中获得详细的内容信息以满足具体的应
用要求。而捕捉到的数据只是一串字节。通常网卡驱动程序和协议栈会对这些数据处理，但
是在我们应用程序里捕捉的数据包，必须由我们自己进行分析，而要进行分析，我们必须了
解一些相关的协议。根据这些协议知识，我们可以从捕获的数据包中获得网络上各种信息，
比如网络上运行的协议和提供的服务，还可以知道一个数据包的源地址和目的地址以及它所
负载的应用信息等。网络通信的基础是协议，协议通常是公开的，因而对协议的分析是可行
的。数据帧中的各个部分的字节都有特定的含义，通过对数据包的原始数据进行解码，显示
数据包各个域的信息，然后根据适当的有关协议的 RFC 文档和其它的规范就可以对具体的
内容进行分析，然后根据实际的需要，进行相关的操作，这就是网络内容监控系统的协议分
析部分的主要内容。对于本文中论述的 WebMail 监控系统来说，协议分析不仅仅要判断捕
获的原始以太数据包，还要将特定的数据包逐步重组为应用层数据，这是监控系统实现应用
层功能的基础。
§ TCP/IP 基本原理
基本原理概述
(1) 网络协议的开发通常分不同的层次，每一层所负责的通信功能不同。
协议族，比如 TCP/IP[15]，是一组各个层次上的不同协议的组合。TCP/IP 一般被认为是
一个四层系统，每一层都有不同的功能。图 显示了各种层次的协议和它们之间的关系：
图 TCP/IP 协议族中不同层次的协议
表 描述了 TCP/IP 的四个层次和每个层次的主要协议及主要功能
硬件
接口
RARPARP
IP IGMPICMP
UDPTCP
用户
进程
用户
进程
用户
进程
用户
进程
应用层
运输层
网络层
媒体
表 TCP/IP 层次功能表
TCP/IP 层描述 主要协议 主要功能
链路层 ARP，RARP 和设
备驱动程序及网
络接口卡
链路管理，差错控制，发送时将网络层数据报封装进链路层的帧，
接收时从接收到的比特流中准确地区分出一帧的开始和结束。
ARP（地址解析仪）和 RARP（逆地址解析协议）是某些网络接
口使用的特殊协议，用来转换 IP 层和网络接口层使用的地址。
网络层 ICMP、IP 和
IGMP
数据包的路由选择发生在这一层。TCP/IP 协议族的最为核心的
协议是 IP，被上层协议使用。ICMP 和 IGMP 是 IP 协议的附属
协议。
运输层 TCP 和 UDP 提供源主机和目标主机上的对等层之间可以进行会话的机制。
TCP 和 UDP 是两个互不相同的运输层协议。
应用层 HTTP、FTP、Telnet
和 P2P 等
应用程序的细节由这一层负责处理。如常用于传送网页的 HTTP
协议，用于文件传输协议 FTP，用于简单邮件传送协议 SMTP 等。
(2) 网络上通讯的协议流程
各个协议在网络通讯中如何发生作用，我们可以用以太网中两台主机的通讯来进行说
明。这两台主机在应用层运行 HTTP 协议，图 列出了该过程数据的具体流向以及所涉及
到的所有协议。
图 局域网上运行 HTTP 的两台主机
网络应用程序大多数都设计成客户和服务器模式，服务器提供某种服务，客户则向服务
器发出请求，获得这种服务。这里，通讯的两台主机，一个运行 HTTP 客户程序，一个运
以太网驱动
程序
以太网驱动
程序
IP IP
TCP TCP
HTTP
客户
HTTP
服务器
HTTP协议
TCP协议
IP协议
以太网协议
应用层
运输层
网络层
链路层
以太网
用户
进程
处理应用
程序细节
内核 处理通信
细节
行 HTTP 服务器程序，比如客户访问 web 服务器的网页。在客户机和服务器上，数据处理的
功能层次是垂直方向的结构层次。但在同一层上，双方都有对应的一个或多个协议进行通信。
(3) 数据的封装解封过程
图 所示为一个运行于主机 A 上的应用程序，通过网络发送数据到主机 B 上的应用程
序，数据流通过程在主机 A 上由上至下依次进过网络协议栈，通过网络发送给主机 B，在主
机 B 上又自下而上进过 TCP/IP 四层协议栈。
图 TCP/IP 四层模型数据传输过程
发送的过程是一个封包的过程。主机 A 上，在运输层，用户发送的数据要增加运输层
的头部（TCP 头部或 UDP 头部）,用户数据封装在运输层的数据部分。在 IP 层增加 IP 的头
部数据，运输层的数据和头部都封装在 IP 层的数据部分。IP 层将数据传输给网络设备的驱
动程序，以太网增加头部和尾部后，发送到以太网上。
接收数据的过程是一个解封包的过程。主机 B 上，驱动程序从以太网上接收到数据，然
后将数据去除头部和尾部并进行 CRC 校验后，将正确的数据传递给 IP 层。IP 层剥去 IP 头，
进行校验，将数据发送给其上层运输层。运输层将 UDP 或 TCP 的包头剥去，根据应用程序
的标识符判断是否发送给此应用程序。在主机 B 上的应用程序最后得到干净的有效数据，然
后进行处理。
以太网头
部
网络层头
部
传输层头
部
数据
以太网尾
部
以太网
驱动程序
网络层
运输层
应用程序
驱动程序
网络层
运输层
应用程序
网络层
头部
运输层
头部
数据
封
装
解
封
运输层
头部
数据
数据
主机A
发送数据
主机B
接收数据
以太网数据
46~1500字节
网络层数据
运输层数据
应用层
数据
以太网首部
由 TCP/IP 的四层结构可以看出，本层主要为 IP 协议和 ARP 协议提供服务、发送和接
收网络数据包。以太网是由几家美国商业公司联合开发的基带局域网规范，它已经作为现有
局域网采用的最通用的通信协议标准，目前 TCP/IP 技术主要基于此标准。以太网的封包格
式如图 所示，在 IP 数据的基础上增加了共 14 个字节[16]。
图 以太网的数据格式
以太网用 6 字节来表示源地址和目的地址。这里的源地址和目的地址指的是硬件地址，
例如网卡的 MAC 地址。在地址后面是两个字节的表示类型的字段，例如 0800 表示此帧的
数据为 IP 数据，0806 表示此帧为 ARP 请求。类型字段之后是数据，对于以太网，规定数据
段的大小范围是 46 个字节到 1500 个字节，不足的数据要用空字符填满。例如 ARP 协议的
数据格式为 28 个字节，为了符合规范，其后有 18 个字节的占位符用于满足最少 46 字节的
要求。CRC 字段用于对帧内数据进行校验，保证数据传输的正确性，通常由硬件实现，例
如在网卡设备中实现网络数据的 CRC 校验。
IP 首部
TCP/IP 协议中最重要的协议是 IP 协议，它为上层协议如 TCP、UDP 等协议提供传输的
通路。IP 层的主要目的是提供子网的互联，形成较大的网络，使不同的子网之间能传输数据。
IP 层主要有如下作用：
数据传送：将数据从一个主机传输到另一个主机。
寻址：根据子网划分和 IP 地址，发现正确的目的主机地址。
路由选择；现则数据在互联网上的传送路径。
数据报文的分段：当传送的数据大于 MTU（以太网为 1500），将数据进行分段发送和
接收并组装。
IP 数据的格式如图 所示，不包含选项字段，其头部的长度为 20 字节。
目的地址
（6字节）
源地址
（6字节）
类型
（2字节）
数据（46~1500字节）
CRC
（4字节）
类型0800
（2字节）
IP数据包（46~1500字节）
CRC
（4字节）
类型0806
（2字节）
ARP请求应答（28字节）
PAD
(18字节）
类型8035
（2字节）
RARP请求应答（28字节)
PAD
（18字节）
图 IP 数据报格式及首部中的各字段
IP 提供数据报传送服务，IP 传送的特定是不可靠和无连接的。IP 只提供最好的传输服
务，对 IP 数据包是否能成功到达目的地并不能保证。路由器会丢弃不能到达目的地的 IP 数
据报，并给发送该消息的源端发送 ICMP 消息。由上层某些协议来提供可靠性。IP 独立的处
理每个数据报，并不对后续数据报的状态信息进行维护。因此，发送 IP 数据报时，可以不
按顺序。IP 的正式规范文件是 RFC791。
TCP 首部
传输控制协议，简称 TCP 协议，它在原有 IP 协议的基础上，增加了确认重发、滑动窗
口和复用/解复用等机制，提供一种可靠的、面向连接的字节流服务。
TCP 协议的特点如下：
字节流的服务：使用 TCP 协议进行传输的应用程序之间传输的数据可视为无结构的字
节流，基于字节流的服务没有字节序问题的困扰。
面向连接的服务：在数据进行传输之前，TCP 协议需要先建立连接，之后的 TCP 报文
在此基础上传输
可靠传输服务：基于校验和应答重发机制保证传输的可靠性，接收方对接收到的报文进
行校验和计算，如果有误，不发送确认应答，发送方在超时后会自动重发此报文。
缓冲传输：缓冲传输可以延迟传送应用层的数据，允许将应用程序需要传送的数据积攒
到一定的数量才进行集中的发送。
全双工传输：各主机 TCP 协议以全双工的方式进行数据流交换。
流量控制：TCP 协议的滑动窗口机制，支持主机间的端到端的流量控制。
4位
版本
4位首部
长度
8位服务类型
（TOS）
16位总长度（字节数）
16位标示
3位
标志
13位片偏移
8位生存时间
（TTL）
8位协议 16位首部校验和
32位源IP地址
32位目的IP地址
选项（如果有）
数据
20字节
0 15 16 31
TCP 的数据格式：
TCP 在 IP 协议的基础上进行传输数据，TCP 数据在 IP 报文中的位置如图 所示：
图 TCP 数据在 IP 报文中的位置
TCP 报文包含头部和数据两部分，其数据格式如图 所示。主要有源端口号、目的端
口号、序列号、确认号、头部长度、控制位、窗口尺寸、TCP 校验和、紧急指针和选项等字
段。
图 TCP 报文中的数据格式
（1） 源端口号和目的端口号表示发送端和接收端的端口，用于确认发送端和接收端的应
用程序。发送端的 IP 地址和端口号及接收端的 IP 地址和端口号可以确认一个在
Internet 上的 TCP 连接。
（2） 序列号：序列号是一个 32 位长度的字段，表示分配给 TCP 包的编号。序列号用来
标识应用程序从 TCP 的发送端到接收端发送的字节流。
（3） 确认号：发送方对发送的首字节进行了编号，当接收方成功接收后，发送回接收成
功的序列号加 1 表示确认，发送方再次发送的时候从确认号开始。
（4） 头部长度：表示 TCP 头部的长度，由于 TCP 的数据有可选字段，头部长度用于表示
IP头部（20字节） TCP头部（20字节） TCP数据
TCP数据
IP数据
源端口号（16位） 目的端口号(16位）
序列号（32位）
确认号(32位）
头部长度
（4位）
保留
（6位）
U
R
G
A
C
K
P
S
H
R
S
T
S
Y
N
F
I
N
窗口尺寸（16位）
TCP校验和（16位） 紧急指针（16位）
选项（32位）
数据
20
字
节
头部的长度。
（5） 保留位： 6 位长度没有使用，必须为 0。
（6） 控制位：用作控制位，可以一起设置多个位，含义如下所述。
URG：表示紧急指针有效
ACK：确认序号有效
PSH：表示接收方需要尽快将所收到的数据交给应用层
RST：连接有错，需要重建连接
SYN：用于发起一个 TCP 的连接
FIN：用于表示将要断开 TCP 连接
（7） 窗口尺寸：窗口尺寸也称接收窗口的大小，表示本机上 TCP 协议可以接收的以字节
为单位的数目。
（8） 校验和：用于校验 TCP 传输数据的正误，包括 TCP 头和所有数据，TCP 的数据必须
强制校验。
（9） 紧急指针：只有设置了 URG 位才有效，它指出了紧接紧急数据的字节的顺序编号。
（10） 选项：经常使用的为最大分段长度 MSS。TCP 连接通常在第一个通信的报文中指明
这个选型，它指明当前主机所能接收的最大报文长度。
UDP 首部
UDP 是一种基于 IP 协议的不可靠网络传输协议，在 IP 数据的位置如图 所示：
图 UDP 数据在 IP 数据的位置
UDP 协议是 TCP/IP 的传输协议的一部分，与 TCP 的传输不一样，它提供无连接的不可
靠的传输服务。UDP 协议把应用程序需要传递的数据发送出去，不提供发送数据包的顺序；
接收方不向发送方发送接收的确认信息，如果出现丢包或者重包的现象，也不会向发送方发
送反馈，因此不能保证使用 UDP 协议的程序发送的数据一定到达了接收方或者到达接收方
的数据顺序和发送方的一致性。
图 显示了 UDP 首部的各字段：
IP头部（20字节） UDP头部（8字节) UDP数据
UDP数据
IP数据
图 UDP 数据格式
发送方和接收方的 UDP 端口用源端口号和目的端口号表示。UDP 数据长度表示 UDP
头部和 UDP 数据段的长度，单位为字节。由于 UDP 头部为 8 个字节，因此发送 UDP 的长
度字段最少为 8 字节。UDP 的长度与 IP 协议的长度有关联性，UDP 的长度等于 IP 的长度
减去 IP 头部的长度。UDP 校验和表示整个 UDP 字段的 CRC16 校验和，它的计算方法与 IP
字段是一致的。
HTTP 应用协议
本文中论述的 WebMail 监控系统在应用层是基于 HTTP[17][18]协议，因此这里将详细介
绍。
HTTP 是超文本传输协议，是客户端浏览器或其他程序与 Web 服务器之间的应用
层通信协议，适用于分布式、协作的超媒体系统。它是通用的、无状态的、面向对象
的协议。通过扩展它的请求方法，错误编码号和消息包头，也能应用到其它方面，比
如域名服务器和分布式对象管理系统等。它从开始使用到现在，经过不断发展和完善，
已经演化出多个版本。目前正在使用的是 HTTP/ 和 HTTP/ 这两个版本。
HTTP 协议在客户-服务器模式中具有请求／响应范式功能的协议。HTTP 通讯多
发生在 TCP/IP 的连接上。一个客户机与服务器建立连接后，发送一个请求给服务器，
请求方式的格式为，统一资源标识符、协议版本号，后边是 MIME 信息包括请求修饰
符、客户机信息和可能的内容。服务器接到请求后，给予相应的响应信息，其格式为
一个状态行包括信息的协议版本号、一个成功或错误的代码，后边是 MIME 信息包括
服务器信息、实体信息和可能的内容。
HTTP 报文由从客户机到服务器的请求和从服务器到客户机的响应构成。
HTTP 报文 = 请求 | 响应 ；HTTP/ 报文
请求和响应报文使用通用的报文格式（见 RFC822）去传输实体信息。这两种类
型的报文由一个开始行，零个或多个报头，空行（以回车换行符 CRLF 为前缀，什么
也没有，这个空行表示报文头得结束），和一个可能的报文正文组成。报文格式如下：
源端口号（16位） 目的端口号（16位)
UDP数据长度（16位） UDP校验和（16位）
数据
8个字节
0 15 16 31
通用报文 = 开始行
报文头 CRLF（零个或多个）
CRLF
[报文正文]（可能有）
开始行 = 请求行 | 状态行
请求报文的请求行的组成首先是请求方法，用 SP（空格）与后面的内容隔开，接
着是请求的统一资源标识符（Request-URI）和协议版本，最后以 CRLF 结束，具体的
格式如下：
请求行 = 方法 SP 请求的 URI HTTP 版本 CRLF
响应报文的第一行是状态行，它的组成是协议版本，然后跟着一个数字状态编码，
最后是与状态相关的文本描述，最后以 CRLF 结束。具体的格式如下：
状态行 = HTTP 版本 SP 状态编码 SP 文本描述 CRLF
下面将对请求报文和响应报文的各个部分进行概述
1.请求方法
请求报文的请求方法表示对由请求的 URI 标识的资源所采取的方法，这个方法是
大小写敏感的。有多种请求方法，比如：GET、POST、HEAD、PUT、DELETE、
TRACE、CONNECT 等，对各个方法进行如下解释：
GET 方法是获得由请求 URI 标识的信息；
HEAD 方法与 GET 相似，但服务器不会返回响应的消息正文；
POST 方法用来要求服务器接收附在请求后面的消息实体，并把它作为请求行里
请求 URI 标识的资源的一个新的附属部分。Post 方法可以起到这样的作用，对现有资
源的注释，向公告板，新闻组，邮件列表等添加消息，以表格的形式向数据处理进程
提交数据，通过添加操作扩展一个数据库。
PUT 方法请求将消息正文储存在请求 URI 所标识的位置
DELETE 方法要求服务器删除请求 URI 标识的资源。
TRACE 用于激发一个远程的，应用层的请求消息的回馈，它不含有消息正文。
CONNECT 方法由协议保留，是为了用于能动态切换到隧道的代理服务器。
2.状态码定义
1xx：指示信息。这类状态码表示一个临时的响应，仅由状态行和可选的头域组
成，由一个空行结束。其中 100 表示客户端继续它的请求。101 表示切换协议。
2xx：成功。这类状态码表示客户端的请求被成功地接收，理解和接受。有多种，
其中 200 OK，表示请求成功。201 Created 表示请求被成功实施，并且一个新的资源
被创造。202 Accepted 表示请求已被接受并正在进行处理，但是处理还没有完成。
3xx 重定向。这类状态码表示为了完成请求，用户代理需要采取进一步的行动。
4xx 客户端错误。这类代码用于客户端似乎有错误的情况。
5xx 服务器错误。这类代码表示服务器意思到发生错误或者不能执行请求。
3.消息头
HTTP 消息头遵循相同的由 RFC 822 规定的通用格式，包括通用报头、请求报头、
响应报头和实体报头。每个头域由一个名称，一个冒号和一个域值组成。
通用报头通用于请求和响应报文，但不应用于传输的实体，只用于传输的消息。
这里以 Cache-Control 通用报头为例来说明：
Cache-Control：这个通用头域常用于指定必须被请求 /响应链中所有缓冲机制必
须遵守的具体指令。
请求报头允许客户端向服务器传送关于请求和客户端自己的附加信息。这里以
Accept 请求报头为例。
Accept 请求报头用来规定响应能够接受的某种媒体类型。各个 Accept 报头用来
表示请求特别限定于一些期望的类型，例如一个内嵌图形的请求。
响应报头应许服务器传递响应的额外信息，而这些信息不能放在状态行。这些报
头给出服务器的信息和对请求 URI 标识的资源进行进一步访问所需要的信息。这里
以 Age 报头为例。
Age 响应报头传输发送者对时间的估计，这个时间是自服务器产生响应开始计算
的。
实体报头规定了实体主体的元信息，如果没有实体主体，就规定了请求标识的资
源的元信息。这里以 Content-Encoding 为例。
Content-Encoding 实体报头用作对媒体类型的修饰。当此头域出现时，它的数值
表明对实体主体采用了什么样的内容编码，以及因而可以使用何种解码机制去获得有
Content-Type 头域指明的媒体类型。
§ 协议分析技术
网络监控系统在获取网络数据后需要立即对网络数据进行协议分析，为实际的应用功能
提供相关的数据。网络监控系统中的协议分析的具体繁简程度由网络监控的应用目的所决定。
但是不管其应用目的是什么，其协议分析的基础都是 TCP/IP 协议。首先面对的就是网络以
太帧，经过处理成为 IP 数据包，而后根据实际的需要进行进一步的分析过滤得到 TCP 或
UDP 的数据包，再根据具体的应用协议对于数据包的内容进行重新的拼接，整合恢复成实
际的数据。以上简单叙述的是基于内容进行监控的实现过程，而对流量进行监控的网络监控
应用而言其实现远没有这么复杂，只需要对于协议进行简单的分析，获取数据包的类型、总
长度，有时候还需要获取通信相关的 IP 地址等信息。
就本文所要论述的 WebMail 内容监控系统而言，webmial 在应用层是基于 HTTP 协议的，
所以，要对于 HTTP 通信进行监控，需要从链路层进行协议分析，解析以太帧、IP 数据包
和 TCP 数据包直到 HTTP 应用协议。在操作系统中网络数据从进入到到达应用程序之前的
内核部分的处理都是在操作系统的协议栈中进行的，网络监控系统完成的功能就是包括了协
议栈和应用程序。
协议分析的大概过程可用下面的伪代码进行具体展示：
get（packet）；//使用包获取函数取得一帧数据，存入 packet
ethhdr = （struct ethhdr*）packet；//获得以太网头部
analyse（ethhdr）； //分析以太头，获取信息如 MAC
iphdr = (struct ip *)(ethhdr+ETH_HLEN);//假设是以太网，可以从帧数据得到 ip 头
analyse(iphdr); //分析 ip 头，获取信息如 ip
tcphdr = （struct tcphdr*）（iphdr+IP_HLEN）;//假设运输层是 tcp，获得 tcp 头，
analyse（tcphdr）； //分析 tcp 头，获取信息如端口号
data = （char*）tcphdr + TCP_HLEN；//获得应用层的数据信息
analyse（data）; //根据具体的应用要求对应用数据尽心分析处理。
总之，网络监控的实现原理就是 TCP/IP 协议，但是和操作系统中的协议栈的实现不同
的是，网络监控主要是单向的数据拆包整合的过程，而且，从应用的实际出发网络监控中的
协议分析过远比实际的操作系统的协议栈简单。
§ 本章小结
本章介绍了 TCP/IP 的基本原理，由于本文所要论述的监控系统主要是对 WebMail
进行监控，而 WebMail 在应用层是基于 HTTP 协议的，故重点介绍了应用层 HTTP 协议。
然后概括性的介绍了基于内容的网络监控中的协议分析技术。
第四章 数据捕获和分析模块的实现
监控系统主要实现的功能是：对利用 HTTP 协议收发的 WebMail 邮件内容的捕获和还
原，并从中提取了收发双方的 IP 地址、邮件主题、邮件内容、收发时间等信息。本系统的
设计是可扩展的，根据需要可以增加对其它应用层协议的数据还原内容。
数据捕获和分析模块在网络监控系统中占有非常重要的地位，该模块从网络中捕获数据
并对应用层数据进行分析，其处理结果存储到数据库供以后的查询。由于监控系统的应用环
境很复杂，常常需要面对高速大流量的网络环境，这就要求数据包的处理必须尽可能的快速
和准确。数据截获和分析模块是在 Linux 环境下实现的。首先利用 PF_RING 的数据包捕获
功能对需要监控对象的网络数据进行捕获，然后按照协议分析技术对数据包进行分析，按照
系统需求还原应用层的数据。
§ 主体程序设计
根据上面的分析，程序的流程如图 所示：
图 数据捕获分析模块程序流程
开始
设置网卡为混杂模式
设置编译器
开始抓包
Type==ETHERTYPE_IP
解析并保存数据包
IP头部信息
Protocol==IPPROTO_TCP
从端口判读应用层类型HTTP
HTTP协议分析
输出敏感信息
PF_RING
回调函数
Packet_handler
否
是
否
是
return
return
return
Ip_Packet_Decode
Tcp_Segment_Decode
return
解析并保存数据包TCP
头部信息
是
否
HTTP_Decode
§ 程序实现中的几个要点
HTTP 报文重组
WebMail 在应用层使用 HTTP 协议,使用 80 端口。对于捕获到的数据包，我们只分析源
端口或目的端口是 80 的数据包。由于一帧数据有限，WebMail 邮件常常需要多个数据包进
行传输，故我们需要对 TCP 会话进行重组。IP 和 TCP 端口可以标识一个会话，当两个 TCP
数据包的源 IP 和目的 IP 相同或相反以及源端口和目的端口相同或相反时，这两个数据包属
于同一个 TCP 会话。
重组 TCP 会话常用的方法是：建立一个 TCP 会话列表来记录 TCP 会话，对于捕获到的
数据包，先通过数据包的某些字段的值（帧数据的 IP 头部部分）其是否为 TCP 协议，如果
是，再通过端口号的值（帧数据的 TCP 头部部分，源端口或目的端口是 80）判断是否为 HTTP
协议，如果是，表明该 TCP 会话需要进行重组，如果需要重组，则首先在会话列表中查找，
如果没有发现此 TCP 包所属的会话，则需在会话列表中添加一条新的会话信息。图 说明
了物理数据包进过重组还原为 HTTP 应用层原始数据的过程。
图 组包原理示意图
使用此方法可以将一个 TCP 会话中的所有 HTTP 请求和响应都还原出来。它不仅需要
处理该会话的所有数据包，还需要分析所有的ＴＣＰ会话。就 WebMail 监控而言，邮件内
容通常是在某个ＴＣＰ会话的某些 HTTP 请求报文中或响应报文中，并不需要分析所有的Ｔ
ＣＰ会话，并将一个ＴＣＰ会话里的所有 HTTP 请求和响应报文数据都还原，故这种方法需
要分析冗余数据。这里我们将根据上面的分析，采用一种新的方法。
通过抓包工具分析某种类型的邮箱的发送或接受报文，我们可以观察到，不管信件内容
如何，它们的请求报文的请求行某部分的内容和响应报文的响应行通常是相同的。当要获得
IP 数据 IP 数据 ………… IP 数据 IP 数据
TCP 数据 TCP 数据 ………… TCP 数据
应用层协议（HTTP）
某个邮箱的邮件内容时，我们可以在具有特定内容的请求行的请求报文的响应报文里找到信
件内容。比如新浪邮箱，当我们通过 web 浏览器点击读取某个信件时，web 浏览器和邮件服
务 器 之 间 会 有 一 系 列 的 HTTP 请 求 报 文 和 响 应 报 文 。 分 析 请 求 行 含 有 ： POST
/classic/ HTTP/ 的 HTTP 请求报文，该请求报文的响应报文的响应正文中有邮
件发信人、收信人、主题、发送日期等内容。另外在同一个 TCP 会话里，分析请求行含有 GET
/classic/ HTTP 请求报文，该请求报文的响应报文的响应正文中有邮件正
文的内容。在这个 TCP 会话里的其它 HTTP 请求和响应报文，我们都无需考虑。
这里我们仅以分析网络抓包中的新浪邮箱中的请求行含有：POST /classic/
HTTP/ 的 HTTP 请求报文和它的响应报文为例，来说明邮件内容信息的获取过程。具体
流程如图 所示：
图 新浪邮件部分内容提取流程图
我们要提取信件的内容，必须要将含有信件的数据包捕获。但在复杂的应用环境中，网
络上可能传输许许多多的数据包，这些数据包只有一部分是邮件数据包，而且这些邮件数据
包可能属于不同的邮件，它们按不同的顺序被我们抓取，这就需要我们判断哪些包是邮件包，
哪些邮件包属于同一个邮件中的数据包。
我们根据前面的知识可知，只要知道一帧数据中的源 IP 和目的 IP 以及源端口和目的端
口，就可知到该数据包是否属于某个 TCP 会话。当我们使用 WebMail 发送或读取邮件时，
同一封邮件的请求报文和响应报文都属于同一个 TCP 会话，不同邮件的请求报文和响应报
HTTP协议数据包
与邮件链表中的每个节点的IP和端口进行比对
找到符合条件节点
POST /classic/
HTTP/
创建该TCP会话节点并插入邮
件链表中
响应报文
第一个响应包
组包
响应包结束
组包结束，提取内容
释放内存
是
否
分配缓存空间
开始组包
丢掉
否
否
是
是
否
是
是
文属于不同的 TCP 会话。故在此我们建立一个邮件链表，用来记录不同邮件的 TCP 会话。
这里以上面列举的例子为例。当我们捕获到的 HTTP 协议数据包的请求报文中的请求行含
有 POST /classic/ HTTP/ 内容时，我们就建立一个邮件节点，记录下这个数据包
的源 IP 和目的 IP，源端口和目的端口，当然这个邮件节点也应有一个字符串指针，用来指
向将来存储内容时分配的内存，并将该邮件节点插入邮件链表中。对于后续抓到的数据包，
通过与邮件节点比对，便可知道这些包是否属于某个邮件的请求报文或响应报文。就此例而
言，邮件的内容在响应报文中，故只需将该邮件的响应报文进行组包。注意，这里的响应包
的结束并不一定是一个 TCP 会话的结束，它只是指要关注的 HTTP 响应报文的结束，而一
个 TCP 会话里可能有多个 HTTP 请求和应答报文。
当然，各种邮箱读取邮件时的报文和发送邮件时的报文都不相同，但处理过程跟上面的
流程相似，没有本质区别。
内存回收
邮件节点中储存数据的内存空间是动态分配的，在正常的提取邮件内容后，分配的内存
在程序中会立即回收。然而也可能存在这样一些情况，由于网络情况比较复杂，可能一条会
话连接不是正常结束，或出现少量丢包现象。这些都会导致在程序中判断这些响应报文未结
束，从而也不能对它们展开分析，而给它们动态分配的内存也不能回收，导致内存泄露。监
控系统通常是长时间运行的，系统需要不断的为每一个新的邮件链表的节点分配内存，如果
这些内存不能回收，随着系统运行时间的增长，这些不能回收的内存也会不断增长，最终会
导致系统内存不足，影响监控系统的正常运行。因此必须制定一个有效的策略，对这些内存
进行处理。
如果可以知道无法正常结束的响应报文所属的邮件链表的节点，就可以直接回收分配给
它们的内存，然而由于网络情况的复杂性，很难达到这一要求。这里我们采取这样一种策略，
在每个邮件节点的数据成员中增加一个计数器。每当正常提取邮件内容，删除邮件节点后，
遍历整个链表，将链表中的每个节点的计数器加一，如果该计数器为某个值（比如 10），就
将该节点从链表中删除。这样就避免了监控系统长期运行时内存泄露问题的影响。而对于不
断有新的数据包到来的节点，每到来一个数据包，就把该节点的计数器的数值设为 0。这样
一来，就能保证正常通讯的邮件节点的计数器的数值不会超过某个限定值，从而删除的也只
是一些通讯不正常的邮件节点。这种方法有效的保证了内存的高效应用，经实际应用，也证
明是切实可行的。上面的内容可以用下面的伪代码进行说明：
当有一个新的数据包到达时，
node = find(packet) //找到数据包所在的邮件链表中的节点
= 0;
当删除一个节点时，
node = head->next //从邮件链表的第一个节点开始遍历
while（node！=NULL）
{
++;
if ( ==NUMBER) //如果 count 为某个限定值就从链表中删除该节点
delete（node）；
node = ; //取链表中的下一个节点
}
HTTP 报文解压缩
对于大流量的 Web 站点来说，需要传输的内容有很多。为了能够进行快速的传输，经
常采用压缩技术，对经常传输的图片、视频、文本等进行压缩，减少文件的传输空间和传输
时间。对文件进行压缩，必须使用压缩算法进行压缩。主要的压缩算法有哈弗曼编码、算术
编码和 LZW 编码等等。文件压缩程序就是使用压缩算法对文件进行压缩的程序，gzip 就是
其中的一种。gzip 是一个 GNU 自由软件压缩程序，也可以表示 gzip 文件格式。DEFLATE
是 gzip 的算法基础。DEFLATE 是一个无损数据压缩算法，它结合了哈弗曼编码和 LZ77[19]
算法。gzip 这种普遍数据压缩格式现今已经在 Internet 上得到广泛应用。在使用 HTTP 协议
的应用程序，Content-Encoding 这个 HTTP 实体报头指明了实体的编码方法。如果一个 HTTP
报文经过 gzip 压缩，在 HTTP 消息报头中就会包含 Content-Encoding：gzip 这段内容。
GZIP 文件[20]格式分为头、可选的扩展头、文件体和尾部三部分。GZIP 文件结构图可以
用下图直观显示。
图 GZIP 文件结构图
GZIP 的头部分主要说明压缩格式，压缩方法，压缩标志，压缩文件的修改时间以及在
何种操作系统上进行压缩。额外头字段的内容与压缩标志的设置有关。文件体是用 DEFLAT
压缩的数据。尾部分包含未压缩的原始数据的 32 位 CRC 校验和未压缩原始数据的长度的
低 32 位。
ID1 ID2 CM FLG MTIME XFL OS
额外的头字段
压缩的数据
CRC32 ISIZE
解压 gzip 文件需要正确找到压缩数据的起始偏移，解析其头部就是为了正确找到压缩
数据的开始位置。压缩数据的起始位置如果有误，其最终的 CRC 校验就会失败，而加压出
来的数据将不起作用。压缩数据的解压可通过调用 zlib 库解压 gzip 压缩的内容。
邮件内容的提取
在上面进行 HTTP 数据还原得到的含有邮件内容的文件，它不仅含有信件内容，还含有
各种说明字符串，比如读取邮件时服务器的 text/html 类型响应正文。提取信息时，常常需要
进行字符串匹配，找到提取内容开始的起始位置和结束位置，然后提取这两个位置之间的内
容。字符串匹配经典算法是 KMP 算法，可以据此写出我们的字符串匹配函数。但 KMP 算
法是在已知模式串的 next 函数值的基础上执行的，必须要求得模式串的 next 函数值[21]。由
于要提取的信息有很多，模式串也有很多，求模式串的 next 函数带来很大的工作量。
而在实际的编程开发中利用正则表达式和支持正则表达式的函数库，可以极大的简化处
理字符串的复杂度。
正则表达式就是用某种模式去匹配一类字符串的一个公式。这里简单介绍常用的正则函
数库。首先程序中应包含下面两个头文件：
#include <sys/>
#include <>
下面介绍如何使用正则表达式进行模式匹配从而提取文本信息。
1）编译正则表达式。
为了提高效率，在将一个字符串与正则表达式进行比较前，要先用 regcomp()函数对其
进行编译，将其转化为 regex_t 结构：
int regcomp(regex_t *preg, const char *regex,int cflags);
参数 regex 指向一个字符串，参数 preg 指向一个声明为 regex_t 的数据结构，用来保存
编译结果，参数 cflags 用来决定编译类型。
如果函数 regcomp()执行成功，并且编译结果被正确填充到 preg 中后，函数将返回 0，
任何其它的返回结果都代表有某种错误产生。
2）匹配正则表达式。
在用 regcomp()成功地编译了正则表达式后，就可以调用 regexec()完成模式匹配:
int regexec(const regex_t *preg, const char *string, size_t nmatch,regmatch_t pmatch[], int
eflags);
typedef struct
{
regoff_t rm_so;
regoff_t rm_eo;
} regmatch_t;
参数 preg 指向编译后的正则表达式，参数 string 是将要进行匹配的字符串，而参数
nmatch 和 pmatch 则用于把匹配结果返回给调用程序，最后一个参数 eflags 决定了匹配的细
节。
在调用 regexec()进行模式匹配的过程中，可能在字符串 string 中会有多处与给定的正则
表达式相匹配，参数 pmatch 就是用来保存这些匹配位置的，而参数 nmatch 则告诉 regexec()
最 多 可 以 把 多 少 个 匹 配 结 果 填 充 到 pmatch 数 组 中 。 当 regexec() 成 功 返 回 时 ， 从
string+pmatch[0].rm_so 到 string+pmatch[0].rm_eo 是 第 一 个 匹 配 的 字 符 串 ， 而 从 string+
pmatch[1].rm_so 到 string+pmatch[1].rm_eo，则是第二个匹配的字符串，依此类推。
3)释放正则表达式
当不再需要已经编译过的正则表达式时，都应该调用 regfree()将其释放，以免产生内存
泄漏。
void regfree(regex_t *preg);
4）报告错误信息
如果调用 regcomp()或 regexec()得到的是一个非 0 的返回值，则表明在对正则表达式的
处理过程中出现了某种错误，此时可以通过调用 regerror()得到详细的错误信息。
size_t regerror(int errcode, const regex_t *preg, char *errbuf,size_t errbuf_size);
参数 errcode 是来自 regcomp()或 regexec()的错误代码，而参数 preg 则是由 regcomp()得
到的编译结果，其目的是把格式化消息所必须的上下文提供给 regerror()。在执行 regerror()
时，将按照参数 errbuf_size 指明的最大字节数，在 errbuf 缓冲区中填入格式化后的错误信息，
同时返回错误信息的长度。
消息体的编码转换
计算机中的信息包括数据信息和控制信息，数据信息又可分为数值和非数值信息。非数
值信息和控制信息包括了字母、各种控制符号、图形符号等，它们都以二进制编码方式存入
计算机并得以处理，这种对字母和符号进行编码的二进制代码称为字符代码（Character
Code）。在互联网中，不同的网站采用的编码方式可能并不相同，主要有 GB2312、UTF-8
等多种编码，大部分的网站都支持 GB2312、UTF-8。进行网络监控时，通常将获取的内容
保存，以供将来查询。但提取的内容的编码方式与保存文件的编码方式可能并不相同，需要
进行转换。下面将介绍常用的编码方式和它们之间的转换方法。
1． ASCII 码
美国标准信息交换代码是由美国国家标准学会(American National Standard Institute ,
ANSI )制定的，标准的单字节字符编码方案，用于基于文本的数据。ASCII 码使用指定的 7
位或 8 位二进制数组合来表示 128 或 256 种可能的字符。标准 ASCII 码也叫基础 ASCII
码，使用 7 位二进制数来表示所有的大写和小写字母，数字 0 到 9、标点符号， 以及在
美式英语中使用的特殊控制字符。
Ascii 只用一个字节中的七位来表示字符，最多只能表示 128 个字符。无法解决汉字、
日文假名、朝鲜语和中国少数民族文字组成的大字符集计算机编码问题 。因此产生了其它
的编码方式，例如 GB2312 编码。
2． GB2312 编码
ASCII 码的提出，有效的解决了西文文字的信息化问题，但对于汉字字符却完全
不适用。为了满足国内在计算机中使用汉字的需要，中国国家标准总局发布了一系列
的汉字字符集国家标准编码，统称为 GB 码，或国标码。GB2312 编码通行于我国内
地；新加坡等地也采用此编码。几乎所有的中文系统和国际化的软件都支持 GB 2312。
GB2312 编 码 用 两 个 字 节 (8 位 2 进 制 ) 表 示 一 个 汉 字 ， 所 以 理 论 上 最 多 可 以 表 示
256×256=65536 个汉字。但这种编码方式也仅仅在中国行得通，如果您的网页使用的
GB2312 编码，那么很多外国人在浏览你的网页时就可能无法正常显示，因为其浏览
器不支持 GB2312 编码。当然，中国人在浏览外国网页(比如日文)时，也会出现乱码
或无法打开的情况，因为我们的浏览器没有安装日文的编码表。
3． Unicode 码
Unicode 是一种在计算机上使用的字符编码。它为每种语言中的每个字符设定了统一并
且唯一的二进制编码，以满足跨语言、跨平台进行文本转换、处理的要求。Unicode 标准有
UCS-2、UCS-4。UCS-2 用两个字节编码，UCS-4 用 4 个字节编码。Unicode 固然统一
了编码方式，但是它的效率不高，比如 UCS-4(Unicode 的标准之一)规定用 4 个字节存
储一个符号，那么每个英文字母前都必然有三个字节是 0，这对存储和传输来说都很
耗资源。
4． UTF-8
为了提高 Unicode 的编码效率，于是就出现了 UTF-8 编码。UTF-8 是 Unicode 的实
现方式之一。UTF-8 可以根据不同的符号自动选择编码的长短。比如英文字母可以只
用 1 个字节就够了。
UTF-8 以字节为单位对 Unicode 进行编码。从 Unicode 到 UTF-8 的编码方式如下
[22]：
UCS-4 编码(十六进制) UTF-8 字节流 (二进制)
0000 0000-0000 007F 0xxxxxxx
0000 0080-0000 07FF 110xxxxx 10xxxxxx
0000 0800-0000 FFFF 1110xxxx 10xxxxxx 10xxxxxx
0001 0000-001F FFFF 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
0020 0000-03FF FFFF 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
0400 0000-7FFF FFFF 1111110x 10xxxxxx ... 10xxxxxx
Unicode 到 UTF-8 的转换需要先根据 Unicode 码值确定 UTF-8 编码所需要的字节
数，然后将 Unicode 码值转到相应的 UTF-8 的字节中。UTF-8 的特点是对不同范围的
字符使用不同长度的编码。对于 0x00-0x7F 之间的字符，UTF-8 编码与 ASCII 编码完
全相同。
5． 不同编码方式之间的转换
在LINUX 上进行编码转换时,可以利用iconv 命令实现,这是针对文件的,即将指定文件从
一种编码转换为另一种编码。如果需要将一种编码的字符串转换为另一种编码的字符串，编
程时还可以利用iconv函数族编程实现。使用iconv函数族需要包含头文件是。
#include <>
使用iconv函数进行编码转换，首先应使用函数iconv_t iconv_open（const char *tocode，
const char *fromcode）申请一个转换描述符，这个描述符适应于从fromcode编码到tocode编码
的转换。这个转换描述符可以被iconv（）函数使用任意多次，只有使用iconv_close（）解除
分配后才失效。然后使用函数size_t iconv(iconv_t cd,char **inbuf,size_t *inbytesleft,char
**outbuf,size_t *outbytesleft)，进行实际转换。转换完毕后使用int iconv_close(iconv_t cd)解除
用iconv（）函数申请的描述符。
监控系统用于保存内容的文件编码方式与提取内容的编码方式不一致时，便可采取上面
的方法先进行编码转换，再保存。
§ 功能扩展
本模块作为监控系统的主体部分，主要针对 WebMail 的一般应用进行解析，功能比较
实用、简单，针对性较强，局限性较大。可以通过以下方案加以完善，使其具有更广泛的用
途和更大的实用价值。
功能延伸
数据截获和分析模块实现了一般信件内容的提取，然而在实际的监控中可能还希望获得
电子信箱的信箱名和密码，然而不少的邮箱登陆时可以选择实用 HTTPS 服务，并不像 HTTP
那样对信息进行明文传输，监控使用 HTTPS 服务的邮箱与 HTTP 有所不同，需要了解
HTTPS 协议机制。
HTTPS[23]，超文本传输协议安全。是 HTTP 协议和 SSL[24]协议的组合，用以提供加密
通讯和对网络服务器的安全鉴定。HTTPS 连接经常用于万维网上的交易支付和企业信息系
统中敏感信息的传输，就邮箱而言，许多 Web 电子邮箱登录时提供 HTTPS 服务，传送
Web 电子邮箱的账号和密码。HTTP 默认使用端口 80，而 HTTPS 默认使用端口 443。
“http：//”是 HTTP 的 URL 起始，而“https：//”是 HTTPS 的 URL 起始。相较于 HTTP 的
明文传输易被监听而言，HTTPS 的安全性高很多。HTTS 是对工作在一个加密连接上的
常规 HTTP 协议的称呼，并不是一个单独的协议。其中 HTTP 在应用层工作，而 SSL 则
工作在一个较低的子层，处于传输层和应用层之间。SSL 在 HTTP 报文传输之前，对其
加密，对到来的 HTTP 报文，又进行解密。
针对 HTTPS 安全通信协议建立连接的网络，可以采用中间人攻击的方式进行主
动监听。主动监听是主动地控制通信数据的特点，制造数据包注入到网络，并将通信
数据重定向到攻击者的机器。中间人攻击（Man-in-the-MiddleAttack，简称“MITM 攻
击”）是一种“间接”的入侵攻击，这种攻击模式是通过各种技术手段将受入侵者控制的
一台计算机虚拟放置在网络连接中的两台通信计算机之间，这台计算机就称为“中间
人”。然后入侵者把这台计算机模拟一台或两台原始计算机，使“中间人”能够与原始计
算机建立活动连接并允许其读取或修改传递的信息，然而两个原始计算机用户却认为
他们是在互相通信。通常，这种“拦截数据——修改数据——发送数据”的过程就被称
为“会话劫持”（SessionHijack）。
协议扩展
目前数据截获和分析模块实现了 WebMail 信件内容的提取功能，更进一步，该模
块可以添加更多的协议分析功能，对网络其它的即时信息进行截取和分析，如常用的
FTP，POP3，SMTP 等。
§ 本章小结
本章首先介绍了监控系统的主体程序设计流程，然后重点介绍了程序实现中的几个关键
点：HTTP 数据还原，内存回收，HTTP 报文解压缩，邮件内容的获取和消息体的解码。
第五章 总结与展望
§ 总结
随着互联网的不断发展，网络信息内容监控也不断发展和不断完善。网络与人们的生活
也日益紧密，信息安全也越来越引起人们的重视，越来越多的部门，企业和单位使用网络信
息内容监控。
本文围绕 WebMail 监控系统的设计和实现，主要完成了下面几个方面的研究：
1、本文探讨了网络监听的原理，以及在不同的网络物理拓扑结构下的监听方式，还讨
论了数据包的 BPF 捕获机制，常用的数据包捕获函数库 Libpcap 和使用 PF_RING 套接字对
抓包性能的改进。
2、本文对 TCP/IP 协议进行了分析，并着重分析了 WebMail 的应用层协议 HTTP 协议。
3、本文对监控系统的整体框架进行了描述，并详细讨论了主体程序中关于应用层的几
个要点：HTTP 数据还原、内存回收、HTTP 报文解压缩、邮件内容获取和消息体解码。
本文的研究成果已在某重要的网络信息内容监控中得到应用，能够获取已监控的各种
WebMail 邮箱的详细信息。
§ 展望
由于网络技术的不断发展，网络速度也在不断提升，对数据包捕获机制和数据包处理工
具也应进行更加深入的探讨和研究，提升系统的性能。
本文论述的网络内容监控系统是基于 IPV4（互联网协议第四版）。IPV4 在当今互联网
上被广泛应用，也有不少缺陷，有限 IP 地址就是其一，IP 地址的匮乏使得人们面临着将来
无 IP 地址可用的情况。为了解决 IPV4 应用上的一些问题，人们正在研究 IPV6（互联网协
议第六版），可以预计在不久的将来，IPV6 将取代 IPV4 的统治地位。因此，网络内容监控
系统也应在今后探讨对于应用 IPV6 的网络监控问题。
致 谢
本文的研究工作是在罗忠文老师的精心指导下完成的。研究生三年来，罗老师始终关心
着每一个学生的成长，他定期抽出大量的时间与我们进行交流，及时了解我们的动态和存在
的问题，并及时的给予解决和指导。这使得我的三年的研究生生活无论是知识还是学习能力
上，都获得了很大的提升。罗老师在学位论文选题之初，就对我进行了精心的指导，提出了
不少的宝贵意见，使得我对论文应该探讨的方向有了明确的认识。学问论文的撰写和最后的
定稿，罗老师也始终关注。罗老师知识渊博，积极进取，对工作一丝不苟，对治学务实严谨，
精益求精。在与罗老师三年的交流中，切实感受到老师这种默默的感染力量，使我获益匪浅。
无论是生活还是学习和工作上，罗老师都是我的榜样。
感谢白虹公司提供的实习机会，本文的研究内容部分源于白虹公司的实习项目。这段实
习经历不仅对本文有了很大的帮助，有了切实的实践平台，还为今后的工作提供了宝贵的经
验。同样也要感谢公司的各位同事在实习期间对我的热心帮助。这里也要特别谢谢我的学长，
邬剑飞同学，正是由于他的引荐，才有这次实习，还有同学何伟，我们常常在一起探讨学习
和工作中的问题，互相促进，受益匪浅。
衷心感谢实验室的姚志刚，朱勇，许寅，马奔宇同学对我平时学习的热心帮助。
感谢父母，他们是我学习和生活的坚强后盾。
本论文的不少知识都是通过网络查询和阅读博客得到的，感谢那些对各种技术问题撰写
博客的人，正是你们的热情奉献，使得各种知识更加快速的传播。
参考文献
[1] 第二十七次中国互联网络发展状况报告[R]. 中国互联网络信息中心（CNNIC），
[2] 谭思亮. 监听与隐藏——网络侦听揭密与数据保护技术[M]. 北京: 人民邮电出版,2002
[3] 邓友良. HTTP 报文监测和过滤技术研究: [学位论文]. 四川省成都市: 西南交通大学,
.
[4] STEVENS BILL FENNER 等著，杨继张译. UNIX 网络编程 第一卷：套接
口 API（第四版）[M]. 清华大学出版社，
[5] 王磊. 基于 Linux 的千兆网络数据包捕捉技术的研究与实现: [学位论文]. 山东: 山东大学，
.
[6] 平震宇. Libpcap 数据包捕获机制剖析与研究[J], 信息网络安全，
[7]
[8]
[9] Luis MartinGarcia. Programming with Libpcap - Sniffing the network from our own
application. Hakin9 Magazine. Issue 2/2008
[10] J. Mogul and K. Ramakrisnan, Eliminating Receive Livelock in an Interrupt-Driven Kernel,
Proceedings of 1996 Usenix Technical Conference, 1996.
[11] L. Rizzo, Device Polling Support for FreeBSD,
BSDConEurope Conference, 2001
[12]
[13]
[14] Luca Deri. “Improving Passive Packet Capture: Beyond Device Polling” [J]. [2005-10-03].
[15] Stevens. 范建华，胥光辉，张涛等译. TCP/IP详解卷1：协议[M]. 北京：机械
工业出版社. 2000-7.
[16] 宋敬彬，沈海滨等. Linux 网络编程[M]，北京：清华大学出版社. 2010-1.
[17] RFC 2616 - Hypertext Transfer Protocol -- HTTP/[S]. Network Working Group
1999.
[18] 协议中文版-RFC2616[S].
[19] 马巧梅 朱林泉 基于LZ77算法的文本压缩软件的实现[J], 电脑开发与应用，
[20] GZIP file format specification version [S]. L. Peter Deutsch 1996
[21] 严蔚敏，吴伟民 数据结构[M], 北京：清华大学出版社. 2003-3.
[22] Marius Bancila. The Basics of UTF-8[N]. misc /misc/multi-li
ngualsupport/ September 2005
[23]
[24] 令晓静，田红心 SSL协议的分析及实现[J]. 计算机与信息技术，
