P2P流媒体直播点播(带宽节约95%以上)技术分享

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

介绍

从2011年接触P2P技术至今，接触过比较多类型的P2P技术，开发过多个不同的应用场景的商用P2P技术方案。这篇文章主要介绍是相对新一点的PCDN技术（CDN + P2P），该方案从4年前概念还比较新的时候由于产品需要开始开发，现在已经在公司商用项目使用了3年左右，前后也经历过修修补补，大小调整等，现节约率、稳定性、简单性也都达预期，故写下本篇文章，一来为有这方面开发需求的同学提供一点帮助，另一方面作为自己的文章归档。

为什么需要CDN + P2P这种方案，历史背景是由于当时公司直播和点播资源均是在第三方CDN上，不便于自建直播点播分发，基于成本和各方面考虑，继续使用第三方CDN的前提下，实现P2P功能来降低公司运营成本，用户量很大，CDN成本还是非常恐怖，CDN具体使用的哪家就不多说了，常规的CDN厂家原理和标准基本都差不多，直播点播领域通常为nginx-rtmp或srs或完全从头开发，CDN系统不是本文的重点，不做剖析和赘述。直播我们使用的是HLS协议，点播是通用的标准http协议的点播和下载，P2P系统部分也就是匹配标准http协议来实现。

需求分析

实现一套标准HTTP协议的P2P系统，以提供标准协议的直播/点播/下载应用场景，容量设计范围为数千到千万级用户同时在线的支持能力。
实现服务器横向扩容升级及对节目增长、用户增长进行自动平滑迁移。
轻量级且支持跨平台(windows/linux)部署的稳定服务架构，简化的部署运维方式以降低系统的使用维护成本。
超轻量级的客户端SDK架构，支持主流系统平台(windows/linux/android/ios),最小化SDK体积（<1MB）,最小化的资源消耗以满足移动端为主流的使用场景。
实现主流直播点播码率(<=5Mbps)下的持续P2P高性能，同时具备超高清4K（或>=10Mbps）码率的适应能力。
全量支持标准HTTP协议簇，支持HLS直播，支持HTTP-主流视频格式(.mp4/.flv/.avi/.mkv/.wma/.afs等)的点播或HTTP-任意格式文件的下载。
实现各类Cone类型的NAT穿透能力以适应不同运营商复杂的网络环境与多元的网络设备，夯实高效P2P分享的基础。
实现分享能力范围50%-95%（视具体场景），以降低带宽流量成本，支持公网-公网、公网-内网、内网-内网，等网络场景下的高效P2P。
实现P2P系统的一键化部署与可视化的管理与配置。
实现P2P详尽统计功能(分享率，在线人数，带宽流量等)，提供不同粒度组合(如时间范围，直播/点播/下载，不同系统平台等)的统计，并进行可视化展示。
实现系统内部动态防盗链。实现P2P系统黑名单防御。

提一下系统容量范围，这个范围当时也是为了匹配公司的产品而制定，后产品更新上线，并发能力也得到了确认，现在场景是400-500万日活，70万峰值并发，完全无压力。下面表是结合实际并又经过压力测试得出的值。实际上根据需求，各个服务可以再加设备做扩容等，容量可以说并没有具体的理论上限，这个做系统开发的朋友应该能理解。不过在软件领域给不懂技术的领导不能这么说，领导会认为总有个上限，宇宙都有大小，你给我个上限 -_- !

系统模块	名称	容量	容量单位	进程/设备	最大容量
Auth-Server	授权服务器	略	略	略	略
Control-Server	控制服务器	>1,000,000	活跃终端/进程	=1	>10,000,000
Nat-Server	Nat服务器	>10,000	活跃终端/进程	<20	>10,000,000
Peer	客户端SDK	=1	活跃终端/进程	<10	<10

术语定义

名称	缩写	描述
P2P	P2P	全称对等网络Peer-to-Peer Network
HTTP	HTTP	全称 HyperText Transfer Protocol, 超文本传输协议
Control-Server	CS	全称 P2P系统 - 总控制服务器
Nat-Server	NS	全称 P2P系统 - Nat穿透与Peer管理服务器
Peer	PR	全称 P2P系统 - SDK (既持有数据的本地HTTP代理)
Auth-Server	AS	全称 P2P系统 - 授权管理服务器
DataTransProtocl	DTP	全称 P2P系统 - 基于udp的数据传输协议
Client	CT	全称客户端，(如播放器,下载器)
MYSQL	DB	全称第三方开源数据库
IPServer	IS	全称自建/第三方全球精确IP库服务
DNS	DNS	全称第三方域名解析服务
WebSocket	WS	全称 TCP全双工通信协议
CDN	CDN	全称 Content Delivery Network, 第三方内容分发网络
Source	SRC	全称 HTTP源站

