kaiyun官方注册
您所在的位置: 首页> 通信与网络> 业界动态> 10Gb/s线速可扩展P2P流量识别引擎

10Gb/s线速可扩展P2P流量识别引擎

2008-07-30
作者:范红永, 张 进, 刘勤让, 汪

摘 要:通过引入流特征统计和深度数据包检测相结合的思想,设计了一种可扩展的10Gb/s线速P2P流量识别引擎" title="识别引擎">识别引擎,给出了该引擎的硬件实现方案,详细介绍了方案中已知流过滤、传输层特征统计、净荷关键词匹配等核心部分的实现。测试表明,该引擎可完全实现10Gb/s速率下的P2P流量线速识别,识别准确率大于95%。
关键词:识别引擎; P2P流量; 流特征识别;深度数据包检测

近来,P2P流量成为一个流行的问题,这种无序的流量占用网络中50%~90%的带宽[1],造成网络拥塞,致使服务质量下降。通过在网络中主动识别标识P2P流量,并在此基础上实现对P2P流量的管理与控制,是目前被业内认可的一种解决方案。
  有一些工具使用深层数据包检测技术" title="检测技术">检测技术[2]DPI(Deep Packet Inspection)通过软件(如P2P终结者)的方式在小型局域网中识别处理P2P流量,其能力有限; 华为、Cisco等公司也推出了相关产品,基于DPI技术对流量的应用层协议分类,标识出P2P流量,其最大吞吐率" title="吞吐率">吞吐率为4Gb/s。韩国的JamesWon-KiHong等人研发的流量监控系统NG-MON是基于流量特征的检测技术[3](Transport Layer Identification),但其性能参数未知。DPI技术的缺点是对新P2P应用检测具有滞后性,难以检测加密P2P应用,性能与载荷检测的复杂度相关。基于流量特征的检测技术[4]能够克服这些缺点,但它不能指示P2P应用协议具体类型,当其他应用的流量与P2P流量特征类似时容易误判。
  针对目前已经成为主流链路" title="链路">链路传输速率的10Gb/s速率,笔者设计了一种高效的P2P流量识别引擎,把深层数据包检测技术和基于流量特征的检测技术结合,兼顾效率和精度。该引擎能够对10Gb/s链路的P2P流量线速识别。
1 P2P识别引擎设计
  本设计的P2P识别引擎采用流水作业方式,如图1所示。


  当一个IP数据包(设为flow:由源IP地址SrcIP、目的IP地址DstIP、源端口SrcPort、目的端口DstPort和协议域Protocol组成)进入该引擎时,它首先通过已知流比较,未知的流量数据包送到端口匹配识别引擎进行端口匹配,接着不匹配的数据包由传输层特征识别引擎处理,将未知类型P2P数据包送至净荷检测识别引擎,做具体类型判断。对于每个模块识别出的非P2P流量直接输出到引擎对外接口;对于识别出的P2P数据包,则添加类型指示并送到输出FIFO,类型指示包括P2P具体类型和P2P未知类型。最后,数据包由FIFO输出。
1.1 已知流过滤
  对于P2P流量而言,具有数据量大,在线时间长的特点。数据包(flow)和储存在TCAM中的已知P2P流直接比较,快速区分出是否为已知P2P流;同时有很多知名Web等服务器的IP地址固定,通过IP地址判断不是P2P流量。
1.2 端口匹配识别引擎
  许多P2P应用软件有默认的使用端口,一些用户没有修改软件默认端口的习惯,通过端口可以识别一部分P2P流量。
1.3 传输层特征识别引擎
  传输层识别引擎通过对主机传输层特征的统计识别P2P流量。根据已有研究成果[4],目前P2P流量在传输层特征上存在以下两个特征:
  (1)许多P2P应用在一对主机之间同时采用TCP 和UDP连接;
  (2)某一主机与多个目的主机通信,并且对于不同目的主机通常采用不同的目的端口。
  上述特征也存在一些例外情况,如DNS、NETBIOS、IRC、游戏和多媒体业务流量有(1)的特征, 有时Mail、DNS、Game也具备上述(2)的特征。本设计采用参考文献[4]的方法可以区分这些应用。考虑到骨干网链路上主机数目众多,无法测量所有主机的传输层特征;但是由于网络流量大小服从Zipf分布的特性,10%的主机的流量占据了链路总流量的90%[5],因此,采用抽样的方式,仅仅测量流量大的主机的传输层特征。抽样算法采用参考文献[6]中提出的sample-and-hold算法。
1.4 净荷检测识别引擎
  不同的P2P协议净荷具有不同的特征,采用特征字符串来匹配净荷的方式可以精确识别P2P具体应用的具体类型。
2 P2P识别引擎的实现
  P2P识别引擎可以识别10Gb/s网络中P2P流量。它包括已知流过滤、端口匹配识别、传输层特征识别、净荷检测识别四个部分,并随着发展可以扩展新的功能模块。这在Xilinx Virtex-4 LX160 FPGA上得到了实现。
