P2P


P2P(Peer to Peer):点对点通信或称为对等联网。每个用户既下载数据，又作为服务器存储数据

并供其他用户下载。他的本质，是一种硬盘的共享，是把每个人电脑上的一部分硬盘，拿出来与其他人共享。

1999年互联网界非常著名的一个创业者，他的名字叫Shawn Fanning。他创立了一个叫

Napster的mp3音乐分享网站，他通过将每个人电脑上的mp3汇集成一张目录，当有人想下载mp3时，

那么Napster就会找到那些有这个mp3的电脑，同时去从这些电脑中下载一个个小小的碎片，然后在你的电脑上

拼成这个mp3。所以Napster本身并不拥有MP3，他只是帮助那些拥有mp3的人互相分享，我们把这个

叫做点对点的分享。

P2P可以是一种通信模式、一种逻辑网络模型、一种技术、甚至一种理念。在P2P网络中，

所有通信节点的地位都是对等的，每个节点都扮演着客户机和服务器双重角色，节点之间通过直接通信实现

文件信息、处理器运算能力、存储空间等资源的共享。P2P网络具有分散性、可扩展性、健壮性等特点，

这使得P2P技术在信息共享、即时通讯、协同工作、分布式计算、网络存储等领域都有广阔的应用。

传统的CS模型:


p2p模型:


说到P2P我的第一印象就是迅雷。

迅雷就是做P2P下载的，它的逻辑是把电影文件，放到每个不同的电脑上，然后彼此分享，这个模式极

大地节省了资源。它将整个文件虚拟等份拆分→制作bt种子，记录等分文件信息及追踪信息→用户获取种子→

下载工具解析文件信息并追踪拥有分块文件的用户地址→发起连接→同时从多个用户计算机直接下载分块

文件（无需再上传至服务器）

迅雷将P2P技术优势发扬光大，并加以改进推出P2SP（存储资源至迅雷自己的服务器，P2P下载的同时还解析HTTP的下载链接）；

当年大型网络游戏在国内的井喷式发展吸引了大量玩家，而安装文件动辄几个GB，还不到100kb/s的HTTP下

载速度实在无法满足用户需求。迅雷为用户提供高速稳定的下载体验，快速占领下载工具市场；2004年，迅雷超越

传统HTTP/FTP下载工具龙头——网际快车，成为市场第一。其实网际快车和比特彗星的没落也与网络游戏有关，

创始人由于沉迷于魔兽世界，停更软件长达一年。

2006年用户数量破亿，迅雷积累大量P2P用户，用户越多资源越多，下载速度越快，由此迅雷在下载工具市场的地位

变得无法撼动。

- 版权问题

P2P传输是用户间直接共享，不向版权方支付任何费用。版权方起诉下载用户不现实，转而起诉P2P下载工具。

2011年-2014年一季度，迅雷涉及版权的诉讼达366起。版权及诉讼问题影响公司自身发展。虽然迅雷只输了3起官司

，赔偿5.6万人民币，但确实为用户盗版提供了帮助。迅雷曾经因版权问题受到美国电影协会质疑而影响IPO进程。

- 监管与安全

数据传输完全不需要中心服务器使得P2P传输缺乏监管，色情暴力、敏感政治等无法从正规渠道获取的非法内容，

却可以通过私下分享种子文件传播。无法确定下载内容是否包含病毒程序。

- 传输速度

上行带宽影响下行带宽：P2P用户需要作为服务器为其他用户提供下载服务。用户打开迅雷即便自身

不下载任何数据也会影响网速，因此迅雷一度被称为“吸血迅雷”，在大学寝室开迅雷的童鞋也常常被室友揪出来批斗。

因为整个互联网的基础设施是非对称型的，下行特别快，上行会窄一点。P2P场景虽然把上行带宽用起来了，

但是最终对社会的成本是比较高的。P2P虽然用户节点多，但数据传输较为无序，算法有优化空间。

随着互联网信息量暴增，尤其是视频格式从avi/rmvb发展到mkv，用户对视屏分辨率的要求越来越高，

一部蓝光高清电影有可能达到十几GB，即便P2P传输也压力山大。

