2010年08期《计算机工程与科学》准确高效的应用层协议分析识别方法

准确高效的应用层协议分析识别方法,该文刊登于2010 年08期《计算机工程与科学》

准确高效的应用层协议分析识别方法

牟 乔

北京德星电子科技公司BSP Dept.，北京市海淀区理想国际大厦9层，100080

摘 要: 对现行应用层协议分析方法进行总结概述，并介绍一套全新的、模块化的、分为低、中、高、补等四个级别十二大类的协议分析识别方法，可准确高效地将网络上的各种通讯数据分门别类，以便于随后进行网络流量监控与管理。尤其针对加密或伪装类数据包，可不经过解密等需要深入进行数据剖析或产生过多计算量的复杂途径进行分析。即使是不能分析的未知流量，亦有相关特殊方法进行强制性或使用者控制的非强制性操作而将其纳入可控范围进行管理。列举了利用模块化特性，在Linux平台上实现本方法并进行实验后得到的数据的比较，以及整套系统在真实应用环境中的分析效果。 关键词: 准确，高效，应用层，协议分析，协议识别

中图法分类号: TP 文献标识码: A 文章编号：290142

A suite of Precise and Efficient Analyzing Technique for Application Protocols

MU Qiao

（BSP Dept., Beijing Destiny Electronic Technology Co. Ltd., Beijing 100080）

Abstract: Collect and summarize the protocol analysis method currently, and introduce a new suite of analyzing

technique divided into 4 levels and 12 sorts. We can assort the application data including the unrecognizable data running on the internet into different kinds of protocols efficiently and precisely using this technique. For those encrypted or

masked packets, it may finish the analysis task without decrypt or any other complicated calculation. Once they have been classified as protocols, Network Traffic Control could be done easily.

Key words: Precise, Efficient, Application Layer, Protocol Analysis, Data Distinguishing

近年来，随着人们对信息量需求的增长，P2P和流媒体2.1 新识别方法的理论依据 等非关键性应用不断抢占网络带宽，如何禁止或控制非核心分析的实现过程是基于链表遍历和字符对比，识别匹配应用从而保障关键业务应用已成为热门话题。 所需时间、准确率与整体识别引擎的规模大小均成正比。另

根据美国Ellacoya网络研究公司发布的调查一百万宽外，哈希表的效率也是一个非常重要的参数。将协议大致分带用户的网络流量状况的统计报告，结果表明基于HTTP协为N类，基于HTTP协议的互联网流量与P2P应用流量等，议的互联网流量已占据全部流量的46％；排名第二的是P2P有计算等式：

应用的流量，其占据37%的比例。排在后面的流量分别属于

第N类引擎数×第N类比对字符数

新闻组（9%）、非HTTP协议的视频流媒体（3%）、网络游戏平均计算次数＝∑——————————————— ÷哈希参数＋补级保留值

第N类协议占总流量的百分比 （2%），以及VOIP网络电话（1%）。网络中的数据是呈现多

其中，哈希参数＝哈希表效率×100，补级保留值为补级分析方法消耗计算次数

元化，复杂化的，而对其加以控制管理的前提是分析出各种

类型数据的所属，因此，协议分析识别是网络带宽管理与分

2.2 整体系统架构概述

配的必要前提条件。

整体架构基于Linux的环境，秉承模块化的概念，由前

至后，在内核的网桥上可划分为连接跟踪模块(Conntrack)，

1.现行识别方法 协议分析模块(Protocol Analysis)，条件匹配模块(Matching)，

流量控制模块(Traffic Control)以及数据传导模块等。新的识

别方法应用于协议分析模块。

随着网络通讯技术的日新月异，许多现行识别方法均已

过时甚至失效，不能作为准确的识别标准来使用。目前最典

型的方法为纯端口判定识别与L7filter对比识别。但由于

协议的端口，特别是新协议的运行端口变得不可预期，从而使得纯端口判定识别开始走出人们的视野；而L7filter对比识别因为在识别过程中会造成不可预估的延时并大大影响整体管理系统的运行效率也在逐步地被淘汰。另外，在真

实的网络中，无法识别的流量一般会占到总流量的30%以上，而鉴于这些未知流量的不确定性和大数据量等原因，对其进行控制就显得尤为重要。但遗憾的是现行绝大多数方法

均不能做到对其进行管理。所以，对于新识别方法的需求就显得尤为迫切。

