p2p流媒体视频网站的技术架构是什么样的

流媒体内容的传递需要CDN的支撑

以视频点播等影视节目为主的流媒体业务的引入，给网络运营带来了很大冲击，传统的网络模型和业务模型难以满足流媒体业务的需要。从上面的论述中，可以归纳出流媒体业务的属性主要体现在如下几个方面：

（1）高带宽需求。一般影视节目带宽需高达500kbit/s～1Mbit/s，而且要求稳定的带宽保证。

（2）高QoS保证需求。流媒体业务对QoS提出了严格的要求，如750kbit/s的MMS/TCP媒体流要求端到端丢包率小于2％，双向时延小于140ms。

（3）双向不对称/对称流需求。对于视频点播节目，一般是双向不对称的服务。

（4）点对多点的广播流需求。对于IPTV、直播类业务，需要支持从单点（广播源）到多个接受点（用户终端）的流传输。

（5）并发服务/业务数是个瓶颈。流媒体类业务一般是服务器—客户端或客户端—客户端的业务服务架构，视音频编解码是服务器和客户端的重要功能之一，视音频编解码需要耗费大量的服务器/客户端软件和硬件资源，因此目前的服务器或客户端难以承受大的并发服务/业务请求，一般服务器只能支持1000以内的并发影视媒体流访问。正是由于流媒体业务具有上述属性，而目前基于包交换的IP网不是为上述业务属性设计的，因此直接在当前的IP网上承载具有上述属性的流媒体业务会产生如下问题：

（1）端到端带宽和QoS难以保证。

（2）网络通常不支持多播，广播型业务需要采用多个点对点传输实现，不但耗费大量的骨干网络带宽，而且对源点也构成极大的压力。

（3）一旦流媒体业务用户量和业务量加大，对现有网络的流量流向模型造成很大的冲击，甚至会使得现有网络难以满足常规业务的开展。

（4）SP的接入是个瓶颈，会影响业务的正在开展，接入带宽、业务访问能力描述。

上述问题在现有网络框架下是难以解决的，引入内容分发网络（CDN）正是为了解决上述问题。其好处是：

（1）通过CDN的引入，可以将用户业务服务点更靠近用户，可以放在省网、本地网，甚至放在小区里，可以将目前尚未解决的带宽保证和QoS保证问题的距离缩短，从而可以有效地“解决”此问题。

（2）通过CDN的引入，可以将大量流媒体内容预先分发到省网、本地网范围内，同时可以通过本地自动缓存操作，大大缓解流媒体业务对骨干网流量流向的冲击。

（3）通过CDN的引入，可以实现广播流的树型分发和服务，实现“应用层”多播。

（4）通过CDN的引入，将流媒体业务服务器分散和下放，可以有效缓解对SP接入的压力。

五、CDN技术将促进流媒体业务的开展

内容分发网络（CDN，ContentDistributionNetwork），有时也可以称作内容传递网络（ContentDeliveryNetwork）。CDN的核心思想是将内容从中心推到边缘靠近用户的地方，这样，不但有效地提高了用户访问内容的服务质量，而且还能减轻中心设备和骨干网络的压力。

CDN的特点:本地Cache加速镜像服务远程加速带宽优化集群网络抗攻击

速网科技CDN给您带来的好处

1)通过提高网站响应速度，改善用户体验，增强用户满意度和粘合度；

2)轻松应对突发流量，随时展开网络推广；

3)有效抵御洪水式网络攻击，使网站永不宕机；

4)减少源站点负载，节省网站分布式架构的支出成本和运维成本。

那什么又是P2P技术，P2P技术和流媒体之间有什么样的联系，简单地说，P2P流媒体就是加入了P2P技术的网络视频。就像BT和电驴的出现带来了下载的革命性体验一样，P2P技术的应用也使得网络视频给用户带来全新视觉感受。P2P流媒体有效解决了传统网络电视对用户带宽、服务器负载的高要求。传统网络电视对用户带宽、服务器负载的高要求都限制了流媒体的应用，宽带虽然速度有了很大提高，但视频质量仍然不够理想，特别是节假日或者上网高峰。

