P2P文件分发简介

P2P出现的原因

在传统的 C/S 模式中，如果服务端需要向客户端分发一个大文件，就会出现一个服务器向大量主机（称为对等发）分发一个大文件的情况，也就是说服务器必须向每个对等发发送该文件的一个副本，这样导致了服务器承受了极大的负担，并且消耗了大量的服务器宽带。而为了减轻服务端和网络的压力，就出现了P2P文件分发的概念，所谓P2P文件发放的含义就是让成对的间歇连接的主机都参与分发文件的队列中，这将大大减少服务器和网络宽带的压力，而不仅仅向传统的C/S模式一样只有一个服务端在分发文件。我们经常使用的迅雷下载就是符合P2P文件分发系统的一种应用模式。

P2P体系结构的拓展性

下图中 us 表示服务器接入链路的上载速率， ui表示第 i 对等发接入链路的上载速率，di 表示第 i对等方接入链路的下载速率。F表示被分发的文件长度（以比特计），N表示要获得的该文
件副本的对等方的数量。分发时间（distribution time）是所有N个对等方得到该文件的副本所需要的时间。

C/S系统结构

P2P体系结构

下图是比较权威的数据。分析可知P2P模式在无论N为何值的时候最小分发时间都要小于C/S模式，并且随着文件越来越大，P2P模式的最小分发时间的上升幅度越来越小。

导致这种数据情况的原因也很明显，就是每个参与到文件分发队列的主机都能帮助服务器分发文件，当一个对等方接收到某些文件时，它能够使用自己的上载能力重新将文件数据分发给其它的对等方，这样就无需服务器发送多个一模一样的文件数据副本。

注意： 在P2P体系中，被分发的不是一整个文件也不是一个比特，而是以文件块为单位的。

BitTorrent协议

BitTorrent协议简介

BitTorrent是目前最流行的P2P协议，用BitTorrent的术语来说，参与一个特定文件分发的所有对等方的集合称为一个洪流，在一个洪流中的对等方彼此下载等长度的文件块，典型的块长度是256KB。当一个对等方参与到洪流时，它没有块，随着时间的推长，它从其它对等方下载了块，并且也可能为其它对等方上载了块。一旦该等对方获得了整个文件的全部块，它可能会自私的离开洪流，也可能会大公无私的为其它对等方上载块。BitTorrent是一个相当复杂的协议，一个洪流可能具有数以百计或者千记的对等方。在BitTorrent中每个洪流具有一个基础设施节点，称为追踪器。当一个对等方加入到洪流中，需要先向追踪器注册自己，并周期性的通知追踪器它是否还在洪流中，追踪器也是以这种方式跟踪参与到洪流中的对等方。

BitTorrent协议原理简介

BitTorrent的协议比较复杂，这里通过一个简单的例子简单了解一下：

请求机制

当一个新的对等方Alice加入到洪流时，追踪器随机的从参与对等方地集合中选择对等方的一个子集（假设50个），这50个子集的 ip 将发送给Alice，Alice持有对等方的列表，试图与列表上的所有对等方创建并行的TCP连接，而成功创建连接的对等方被称为“邻近对等方”，图中显示Alice具有3个邻近对等方。在任何给定的时间，每个对等方将具有来自这个文件的子集，并且不同的对等方具有不同的子集。Alice周期性的访问每个邻近对等方它们所具有的块列表，在这些列表中如果发现自己没有的块，就会发起下载请求。但是，Alice可能有多个邻近对等方，也可能有多个缺少的块。Alice需要使用最稀缺优先方案：针对Alice没有的块在邻近对等方中决定最稀缺的块，也就是所有邻近对等方中副本最少的块，并且首先请求最稀缺的块。这样最稀缺的块就能更加迅速地被重新分发，可以均衡每个块在洪流中的副本数量。

响应机制

