文献综述（或调研报告）：
流是由服务器到客户的音频或视频文件的连续不断的传输[1]。区别于下载，流音频或视频文件无需被完全下载并保存到本地，而是每次只下载一小段即可在流媒体播放器播放。源音频和视频数据被分解为一个个数据报，每个数据报包含了一小片文件，而后这些数据报流经网络到达客户设备，并被解释为视频和音频。直播流是实时推送到网络上的流视频，而不是事先被记录并保存的[2]。一般而言，直播流背后需要有以下几个主要步骤：视频捕获、分割、压缩、编码、CDN分发、CDN缓存、解码、视频播放。CDN分发与缓存并非必需的，这是指如果并非有成千上万观众或在其他情况下可以选择不使用CDN，但是视频流在网络中的传输仍然是不可或缺的一部分。目前已有包括WebRTC、HLS、DASH等多种流传输协议，其中WebRTC支持端与端之间的视频、声音和一般数据传送且该技术在所有的现代浏览器和所有主要平台的原生客户可用[3]，图1展示了WebRTC的整体架构。
在WebRTC中，端连接建立在用户之间以允许浏览器和浏览器（P2P）通信[4]。不同于传统的P2P应用，WebRTC web应用尽管知道端与端的公共IP地址也不能直接建立连接，这是由于浏览器沙箱机制不允许JavaScript应用从任意源侦听到来的流量。为了建立起端到端连接，需要web服务器使用Web Socket向两端提供信令通道，而后两端之间通过JavaScript会话建立协议（JSEP）建立数据通道。在数据通道建立起来之后，浏览器之间即可直接进行端到端的通信。
然而，这个模型（单纯的端对端WebRTC）只足够创造基本的web应用，而诸如群聊、媒体流记录、媒体广播和媒体转码等特性则难以在其上实现[5]。由于这个原因，许多应用寻求中间媒体服务器的帮助。端对端WebRTC与使用媒体服务器的WebRTC的区别如图2所示。在概念上，WebRTC媒体服务器只是一个媒体流量在从源到目的移动过程中会穿过的多媒体中间件，这个中间件可以处理到来的媒体流并提供不同的结果，比如：
- 群聊：向多个接收者发布一个端产生的媒体流，也就是像多人会议单元（“MCU”）一样行动
- 混合：将多个到来的流转变为一个单一复合流
- 转码：在不兼容的客户之间即时适应编解码和格式
- 记录：以持续的方式存储端与端之间交换的媒体
在Kurento中，其主要组成部分即为Kurento媒体服务器（KMS），负责媒体传输、处理、记录和播放等。
Rhinow等人[6]分析了使用WebRTC在web应用中实现直播视频流协议的可行性。WebRTC可以作为一个解决方案，通过允许浏览器之间直接进行端到端通信而不需要任何服务器作为中介。目前对于更复杂的算法和更大的客户集合，端到端的流是可能的。
目前已有诸多基于WebRTC的系统和框架被实现，包括使用WebRTC实现的视频会议系统[4]、基于云的直播流服务平台[8]和端协助框架[7]等。
Apu等人[4]实现了基于Web实时通信（WebRTC）的P2P视频会议系统。由于P2P连接是由现代web浏览器通过WebRTC本地支持的，因此应用P2P方案可以降低广播公司在所需带宽和网络基础设施方面的成本，相比较于其他技术，P2P WEBRTC会议解决方案更具有可扩展性，造成的网络基础设施开销也更少。Varma等人[7]实现了基于WebRTC的HTTP直播流端协助框架并进一步在不同的端密度下实验性地测量了框架性能。在三种场景下，端从和它相邻的端而非从服务器中取得了超过四分之三的数据段，因此服务器负载得到了极大的减轻。Kim等人[8]提出并实现了基于云的WebRTC直播流服务平台以组织灵活分布的MCU簇，云环境支持计算和存储资源的可扩展性和高可用性。