而P2P流媒体却有效解决了传统网络电视对用户带宽、服务器负载的高要求。在目前的流媒体系统中用户之间是没有任何联系的，但是采用P2P技术后，每个流媒体用户也是一个P2P的一个节点。用户可以根据他们的网络状态和设备能力与一个或几个用户建立连接来分享数据，这种连接能减少服务器的负担和提高每个用户的视频质量。P2P技术在流媒体应用中特别适用于一些热门事件，即使是大量的用户同时访问流媒体服务器，也不会造成服务器因负载过重而瘫痪。此外，对于多人的多媒体实时通信，P2P技术也会对网络状况和音视频质量带来很大改进。

实际上基于P2P技术的流媒体播放器，实际上是一个款收看网络电视的软件，我们之所以研究和开发这样的软件除了上面简单的优点外，最主要的一点是能够为宽带用户提供稳定和流畅的视频直播节目。与传统的流媒体相比，这样的播放器采用了P2P-Streaming技术，具有用户越多播放越稳定，支持数万人同时在线的大规模访问等特点。

peer to peer

就是点对点传输的意思

网络中p2p的技术意义是指：计算机网络，其中每个客户计算机都可以作为其他计算机的服务器，允许对文件和外围设备的共享访问，而不需要中央服务器。也可简单的理解为：一对一或点对点传输，平等共享资源的意思。具体在网络中的应用有视频或音频资料的p2p共享模式。这种模式属于不计较版权的，可以由看客的计算机在收看收听的同时，共享给其它就近的想看想听的客户，而不需要通过总部统一发布。

WebRTC ，名称源自 网页即时通信 （英语：Web Real-Time Communication）的缩写，是一个支持网页浏览器进行实时语音对话或视频对话的 API。它于 2011 年 6 月 1 日开源并在 Google、Mozilla、Opera 支持下被纳入万维网联盟的 W3C 推荐标准。

首先，他即是 API 也是协议。

其次，他是浏览器进行音频与视频通话的 API，其实还有屏幕共享的功能。

最后，它现在已经处于 W3C 标准，各大浏览器厂商已经对他进行兼容了。

但是如果我们想使用好 webrtc，就得先了解 websocket。而对于 websocket，大家应该都比较熟悉了，比如社交聊天、多人 游戏 、协同编辑、视频会议、基于位置的应用(地图)、等等需要高实时的场景。我们比较常用的微信、QQ、某些直播软件等等也都是基于 websocket 实现消息与信令的转发。大家看到这里可能在信令这里迟疑了，接着看。

webrtc 是 P2P 的一种技术，什么是 P2P？其实就是 端对端，就说是你的音频、视频流不经过服务器中转，直接由一端发送到另一端。

不经过服务器中转，也就说时候，如果通过过程中服务器突然崩溃，是不是通话还能继续？

是的！但是发送音频视频流前，一定是需要建立 P2P 连接的，建立连接前一定需要服务器进行信令转发，这个信令就是通话两端的标识。

而如果想用 webrtc 实现通话，就得先中转信令、建立连接。而建立连接的话最好是要用 websocket 进行信令转发的。大家都知道，websocket 是个通道，在这个通道的所有端，都可以收到任意一端的消息流，包括发消息的本人。

为什么不经过服务器就可以直接获取到对方的视频音频流呢？是因为建立了 P2P 通道，这个 P2P 在中转信令的时候就已经通了，传输视频音频流的时候还要啥服务器啊。这个时候，肯定有小伙伴表示怀疑，音频视频流可以不通过服务器？是的，我骗了大家，确实要经过服务器，但是只是线上需要服务器转发，如果我们是本地两台或者多台同一局域网的端 进行 webrtc 音频视频流的转发，确实不需要中转服务器，但是线上有可能需要，也有可能不需要，这里又涉及到了一个 打洞 的概念。

我们平常可能会听到比较牛 x 的词汇，什么打洞、内网穿透、NAT 穿越，各种高大上的东西，其实也是蛮好理解的。大家都知道，两个不同网络下的两台主机不可以直接进行通信，而是需要走公网或者说各自的网关。打洞、内网穿透、NAT 穿越其实就是一个意思，就是使用 udp 让我们两台非同一网络的主机互联，不走公网，直接实现连接。有玩过花生壳的同学一定能理解内网穿透这个概念。