在这么多邻近对等方的请求中，BitTorrent使用了对换算法进行响应的选择。其基本思想：Alice根据当前能够以最高速率向它提供数据的邻居，给出其4个优先权，每过10s就会重新计算这4个优先权，用专业术语来说就是疏通。重要的是，每过30s，Alice就要随机选择另一位邻居Bob并向其发送块，如果Bob对Alice的发送速率足够高的话就可能成为Alice的优先权，换而言之，Alice每过30s就随机选择一名新的对换伴侣并开始与那位对换伴侣进行对换，如果二者都满足彼此，则将对方放入前四位优先权，直到发现一个更好的伴侣，这种机制就是为了让对等方以趋向找到彼此的协调的速率上载。

视频流和内容分发网

因特网视频

视频是由一系列的图像以一种恒定的速率（如每秒24张图像）来展现，而一幅未压缩、数字编码的图像由像素阵列组成，其中每个像素都是由一些比特编码来表示亮度和颜色。视频的一个重要特征就是能够被压缩，因而可用比特率来权衡视频质量。在HTTP流中，视频只是存储在HTTP服务器中的一个普通的文件，每个文件具有一个特定的URL，但HTTP流所有客户接受到的视频编码版本相同，也就是比特率相同，显然并没有考虑用户带宽的问题。因此，为了解决固定编码和网络宽带之间的矛盾，就出现了经HTTP的动态适应流，即DASH。在DASH流中，将视频编码成几个不同的版本，每个版本具有不同的比特率，每一个版本都拥有属于自己的URL，DASH初始时根据用户带宽自定义选择一个版本的视频，并且允许用户更改版本。使用DASH后，每个视频版本存储在HTTP服务器中，每个版本都有一个不同的URL，而HTTP服务器也会有一个告示版本的文件，客户端可以根据自身网络情况选择切换版本。

内容分发网-CDN

CDN的概念

在网络中，如果建立大型单一的大规模数据中心存储所有视频并且直接传输给用户存在三个问题：

• 客户远离数据中心时，服务器到客户之间的其中一个通信链路提供的吞吐量如果小于视频消耗速率，则有强大的停滞时延
• 流行的视频可能经过相同的链路发送很多次，既浪费宽带，又需向ISP支付更多费用
• 单个数据中心可能发生单点故障

因此，为了应对分布于全世界的用户分发巨量视频数据的挑战，几乎所有的视频流公司都会使用内容分发网，即CDN。CDN管理分布在多个地理位置上的服务器，在它的服务器中存储视频文件的副本，并且所有试图将每个用户请求定向到一个将提供最好用户体验的CDN位置。

CDN两种服务器安置原则

• 深入：由Akamai首创，通过在遍及全球的接入ISP中部署服务器集群来深入到ISP的接入网中。目的是靠近端用户，通过减少端用户和CDN集群之间链路和路由器的数量，从而改善用户感受的时延和吞吐量，但是这是一种高度分布式设计，维护和管理集群困难。
• 邀请做客：由Limelight和其它CDN公司采用，通过在少量关键位置建造大集群来邀请ISP做客，而不是将集群放在接入ISP中，这些CDN通常将它们的集群放置在因特网交换点，产生较低的维护和管理开销，有可能以对端用户的较高时延和较低吞吐量为代价。

很多CDN没有将视频推入集群，而是通过一种简单的拉策略：如果客户向未存储该视频的集群请求视频，该集群从某种新仓库或另一个集群检索该视频，向客户发送的同时存储副本到本地。存储器满时，删除不经常使用的视频，这个拉策略和因特网缓存与分页机制很像。

CDN操作

当用户主机中的一个浏览器请求一个视频（URL标识）时，CDN必须截获该请求，并确定此时适合用于该用户的CDN服务器集群，将客户的请求重定向到该集群的某台服务器。其主要的步骤：

• 用户访问视频网站
• 用户点击视频链接，发送DNS请求
• 用户本地DNS服务器（LDNS）将该请求中继到一台用于域名的权威DNS服务器，该权威CDN服务器返回CDN域的主机名
• 用户本地DNS服务器向该主机名发起第二个请求，CDN服务器的DNS返回CDN内容服务器的IP响应
• 用户本地DNS服务器向用户主机转发IP地址
• 建立TCP连接并发出HTTP GET请求
• CDN响应