Monthly Archives: September 2009

Linux 系统其协议栈对于工作在数据链路层的 SOCK_PACKET 机制提供了很好的支持，同时它也完全支持 BPF机制，下面将基于 Linux 操作系统基础上，分析 libpcap 函数库对于上述两种机制的实现。 1. libpcap 函数库如利用工作在数据链路层的套接字 sock_packet 来完成网络数据报文的读取，具体实现流程大概是： （1）当网络数据报文到达以后，网卡通过 DMA 方式将数据报文传输到网卡驱动程序接收缓冲环（rx_ring）中接收描述符所指示的位置上，并且在数据传输结束时触发硬件接收中断。系统根据寄存器中的中断类型号调用相应的中断处理程序，最后执行流会间接调用到网卡中断处理程序中的报文接收处理子程序。 （2）在报文接收处理例程中，内核处理数据报文并通过函数 netif_rx() 将驱动程序接收缓冲环（rx_ring）中的数据添加到系统接收队列 backlog 中。操作系统在空闲时调用中断处理程序下半部分即软中断处理函数 net_rx_action()。此函数的主要功能是，检查系统中已经注册的数据包类型并调用相应的处理函数来处理数据报文。libpcap 函数库注册的报文接收类型为 ETH_P_ALL，即接收所有的网络数据帧，其处理函数为 packet_rcv()。该函数工作在数据链路层。 （3）packet_rcv() 函数将直接调用 skb_queue_tail() 将数据报文存放在代表相应网络连接控制结构（struct sock）的接收队列 receive_queue 中。这样数据报文在接收过程中就绕过了 TCP 层和 IP 层繁琐的协议处理过程。 （4）最后，睡眠在 sk 等待队列上的函数 … Continue reading →

2.1.2 传统的报文捕获机制分析 以太网采用了CSMA/CD 技术，通过广播机制实现数据传输。在系统正常工作时，应用程序只能接收到以本机为目标逐句的数据报文，以及广播报文和组播报文。因此要捕获不属于自己的报文，必须直接访问网络底层，首先将网卡置于混杂模式，使之可以接收其它类型的数据，然后系统直接访问数据链路层，捕获数据，最后提交给应用，这样就实现了捕获流经网卡的所有报文。 通过设置网卡工作模式，报文捕获系统便可以在网络上截获位于 OSI 协议模型中数据链路层上的报文。目前大多数操作系统都为应用提供了直接访问数据链路层的手段，它使应用可以监视数据链路层上的报文而不需使用特殊硬件设备。 目前 UNIX 操作系统中有 3 种常用的数据链路层访问机制，它们分别是：BSD 系统中采用的 BPF，SVR4 的数据链路提供者接口（DLPI）和 Linux 的 SOCKET_PACKET 接口，还有其它类似的链路层访问机制。 a. BSD 分组过滤器 BPF BSD 系统及许多源于 Berkeley 的实现均使用 BPF 机制作为数据链路层访问手段。在支持 BPF 机制的系统上，每个数据链路层核心程序都在收到一个保温后直接调用 BPF 接口，并将该报文的拷贝传递给该接口。 BPF 接口不仅可以对数据链路层进行直接监听，而且还可以实现信息过滤。任何一个打开 BPF 接口的应用程序都可以安装自己的过滤器，然后由 BPF 接口对捕获到的每个报文分别进行处理。BPF 的过滤机制基于寄存器级别，并且可以对每个报文应用进程专有的过滤机制，这样，进程就可以实现只捕获自己感兴趣的报文，甚至还可以选择只捕获报文的特定部分。为了减小系统开销，BPF … Continue reading →

http://www.linuxjournal.com/article/6345 http://www.ibm.com/developerworks/cn/java/j-zerocopy/index.html http://blog.chinaunix.net/u/5251/showart_411109.html 2.1 传统的报文捕获实现过程 2.1.1 协议栈运行机制分析 当操作系统协议栈正常工作时，应用程序只能接收到发往本机的数据包，其它地址的数据包将被丢弃。数据包通路分为数据链路层、网络层、传输层、套接字层和应用层几个层次。 数据链路层通过网卡驱动程序判断报文的目的物理地址是否为广播地址或者组播地址，若不是则再判断是否为本机 MAC 地址，若不是将直接丢弃该报文，不向上层提交，不然上交报文；报文被提交到网络 IP 层以后，IP 网络层判断报文（struct sk_buff） IP 头部所含目标 IP 地址是否为本机 IP 地址，如果不是，则不向上层提交，若是则将其提交到 TCP 或者 UDP 层；传输层获取传输层头部目标端口，判断该端口是否已被打开，如果没有打开，则不作处理，不向上层提交，若该端口已经被打开，则将该报文送到该连接（struct sock 和 struct socket 对应一个网络连接）的报文接收队列中，同时唤醒该连接上休眠的等待进程，进程从报文接收队列中取得报文然后返回。下面的例子是 Linux 下： a. TCP/IP 协议栈框架结构 操作系统的内核协议栈基本可以分为数据链路层、IP 层、TCP/UDP 层、INET Socket 层、BSD … Continue reading →