本地开发的话，两台主机连同一局域网，根本不需要内网穿透，就可以直接通信。

线上开发的话，如果能够 STUN 打洞成功，也不需要中转服务器。但是，有打洞不成功的概率，为什么呢，因为没有走公网，没有给运营商带来收益却带来通信成本，肯定要限制。国外打洞成功的概率在 70%，但是国内 50%都不到。

所以，为了防止打洞不成功的情况，我们使用 TURN 中转服务器 转发流媒体数据进行一个最后保障。此外还有一种方式为 逆向连接 ，也可以帮助我们实现 P2P 建立，他的原理是必须是一方走公网，也是有局限性的。

coturn 中继服务器由两部分组成 STUN 与 TURN，STUN 帮助我们打洞，TURN 帮助我们转发流媒体数据。

##连接过程

以下所有 API 截止到 20211206 为最新

##我有疑问

给大家看看 sdp 的本质，就是自身的媒体信息和编解码信息

一个 offer，一个 answer，我们彼此都知道对方的媒体信息与编解码信息，这样我们才能好好协商，我这边该用什么方式对你的视频音频流进行解码、渲染。

过程有些繁杂，具体流程小伙伴们可以看这篇文章 WebRTC TURN 协议初识及 turnserver 实践。

了解 webrtc 的音视频采集、桌面采集；

了解 websocket 和 webrtc 的整个链路建立过程；

实现 1V1 文字传输、视频通话、语音通话、屏幕共享；

实现视频通话、语音通话、屏幕共享过程中的截图、录音、录屏及 截图、录音、录屏的在线播放与下载;

将以上功能部署上线；

在这里，我们要对音视频建立过程画一个基本的流程图。

基本流程图

对于这些信令，我们使用 websocket 进行转发，这里大家会问，为什么不使用 http？

首先，我们的要实现的 demo 本来就含有发送普通文本消息的功能，就是使用 websocket。(长短轮询太老了，性能太差)

其次，第一点可以忽略，http 的请求会打回原路，A 向服务器请求，绝对不会传向 B。

但是如果我们要使用 websocket 转发信令，就要清楚的了解，在同一管道的所有端都会收到这条消息。所以，对于上面流程图来说，其实所有的小箭头都是双向的。

这时候，我们可以在 node 服务中来控制推送消息的方向，也可以在客户端来控制，这里我选择在 AB 端来控制。

其次，我们在本地开发，如果使用一台电脑，两个浏览器的形式，websocket 文字消息是可以的。但是音视频通话不行，因为不管是传输通道还是音视频设备(麦克、扬声器等)都是冲突的。所以，我们可以通过同一局域网，使用两台电脑解决这个问题。并且，因为 webrtc 的安全限制，必须使用 https(不管是线上还是本地)与域名，我们可以通过线上配置 https 与域名，本地设置浏览器忽略 https 与配置 host 文件映射来解决这个问题。

接下来，我们使用 vue 和 nodejs，可以最快最简单的实现 demo。

废话少说，我们开撕！

展示部分代码

这里我使用 socketio 这个第三方包，快速的首发消息，转发信令。(建议大家使用 vue-socketio)可以在组件中收发消息与信令。

将 socket-io 的 websocket 建立连接与接收消息，接收信令放到 vuex 中。

同样，我们在 node 服务中，也是使用 socket-io 这个包

对于视频、音频、及屏幕共享来说，代码都是类似的。所以，举例视频采集。

通过使用 getUserMedia，我们可以采集到音视频双轨的媒体流，我们传入一个参数 constraints，这个参数可以配置(控制采集音频还是视频)

将采集到的动态媒体流赋值给 video 标签，我们自己的画面就显示在网页上了。

同样，如果是音频采集，只需要配置参数 constraints 中的 audio 为 false 即可。

电脑屏幕采集，只需要将 getUserMedia 这个 API 替换为 getDisplayMedia 即可。

此时视频端发起端，采集到了媒体流后，需要发送 apply 信令给接收端。这个信令是询问接收端是否接起视频通话。

如果接起，接收端会采集自己的音视频双轨的媒体流，并且初始化 peerconnection，将媒体流放入此管道，监听 ICE 候选信息 如果收集到，就发送给对方，并将自己的同意信令 reply，回复给视频发起端。

