zoukankan      html  css  js  c++  java
  • 直播P2P技术1-技术入门

     

    1. 直播协议

    直播协议主要有RTMP,HLS,MPEG-DASH,RTSP,HTTP-FLV等。每种协议都各有长短,比如RTMP延迟低,但诞生于Adobe,依赖于Flash Player,在如今FLash Player面临被淘汰的时代,RTMP前途未卜;HLS是苹果基于HTTP开发并主导的流媒体协议,它充分利用了HTTP的通用性,并能根据带宽自适应码率,但单个TS文件duration过大(一般为10s),延迟较高;MPEG-DASH类似于HLS,也是基于HTTP的,不同点是DASH单个片段duration灵活可变(如小至3s),且是开发性的流媒体协议,使其得到很多厂商的大力支持。

    2. P2P技术

    P2P技术是分布式系统的应用之一,通常表现为客户端之间直接进行数据交换共享。在P2P过程中,所有客户端的活动形成了一张逻辑上的虚拟网络,该网络结构被称为P2P模型的网络拓扑。一般网络拓扑结构有三种:完全网状,树状,基于DHT的环状,分别如下图1,2,3所示: 

    P2P技术可用于文件共享,流媒体,点对点通信等,如常见的迅雷,视频网站的P2P插件。

    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网络获取的数据量与客户端完整观看所需的数据量的比值。

    为了方便下面讨论的不同模型优缺点,作如下定义:

    • 跳数:一个数据块传输过程中经过的节点数
    • 控制请求:所有非实际数据块传输的请求
    • 数据请求:一次实际数据块的传输请求
    • Tc:一次控制请求的传输时间
    • Td:一次数据请求的传输时间
    • T:一个数据块从一个节点到另一个节点的总时间
    • Tn:一个数据块经过n跳到达另一个节点的总时间
    • B:直播码率
    • Bu:节点上行带宽
    • Bd:节点下行带宽
    3.1 基于网状拓扑的直播P2P

    网状拓扑模型,也称PULL模型,结构如上图1. 所示。此模型中网络节点完全对等,数据流动完全随机无序。节点对等,是指数据可以在节点之间双向流动,随机无序是指节点之间交换的所有数据的序列关系是随机无序的。节点之间交换数据一般由3子过程组成(如下图4.所示):向对方发送自己数据的bitmap,对比双方bitmap来决定从对方请求哪些数据块并发送请求,发送实际数据块给对方。

    注:bitmap是一个bit数组,每一个bit位唯一标识了一个数据块的有无

    PULL模型的优点是每个节点都参与数据的下载和上传过程,最大利用了节点的资源和计算能力。假设每个节点随机下载的数据量比例为R(R < 1),则理想情况下,单个节点Bu,Bd满足Bd>=R*B/8; Bu>=(R/(1-R))*B/8

    然而缺点也很明显:延迟高。假设从发送bitmap到接收bitmap请求的时间为Tc,发送数据获取请求到接受数据获取请求的时间为Tc,完全发送一个数据块到接受一个数据块的时间为Td,那么一块数据的单跳传输的时间T,必有T>2*Tc+Td。若一块数据经过n个节点,到达另外一个节点,那么数据块到达最后一个节点的时间Tn,必有Tn>nT=2n*Tc+n*Td

    PULL模型的特点,使其适合应用在延迟较高的直播P2P网络中,而不适合于延迟要求较低的场景。

    3.2 基于树状拓扑的直播P2P

    树状拓扑模型,也称PUSH模型,结构如图2. 所示。父节点相比子节点延迟低,下载速率块,上行带宽大。一旦两个节点通过订阅协议形成父子关系,父节点可以立即持续地向子节点推送数据。一个完整的过程如下图5. 所示:

    由于一次订阅后,父节点可持续地立即地推送数据给子节点,整个过程快速高效。单跳数据的到达时间T,有T~=Td, n跳数据达到的整体时间Tn,Tn~=n*T

    PUSH模型形成的网络并不是一个对等的P2P网络,数据流动只能从父节点到子节点。这样关系直接导致顶层节点P2P上行负载大,非顶层节点未参与P2P下行过程,底层节点(叶子节点)既未参与P2P下行,也未参与P2P上行过程。实际生产环境中,用户上行带宽往往是受限制的,即使通过完美算法,使上、下行能力不同的节点,演化到树中合适的一个位置,也无法弥补压力集中在少部分非叶子节点上的天生弱点。假设直播的数据码率为B,对于1-N树状模型(指一个父亲点最多可以有N个子节点)而言,非叶子节点的上行带宽Bu,必须满足Bu>=N*B/8,下行带宽Bd,必须满足Bd>=B/8,若B成倍增长,对应的Bu,Bd也将成倍增长。当实际Bd,Bu无法满足要求时,整棵树将坍塌。

    所以基于树状拓扑的模型是一个较理想的网络拓扑模型,适合于低码率的直播P2P网络,而不适合码率较高的直播场景。

    3.3 基于一致哈希的环状拓扑直播P2P
  • 相关阅读:
    Redis基础知识补充及持久化、备份介绍
    Redis基础认识及常用命令使用
    Docker实战(7):Docker无日志(无*-json.log文件)
    Linux实战(11):Centos安装Jenkins
    Linux实战(13):Centos8 同步时间
    Docker实战(6): 导出docker镜像离线包
    Linux实战(13):Centos8安装FFmpeg
    Linux实战(12):解决Centos7 docker 无法自动补全
    Linux实战(11):Centos后期添加网卡配置
    Linux实战(11):配置PPPOE拨号
  • 原文地址:https://www.cnblogs.com/Sunlnx/p/5929611.html
Copyright © 2011-2022 走看看