2. 新的识别方法

经过深入分析大量数据包后，在实践中总结出以下新的识别方法，并分为初、中、高、补四个级别、十二类，限于篇幅每类方法仅作简单叙述。 ---------------------------------

收稿日期：2009-03-10；修返日期：2009-06-02

作者简介：牟乔，男，北京德星公司嵌入式软件工程师，中国计算机学会工程师会员(E200013062)，曾就读于中国科技大学少年班及德国法国名校。

准确高效的应用层协议分析识别方法,该文刊登于2010 年08期《计算机工程与科学》

2.3 初级识别方法 2.3.1端口初级判定法

端口判定是指基于指定特殊端口，或基于可由公式计算出来的端口序列的初级识别方式。端口判定一般用于初始判定，仅作为一个条件来淘汰那些不符合的数据。在引擎链中，端口引擎即是针对端口初级判定的，类似于哈希表，有一个包含65536项的指针数组，每一个成员指向一个引擎链，而当数据包经过时，根据其自身的端口号而进入相应的引擎链进行判定。如Https数据就会自动进入TCP 443引擎链进行对比识别判定。

虽然端口初级判定一般仅作为一个初始筛选条件，但针对1024端口以下、有RFC文档的公认协议，仍可由端口初级判定来确定其所属协议。例如，Tacacs协议一般走49端口，SQLnet协议一般走66端口，Finger协议一般走79端口，SunRPC协议一般走111端口，AppleTalk会利用201到209端口等。

2.3.2首字符初级判定法

首字符判定是指基于指定第一个有效数据包的有效数据第一位，或基于可由公式计算出来的首字符、双首字符的对应值的初级识别方式。首字符判定仅用于初始判定, 在引擎链中，首字符引擎即是针对首字符初级判定的。与端口引擎链类似，但其大小为指定的。如针对TCP、UDP的首字符引擎链哈希表大小为256，因为第一字符从0x00到0xff的256种可能。而对于特殊的，如tcp80series或udp53series上的首字符、双首字符引擎哈希表大小则指定为1296。因为其数据为肯定是地址的明码，故共有a～z、0～9等36种可能（特殊字符如“_”、“-”等均看作与0相同），故而36 * 36 = 1296种可能。

其后各类数据就会进入相应的引擎链进行匹配，大大缩短了其所遍历的引擎链长度。如电骡的数据以0xe4开头居多，则此类数据会进入哈希值为0xe4的UDP首字符引擎链进行查找；再例如中华网的邮件服务，为，即“6d 61 69 6c 2e 63 68 69 6e 61 2e 63 6f 6d”，通过提取双首字符“m”和“c”，则可以得到对应的key值23与13，通过公式，有其最终key值（即对应的引擎链编号）298，以进入tcp80series_engine[298]引擎链进行识别判定。

无论当前通过或正在进行判定的是所属连接的第几个数据包，首字符一直都是第一个有效数据包的有效第一位！此值是在连接跟踪中成立连接的时候赋给的，在连接消亡或中断之前不会有任何改变！

2.3.3长度/二重长度初级判定法

长度判定广泛应用在众多协议识别中最常用的淘汰性判定方式，根据连接跟踪中赋给的包长度值去判定当前数据包是否满足条件。而基于结构，有针对第一个有效数据包的单独长度判定或针对前两个有效数据包的二重长度判定。而在连接跟踪处理数据包并将前两个有效数据包的长度记录下来的同时，需同时记录一个已通过的有效数据包的包数统计值。这个统计值非常重要，因为实际分析中并非总是可以根据第一个有效数据包长度就完成识别，这样一来就需要这个统计值来定位当前的数据包究竟在连接中是第几个有效包。值得一提的是，虽然理论上应该将这个统计数据一直进行下去，但因为绝大多数的判定过程均可在前三个有效数据包之内结束，故在此只会统计到第四个，对于其后的情况则不予理会。这也是效率与准确性之间妥协的一个结果。

三类初级识别方法均是非常迅速的判定方法，但由于初级方法都是在表层对数据包进行识别，其利用的是在连接跟踪的处理完成的特殊指定字段，故判定中并不会触及数据包本身的真正有效数据。因此，其在准确性上有欠缺，故仅作---------------------------------

收稿日期：2009-03-10；修返日期：2009-06-02