如果拒绝接起，接收端会回复一个拒绝的信令给视频发起端。

接收端此时收到拒绝，会关闭视频音频流的采集。

接收端此时收到接起，会初始化 peerconnection，并将自己的媒体流放入此管道，监听 ICE 候选信息 如果收集到，就发送给对方。并且创建一个 offer(此 offer 包含 sdp)，将 offer 放到本地后，发送 offer 给视频接收端。

视频接收端接收到 offer，放到自己的远端，并且创建一个 answer，将 answer 放到本地后，发送给视频发起方。

视频发起方接收到 answer，将 answer 放到远端。

此时，接收和发起端都在监听 ICE 候选信息 如果收集到，就发送给对方。一但监听到了就将对方的动态媒体流赋值给 B，播放出来。

截图：我们可以使用 canvas 利用相关方法 getContext("2d")drawImage ， 实现 web 层面的截取。

录音/录像/录屏：使用 MediaRecorder 将我们的媒体流或者对方的媒体流保存到数组中。

只需要将保存的静态媒体流赋值给 video 标签

同理，我们可以将音视频流下载下来。

部署 webrtc 重要的两个条件：域名 与 https，我们需要配置这两块。

我们的 node 服务不仅是 https+域名，websocket 也需要更为安全的 wss 协议，我们需要给我们的 websocket 配置 wss。

在前面我们也提过，本地开发之所以能够成功，并且有效果，是因为内网是直接通信的，并没有走公网，也就没有实现内网穿透。

如果我们想要在线上实现这个功能，我们必须配置 coturn 中转服务器。centos 内核的配置文章可以参考 这篇，ubuntu 内核的配置参考 这篇。

在开发和上线后能够发现以下几个问题。

环境、设备、信号溢出、算法不兼容产生的噪音、声学与线路产生的回音、网络拥塞及数据包传输速率不稳定产生的延迟。

我们可以通过接入一些算法及提高硬件设备质量，来减少噪音回音，降低延迟。

对于噪音，采集音频时可以设置 noiseSuppression: true ，可以降低 一些环境及设备的噪音。

对于回声，采集音频时可以设置 echoCancellation: true ，可以去除回声。

剩下的交给算法、设备和网络来处理了。

在这方面的 探索 ，我就到此为止了，大家可以接着研究 WebRTC 传输是如何保证音视频服务质量 ，研究一下成熟应用是如何解决这三大难点的。

大家在视频通话过程中，可以使用多种特效。美颜、贴纸等等。

然而在 webrtc 的 web 端领域，视频特效领域是非常潜的。造成这种情况的原因是 js 的性能问题。

比较简单的方法就是使用 canvas 画布，对我们的视频图象加一层滤镜，但是在本质上并没有改变媒体流。传输到远端仍然是没有特效的。当然，我们可以通过 websocket 控制远端的视频特效，但是由于视频流没有改变，对方如果下载视频流的话，播放出来仍然是没有特效的。

另一种方案如下，这里我就不做赘述，大家可以思考一下是如何实现的(以下为简单特效与贴纸)。

需要创建 n-1 个 PeerConnection 连接，因为我们要与 n-1 个人进行视频共享，每个人都是这样。但是这里会涉及谁主动发 offer 的问题。我们可以让新加入的成员向其他 n-1 个成员发送 offer，也可以使 n-1 个成员向新加入的成员发送 offer。这里我们可以用遍历的方式生成 PeerConnection 和 offer。当然多人通话就看你服务器顶不顶的住了。

这里我们就不知情的使用了多端通信的知名通信方案——Mesh，Mesh 就是两两通信从而形成网状结构。除了 Mesh 这种通信方案，还有 MCU，MCU 方案主要是将同一房间的所有终端的音视频流进行混合然后发向各个终端，这样服务器的压力其实是非常巨大的。另外还有 SFU 通信方案，中转服务器收到某终端音视频流后，单一转发到其他终端。

经过上面一系列的理解、思考、构建、开发、部署等等，我们对 webrtc 有了一些初步的了解及认识。对于这方面的研究与 探索 我们都要继续继续深入下去。因为满足我们的好奇心与求知欲，提升我们的这一领域的技术，丰富我们整体的知识体系，何乐而不为呢。

