CN101577641A - 针对网络p2p应用的mcmpa监控方法 - Google Patents
针对网络p2p应用的mcmpa监控方法 Download PDFInfo
- Publication number
- CN101577641A CN101577641A CNA2008100941866A CN200810094186A CN101577641A CN 101577641 A CN101577641 A CN 101577641A CN A2008100941866 A CNA2008100941866 A CN A2008100941866A CN 200810094186 A CN200810094186 A CN 200810094186A CN 101577641 A CN101577641 A CN 101577641A
- Authority
- CN
- China
- Prior art keywords
- application
- network
- bandwidth
- protocol
- software
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明涉及一种针对网络P2P应用的监控方法及对应软件。该发明主要基于以下技术:(1)P2P应用协议监听和解析技术;(2)P2P应用协议机制分析技术;(3)P2P应用协议封禁技术;(4)P2P带宽通道分配技术;(5)P2P流量控制技术。基于以上技术成果和有限量P2P应用软件解析的支持,本发明的处理步骤如下:(1)监听网络中的P2P应用,并使用封包撷取和ipp2p匹配解析未知的P2P协议;(2)针对解析的P2P协议进行协议分析;(3)基于(2)允许或封禁该P2P软件的使用;(4)基于(2)在该P2P软件与其他网络软件中分配带宽通道;(5)基于(2)控制该P2P软件的流量。
Description
技术领域
本发明涉及一种针对网络P2P应用的监控方法(MCMPA)及对应软件。
背景技术
网络P2P的技术背景:
P2P技术属于覆盖层网络(Overlay Network)的范畴,是相对于客户机/服务器(C/S)模式来说的一种网络信息交换方式。在P2P网络中,每个节点既可以从其他节点得到服务,也可以向其他节点提供服务。这样,庞大的终端资源被利用起来,一举解决了C/S模式中的两个弊端。P2P网络有3种比较流行的组织结构,被应用在不同的P2P应用中。
(1)DHT结构。分布式哈希表(DHT)是一种功能强大的工具,虽然DHT具有各种各样的实现方式,但是具有共同的特征,即都是一个环行拓扑结构,在这个结构里每个节点具有一个唯一的节点标识(ID),节点ID是一个128位的哈希值。每个节点都在路由表里保存了其他前驱、后继节点的ID,如图1(a)所示。通过这些路由信息,可以方便地找到其他节点。这种结构多用于文件共享和作为底层结构用于流媒体传输。
(2)树形结构。P2P网络树形结构如图1(b)所示。在这种结构中,所有的节点都被组织在一棵树中,树根只有子节点,树叶只有父节点,其他节点既有子节点也有父节点。信息的流向沿着树枝流动。最初的树形结构多用于P2P流媒体直播。
(3)网状结构。网状结构如图1(c)示,又叫无结构。这种结构中所有的节点无规则地连在一起,没有稳定的关系,没有父子关系。网状结构为P2P提供了最大的容忍性、动态适应性,在流媒体直播和点播应用中取得了极大的成功。当网络变得很大时,常常会引入超级节点的概念,超级节点可以和任何一种以上结构结合起来组成新的结构。
网络P2P的应用背景:
由于能够极大缓解传统架构中服务器端的压力过大、单一失效点等问题,又能充分利用终端的丰富资源,所以P2P技术被广泛应用于计算机网络的各个应用领域,如分布式科学计算、文件共享、流媒体直播与点播、语音通信及在线游戏支撑平台等方面。
(1)分布式科学计算。P2P技术可以使得众多终端的CPU资源联合起来,服务于一个共同的计算。这种计算一般是计算量巨大、数据极多、耗时很长的科学计算。在每次计算过程中,任务被划分成多个片,被分配到参与科学计算的P2P节点机器上。在不影响原有计算机使用的前提下,人们利用分散的CPU资源完成计算任务,并将结果返回给一个或多个服务器,将众多结果进行整合,以得到最终结果。
(2)文件共享。节点在共享一个文件时,首先将文件分片并将文件和分片信息保存在一个流类型文件中,这种节点被称作“种子”节点。其他用户在下载该文件时根据文件的信息,将文件的部分分片下载下来,然后在其他下载该文件的节点之间共享自己已经下载的分片,互通有无,从而实现文件的快速分发。常见的如BitTorren、Gnutella和KaZaA等。
(3)流媒体直播。P2P流媒体直播软件如Coolstreaming、AnySee、Gridmedia等学院系统以及PPLive、PPStream、沸点和TVAnts等商业产品。AnySee就是基于优化的网状结构(如图2所示),即每个节点维护一定数量的邻居成员,并从中选出最合适的“伙伴”节点与之交换数据。伙伴的数量既有上限又有下限,在不满足下限时,节点会不断寻找新的合适节点加入伙伴列表;在达到下限时,节点停止主动寻找伙伴的过程,但可以接受其他节点将其加入伙伴列表的请求;在达到上限时,节点不再和新的节点建立伙伴关系。
(4)流媒体点播。典型的有GridCast系统、PPStream点播系统。应用中采取一种同心圆环的媒体内容组织结构。在每一个节目频道里,媒体内容按指数递增的区间进行划分。每个节点记录几个正在观看各个段之间内容的节点。在网状结构中,定期交换这种分段记录,从而,在某个用户拖动观看点时,可以快速定位到相应段的记录节点处,并从这些节点当时所观看的区间内得到大量备用记录以请求该区间媒体数据。
(5)IP层语音通信。IP层语音通信(VoIP)是一种全新的网络电话通信业务。Skype即是一款典型的P2P VoIP软件,它采取类似KaZaA的拓扑结构,在网络中选取一些超级节点,在通信双方直连效果不好时,一些合适的超级节点则担当起其中转节点的角色,为通信双方创建中转连接,并转发相应的语音通信包。
网络P2P应用的现存问题:
虽然P2P有着诸多优势,但它也同时面对若干困难的问题:
(1)消耗大量网络带宽资源。由于P2P并发连接的特点使得P2P应用必然消耗大量可用资源,很容易导致网络拥塞,并导致其他互联网应用的性能降低。尤其现在,许多运营商采用包月形式来提供用户使用的网络,所以网络带宽洪水般充斥当前不断扩容的网络,却没有带来投资预期的业务收入的增长,造成运营商的投资增长与收入不成比例的窘境。
(2)业务管理不便。P2P的“无中心化”特点使业务传播的扁平化特征更加明显。运营商除了限制用户接入带宽以外,基本上没有其它有效管理手段,而限制用户接入带宽在某种程度上违反用户使用合同。另外,P2P应用种类每天都在增加,而且往往使用私有协议和动态随机端口,导致业务难于监控。
(3)不良信息大量扩散。当前,基于互联网的P2P业务往往缺少有效的身份识别和信息管理手段,造成大量反动、违法、骚扰等不良信息在网络中传播。随之而来的是家庭、社会、政府对于宽带网络发展的担忧,对P2P业务发展带来了不利的消极影响。
(4)用户终端安全问题。由于P2P往往允许任何电脑互联,必然有一些别有用心的人利用P2P业务系统或者对端电脑本身的漏洞侵入用户电脑,获取重要信息或者进行破坏,给用户造成难以估量的损失。另外,许多病毒也通过P2P系统泛滥成灾,严重破坏用户终端的安全性。目前,通过P2P下载的文件中至少有20%以上的文件都带有病毒,从而影响了P2P在用户心目中的形象,导致很多企业限制甚至禁止使用P2P。
(5)知识产权保护问题。P2P下载应用加剧了盗版的泛滥,服务提供者和管理者也很难限制使用者侵犯版权。P2P应用成为目前盗版音乐、电影、软件的“天堂”。目前,P2P应用的盗版问题严重地冲击道德法律。
发明内容
我们针对P2P下载和P2P流媒体两种应用,通过监听、分析和带宽通道、流量控制的方法,在一定程度上解决监控和管理P2P软件“消耗大量网络带宽资源”和“业务管理不便”的问题。
P2P协议监听解析方法(MCMPA-M):
目前的P2P软件都可以使用动态端口来进行数据连接,而且也可以使用其他协议的标准端口如80等进行通信,因此普通的端口封禁很难奏效,只能从通信内容中进行判断。我们的协议监听解析方法提供了ipp2p匹配,可匹配很多种P2P协议。下面说明各种P2P协议的匹配特征。
1.UDP
(1)eMule/eDonkey/Kad:使用图3所示二进制数进行协商。
(2)Gnutella:明文检查起始数据是否为“GNUTELLA”或“GND”。
(3)KaZaA:UDP数据部分的结尾6个字节是“KaZaA\0”。
(4)BitTorrent:UDP长度24字节(含UDP头),起始8个字节为:00 00 04 17 27 1019 80
2.TCP
(1)Ares:使用图4所示二进制数进行协商。
(2)SoulSeek:前8个字节格式为:xx xx 00 00 yy zz 00 00,其中xx xx为16位负载长度-4,yy!=0,zz任意或者数据长度8字节,全0或者数据格式为:01 xx 00 0000 yy..zz 00 00 00..,其中负载长度大于xx+6,负载第xx+4+1字节(zz)不为0,而负载第xx+5+1字节、第xx+6+1字节为0。
(3)WinMX:负载长度为4字节时负载内容为“SEND”或负载长度为3字节时负载内容为“GET”,其他情况负载长度必须大于10,负载必须以“SEND”或“GET”开头,而且负载内容中出现0x2 0 0x22,之后出现0x22 0x20。
(4)appleJuice:负载起始数据为“ajprot\r\n”。
(5)BitTorrent:负载第一字节为0x13,而且后续数据为“BitTorrent protocol”。
(6)KaZaA命令:负载最后以“\r\n”结尾,而且起始数据为“GET/.hash=”。
(7)gnutella命令:负载最后以“\r\n”结尾,而且起始数据为“GET/get/”或者是“GET/uri-res/”。
(8)各种类型的gnutella:负载最后以“\r\n”结尾,而且起始数据为“GNUTELLACONNECT/”或者是“GNUTELLA/”或者是“GET/get/”或“GET/uri-res/”,而且负载中包含“\r\nX-Gnutella-”或“\r\nX-Queue:”。
(9)各种类型的KaZaA:负载最后以“\r\n”结尾,而且起始数据为“GIVE”或者是“GET/”,而且负载中包含“\r\nX-Kazaa-Username:”。
(10)edonkey文件碎片传输:负载第一字节为0xe3,第6字节为0x47。
(11)各种类型的edonkey/emule:负载第一字节为0xd4,而且第2、3字节表示的长度等于负载长度减5,而且第6字节为0x82或0x15负载第一字节为0xc5,而且第2、3字节表示的长度等于负载长度减5,而且第6字节为0x01/0x02/0x60/0x81/0x82/0x85/0x86/0x87/0x40/0x92/0x93/0x12。负载第一字节为0xe3,如果第2、3字节表示的长度等于负载长度减5,而且第6字节为0x01/0x50/0x16/0x58/0x48/0x54/0x47/0x46/0x4c/0x4f/0x59/0x65/0x66/0x51/0x52/0x4d/0x5c/0x38/0x69/0x19/0x42/0x34/0x94/0x1c/0x6a。如果第2、3字节等表示的长度大于负载长度减5,而且第4、5字节为0,第6字节为0x01或0x4c。如果第2、3字节等表示的长度小于负载长度减5,则负载偏移该长度字节后的第6字节为0xe3/0xc5。
(12)直接连接(Direct Connect):负载第一字节为0x24,而且最后一个字节为0x7c,而且从负载第2字节的数据格式为“Lock″/″Key″/″Hello″/″MyNick″/″Search″/″Send”。
P2P应用带宽分配和流量控制方法(MCMPA-C):
MCMPA控制方法的核心是其数据处理平面,负责数据包处理,其中:
(1)PAE(Packet Analysis Engine):数据包分析引擎,负责应用层识别,使用上文描述的P2P协议监听解析方法。
(2)ACE(Access Control Engine):访问控制引擎,负责访问控制。
(3)BME(Bandwidth Management Engine):带宽管理引擎,负责带宽限制和流量分配,提供以下三种带宽管理机制:
■带宽限制:根据策略对特定应用协议进行带宽限制,避免这些IP/IP组、应用协议过度使用带宽而影响他人和整个网络。特别地,支持针对“未知协议”的带宽限制功能,可将未识别或尚未支持的协议流量或异常流量控制在一定的范围内。图5是为某用户设定的策略:每天8点到24点将P2P下载和P2P NetTV的上下行带宽限制为10M,其它时间不限,并使用自定义的图表定制的实际效果图。
■带宽预留:预留出一定的带宽给特定的应用协议使用。比如:假设网络出口的总带宽为100M,如果为某些IP、IP网段、应用协议预留了10M带宽那么其他所有IP、应用协议可使用的总带宽即为90M。预留出的10M带宽始终属于规定的IP、IP网段、应用协议所有,其他任何IP、应用协议无论如何都不能占用。
■带宽保证:带宽保证与带宽预留类似。所不同的是,带宽保证在其保证的带宽不能满足要求的时候,会从剩余的总带宽里借用所需带宽。以上面提到例子为例,如果做一条带宽保证策略,分配10M带宽给某P2P协议,那么当某个时刻该P2P协议所需要的带宽大于10M,比如15M时,那么就会从其余的90M带宽中借出5M给该P2P协议以满足其使用。
MCMPA方法的带宽管理灵活性在具体使用中体现在两个方面:
(1)数据通道:定义带宽管理和调度方式。上面所说的带宽限制、带宽预留和带宽保证就是三种不同类型的带宽对象。系统根据带宽类型和带宽的大小系统地对带宽进行分配和调度。
(2)策略:策略是用来将流量进行分类的机制。所定义的每一条策略可以包含源地址、目标地址、数据流向(上行还是下行)、应用协议等因素。当匹配这些因素后,就会执行某个动作,如阻断、放行或将其注入某个数据通道。通过将符合这些条件的数据注入通道,实际上就已经对符合上述条件的数据包实施了流量管理。
附图说明
图1为常用的P2P组织结构示意;
图2为P2P流媒体软件Anysee网状结构示意;
图3为eMule/eDonkey/Kad二进制数协商示意;
图4为Ares二进制数协商示意。
图5为带宽限制实际效果示意。
图6为P2P下载协议统计表单示意。
图7为P2P网络电视协议统计表单示意。
具体实施方式
第一步运行程序监听P2P协议并解析
将MCMPA程序运行在一个特定内网的某一电脑上,执行程序,并点击“开始监听”按钮,MCMPA使用发明内容中的MCMPA-M方法开始执行监听该内网所有运行电脑中的P2P协议并进行对应的解析。
第二步 协议统计和各种信息表单输出
针对监听和解析的P2P协议,程序软件将进行统计并输出图6与图7类的表格,供使用者查询和了解。
第三步 带宽分配和流量限制
针对统计后的协议极其对应信息,可提供如下三种方式针对协议及IP/IP组进行带宽分配和相应的流量限制。
■带宽限制:根据策略对特定应用协议进行带宽限制,避免这些IP/IP组、应用协议过度使用带宽而影响他人和整个网络。特别地,支持针对“未知协议”的带宽限制功能,可将未识别或尚未支持的协议流量或异常流量控制在一定的范围内。图5是为某用户设定的策略:每天8点到24点将P2P下载和P2P NetTV的上下行带宽限制为10M,其它时间不限,并使用自定义的图表定制的实际效果图。
■带宽预留:预留出一定的带宽给特定的应用协议使用。比如:假设网络出口的总带宽为100M,如果为某些IP、IP网段、应用协议预留了10M带宽那么其他所有IP、应用协议可使用的总带宽即为90M。预留出的10M带宽始终属于规定的IP、IP网段、应用协议所有,其他任何IP、应用协议无论如何都不能占用。
■带宽保证:带宽保证与带宽预留类似。所不同的是,带宽保证在其保证的带宽不能满足要求的时候,会从剩余的总带宽里借用所需带宽。以上面提到例子为例,如果做一条带宽保证策略,分配10M带宽给某P2P协议,那么当某个时刻该P2P协议所需要的带宽大于10M,比如15M时,那么就会从其余的90M带宽中借出5M给该P2P协议以满足其使用。
Claims (10)
1.一种针对网络P2P应用的监控方法,命名为“MCMPA”(Monitor and Control Method forP2P Application),其特征在于:
(1)针对若干P2P下载应用和P2P流媒体应用;
(2)网络P2P应用的协议分析技术;
(3)网络P2P应用的监视分析技术;
(4)网络P2P应用的控制技术。
2.根据权利要求1中的方法,其特征在于:
针对有限的P2P下载应用和P2P流媒体应用。
3.根据权利要求1中的方法,其特征在于:
使用基于封包撷取和ipp2p匹配解析未知P2P协定的方法对P2P应用协议进行分析。
4.根据权利要求1中的方法,其特征在于:
获取参与用户状态和带宽通道占用的实时信息并显现。
5.根据权利要求1中的方法,其特征在于:
支持对P2P应用的控制,如允许或禁止使用某种P2P应用。
6.根据权利要求1中的方法,其特征在于:
支持对P2P应用的带宽和流量属性的控制。
7.根据权利要求4中的方法,其特征在于:
使用递进式记录查询、统计、报表一体化方法。
8.根据权利要求5中的方法,其特征在于:
支持基于用户、时间段的策略定制。
9.根据权利要求6中的方法,其特征在于:
支持自定义带宽通道,以及对应的优先级、速率上下限。
10.根据权利要求6中的方法,其特征在于:
支持基于应用协议的带宽通道分配。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNA2008100941866A CN101577641A (zh) | 2008-05-08 | 2008-05-08 | 针对网络p2p应用的mcmpa监控方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNA2008100941866A CN101577641A (zh) | 2008-05-08 | 2008-05-08 | 针对网络p2p应用的mcmpa监控方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN101577641A true CN101577641A (zh) | 2009-11-11 |
Family
ID=41272435
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNA2008100941866A Pending CN101577641A (zh) | 2008-05-08 | 2008-05-08 | 针对网络p2p应用的mcmpa监控方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101577641A (zh) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101854391A (zh) * | 2010-05-25 | 2010-10-06 | 南京邮电大学 | 一种基于对等网络的阿瑞斯协议分析系统的实现方法 |
CN101945127A (zh) * | 2010-09-10 | 2011-01-12 | 华中科技大学 | 一种VoIP系统中的语音动态中转方法 |
CN102025739A (zh) * | 2010-12-14 | 2011-04-20 | 汉柏科技有限公司 | 基于主机行为的多维度协议识别方法 |
-
2008
- 2008-05-08 CN CNA2008100941866A patent/CN101577641A/zh active Pending
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101854391A (zh) * | 2010-05-25 | 2010-10-06 | 南京邮电大学 | 一种基于对等网络的阿瑞斯协议分析系统的实现方法 |
CN101854391B (zh) * | 2010-05-25 | 2013-01-02 | 南京邮电大学 | 一种基于对等网络的阿瑞斯协议分析系统的实现方法 |
CN101945127A (zh) * | 2010-09-10 | 2011-01-12 | 华中科技大学 | 一种VoIP系统中的语音动态中转方法 |
CN101945127B (zh) * | 2010-09-10 | 2012-11-14 | 华中科技大学 | 一种VoIP系统中的语音动态中转方法 |
CN102025739A (zh) * | 2010-12-14 | 2011-04-20 | 汉柏科技有限公司 | 基于主机行为的多维度协议识别方法 |
CN102025739B (zh) * | 2010-12-14 | 2013-06-19 | 汉柏科技有限公司 | 基于主机行为的多维度协议识别方法 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
Karagiannis et al. | Should internet service providers fear peer-assisted content distribution? | |
Nguyen et al. | Federated deep reinforcement learning for traffic monitoring in SDN-based IoT networks | |
US8199651B1 (en) | Method and system for modifying communication flows at a port level | |
Rhinow et al. | P2P live video streaming in WebRTC | |
CN104320358A (zh) | 一种电力通信网中的QoS业务控制方法 | |
CN108733821A (zh) | 一种监控视频截图的分发与展示方法及系统 | |
Augustin et al. | On traffic patterns of http applications | |
CN102571946A (zh) | 一种基于对等网络的协议识别与控制系统的实现方法 | |
CN101577641A (zh) | 针对网络p2p应用的mcmpa监控方法 | |
CN101645803A (zh) | 点对点业务的识别方法和互联网业务识别系统 | |
Zhang et al. | A method for real-time peer-to-peer traffic classification based on C4. 5 | |
Lehrieder et al. | Mitigating unfairness in locality‐aware peer‐to‐peer networks | |
Sluijs et al. | Cloud computing in the EU policy sphere: Interoperability, vertical integration and the internal market | |
Ghareeb et al. | P2PWeb: A Client/Server and P2P hybrid architecture for content delivery over internet | |
Li et al. | High performance flow feature extraction with multi-core processors | |
CN101686170A (zh) | 基于多出口用户路由的分级传输品质保障系统 | |
Lu et al. | Towards a novel web services standard-supported CDN-P2P loosely-coupled hybrid and management model | |
Lin et al. | An isp-friendly file distribution protocol: analysis, design, and implementation | |
Qin et al. | CUFTI: Methods for core users finding and traffic identification in P2P systems | |
Wang et al. | A study on key strategies in P2P file sharing systems and ISPs’ P2P traffic management | |
Kassim et al. | Bandwidth gain analysis for HTTP and HTTPs traffic on IP based network | |
Yoon et al. | Signature maintenance for Internet application traffic identification using header signatures | |
Cai et al. | Iq-services: network-aware middleware for interactive large-data applications | |
Tang et al. | Characterizing user behavior to improve quality of streaming service over P2P networks | |
Wichtlhuber et al. | Reciprocity with virtual nodes: Supporting mobile peers in Peer-to-Peer content distribution |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C57 | Notification of unclear or unknown address | ||
DD01 | Delivery of document by public notice |
Addressee: Cai Wenxi Document name: Notification of Publication of the Application for Invention |
|
DD01 | Delivery of document by public notice |
Addressee: Cai Wenxi Document name: Notification of before Expiration of Request of Examination as to Substance |
|
DD01 | Delivery of document by public notice |
Addressee: Xu Kun Document name: Notification that Application Deemed to be Withdrawn |
|
C02 | Deemed withdrawal of patent application after publication (patent law 2001) | ||
WD01 | Invention patent application deemed withdrawn after publication |
Open date: 20091111 |