作者简介：牟乔，男，北京德星公司嵌入式软件工程师，中国计算机学会工程师会员(E200013062)，曾就读于中国科技大学少年班及德国法国名校。

为预处理，与中、高级识别方法配合使用。而基于初级方法

速度快这个特性，在真正应用中一般都是判定数据包是否“不符合”当前协议，一旦不符合，则立刻跳出当前引擎，以缩短协议分析识别的耗时及网络延时。

2.4 中级识别方法

2.4.1 字符串、关键字比对识别法

从整体架构来说，在明确分析出数据是属于TCP或者UDP后，会令当前数据包所属连接的一个char型指针指向当前数据包的有效数据的第一位。其后，可用移动指针的方式来指向每个字符，并根据简单的“==”和“!=”来判定当前字符是否符合条件。对于连续或基本连续（即某个长字符串中间或夹杂这少数不确定的字符）的字符串，则可用位比对来实现，因为位运算的操作要比“==”和“!=”效率高。字符串、关键字比对一般不会单独使用，因为移动指针或进行位比较都是在剖析数据包内部数据。一般常用的方法是先用初级判定方法来淘汰掉大多数不符合的数据包之后，再开始进行字符串、关键字比对。另外，有一些特殊的应用，特别是游戏类的通讯协议，由于需要额外检测连接状态，经常会出现连接的第一个甚至是前两个有效数据包都只包含少量数据的情况，即不得不从第二个甚至第三、第四个包开始进行比对。由此可见，有效数据包统计量就变得不可或缺了。

例如游戏类，完美时空协议簇（完美时空开发和运营的一系列网络游戏，包括完美世界、武林外传、赤壁、诛仙、热舞派对等），经过数据分析，可发现其基本全部利用TCP 29000端口进行通讯，而且第一个有效数据包的有效数据第二位总是比第一个有效数据包的长度大2，而且第一个有效数据包的有效数据遵循“01/03 xx 10 xx 00 00 xx xx”这个模式（“xx”代表不确定字符）。于是，便可以很轻松地利用等于或不等于来写明判定程序。

不过由于位对比必须是在两块内存间进行，需要先将数据包中的数据用memcpy复制到一个字符串中，然后与固定的字符串进行对比。但由于memcpy造成的延时和资源消耗要远比使用位对比节省下来的部分多得多，因此，在实际应用中不提倡使用位对比。

2.4.2 五元组比对识别法

协议的目的在于通讯，而网络不可能在某一时段只运行通讯双方希望获取的数据，所以，各种协议的内部就一定包含了特殊的、能够让通讯双方都认可的特定字符，以有效地从网络分复繁杂的诸多数据中找到自己需要的。即，这些特定字符中很多情况下都包含了通讯双方的自然信息，如IP地址，正在使用端口或下一连接使用的端口等。虽然连接已经建立之后依旧告知当前使用的IP地址和端口（准备使用的下一端口等情况放在连接跟踪部分讨论）实质上是没有意义的，但其却为识别提供了极大的方便。

连接信息五元组包括源IP地址、目的IP地址、源端口、目的端口以及所属协议（并非应用层协议号，而是四层协议号），其中又以源IP地址最为常见。从本质上来说，五元组识别是一种动态的字符串比对识别。

例如流媒体类，PPlive，经过抓包分析，发现它承载主要数据流量的连接大部分是UDP，且以0x0b、0x0c、0x0d开头。于是便可在UDP 0x0b，UDP 0x0c，UDP 0x0d分别注册三个首字符引擎，而其第一个有效数据包的有效数据的第49（+0x30）位到第52位恰恰是源IP地址的十六进制表示，同时发现第65（+0x40）位到第68位恰恰是其目的IP地址的十六进制表示。这样就可以首先利用ntohl来获取连接信息中的源、目的IP地址并转换成本机模式，之后用一个包含4个成员的数组用整形记录下每段的地址，如192.168.2.46记录为0xc0、0xa8、0x02和0x2e。再用数组的各成员同经过移动的数据指针所指数据进行对比以确定其

准确高效的应用层协议分析识别方法,该文刊登于2010 年08期《计算机工程与科学》

是否属于PPlive通讯数据。

虽然五元组中可用的还包括源端口和目的端口，但一般不用端口来进行判定。一方面由于有IP地址的4位判定已经足够，不需再用端口的2位数据进行匹配，另一方面基于连接的不确定性，在这里端口并非是一个较好的判定依据。

