张鹏:腾讯云直播 PCDN 加速方案(上)

阅读数:239 2019 年 10 月 31 日 23:56

张鹏:腾讯云直播PCDN加速方案(上)

6 月 29 日,音视频及融合通信技术技术沙龙圆满落幕。本期沙龙特邀请腾讯云技术专家分享关于最新的低延迟技术、全新的商业直播方案等话题,针对腾讯云音视频及融合通信产品的技术全面剖析,为大家带来纯干货的技术分享。下面是张鹏老师关于腾讯云 X-P2P 的分享,为大家揭开 P2P 神秘的面纱。

大家下午好,今天由我给大家带来腾讯云 X-P2P 的技术分享,我是张鹏,现在是腾讯高级工程师,从 2014 年至今一直研究 P2P 技术,相信在座的各位很多对 P2P 还比较陌生,今天就由我来给大家揭开 P2P 这个神秘而又神奇的技术的面纱。

P2P 简单而言,就是你有我有大家都有的东西,我们可以通过网络相互连接来分享之。P2P 架构体现了互联网架构的核心技术,因此这种概念被描述在 RFC 1 里面,可谓由来已久,是早期互联网建设者心中最梦寐以求的架构。至于为啥现在一直是中心化的服务模式呢?主要还是它的一些历史原因和技术原因没有解决,但是我们也能在近 30 年互联网技术飞速发展的时期里,依然能看到 P2P 的产物,比如 netsper,PPLive,bt,还有 06~08 年国内 P2P 学术圈的黄金时期,如香港科技大学的 CoolStreaming,华中科技大学的 AnySee,清华大学的 GridMedia,代表着当时的流式 P2P 的最高境界了。而后,P2P 陷入被封杀的一片低潮期,QQ 旋风、迅雷下载也慢慢被移动互联网淹没在历史洪流中,可能只剩下一些视频团队在私下里继续做着,直到 2014 年直播兴起,腾讯云 X-P2P 也随之再次兴起。

张鹏:腾讯云直播PCDN加速方案(上)

接下来 P2P 从 2014 年到现在经历了 5 年的打磨完善,产品也非常的稳健成熟,覆盖 Android、IOS、H5、PC 等各种平台,它有更多的节点进行加速,延迟也是等同于 CDN 甚至优于 CDN 的起播速度,在 S8 赛事期间峰值达到 8T,经历了大规模的直播活动的检验,同时也见证了 flash 由盛转衰的过程。

为什么要做 P2P

P2P 更多集中在视频这个行业里,主要是带宽成本居高不下,带宽的需求速度大于带宽成本下降速度。现在大家通过网络看视频、直播,都要求卡顿更低,时延更低。在这样的情况下传统的 P2P 是满足不了的,而腾讯云 X-P2P 完美地解决了这些问题。

P2P 能达到 60% 的分享率,在一些人比较多的房间里面甚至可以达到 80% 的分享率,它的卡顿率是低于 CDN 的卡顿率的,他们的延迟跟 CDN 是一样的。

张鹏:腾讯云直播PCDN加速方案(上)

P2P 技术是怎么做

首先所有的节点都要有数据一致性,比如说我向你要这些数据,你给我的数据肯定要和我认为的数据是一致的。

对于点播而言,点播是固定的文件没有不断更新的数据,每个人可以按照 Offset 去分,比如说第 1~1000 字节是一片,1001~2000 字节是一片,我向你请求的第二片肯定是我想要的。直播就不一样了,直播不能按照 Offset 去做,比如说我在第一秒看到视频,第 1~1000 字节是我的第一片,你第二秒看到的视频起始位置不一样,向你请求第 1~1000 字节肯定是不行的。

张鹏:腾讯云直播PCDN加速方案(上)

直播可以按照 dts 去切片,这个到后面会涉及到各种各样的问题。传统的 P2P 就是搞个中心切片服务,把直播先切成片,比如说 HLS 和 DASH,每一个数据都是一个文件,这样可以达到数据一致性。

针对 FLv 和 FMP4,传统的中心切片服务器把它切片保存下来。现在我们则突破了在原始直播流上无法进行切片的限制,且对直播流无任何损害,完全不修改它里面的 mux 信息和 codec 信息。因为,Flv 和 FMP4,无论是 tag 格式还是 box 封装格式,天然就带有某种意义上的严格的边界,我们只要发现从哪个边界开始,跟其他的 peer 约定好开始信息,就可以在它的原始直播流身上实现分片去做 P2P。

我们这种方式跟直播流(Flv 或者 FMP4)合成一体,P2P 的数据可以直接交给播放器,且不影响播放器的行为,也就是对视频内容的侵入性上可以做的非常完美。

张鹏:腾讯云直播PCDN加速方案(上)