最后，以上所有的内容都来源于资料、个人实验及个人总结，文中有错的地方希望大家及时指正。

1、 基于软件的视频聊天网站。

a) 纯C/S架构，基于软件的视频聊天网站，视频聊天平台是软件而不是网站。通过网站与软件的数据同步来实现视频聊天网站的功能。网站会员通过下载网站提供的客户端登陆，然后在统一的软件平台里进行视频交流。

b) 软件以常规软件模式的P2P技术进行开发。性能优秀、服务器承载量大，和网络电视台使用几乎一样的技术。。

c) 功能强大，因为软件是在本地执行的，对于文件传输、截图等软件模式才能开发的功能有着非常大的优势。

d) 开发成本极高、开发周期长。基于此模式的视频聊天网站初期投入非常的大，需要花费较长的时间和非常大的成本来进行开发。因为开发软件的成本本来就比开发同等规模网站的成本高很多倍，1个视频聊天软件的开发成本比开发1个网络电视台的成本还要高很多倍。

e) 必须开发基于各种操作系统的软件版本或则兼容的软件版本，维护成本极高。

f) 此模式非常适合于通过长时间积累运作盈利以及资本雄厚的站长运作。不适合中小型站长运作。

2、 基于插件的视频聊天室。

a) 通过软件开发的插件来实现高性能视频聊天。如果要通过网站进行视频聊天客户必须先安装插件。

b) 此类型网站几乎都是使用第三方开发的视频聊天插件来搭建视频聊天网站。

c) 如果要使用此类插件必须支付上千元费用，如果要使用完全自由功能的插件，必须支付高昂的费用。运作成本高。

d) 如果要开发此类插件，开发成本和基于软件的视频聊天网站几乎一样。

e) 当前网络病毒木马横行。由于网站访问者很多情况下并不知道插件的具体用途以及内部的机制，让很多的访问者对此类视频聊天室敬而远之。同时，各种安全工具也会对插件进行限制。这导致了此类视频聊天室给网站访问者带来非常强的威胁感。虽然有时候会试着下载，去看，但很多也会很快删除插件，防止插件给系统带来攻击或病毒，因为他们并不知道插件是否包含病毒或则木马。

3、 纯WEB的视频聊天网站。

a) 通过ADOBE提供的Flash Media Server或Red等视频服务器进行视频聊天网站开发。

b) 基于此模式的视频服务器端在多人视频聊天下，性能比不上基于软件或插件开发的P2P视频聊天系统。因为此种模式是c/s模式的。C端就是FLASH PLAYER，S端就是视频服务器。如果要搭建此类视频聊天网站必须在服务器端安装视频服务程序。

c) 目前情况下，对服务器性能以及带宽要求比较高。支持的用户数量比前面两种低很多。同时由于FLASH PLAYER是在网站上运行的，虽然会将FLASH下载到本地，但由于FLASH PLAYER的安全限制非常严格，在默认情况下无法实现本地文件操作以及相关的功能，所以，在功能上没有基于软件或则插件模式的视频聊天系统功能强大。

d) 使用FLASH PLAYER作为客户端，几乎跨域任何操作系统和电脑。ADOBE 公司推出的FLASH PLAYER 10已经支持UDP模式的P2P视频聊天，这无疑将对未来视频聊天系统产生革命性的影响。

e) 开发成本低、周期短。由于FMS等视频服务器通过不断的改版对视频以及音频的压缩都是非常优秀的，而且不需要做任何开发，大大的节约了开发成本和时间。也不存在跨越防火墙以及NAT穿透等高成本网络功能开发费用。

f) 可以通过FLASH开发工具，如FLEX开发客户端FLASH，在界面开发以及功能开发上所花费的时间远远小于开发软件或插件需要花费的时间。

g) 此模式非常适合搭建进行一对多视频展示的视频聊天网站。

h) 此模式，是目前很多中小型视频聊天网站站长的首选方案。通过具有吸引力的视频内容吸引客户，然后收费，实现网站盈利，盈利模式简单实用，盈利周期短、运作成本低廉。