2.4.3 库比对识别法

库比对识别是指，当其某个或某些特殊数据的固定位置的数值总是在某一个范围或一定属于某几个值中间的一个的情况下，而采取的将所有可能的值录入一个数组或数据库，以进行比对判定的方式。这种方法一般常应用于判定即时通讯类软件产生的数据的识别和P2P类的初始连接数据识别。

例如即时通讯类，腾讯QQ，虽然它的协议是加密的，客户端不断在升级，协议也经常有伪装，但对于腾讯QQ2008以后的客户端来说，其版本号是一个固定的2位数值，而且在每次连接的开始都会检测传递当前客户端的版本号。截至腾讯2008 KB7为止（包括腾讯2009），其版本号可以罗列如下：{0x12, 0x03}, {0x11, 0x5b}, {0x12, 0x21}, {0x12, 0x37}, {0x15, 0x01}, {0x11, 0x4d}。

在利用版本号判定的同时, 还发现命令号也是一个固定的2位指令集，包括初始连接、握手、失败、聊天文字传输、密钥传输等等，例如{0x00, 0x91}, {0x00, 0x62}, {0x00, 0xba}, {0x00, 0xdd}, {0x00, 0x22}, {0x00, 0x16}, {0x00, 0x17}, {0x00, 0x02}, {0x00, 0x01}, {0x00, 0xd4}, {0x00, 0x0d}等（具体各命令的对应功能在此暂不详述）。

由此，判定程序可以很明了地写出，对比其第一个有效数据包的有效数据第二、三位是否符合版本号中之一，而且第四、五位是否符合QQ的指令集之一。

2.3.4 白名单、黑名单过滤识别法

白名单、黑名单过滤实质上是一种专门针对Http的库比对识别，采取取得地址关键字与库中的关键字进行匹配的方式来进行识别。属于白名单即为绝对安全的网址（如各个网页邮箱的访问，等），会在流量控制中为此类Http数据单独建立一个保障队列，以保证其访问速度，而相对应的属于黑名单即为绝对禁止访问的网址（如色情网站或游戏网站，等），一旦识别出当前数据是访问当前这类地址时，条件匹配模块会立即为其连接打上禁止的标识，并在流量控制模块中进行丢弃数据包操作。 由于这是专门针对Http的操作，所以可以利用tcp80series_engine来缩短查找过程，依旧是首先在注册引擎前计算出其哈希值并挂载到相应的引擎链上。当Http数据包到来是，就会进入相应的链表进行对比查找。

白名单、黑名单可根据具体使用环境来进行自行设置，例如，关键部分为x.google.x（“x”代表不确定部分）。所有的白名单、黑名单都可用“.”和“/”这两个特殊符号来确定关键部分的指针位置的。

2.4.5字段标志获取识别法

根据Http的RFC文档，可知其各部分数据在初始连接交互时是以明码传输，并由如Referer、Host、Connection-type等几个标识而划分成的几个字段引领各段数据。在进入tcp80series引擎链之前，数据包需要经过循环移动指针来确定地址信息（如）的位置来计算双首字符关键值。此信息有时存在于Referer字段中，有时出现在Host字段中。在定位到字段后，便可随意读取各所需的信息了。

需要注意的一点是，因为进行字段标识获取之前就已经确定了当前数据肯定是Http协议，且字段的第一位肯定是大写，最后肯定跟着一个特殊符号“：”，所以对字段的字符串对比判定可以精简到三位，即：字段的第一位的大写字符，---------------------------------

收稿日期：2009-03-10；修返日期：2009-06-02

作者简介：牟乔，男，北京德星公司嵌入式软件工程师，中国计算机学会工程师会员(E200013062)，曾就读于中国科技大学少年班及德国法国名校。

最后跟着的特殊符号“：”，以及中间的某一个必要位（如特

殊符号、大写、或在没有必要位时直接利用第二位即可）。