2.1 已知流过滤的实现
  要线速地对10Gb/s数据流进行处理,需兼顾处理速度和存储容量要求,所以笔者使用TCAM1实现对数据包的过滤。在一条链路中,识别引擎的工作时间越长, 识别出来的P2P流量越多,把识别出来的P2P流量用流标识符(SrcIP、DstIP、SrcPort、DstPort和Protocol经过Bloom filter运算压缩[7]成20bit流标识符)存储在FPGA片外的TCAM1中。许多知名网站服务器(如sina、 hotmail等)的访问量很大,其IP地址固定,把这些IP地址也储存在TCAM1中。如果SrcIP或者DstIP在表中,则可以直接判为非P2P流量。在TCAM1中,如图2所示,划分出多块空间,分别对应存储已知具体类型和未知类型的P2P流量标识符、知名网站服务器IP地址。通过TCAM掩码可以选择每一行中的比特哪些必须匹配,哪些可以忽略。如果所有的值在没有掩码的比特位置都匹配了,根据返回的空间地址可以知道数据包的类型。通过发送控制包到 P2P识别引擎可以改变TCAM掩码、TCAM值和TCAM空间分配。对于识别出具体类型的P2P流量,把数据包添加类型指示直接送到输出FIFO中,对未知类型的P2P流量数据包添加类型指示送到净荷检测模块处理,对知名网站服务器的数据包直接送到引擎对外接口;如果没有匹配,则认为是未知流量,对其添加未知类型指示送到端口匹配识别模块作处理。对已知流的快速标识,可以提高判别效率,节省FPGA资源。


2.2 端口匹配的实现
  目前很多的P2P应用软件中都有默认的使用端口,例如eMule使用端口4662/4672/4673等。据统计,目前P2P默认端口数量在100以下,使用FPGA的BLOCK RAM实现的CAM可以高效地完成端口匹配工作。在这个CAM中,对不同类型端口同样分配不同空间位置,由返回地址获得P2P类型。对于端口匹配识别出的具体类型P2P流量,把流标识符写入TCAM1相应的位置,同时把数据包添加类型指示直接送到输出FIFO中;对没有识别出流量类型的数据包,送到传输层特征识别引擎处理。
2.3 传输层特征识别引擎的实现
  传输层特征识别引擎的实现框图如图3所示。


  首先,对于到达的每个数据包,按照概率p对其进行抽样。如果数据包被抽样到,则以“SrcIP +DstIP”作为流标志,将该数据包所属的流(设为F)送往TCP/UDP对判别模块。如果检测到F中同时存在活动的TCP和UDP连接(活动时间取64s[7]),并且端口不是表1中列出的端口,则判定F为P2P流量,并输出到净荷检测识别模块;如果是表1中端口,则根据参考文献[4]中方法进一步处理;否则,将F送入(IP,PORT)检测模块。(IP,PORT)检测模块分别统计与各个SrcIP通信的DstIP和DstPort的数量,如果两者数量接近,且均远大于1,则认为该源IP地址所对应的流量为P2P流量。


  笔者参考了文献[7]的算法思想,基于d-left Hash函数实现了TCP/UDP连接对检测模块。采用4个独立的Hash函数,Hash结果空间大小为210,每个Hash单元存放8个(源)IP地址及2bit的状态标志。IP地址并不直接存放,而是首先对其进行压缩运算,得到一个长14bit" title="14bit">14bit的地址标号,再将地址标号存放在Hash单元中。这样,实现TCP/UDP连接对检测模块共需要的存储容量为:
  4×8×210×(14+2)=524 288bit
  对于所选用的FPGA而言,采用片内SRAM即可满足这一需求。
  (IP,PORT)检测模块基于Bloom Filter的思想实现。如图4所示,(IP,PORT)检测模块共维护10K条统计表项,每条表项在FPGA片外SRAM中对应一个96bit的存储区域。其中有92bit用于Bloom Filter的Hash向量,4bit作为统计计数器。每到达一个数据包,通过查找其源IP地址统计项的Hash向量,判断目的IP地址是否是一个新地址,如果是则将对应的计数器加1。否则更新Bloom Filter的Hash向量。与实现TCP/UDP连接对检测模块类似,不直接存储源IP地址,而是存储其14bit的压缩标号。这样,实现(IP,PORT)检测模块共需要140KB的FPGA片内存储空间以及(960×2)=1 920KB的片外SRAM存储空间。比较容易就可以实现。