- 丧失资源优势，用户流失

- 盗版资源：

迅雷为融资及业务发展解决了版权的问题，包括字幕组在内的盗版资源转战虚拟网盘

（以前都是要迅雷种子/磁链，现在流行百度云盘）

- 色情暴力：

2014年扫黄打黑办公室开展净网行动，典型事件是快播CEO王欣的入狱，时至今日涉及色情、暴利、政治

敏感的资源很难再从迅雷获取。

完美契合迅雷的技术优势与互联网趋势，成为最佳的转型方向。

点播业务峰值是相对均衡的，它已经通过各家CDN在功能、性能、稳定性以及响应度各种努力，把它做到了一秒

的延时、秒开、高质量、低卡顿。但直播业务的峰值时不时出现巨量增长，且往往并发非常高，也就两个小时。

这会带来高额的带宽成本。在此基础上若引入P2P结合CDN，可降低整体产品的使用成本。

传统的P2P架构已经老化，就是早期的迅雷以及在快播做的P2SP架构。其最大的场景，是PC上的分布式网络。

而现在机顶盒、路由器、手机等所有设备都已经自动化，以前PC的这套网络已经落后，亟待革新。

传统P2P的最大特点就是高分享率、但低可用性。比如说原来在快播做的数据分享率可以做到99%，

但质量是无法保障的。而CDN+P2P是把CDN的高可用性、可管理、可运维去和P2P的加速性、可靠性以及突发

处理能力做一个有机结合，在网络层面提高系统的可扩展性，降低成本，降低跨域、跨流量的问题。

2015年6月，迅雷全资子公司网心科技推出星域CDN，正式布局P2PCDN业务。P2PCDN与传统CDN或云CDN模式

的区别在于，服务器不再由厂商自建而是P2P用户自己提供或购买设备，带宽从P2P用户端低价收购。

CDN成本大幅降低（服务器成本，带宽采购成本），服务器规模理论上无限多且容易扩展（多卖一台设备就多一个P2P服务器）。

从官方透露的信息来看，星域CDN业务受到视频直播领域客户的广泛认可。爱奇艺、快手都是星域CDN的客户，采购量有所增加。

星域CDN也与小米、熊猫、陌陌、bilibili和触手等用户保持密切合作。

但在成本方面：迅雷节省的成本越多，用户可得收益越少。对迅雷而言，CDN服务利润=给客户提供的

带宽售价-从用户收来的带宽成本-自身服务器的架设成本。对用户而言，分享带宽的动机=迅雷收集闲置带宽所

给予的收益-硬件购置与损耗成本-电费成本-网络成本（注：一般用户的网络实际上是成本略低的家用网络，

若将其用于商业用途，或违反与电信商签署的宽带协议）。

需要注意的是，一旦参与迅雷CDN计划的用户减少，迅雷CDN市场占有率也会降低。所以，

给予用户足够的动机显得至关重要。

为了刺激用户的分享热情，迅雷开启了一系列的计划。其中最有名的是玩客云

1. 迅雷水晶

将用户PC直接作为服务器，用户贡献上行带宽，所得奖励为迅雷水晶，迅雷水晶可兑换人民币。问题：

硬件损耗大，耗电量高，影响网速。

2. 赚钱宝+IDC专属项目

2014年腾讯云计算总裁陈磊加入迅雷任CTO，合作迅雷云计算业务。2015年4月推出二代P2PCDN计划：赚钱宝。

赚钱宝是独立的硬件设备，由玩家购买作为服务器。玩家贡献上行带宽，所得奖励为迅雷水晶，10000水晶=1人民币。

IDC专属针对的是闲置机房/个人网管。解决了上一代的问题：赚钱宝较PC功率小，耗电量低；

作为独立硬件贡献闲置带宽，网速影响小。

3. 玩客云

玩客云与赚钱宝的运作模式类似，用户购买玩客云设备，贡献带宽与储存，按照一定规则获取玩客币。

唯一的不同之处就在于赚钱宝给人民币，玩客云给玩客币。

扯远了，这里回来继续说P2P。