以上所述的仅仅是字段标志获取识别的一种应用，更为重要的功能是辅助进行“嵌入式”协议的识别。对于迅雷和很多P2SP类协议（分块下载协议），其传输数据都会伪装成Http协议，但它们有一个共同的特性，就是存在Pragma字段，且随后一定紧跟Range字段。Pragma的作用是标明当前是一个分块下载型的连接（一般显示为“Pragma: no-cache”），而Range则是确定接下来传输的数据在整体数据中的位置（如“Range: bytes=638837539-”）。于是，根据先“Pragma”后紧跟“Range”这个独一无二的特征，迅雷等协议的传输数据可以准确地被识别出。不过，即便已将对比过程精简又精简，其仍会消耗大量的时间用于循环判定。所以，字段查找过程可以“嵌入”到查找tcp80series的地址信息的过程中。这样一来就不存在进行多次循环对比的问题，可大大减少因为判定迅雷等协议而在TCP 80/8080端口造成的延时（即造成网页浏览缓慢）。但是有其利必有其弊，在协议进行“嵌入式”判定的同时也决定了此模块必须融入当前“嵌入”的模块，不可自由加载卸载。如迅雷等协议嵌入在tcp80series引擎链预处理的循环查找判定中，而tcp80series引擎链又整合在TCP总判定的模块内，所以，迅雷等P2SP类、分块下载协议实际上就成为了系统默认协议。

五类中级识别方法与初级识别方法相比，最重要的区别是开始剖析数据包内部的有效数据，所以，尽管会造成一定的延时问题，其判定效果要远比初级识别方法好。一般除极特殊协议外，都需要利用中级识别方法来准确识别数据。

2.5 高级识别方法 2.5.1连接跟踪识别法

连接跟踪识别在本身Linux系统中已经有所描述，不过那是针对FTP、Amanda等协议，且其过分考虑的通用性，这并不符合应用层协议识别的标准，需加以简化改进。

首先需要明白一个结构，就是expect。这个结构会由指针连接成一个链表存在于连接跟踪模块之中，在每个连接建立之初，会查找expect链表，看是否有相吻合的五元组存在。如存在，则表明此新连接是被一个已经建立的连接所期待出现的，而且可以称这个新连接为已建立的连接的子连接，已建立的连接就相对应地称之为父连接。

现有的连接跟踪识别不符合需求。首先在本方法中不需要区别二、三层和四层的协议，因为在判定之前，已经很明确地识别出其是属于TCP还是UDP了（其他数据已由其他各层引擎判定结束）。其次，FTP、Amanda等协议每个父连接只会拥有一个单一的子连接，而诸如BitTorrent等协议，每个父连接会对应几十甚至上百个子连接。故综合以上需求和条件，确立了使用一个一元数组进行记录的方式来读取、传输和记录写入Expect的五元组信息。

Expect链表的五元组信息是由读取特定父连接的特定数据包的特定数据而确定录入的，于是，如何确定父连接并且找到关键数据包和关键数据包内的关键数据就成为了连接跟踪识别的关键。

以BitTorrent协议为例，可发现在初始连接服务器过程中，会有以下伪装成Http的通讯数据，“GET /announce.php?info_hash=… … HTTP/1.1”（“… …”部分为略去的部分非关键数据），从字面很容易理解，这里本机正在跟服务器声明某些关键信息，而紧跟着从服务器的返回数据中在“HTTP/1.1 200 OK”之后可以发现“:interval”和“:peers”等渴望已久的节点信息。但是仍需注意的是，这里是把特殊符号同时放在字段的前面和后面来传输的，如“:peers300:”代表有300 / 6 = 50个节点信息（每个节点信息包含4位的IP信息和2位的端口信息）。先用一个暂存结

准确高效的应用层协议分析识别方法,该文刊登于2010 年08期《计算机工程与科学》

构数组将信息读出，然后再逐个导入Expect链表，这样一来BitTorrent的父连接就分析完毕了，接下来的就是等待子连接的出现。

当然，BitTorrent并非是那样照章办事，而是总会进行一定地伪装以欺骗分析技术人员，如它有可能将“GET /announce.php?info_hash=”更改成“GET /?info_hash=”或“announce?info_hash=”等，并且这个父连接使用的端口也不会总是固定在80和8080上，但它却会总以“GET /”开头。这样，分析过程中可以做的就是在TCP 0x47上加一个首字符引擎。

另外，BitTorrent的父连接在传输节点信息时，实质上有简、繁两种模式，以上所提及的6位数据表示一个节点是简洁模式，繁杂模式即是完整模式，它会把地址用十进制数值包括“.”来完整地表示出来，具体采取哪种模式会在首包（请求包）中标明。不论是简洁还是完整模式，只要锁定了关键连接的关键数据包，一切均可迎刃而解。