3.3 基于 DAG 的流量采集方案 通过使用网络监控卡DAG代替普通网卡实现数据包捕获，DAG 自动实现将接收的数据包通过主机 PCI-X 总线写入主存，避免 CPU 频繁响应网卡硬件中断所造成的干扰。DAG 能够为主机 CPU 分担大量负载，因此系统的数据包捕获能力和深度分析能力都有极大的提高。 3.3.1 DAG功能特点 DAG 有如下六个功能特点： （1）工作在物理层，在数据包捕获、过滤和传输环节能够为主机 CPU 减轻计算负担，在数据包捕获应用中，DAG 卡能够以极少的中断次数（数量级为102）自动实现数据包捕获，而普通千兆网卡将产生大量的中断调用，在数据包过滤环节中 DAG 卡使用板载硬件实现过滤器功能，不占用 PCI 总线以及主机 CPU 资源，普通千兆网卡则必须将数据包通过 PCI 总线送入主机内存，在系统内核中实现数据包过滤功能。 （2）为每个数据包提供高精度的时间戳，通过硬件实现的时间戳引擎能够达到很高的解析精度。数据包记录时间戳随后存储到外部 FIFO(First In First Out) 缓存，等待 PCI 总线资源写入到主存。单张 DAG 卡的时钟精度可达到 7.5 … Continue reading →

3.1 基于 Libpcap 的流量采集方案 自1994年6月 Libpcap 正式发布0.0.1版以来，已经诞生了多个不同的版本，包括由官方网站 www.tcpdump.org 正式发布的版本，以及由美国洛斯阿拉莫斯国家实验室(Los Alamos National Laboratory)开发的支持 mmap 系统调用的 Libpcap 版本。 Libpcap 的工作流程可简要概括如下：首先，接收网卡驱动缓存的数据包，对接收到的所有数据包进行过滤规则匹配，如果匹配成功就将数据包拷贝到系统内核空间缓存，否则直接丢弃数据包；其次，将数据包从系统内核空间拷贝到用户空间；最后由运行在用户空间的流量监测分析程序调用 Libpcap 提供的 API 接口读取数据包信息。 Libpcap 几乎支持所有的类 Unix 操作系统，包括主流的 Linux、FreeBSD、Solaris 等等。使用 Libpcap 可以带来很多优点： 第一、众多基于 Libpcap 开发的网络工具在各种版本的 Unix 平台上很容易移植； 第二、Libpcap 有良好的兼容性，能够屏蔽底层网络的不同，方便用户使用； 第三、Libpcap 拥有高效的包过滤器 BPF。 … Continue reading →

2.3.2 存在的性能提升空间 一方面，通过对软件结构优化提升性能，有如下三种方式的改进： （1）优化过滤器，例如采用 BPF(Berkeley Packet Filter)。 （2）在数据包捕获驱动和上层应用程序之间共享缓存。 （3）使用中断融合和 NAPI 技术降低网络设备所产生的中断频率。 另一方面，利用硬件加速实现性能提升，有如下两种方式的改进： （1）通过安装多个 CPU，提高工作站的数据处理能力。 为了使工作站拥有更强大的数据包处理能力，目前在计算机工业界普遍采用并行处理方法，将整个数据包处理流程从逻辑上划分为多个互不干扰的子流程， 分配给工作站的不同处理单元以提高数据包并行处理能力。 （2）利用辅助硬件设备加速，如 DAG 卡、智能网卡。比较分析可知，软件和硬件的性能提升方式是可以相辅相成的，硬件加速方式通过增加 CPU 个数来提高并行处理能力，而软件结构优化方式着重提高数据包串行处理能力。通过软硬件相结合的方式实现的流量监测分析系统可以达到更高的数据包分析处理能力。 从硬件角度需要着重考察如下几个要素：CPU 处理能力、PCI 总线传输能力、内存读写周期以及存储设备容量等；从软件角度需要着重考察的要素包括：网卡中断处理例程调用频率、操作系统对外围高速设备的轮询支持、内存拷贝开销、系统调用开销、内核中的套接字缓存数量。随着工作站硬件性能的不断提高，目前通用CPU的处理能力最高达到 3.2GHz、从 Linux 2.4.17 之后的版本增加了对 SMP 的支持、DDR 内存的访问频率也大幅度的提高到 333MHz、PCI-X 总线频率达到 64 位 133MHz，PCI 总线带宽可达 133MHz*64bit=8512Mb/s。由此可知，基于通用硬件平台开发高速链路流量监测分析系统的硬件瓶颈已经消除，那么如何消除软件造成的性能瓶颈就成为问题的关键所在。 网卡驱动程序与操作系统内核占用将近一半（1551 Cycle）的 … Continue reading →