整体设计

系统内部主要是有以下几个服务构成

1. Auth-Server(AS)授权服务器：主要是用于对整个系统授权，目的是防止系统被拷贝，不能取得授权将无法使用系统，毕竟属于内部技术，部署到服务器上还是要注意安全。

2.Control-Server(CS)控制服务器：主要是对整个系统进行全局控制，对整个系统的做负载管理、各种设置，统计、防御等。搭配了一个mysql数据库，实际上也没有特别复杂数据的存取，也可以自己设计数据结构或者采用json等代替。减少对数据库存取的依赖才能够提高并发，将常用的数据内容加载到内存中，比如频繁的调度请求需要的数据内容动态加载到内存。

3.Nat-Server(NS)穿透服务器：主要是用于peer之间协助穿透，还有就是保存各个peer的基本信息，用于种子选择。做过nat穿透的同学应该知道nat穿透这个东西，只是我们并没有采用第三方的开源服务，因为原理不难，所以自己实现有利于调试和改动的方便。

4.Peer客户端代理：也就是SDK，客户端的http代理，所有http服务都通过Peer代理，这样Peer可以在代理过程中获取到切片数据并使用这些切片数据与其他Peer之间进行P2P数据分享。

5.第三方的IP库：这个服务是为了给客户端匹配ISP信息，准确的ISP信息利于对端Peer节点的选择从而提高分享效率，也可以自己借助网上的一些ip信息表来搭建isp信息服务，不过由于isp信息更新很频繁，可以采用第三方的服务来支撑。

技术点分析

轻量简单：由于整个系统由于不需要进行直播或者点播的内容分发（CDN的工作），仅仅只需要管理所有peer点的状态，穿透，数据分享，统计等，所以系统非常轻量级，对设备性能和带宽要求也非常低，部署简单，常规就2种（CS,NS）服务需要部署，我们是将服务直接打包到docker，非常简单快捷，秒秒钟部署完成，系统符合希望的轻量高效且部署简单的原则。

关于穿透：穿透实际上是一个课题，感兴趣的朋友去看看其他相关资料，这方面资料非常多，适合扫盲，由于这方面资料也比较基础，在实际应用中还有很多需要处理的细则，建议可以去看看开源的穿透库来补充学习。我提下需要注意的内容：

1. 注意保活，穿透成功以后互相通过一个心跳包保活，最好不要超过10s比较安全，不同路由器关闭nat映射的时间不同。

2. 很多基础资料会介绍圆锥型，限制锥形，端口限制锥形，对称性等几种不同类型的路由设备，大多数将对称型单独介绍，其他3种归为一种，穿透方式也一样，但实际上端口限制锥形的是需要特别处理的，而且端口限制的路由设备最多。处理具体办法是去参考一下linux系统的iptables相关知识，路由器实际上也是linux系统。概括起来就是互相发送穿透包之前要首先互发一次ttl包，该包不要发送到对方路由器上，仅发送到自己路由器上，给自己路由器留下一个nat映射即可，因为一旦发送到对方路由器上，就会导致对方路由器不认识该包来源而丢弃并且后续会跳变端口。

3. 对称性的穿透无非就是预测端口，但经过实际验证，预测成功的可能性很低，索性直接放弃这部分穿透，因为穿透率并不是影响分享率的第一要素。大部分4g都是对称性，基本直接放弃穿透。

切片方式: 直播是HLS，本就是TS切片文件，但切片文件太大，非常不利于网络传输，甚至根本无法传输，所以ts切片还要进行再次切片，大小不要超过1k，超过1k的大小的数据包udp传输丢包大大提高，有的网络甚至根本收不到，推荐188*5=940 个byte为一个切片包。点播切片也一样，可以采用1k大小来切片，点播文件大小都能通过http协议中获得，需要注意的是点播需要照顾不同文件的点播方式，拖动seek等，可以通过抓包来分析播放器播放不同文件或拖动时候的行为，匹配上即可。