需要注意的是，并非所有注册到Expect链表的信息节点都会被用到，为避免长时间运行而造成内存溢出等后果，需对每个信息节点设定一个死亡时间，虽然BitTorrent的官方文档中定义的是30分钟，但在实际试验中发现，只要300秒的时间即可确定当前子连接信息是否是可被激活的。

2.5.2可疑性模糊识别法

可疑性模糊识别仅仅是针对P2P而言。鉴于加密等原因，在为效率着想而不可对数据进行解密时，可首先根据现行统计数据或其它相关现况而判定出一个分别针对各个用户的可疑程度（如该地址是否出现了某种P2P的初始连接数据包等），并扫描可疑端口（如电骡的UDP 4661到4669端口等）和可疑首字符（如电骡的0xe2、0xe3和0xe4等），一旦发现这些可疑处的流量超过某个值（由经验来讲，一般办公室正常上网带宽平均不会超过10K），就可以立即认定此用户（地址）正在使用相应的P2P软件。

虽然这样可较准确地判定出P2P流量，但其并不能很好地区分其究竟属于何种P2P，比如当网络中检测出某个用户同时有电骡和Limewire的初始连接包，且其可疑端口上的数据超出了正常上网的流量范围时，尽管在判定中可以确定这部分流量属于P2P，却无法区分开它是属于电骡还是Limewire。但在实际使用中，基本不会有同时使用两种P2P软件同时进行下载，并且对于三大最常见P2P，即BitTorrent、电骡和迅雷来说，迅雷已经在字段标识搜索对比判定方法中描述得很清楚，它绝大多是流量还是来源于P2SP 中的“S”，即服务器，而部分流量肯定是伪装成Http来进行传输的。对于BitTorrent，一般它用伪装的Http以及UDP来进行与服务器的通讯和DHT网络的资源探索，但最终的承载流量的数据包会利用没有任何规律的加密过的TCP大数据包来进行传输。电骡虽然一般情况下使用UDP和TCP（很少，一般仅在UDP失效的情况下才会发生）来进行资源探索，但真正的数据传输却都是依靠UDP数据包。如此，三大P2P便可以非常简单地区分开来。虽然这种可以行模糊识别存在一定的误判性，但其结果却是在可以接受的范围内的。

如同连接跟踪中需要额外的Expect链表进行子连接信息五元组的暂时存储一样，可疑性模糊识别也需要二维数组来暂存各个P2P协议的可能性IP地址。由于一般的网络均采用B类或C类网址，故所需要顾及的仅仅是内网地址的后两位。首先每当检测出某种P2P协议的初始连接包时，除了要为连接赋上相应的协议号，还要向这个可疑性判定二维数组中的对应项中填入当前连接的源地址的后两位。这样每当可疑端口或可疑首字符上的流量出现异常时，只要其IP存在于这个二维数组中，那么就可以直接将这些未能识别出的大流量数据判定为相应的P2P协议。

有添加过程就必须有删除过程，否则这个二维数组会很---------------------------------

收稿日期：2009-03-10；修返日期：2009-06-02

作者简介：牟乔，男，北京德星公司嵌入式软件工程师，中国计算机学会工程师会员(E200013062)，曾就读于中国科技大学少年班及德国法国名校。

快被塞满。每当发现某个已经被判定成在使用某种P2P的

IP的全部流量低于某个警戒值时（如5K），则即可认为其已经关闭了P2P下载，并将此地址对应的所有项统统从数组中删除。

2.5.3用户行为识别法

行为特征与行为识别是非常新的一种技术，其主要面向的对象也是P2P协议。因为P2P协议会自动跳转端口并且对自身数据进行加密，所以其对防火墙和安全代理的穿透性以及对网络管理人员的欺骗性非常强，很多时候单纯地去基于数据字符本身来进行判定只会竹篮打水一场空，这时，就需要一种站在更高的角度去看待和识别P2P的方法。

首先，不论P2P如何伪装，它的数据量是无法掩饰的，而且，它的多连接数、单个包数据量异常大以及使用非常规端口（1024以上，实际上经常在5000以上）等特性也是无所隐遁。因此，数据包内的数据究竟如何可以完全不去理会，改而从统计上入手。总的来说，虽然P2P在每次使用时的通讯端口都不同，但在每次使用中的通讯端口却是固定的。有以下几个行为特征可以总结出：

(1) 每次使用的某段时间内总是用固定的几个本地端口进行通讯；

