作者：deepstreamHub（原文链接）
翻译：刘通
原标题：WebRTC in production
上一篇：WebRTC教程—文件传输
这次要来说几个坏消息。之前那几篇教程中的示例可能在你的机器上运行良好。它们可能在你同事的电脑上运行也没问题。但是从扩展性来看，想要做一个世界范围的WebRTC应用还要需要克服一些困难。
浏览器限制
WebRTC目前支持最新版本的Chrome，Firefox和Edge浏览器，还不支持Safari（译者注：此处有错误，apple及Safari在2017年6月宣布支持WebRTC）或者很多手机端浏览器。大多数浏览器规范都可以选择使用其他机制来解决这个浏览器限制问题，但是对于WebRTC来说不太可能。老旧的替换方案，比如Flash RTMP，不支持它的浏览器同时也不支持WebRTC。所以，很多视频会议应用提供方在默认使用WebRTC的同时，也还会继续提供可下载的客户端以免WebRTC无法使用。
连接性
障碍之一是在建立WebRTC连接的时候会出现，叫做NAT。NAT在路由器中被使用，互联网服务提供商或者大型企业将一个公共IP地址后的多个终端都捆绑在一起，然后使用路由器进行数据分配。这就使两个对等端想要进行直接连接变得很困难。为了解决这个问题我们可以使用TURN技术。幸运的是，有很多公共的STUN和TURN服务器可供使用。想要使用TURN服务器的话，只要在RTCPeerConnection构造函数的选项中中指定URL就行，比如{ iceServers: [ { url: ‘stun:stun.l.google.com:19302’ } ] }。即便连接建好了之后，也有可能会发生断开的情况。这可能是由于不良的网络环境，打开了太多标签页，或者其他各种原因造成的。不过只要你检查每个连接的状态的话，掉线之后马上检查修复重连，就不是一个大问题。
视频流
只要你用过视频会议服务你就会意识到一个事情：完全稳定的视频或者音频流现在为止还是不存在的。WebRTC也是一样。
搭建一个端到端的视频会议应用听起来挺吸引人的：不需要中央服务器也就不会出现故障，也没有高额的流量开销。但这在现实产品中几乎是不可能的事情。
原因有很多。用户之间使用的输入和输出条件差别非常大。不同的网络摄像头提供的分辨率，帧速率和质量都不相同，而且这些摄像头采集到的图像还要被投到各种大小的屏幕和窗口中。
带宽在其中扮演了更为关键的角色。一个压缩后的HD流需要大约5Mbit/s的带宽。在全网格10人P2P视频会议中，每个节点需要发送和接收50Mbit/s的数据—绝大多数的互联网运营商都无法提供这样的上行速度。
这就意味这对于几乎所有WebRTC视频流应用来说，“端”这个字的意思是硬件或者软件服务器，不是MCU就是SFU。
不是MCU就是SFU？
MCU是一项可以将一个或者多个视频流整合成单独一个流，并且将这个流传输给多个端点的技术。它还具备其他功能，比如视频压缩，播放同时更改分辨率，或者生成关键帧等等。
SFU也提供相似的功能，但只会依据指定将数据流传递给一个端点。
它们的区别是什么？想象一下你在一个有20人的视频会话里面，大家用的都是不同的摄像头和显示屏。用SFU的话你有20个预处理数据流需要进行后续操作。但是MCU只会给你一个精心编排过的数据流，包含了你真正想要显示在屏幕上的信息。
听起来很不错对吧？实际情况是SFU正在快速成为一条标准。MCU需要对每条视频进行解码，重新设置大小并且转换格式，并且组成一个新的帧—这种运算十分复杂，并且需要非常昂贵的硬件支持—尤其是播放HD，4k设置8k画面的时候。
用户端，甚至浏览器都会变的足够快来处理较多的计算—所以直接使用SFU进行传输通常就足够了。
文件传输
文件传输也会同样困难。WebRTC给了开发者选择TCP还是UDP的权力。为了高效的传输文件，用无序但是可靠的模型更加合适。这也允许一次从多个对等端那里获取文件的一部分，让下载速度获得了大量的提升。
另一个限制是浏览器是将输入的文件数据都存入缓存中—这就极大的限制了可进行传输文件的大小。
这一系列的教程就到此结束了，希望能够对您有所帮助。