国外流行 HLS、DASH,是天然的原生切片式视频格式,它最大的优势是为自适应码率降低卡顿而生,那 FLv 和 FMP4 怎么实现自适应码率呢?自适应码率无非就是码率变了,把新的解码参数交给播放器,播放器的接下来的下一个(I 桢)给它续上,这就是自适码率了。如果说我带宽只有 6 兆,我非要看 8 兆超清的视频,把它降下去来就能达到流畅观看的效果,显著降低卡顿率。

如果我们实现了(Flv 或者 FMP4 的)直播流的自适应码率,那会怎么样?我之前还觉得 HLS、Dash 有自己那么大的优点,国内为什么不用它是因为国内比较落后;然而现在,我改变了我之前的看法,在 Flv 和 FMP4 直播流上使用自适应码率其实是比 HLS 和 Dash 更好的,因为它是在单 TCP 连接实现的,而单连接明显是比多连接要好的。大家不妨想想,HTTP 2 跟 HTTP 1.1 相比,它最大的改进其实是能在一个 TCP 上复用多个 Http 请求 / 响应出来,因为单一 TCP 连接的拥塞控制和顺序到达,肯定比多 TCP 连接的拥塞竞争要好的。但是 HLS、Dash 却反而把一个视频播放流请求变成很多个连接的文件请求,这其实是一个历史性倒退,如果在 Flv 或者 FMP4 直播流上做到自适应码率,那其实是比 HLS、Dash 还要领先的技术。

张鹏:腾讯云直播PCDN加速方案(上)

P2P 的客户端侧第一部分任务就是穿透,穿透这个技术很有意思,可能大家没做过 P2P,这是最有意思的。说穿透我们必须要说一下当前的互联网有 NAT(网络地址转换)。我们的公网地址不够,所以我们在局域网上用内网地址。我们在发送请求的时候,我们用内网地址加一个端口标识这个请求;而请求数据来到因特网,则被 NAT 映射成一个公网地址和端口。这带来的一个问题是我知道 B 的地址,但是无法去连接,因为我向 B 发数据的时候,数据包直接被 B 的 NAT 阻止掉,因为 B 的 NAT 不认识我。大家也可以想一下,你绝无可能凭空主动连接到别人家内网里指定的某台机器,就算它在监听某个端口也不行,别人家内网里的主机、地址分布对你而言是个彻底的黑箱。

张鹏:腾讯云直播PCDN加速方案(上)

那在 P2P 之前我们要建立其跟其他 Peer 的连接,具体怎么做呢?它需要一个公网服务器 S 的帮助,A 先连接 S 会告诉 A 公网地址,B 也一样;第二步是 A 知道 B 的通信地址之后,A 先主动连接 B,这个请求连接的数据包则被 B 的 NAT 干掉,因为 B 还不认识 A。A 再通过 S 由它代 A 转给 B 一封信息包,这个包一定能够到达,然后 B 预先已经和 S 建立过连接,是认识 S 的。B 收到这个信息包之后,就知道在外面敲门是 A,然后给 A 也回一个握手包;A 曾经主动连接过 B,是认识 B 的,那 B 的握手包就被 A 收到了,那么他们之间的连接就建立了起来。

P2P 之 NAT 类型,大概有七种:

第一种是公网型的,直接部署在公网上。

第二种带有防火墙,防火墙比如说安全软件为了安全,直接阻止了 UDP 协议,所有的 UDP 连接都是直接拒绝。

第三种是 Symmetric Firewall 对称型防火墙。

第四种是 FullCone NAT 完全锥型。

第五种是限制圆锥形,你想跟我通信,连接我,我必须得先认识你的 IP。

第六种是加了端口的端口限制圆锥形,通信时要同时验证对方的 IP、PORT。

第七种是对称型,换目标的话也会换地址,这是最与众不同的,也是最麻烦的。

张鹏:腾讯云直播PCDN加速方案(上)

P2P 之 STUN 协议,除了 STUN,其他协议对 P2P 是没有任何意义的。譬如 TURN 是经过中转服务器,中转服务器转发给 B,B 通过中转服务器转发给 A,其实是脱离 P2P 原来的意思。UPnP 是微软需要安装自己的硬件来支持它这个协议,全网并不是所有的设备都这样,对于 P2P 也没有意思。能够带来大范围对等网络 P2P 的唯有 STUN 协议,关于 STUN 协议怎么工作的,详细可以看 PPT,在此不做赘述。

张鹏:腾讯云直播PCDN加速方案(上)

我们知道了 NAT 类型,知道了 STUN 协议之后,那对于网络上的大部分节点,我们就能随心所欲互相建立起连接了吗?

其实还是不能的,为什么呢?因为现在网络上最多的是对称型 NAT 的,对称型的是最难应付的。我举一个例子,假设这是对称型的 NAT,这是限制型的 NAT,来演示它非常难穿透。

腾讯依赖 QQ、微信和 QQ 旋风多年的技术积累,突破了对称型 NAT 的限制,让他们大都能够相互穿透,对我们 X-P2P 而言其实已不成问题,由于时间关系就不细讲了。

评论

发布