2.1 网络流量采集技术 2.1.1 网络流量定义 网络流量指单位时间内网络中的通信量，是衡量网络运行负荷和状态的重要参数。进行网络流量管理和控制是保证网络高效运行、合理地分配网络资源、避免拥塞和拥塞恢复的有效方法。分组交换网络中的流量管理功能分别位于 OSI 模型的几个相关层次中，目的各不相同。数据链路层中的流量管理表现为“流量控制”功能；网络层的流量管理表现为“拥塞控制”的功能；传输层流量管理采用“窗口控制”的方法，不同之处在于控制的是联网主机之间的传输流量，避免网络拥塞也是其目的之一。 2.1.2 网络与业务流 流量管理的理论基础是网络流理论。在广义网络中传送的信息、物质或者能量，都可以统一视为某种“流”的形式，即网络流。具体到通信网络，网络流指 的是信息流。即时流量反映了该时刻网络中的通信率和网络负荷情况，链路容量表示最大可以通行的网络流大小。通信网络的流量情况是实时变化的，不仅与某时间段内的用户请求量有关，而且与路由选择关系非常密切，有时还会受到一些异常情况例如地震、故障等的影响而产生波动或剧变。 需要注意的是，实际应用中存在双向链路的情形。双向链路在拓扑上可以用两条方向相反的单向链路来表示，双向链路中的流量是相关的，流量和应不大于 原双向链路容量。 2.1.3 流(Flow)的基本概念 在网络技术上，至少在三个领域用到了“流”（flow）的概念：首先，在资源预约类协议 RSVP 中，“流”用来描述网络流量；其次，在交换技术中，“流”被看作交换的一个单元；最后，“流”是网络测量中的一个重要概念。作为网络测量中的“流”概念包含以下三个要素： （1）方向性。首先，可以把“流”定义为单向或双向，面向连接的 TCP 流一般是双向的，从 A 到 B 的流量必然会引起从 B 到 A 的流量。不过目前网络上流行的多媒体业务流一般都是单向的，实时音频流或视频流通常基于 UDP 协议实现，无需对端进行确认。网络中单向“流”和双向“流”的应用领域都很广泛，从网络测量角度而言，单向“流”的路由问题十分重要，可能对网络流量特征造成巨大影响；双向“流”在协议分析、业务流定位中不可或缺。从单向数据到双向数据总是可能，所以在网络测量中，一般把“流”定义为单向的，也就是说从 A 到 B 的流和从 B 到 A 的流视为两个互不相干的独立流。 （2）端点特性。定义一个“流”最重要的是要说明流对应的端点（流的起点和终点）和协议使用情况，通常来说定义一个“流”需要以下五个元素： … Continue reading →

1.1网络流量监测的意义 随着网络应用的不断发展，以 IP 数据包交换为特征的计算机网络已经逐渐替代以电路交换为特征的传统网络。以 Internet 为代表的 IP 网络规模不断扩大，各种新的网络设备、基于不同流量模型的业务应用的不断出现使得网络拓扑结构、网络应用及网络管理日益缤纷复杂。人们也逐渐认识到对网络行为的深入理解是保障网络健康运行的决定性因素之一，是网络容量规划、流量工程、故障诊断、性能提升的科学决策依据，是保障网络高可靠、低延迟/丢包、降低操作复杂性的基础。网络监测作为时下流行的一种方法和手段是获得网络行为特征的重要手段之一。

We’ve just introduced a feature that allows you to resize your Linode from one plan to another with the press of a button. Now you can upgrade or downgrade a Linode without requiring a support ticket or waiting on us. … Continue reading →