2.4 净荷检测识别的实现
  净荷复杂就会造成检测性能下降,10Gb/s的数据难以完全实现线速检测。但是通过上述三个模块的处理,送到净荷检测的数据包速率大大降低(10%),就可以实现线速检测。
  不同的P2P协议具有不同的特征[8],表2给出了几种典型应用协议数据区的判别特征。从不同应用协议的净荷特征可以看出,绝大部分协议的报文特征体现在净荷开头的前20字节,少数协议的报文特征还会体现在净荷结尾处的某些字段。用上述固定位置字段的特征信息可以进行数据包的识别。


  净荷检测识别引擎如图5所示,使用FPGA外的TCAM2可以高效地实现净荷关键词的匹配。对不同净荷特征分配不同空间,当一个IP包到达,净荷的匹配比特与TCAM中的表项值比较,如果没有掩码的值都匹配了,根据返回的空间地址可以确定P2P的类型,把未知类型更改为具体类型指示并送到输出FIFO中,同时把流标识符写入TCAM1相应的位置;如果没有匹配成功,则认为是未知类型的P2P数据包送到输出FIFO中。


  采用多个净荷检测识别引擎并行工作的方式,可以提高处理能力。
3 性能分析与测试
  在Xilinx Virtex-4 LX160 FPGA上综合P2P识别引擎在布局布线后的结果列在表3中。核心逻辑占用了69%的逻辑资源和88%的block RAM。
3.1 吞吐率
  本文设计的P2P识别引擎器件采用Xilinx Virtex-4 LX160 FPGA、IDT 71T75602 SRAM、IDT 75K72100 TCAM。
  对于实现在FPGA内部的模块,FPGA的工作时钟在125MHz,同时处理128bit的数据,这样可以得出P2P识别引擎的吞吐率:128bit×125MHz=16Gb/s。完全能够实现10Gb/s的线速处理。
  对于查表匹配模块,TCAM工作时钟在100MHz,按照每个最短数据包64字节计算,查表速率:64×8×100=51.2Gb/s;更新一个TCAM表项的内容需要4个时钟周期,更新速率:51.2/4=12.8Gb/s。可以实现对10Gb/s数据的线速处理。
  对于SRAM模块,设链路数据率为10Gb/s,最小包长为64字节,则每个数据包的传输时间为51.2ns。SRAM的读写周期为4ns,接口位宽32bit。每收到一个数据包,需要读写SRAM各三次,共需24ns。那么,还剩余27.2ns用于判断Bloom Filter的Hash向量的四个对应位是否为1,并更新计数器。满足本设计所选用的FPGA要求,同样能够实现10Gb/s的线速处理。
  按照流水处理的方式,本文设计的引擎可以实现对P2P数据的线速识别。
3.2 测试
  如图6所示,在测试时使用Spirent AX4000测试仪发送链路速率为10Gb/s包含各种类型流量的数据包,识别引擎对其中的P2P流量识别,把识别的结果用FPGA中实现的统计模块记录下来,通过PC观察结果。


  测试结果表明,该引擎可以在10Gb/s速率下完成对P2P数据包的识别,且准确率大于95%。但该引擎还有待实际网络流量的测试。
  本文设计的 P2P识别引擎实现在高性能路由器中(国家863计划信息技术领域重大专项,大规模接入汇聚路由器系统性能及关键技术研究),满足对10Gb/s链路数据中的P2P流量线速识别。FPGA所具有的大规模并行处理能力和可编程的灵活性使得该引擎能获得极高的处理性能,并且通过重新下载配置信息来改变功能,能够适应P2P应用的日益变化和性能需求,具有良好的可扩展性。


参考文献
[1] 邬贺铨. 2007年宽带世界论坛亚洲会议.演讲稿.
[2] SEN S, SPATSCHECK O, WANG D. Accurate, scalable in-network identification of P2P traffic using application signatures. In www, 2004.
[3] HAN S H, JAMES W K H. The architecture of NGMON: A passive network monitoring system for high-speed IP networks. Lecture Notes In Computer Science;Vol. 2506,2002.
[4] KARARGIANNIS T, BROIDO A, FALOUTSOS M, et al. Transport layer identification of P2P traffic. In Proceedings of ACM SIGCOMM, 2004.
[5] ESTAN C, VARGHESE G. New directions in traffic measurement and accounting. SIGCOMM '02, August 19-23,2002, Pittsburgh, Pennsylvania, USA.
[6] CLAFFY K, BRAUN H W, POLYZOS G. A parametrizable methodology for internet traffic flow profiling. In IEEE JSAC, 1995.
[7] BONOMI F, MITZENMACHER M, PANIGRAHY R. Beyond bloom filters: from approximate membership checks to approximate state machines. SIGCOMM’06, September 11–15, 2006, Pisa, Italy.
[8] White paper-netflow services and applicationshttp://www.cisco.com/warp/public/cc/pd/iosw/ioft/neflct/tech/napps_wp.%htm.

本站内容除特别声明的原创文章之外,转载内容只为传递更多信息,并不代表本网站赞同其观点。转载的所有的文章、图片、音/视频文件等资料的版权归版权所有权人所有。本站采用的非本站原创文章及图片等内容无法一一联系确认版权者。如涉及作品内容、版权和其它问题,请及时通过电子邮件或电话通知我们,以便迅速采取适当措施,避免给双方造成不必要的经济损失。联系电话:010-82306118;邮箱:aet@chinaaet.com。
Baidu
map