(2) 发起大量的连接，并且是一个内网IP对一群外网IP； (3) 其利用的通讯端口是非常规端口，一般会在5000以上； (4) 数据流量一定有异常，单个数据包的长度有异常； … …

由此，便可根据统计数据来简单而轻松地进行判定。 P2P类，Poco，经过反复抓包并查看数据后，发现软件启动时会首先大量发UDP 1107探测包（吻合第2条行为特征）以检测当前本机的peer表中的各个节点是否能够连通；每次使用过程中会在固定的时间内使用用固定端口通信，如UDP 8009，UDP13018等（符合第1、3条行为特征）；还有最重要的就是使用Poco的IP的流量远远大于正常上网的流量（符合第4条行为特征）。

需要补充的是，行为识别或多或少仍然存在一定的不足，在实际应用中，一般还会与可疑性模糊识别的混合使用。

三类高级识别方法与前两个级别相比，最大区别就是不仅限于对当前数据包本身的分析，其还包括诸如利用链表暂存连接信息而构造出的父子连接关系跟踪识别，利用特定条件触发而记录IP后轮询可疑性而进行的模糊识别，以及基于行为层面的判定等。所有本类方法均需要额外向系统申请内存用以存储辅助判定的各数据表或库。虽然高级识别方法可以极大地加强识别率和准确率，但延时极大，因此，需要尽量控制使用高级识别方法。

2.6 补充识别方法

补充识别方法是在已经过各种判定后却一直未能识别出协议之后所采取的最后的方法。因为网络中未能识别的流量一般在30%左右，为了进一步管理这30%的流量，需进一步将这些未知流量的部分信息解析分组并呈现于统计之中。补充识别方法是最后的方法。

2.6.1强行端口甄别

强行端口甄别分为两种，一种是在分析TCP协议时，针对未能形成连接的数据包以及握手数据包。由于在实际网络环境下，这种类型的数据虽然占据的流量并不是很大，但其数据包量非常大。所以不能简单地将其归类为未识别数据。在试验的模拟环境下，这部分数据包占据了未知数据流量的10%，总包数的40％以上。

另一种强行端口识别定位于低、中、高三个级别的识别之后，当某个正常的连接经过完整的引擎链后却无法匹配任

准确高效的应用层协议分析识别方法,该文刊登于2010 年08期《计算机工程与科学》

何一个引擎（协议）时，就需要读取连接跟踪结构中的连接信息五元组中的目标端口，并将其赋值为特殊的一系列协议号，从而标识出基本特征。

图-3 仅应用低级分析识别方法的应用流量协议统计饼图

3. 实验数据

利用以上分析方法，在Linux环境下运行所编写的程序。实验分为准确性和识别率两个方向，分别由加载全部协议分析模块（低、中、高、补）和仅加载基础协议分析模块（低、补、及部分中级）来模拟旧识别方法和新识别方法的应用状况。另，额外地做一轮仅仅应用低级分析识别方法的实验，以同前两种情况进行对比。

3.1 环境搭建如下图：

图-4 仅应用低级分析识别方法的应用流量协议统计列表

3.3.2 第二组实验：

图-5与图-6为仅加载基础协议分析模块（即，除了最常用的20余种协议以及内置的协议外，其他的分析模块均为加载）而得到的统计结果。很明显，现在的效果要比前一组好得多。对于同样的数据，至少已经分析出迅雷、Http、PPStream等协议，但依旧存在着许多端口未能分析。

图-2 实验环境搭建示意图

3.2 实验中进行的操作

实验的4个小时内，在本地终端上主要进行了以下应用操作：

(1) 浏览网页 (2) 观看网页视频

(3) 使用PPStream流媒体软件 (4) 使用皮皮在线影视流媒体软件 (5) 使用迅雷下载Bittorrent (6) 内网互传文件

(7) 登录Poco下载歌曲

(8) 使用Windows Messenger（即MSN） (9)

登录网页邮箱收发带附件的邮件

3.3准确性与识别率 3.3.1 第一组实验：

图-3与图-4为仅应用低级分析识别方法（即，除了基础架构外的分析模块均未加载）而得到的统计结果。很遗憾一个协议都没有分析出来，因为现在的协议已经不能仅仅依赖与端口进行判定。

图-5仅加载基础协议分析模块的应用流量协议统计饼图

