没有合适的资源?快使用搜索试试~ 我知道了~
### P2P_Behaviour_Detection
#### Peer-to-Peer (P2P) Behaviour Detection by TCP Flows Analysis
**背景与重要性**
随着互联网技术的发展,P2P(Peer-to-Peer)应用变得越来越普遍,如Gnutella、Kazaa、eDonkey等。这些应用程序有时会占据高达50%的互联网流量。因此,对于ISP(Internet Service Provider)而言,检测这些应用变得非常重要。传统的基于TCP端口的方法由于端口的动态变化而不再适用。本研究旨在通过分析路由器上的TCP流(如Cisco的NetFlow)来识别P2P用户及其流量。
**主要内容概述**
- **P2P网络概述**
- 定义及特点:P2P网络是一种分布式网络结构,在这种结构中,每个节点既是服务提供者也是服务消费者。
- 发展历史:从最早的Napster到后来的Gnutella、Kazaa等,P2P技术不断发展,应用场景也越来越广泛。
- **流行的P2P文件共享系统**
- **FastTrack**:由Kazaa采用的一种P2P架构,支持大规模的数据共享。
- **Gnutella**:一种完全去中心化的P2P网络协议,支持文件搜索和下载。
- **DirectConnect**:一种小规模P2P网络,主要用于文件共享。
- **eDonkey**:早期的P2P文件共享软件之一,以其强大的文件校验机制著称。
- **BitTorrent**:一种高效的文件分发协议,特别适合大文件的分发。
- **WinMX**:一个早期的P2P网络,主要流行于欧洲,支持音乐文件的共享。
- **检测方法**
- **主动爬虫**:通过模拟用户行为,主动访问P2P网络,收集相关信息。
- **内容检查**:检查数据包中的具体内容,判断是否为P2P流量。
- **NetFlow介绍**:
- **数据导出**:路由器周期性地将流量信息导出到专门的服务器上。
- **数据收集**:收集这些导出的信息,进行进一步的处理。
- **数据分析**:对收集的数据进行分析,识别P2P行为。
- **NetFlow的优势**:实时性高、覆盖范围广、易于实现等特点。
#### P2P行为特征
- **存在应用层覆盖网络**:在P2P网络中,节点之间通过一种覆盖网络连接起来,这种网络不依赖于底层网络的路由表,而是根据P2P网络自身的规则建立连接。
- **数据流模式**:P2P流量通常表现出与其他类型流量不同的模式,如突发性的数据传输、非连续的数据包等。
- **端口使用情况**:尽管P2P流量可能使用动态端口,但通过对特定时间段内活跃端口的统计分析,仍然可以发现一些规律。
- **文件大小分布**:P2P文件共享通常涉及较大文件的传输,因此文件大小的分布也可能成为一种识别依据。
#### 实践案例
- **eDonkey流量检测器开发**:本研究开发了一个基于NetFlow跟踪的eDonkey流量检测器,并在比利时列日大学的实际流量中进行了测试。
- **性能评估**:通过对实际网络流量的检测结果进行分析,验证了所提出的P2P行为特征的有效性。
- **改进与未来工作**:提出了几种可能的改进方案,包括更准确的数据包分析算法、更高效的数据处理方法等,以及对未来研究方向的建议。
**总结**
通过本研究,我们不仅深入了解了P2P网络的行为特征,还成功开发了一种有效的流量检测方法。这对于ISP管理和优化网络资源具有重要意义。此外,研究中提出的理论和技术也可以应用于其他类型的流量分析和管理。
UNIVERSITY OF LI
`
EGE
Faculty of Applied Sciences
Peer-to-Peer Behaviour Detection by
TCP Flows Analysis
CYRIL SOLDANI
Academic year 2003–2004
Peer-to-Peer Behaviour Detection by TCP Flows Analysis
CYRIL SOLDANI
14th may 2004
Abstract
The use of peer-to-peer (P2P) applications is growing dramatically. It concerns applications
like Gnutella, Kazaa or eDonkey. These applications sometimes represent as most as 50% of
Internet traffic. So, it became important for ISPs to detect these applications. As the TCP port
can change, an identification based on TCP gate is not possible.
Main goal of this work is to use knowledge about TCP flows on routers (Cisco’s NetFlow)
to identify P2P users and flows.
We first present P2P networks in general and some popular file-sharing systems. We then
discuss different techniques to try to measure P2P traffic. We analyse results of measurement
of P2P traffic and we try to derive a characterisation of P2P behaviour based on these re-
sults. Our characterisation is based on the existence of an application layer overlay network
between peers.
We test our characterisation in a practical case. We develop a detector for eDonkey traffic
under Linux based on NetFlow traces. This detector is tested against traces from the traffic
of University of Li`ege. We show than our characterisation allows a significant gain for the
detection of P2P traffic volume and we discuss performance of our detector. Finally, possible
improvements and suggestions for further work are proposed.
End of studies dissertation to achieve the grade of Engineer in Computer Sciences.
Under supervision of:
• Professor GUY LEDUC, Research Unit in Networking (RUN), University of Li`ege
• Mister
´
ERIC VYNCKE, Cisco Systems
CONTENTS
2
Contents
1 Introduction 4
1.1 What is peer-to-peer? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 P2P architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 Degree of centralisation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2 Network structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Some popular P2P systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.1 FastTrack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.2 Gnutella . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.3 DirectConnect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3.4 eDonkey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3.5 BitTorrent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3.6 WinMX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.4 Need for detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2 Measurement methodology 13
2.1 Active crawler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Content inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Introduction to NetFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.1 Data export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.2 Data collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.3 Data analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 NetFlow advantages and limitations . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.1 Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5 Choice of measurement methodology . . . . . . . . . . . . . . . . . . . . . . . 17
2.6 Characterising parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3 P2P behaviour characterisation 20
3.1 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.1.1 Host distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.1.2 Traffic volume distribution . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1.3 Traffic evolution over time . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1.4 Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.1.5 Host connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.1.6 Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1.7 Connection duration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1.8 Port numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2 Other considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.1 File swaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.2 Fast evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.3 Proprietary protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.4 Verification difficulty . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.5 Similarity with other protocols . . . . . . . . . . . . . . . . . . . . . . 26
3.3 Behaviour characterisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.1 Heterogeneity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
CONTENTS
3
3.3.2 Bias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.3 Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.4 Ideas to detect P2P traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.4.1 Using inequity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.4.2 Idle connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.4.3 Auto-learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.4.4 Negative approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4 eDonkey detection 31
4.1 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.1.1 Connection to server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.1.2 Connection with other peers . . . . . . . . . . . . . . . . . . . . . . . . 32
4.1.3 Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2 Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.1 Presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.2 Known peers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2.3 Suspect traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.4 Suspicion computation . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3 Performances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3.1 Testing methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3.2 Completeness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3.3 False positives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.3.4 Remark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3.5 Complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.4 Improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.4.1 Guarantee some known hosts . . . . . . . . . . . . . . . . . . . . . . . 44
4.4.2 Implementation tricks . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.4.3 Longer evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.4.4 More specific characterisation . . . . . . . . . . . . . . . . . . . . . . . 47
5 Conclusion 49
References 50
1 INTRODUCTION
4
The use of peer-to-peer (P2P) applications has grown dramatically in recent years. Due
to the bandwidth intensive nature and popularity of some P2P applications (especially file
sharing software), P2P traffic sometimes represents more than 50% of Internet traffic volume.
So, it became important for ISPs to detect these applications. As the TCP port numbers are
not fixed anymore, identification based on TCP gate is not possible. This brings the need for
a precise P2P traffic characterisation.
We will first present peer-to-peer systems and the implication they have on the underlying
network. We will next discuss some measurement methodologies that permit P2P behaviour
characterisation. Following this discussion, we will present results that were obtained either
by direct measurements or from earlier work and we will try to derive a P2P traffic char-
acterisation from these results. This behaviour characterisation is then refined and applied
for a case study: the eDonkey file sharing application. We will present the analyser we have
implemented for this protocol and discuss its performance.
1 Introduction
This section focus on definition of P2P concepts, description of P2P architectures and pre-
sentation of some popular P2P systems. We will also briefly mention why P2P detection is
necessary.
1.1 What is peer-to-peer?
The Peer-to-Peer Working Group (http://www.p2pwg.org), a consortium including Intel,
IBM, Hewlett-Packard and other industry leaders defines P2P as the “sharing of computer
resources by direct exchange”. These systems typically lack dedicated, centralised infrastruc-
ture. The peers contribute resources and participate to resource location. The organisation
of peers is mainly “flat-model”, each peer interacting directly with some other ones, without
implication of any central authority.
Another characteristic of most P2P systems is their self-organising capability. The topology
of the P2P network adapts dynamically as peers enter and leave the network, maintaining
connectivity, availability and performance.
Peer-to-peer applications are mainly designed and used for large-scale file sharing. In such
systems, end-users are allowed to easily search, obtain or contribute content. P2P systems
differ from the traditional client/server model because files are served in a distributed manner
and replicated among the network on demand. Since hosts participating in P2P networks also
devote some computing resources, such systems scale with the number of hosts in terms of
hardware, bandwidth and disc space.
Another application of P2P systems is for sharing other resources than data, and especially
computing resources. Distributed operating systems are for the moment rather experimental,
but grid computing becomes a common way to solve large problems such as brute-forcing an
RSA coded message or decoding human genome. Although grid computing existed prior to
P2P systems, combining P2P to grid computing allows additional flexibility and gives better
scaling properties in regard to older grid computing techniques.
In file sharing systems, typical files sizes range from 4 – 5 Mb (a song in MP3 format) to
剩余51页未读,继续阅读
资源推荐
资源评论
147 浏览量
192 浏览量
118 浏览量
133 浏览量
197 浏览量
2021-05-19 上传
2021-03-14 上传
156 浏览量
146 浏览量
2018-10-26 上传
194 浏览量
178 浏览量
135 浏览量
2014-04-01 上传
2021-02-28 上传
146 浏览量
165 浏览量
193 浏览量
2021-02-10 上传
200 浏览量
114 浏览量
2024-12-21 上传
174 浏览量
2013-05-30 上传
2021-06-25 上传
2017-09-27 上传
178 浏览量
资源评论
cssunq
- 粉丝: 0
- 资源: 5
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
最新资源
- 基于Flink商品实时推荐系统详细文档+全部资料.zip
- 基于flink流数据处理平台详细文档+全部资料.zip
- 基于flink实时流计算任务详细文档+全部资料.zip
- 基于Flink实现实时冰蝎(Behinder)流量检测详细文档+全部资料.zip
- 基于Flink实现的商品实时推荐系统、flink统计商品热度,放入redis缓存,分析日志信息,将画像标签和实时记录放入Hbase,根据用户画像重排序热度榜,并
- 基于flink统计实时ip热点统计详细文档+全部资料.zip
- 基于flink用户画像的基本代码详细文档+全部资料.zip
- 基于Flink用户埋点行为日志分析平台,项用户行为日志收集、存储、分析平台,支持用户自定义查询条件详细文档+全部资料.zip
- 基于flink最新的[FLIP-27]架构对MQTT connector的实现详细文档+全部资料.zip
- 基于Flink与Storm的流式计算详细文档+全部资料.zip
- 远卓—深圳庄维房产—庄维年度培训计划申请表1206.doc
- 远卓—深圳庄维房产—庄维培训实施申请表1206.doc
- 远卓—深圳庄维房产—庄维培训计划制定流程V0.95why1206.doc
- 远卓—深圳庄维房产—庄维年度培训计划申请表V0.95why1206.doc
- 远卓—深圳庄维房产—庄维培训计划制定流程1206.doc
- 远卓—深圳庄维房产—庄维员工培训制度1206.doc
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功