数据分享：Peer之间采用的是udp传输方式，udp自然牵涉丢包，所以需要设计超时重传，数据在安全区的时候可以通过重传方式来反复完整缺失的数据包，注意，重传的频率要控制，过于频繁会导致网络过多小包，过于松散，会导致丢包难以得到有效补充。一旦数据进入紧急区即将用于播放，还未P2P完整，立即回源完整数据。注意，回源完整数据需控制回源的频率，回源过多会增加CDN的链接负担，我们是采用多个连续缺失的数据切片合并为一个请求。

高并发：服务高并发这方面是个课题，就无法做详细的概述，首先是程序上尽量单程序支撑较高的并发，如内部数据结构设计和查询算法等的设计等，还有对锁的控制也很重要，尽量少锁无锁，必须用锁的地方也尽量用读写锁。开发语言也可以选择原生利于高并发的开发语言，例如golang。

技术栈选择

这部分还是要根据公司或者个人技术储备来选择，我们在开发该系统过程中技术栈选型如下：

服务部分 golang

SDK部分 c++11

服务部分照顾跨平台和高并发，选择的golang这个没有什么过多需要说的。SDK要兼容不同平台上面使用，且要体积小，性能高，所以采用的是纯C++11编写，建议尽量不要使用第三方的库，一个是这种底层开发本就追求绝对掌控，很多第三方库着实坑不少，常见的ace boost libevent 以往使用过程中均碰到过大大小小不同的坑，且跨平台编译也要处理很多乱七八糟的问题。后对于底层都倾向原生开发，再一个，第三方库过多会撑大最终SDK的体积。

其他内容

实际上商用系统牵涉的方面还是比较多，比如系统的高可用，容灾等，这些只需要开发时候要留足这些功能，往后运维人员便能进行这方面的部署和优化。本文仅一点简述，仅提供我个人一点经验和参考，但愿对你有所帮助，更多深入和详尽的细节也可以加QQ一起探讨和学习，P2P技术一直在发展，共同交流共同学习共同进步。

P2P流媒体直播点播(带宽节约95%以上)相关推荐

P2P流媒体直播点播(带宽节约95%以上)技术分享
作者:key zhou QQ:215420465 邮箱:215420465@qq.com 欢迎交流,共同进步. -------------------------------------------- ...
VIEWGOOD（远古）P2P流媒体直播系统的设计与实现
近年来,Internet上的流媒体应用得到了迅猛发展.如何实现一个经济.高效的流媒体通信传输系统已成为流媒体服务系统的核心问题.传统的分布式多媒体系统主要使用C/S模式,服务器以单播的方式和每个客户建 ...
P2p流媒体直播与视频会议有什么不同？
视频直播,是对视频源的实时的观看,用比较直白的话就是我播你看,我播哪你看哪.视频直播系统实现三种形式的直播:第一种现场活动.会议的实时直播.通过摄像机,采集设备将现场的活动采集成数据流传给直播软件,直 ...
收藏：视频网站（JavaEE+FFmpeg）/Nginx+ffmpeg实现流媒体直播点播系统
FFmpeg安装(windows环境)http://www.cnblogs.com/xiezhidong/p/6924775.html 最简单的视频网站(JavaEE+FFmpeg)http://bl ...
P2P流媒体直播的疑问
笔者在读研究生,课题集中在P2P流媒体直播,但是课题组以及学校以前并没有该课题的实践及有价值的理论基础,所以,我是瞎子摸石头过河呀!浏览了很多相关论文,但是还存在很多的疑问.自己也知道,最好的方法是自 ...
基于p2p点播html5源码,毕业论文-基于HTML5的P2P流媒体传输系统的设计与实现.docx...
PAGE 单位代码学号分类号毕业设计(论文) 基于HTML5的P2P流媒体传输技术的设计与实现院(系)名称专业名称计算机科学与技术学生姓名指导教师 2014年6月北京航空航天大学毕 ...
几种P2P流媒体开源项目介绍
P2P流媒体开源项目介绍 1. PeerCast 2002年成立,最早的开源P2P流媒体项目.PeerCast把节点按树结构组织起来, 每个频道都是一个树, 直播源是根节点,父节点只给子节点提供数据. ...
P2P流媒体开源项目介绍
P2P流媒体开源项目介绍 1. PeerCast 2002年成立,最早的开源P2P流媒体项目.PeerCast把节点按树结构组织起来, 每个频道都是一个树, 直播源是根节点,父节点只给子节点提供数据. ...
P2P流媒体技术原理及应用
作者:王洪波,马轶慧英文关键字:P2P network; streaming media; scalability; data-driven 关键字:对等网络:流媒体:可扩展性:数据驱动摘要:基于 ...

P2P流媒体直播点播(带宽节约95%以上)