常见流媒体直播协议都属于C/S型，即所有客户端通过指定协议，从服务端获取直播数据。当客户端数量达到

一定规模后，服务端将承受巨大的I/O和带宽压力。若服务器无法及时处理客户请求，客户端卡播率急剧上升，

从而影响用户观看体验。

直播P2P技术，简单来说，就是客户端之间使用一定协议，交换和共享直播数据，通过减少对服务器的数据请求，

来降低服务端的I/O带宽等方面压力，从而削减服务器带宽成本，降低客户端卡播率。

鉴于通用性与效率，一般很少从底层开始设计一套全新的流媒体直播P2P协议。惯用做法是基于通用协议，

实现客户端的P2P网络。对基于HTTP的流媒体协议，如HLS，MPEG-DASH等，重写客户端数据下载逻辑即可；

对非HTTP的流媒体协议实现P2P，如RTMP，RTSP，需要一套切片服务器，切片服务器负责持续地将数据流切成

一个个数据片段（类似HLS的TS文件），客户端在P2P网络基础上进行数据片段的下载和交换共享。

设计直播P2P协议，通常关注两个要素：客户端延迟，P2P分享率。客户端延迟是指客户端播放到的最新数据时间

戳与服务器最新产生的数据时间戳的差值，P2P分享率是指客户端从P2P网络获取的数据量与客户端完整观

看所需的数据量的比值。

- 邮箱 ：charon.chui@gmail.com

- Good Luck!

SurfaceView就是在Window上挖一个洞，它就是显示在这个洞里，其他的View是显示在Window上，所以View可以显式在 SurfaceView之上，你也可以添加一些层在SurfaceView之上。

if (mWindow == null) { ß

mWindow = new MyWindow(this);

mLayout.type = mWindowType;

mLayout.gravity = Gravity.LEFT|Gravity.TOP;

mSession.addWithoutInputChannel(mWindow, mWindow.mSeq, mLayout,

mVisible ? VISIBLE : GONE, mContentInsets);

}

很明显，每个`SurfaceView`创建的时候都会创建一个`MyWindow`，`new MyWindow(this)`中的`this`正是`SurfaceView`自身，因此将`SurfaceView`和`window`绑定在一起，而前面提到过每个`window`对应一个`Surface`，

所以`SurfaceView`也就内嵌了一个自己的`Surface`，可以认为`SurfaceView`是来控制`Surface`的位置和尺寸。传统`View`及其派生类的更新只能在`UI`线程，然而`UI`线程还同时处理其他交互逻辑，

这就无法保证`view`更新的速度和帧率了，而`SurfaceView`可以用独立的线程来进行绘制，因此可以提供更高的帧率，例如游戏，摄像头取景等场景就比较适合用`SurfaceView`来实现。

**`SurfaceView`的核心在于提供了两个线程：`UI`线程和渲染线程**,两个线程通过“双缓冲”机制来达到高效的界面适时更新。而这个双缓冲可以理解为，SurfaceView在更新视图时用到了两张Canvas，一张frontCanvas和一张backCanvas。每次实际显示的是frontCanvas，backCanvas存储的是上一次更改前的视图，当使用lockCanvas（）获取画布时，得到的实际上是backCanvas而不是正在显示的frontCanvas，之后你在获取到的backCanvas上绘制新视图，再unlockCanvasAndPost（canvas）此视图，那么上传的这张canvas将替换原来的frontCanvas作为新的frontCanvas，原来的frontCanvas将切换到后台作为backCanvas。例如，如果你已经先后两次绘制了视图A和B，那么你再调用lockCanvas（）获取视图，获得的将是A而不是正在显示的B，之后你将重绘的C视图上传，那么C将取代B作为新的frontCanvas显示在SurfaceView上，原来的B则转换为backCanvas。()

不用画布，直接在窗口上进行绘图叫做无缓冲绘图。用了一个画布，将所有内容都先画到画布上，在整体绘制到窗口上，就该叫做单缓冲绘图，那个画布就是一个缓冲区。用了两个画布，一个进行临时的绘图，一个进行最终的绘图，这样就叫做双缓冲。)