图-6仅加载基础协议分析模块的应用流量协议统计列表 3.3.3 第三组实验：

图-7与图-8为加载全部协议分析模块（即，已经使用了全套的低、中、高、补等级别的协议分析识别方法）而得到的统计结果。对比起前两组统计来说，这第三组是最好的。不但分析出了所有正在应用的协议，而且还将Http流量进行了细分，将FLV格式在线视频、网页邮箱服务等从HTTP/类HTTP中剥离出来。而且在加上行为分析等高级分析方法后，UDP 10007等以前无法识别的流量也被识别出来。

---------------------------------

收稿日期：2009-03-10；修返日期：2009-06-02

作者简介：牟乔，男，北京德星公司嵌入式软件工程师，中国计算机学会工程师会员(E200013062)，曾就读于中国科技大学少年班及德国法国名校。

准确高效的应用层协议分析识别方法,该文刊登于2010 年08期《计算机工程与科学》

图-7加载全部协议分析模块的应用流量协议统计饼图

图-9 某集团某时段的应用流量协议统计饼图

图-8加载全部协议分析模块的应用流量协议统计列表

总之，由三组实验统计数据，很好地证明了这套新的协议识别方法的识别效果和准确率。

3.4网络延时/分析效率

延时统计是由thrulay程序从内网端的一台终端向外网端的另一台终端不断发送不能被识别的数据包（这样，数据包就会遍历最多的引擎，也就是这时延时最大）而计算得出的一个平均值。

图-10 某集团某时段的应用流量协议统计列表

实际统计中，在挂载了257种协议（216个模块，且包括诸如迅雷、BitTorrent、电骡、Poco等利用了高级协议识别方法的协议分析模块）后其整体网络延时小于9.2毫秒，正常上网没有任何异常感觉。而且识别率大于95％。

5 结束语

实质上，本协议分析识别方法除了最后的行为识别以外，依旧是基于数据包数据的特征进行处理，但考虑的范围更广，着眼层次更高，分析的深度更专，对突发事件（如未知流量）的处理能力更强，速度更快。但单独的协议分析识别是没有意义的，它需配合其他模块来实现其商业价值，如： (1) 配合统计，进行网络状况监视与流量控制；

(2) 配合瞬间握手等功能，对TCP流量进行网络提速； (3) 构建应用防火墙，入侵监测，进行上网行为监控；

以上是我近几年涉猎Linux设备模型特别是Linux内核的网络部份，在学术探讨交流和具体的网络流量控制设备的研发中，实践总结提炼出的一些方法和经验，主要涉及应用层协议分析与条件模式匹配等内核模块的研发，以及Linux内核中的连接跟踪模块和网络流量控制等模块的改进，期望能得到诸位前辈同仁的指教，以在研讨中前进提高。

参考文献:

［1］ ［2］ ［3］ ［4］ ［5］ ［6］

Jonathan Corbet & Alessandro Rubini & Greg Kroah-Hartman, Linux Device Drivers (3rd Edition), 2005 by O’Reilly Media, Inc.

Daniel P. Bovet & Marco Cesati, Understanding the Linux Kernel (3rd Edition), 2008 by O’Reilly Media, Inc.

Christian Venvenuti, Understanding Linux Network Internals, 2006 by O’Reilly Media Inc.

小高知宏, 基礎からわかるTCP/IP - アナライ作成とザパケット解析, オーム社 2002

W. Richard Stevens, TCP/IP Illustrated - Volume 1: The Protocols, 1994 by Addison Wesley Longman, Inc.

BitTorrent Official Document & eMule Introduction (eDonkey)

由上表明显看出，随着引擎挂载数目的增加，延时量也呈现一个加速度增长，这主要是受哈希表的运算效率所影响。所以，在真实应用中，一般只会根据实际情况选择性地挂载引擎。

4真实环境的分析效果

经过在准确性、识别率以及网络延时方面的协调后，使用者最终可以根据各种具体实际情况来得到一个最佳协议加载量。以下图-9与图-10为在某200人规模的集团总部的出口布置设备上的协议分析效果统计图和统计列表。

---------------------------------

收稿日期：2009-03-10；修返日期：2009-06-02

作者简介：牟乔，男，北京德星公司嵌入式软件工程师，中国计算机学会工程师会员(E200013062)，曾就读于中国科技大学少年班及德国法国名校。

本文来源：https://www.bwwdw.com/article/3c3e.html