为什么开发WebRTC与web开发不一样？

WebRTC是关于Web开发的工作

基本上是这样。但是更多的是关于RTC的。

WebRTC比较强大且用途广泛。它可以在任何地方使用，而且可以被VoIP和网页以外的事物使用。

当我们想要针对一个网页应用开发WebRTC的时候，在过程，工具，和我们需要的基础设施上还是有些区别的。

为什么是这样呢？

因为实时媒体是不一样的，而且比浏览器自己处理的其他大多数事情都要棘手。

情况正如下图一样：

所以是的，WebRTC只是恰好运行在网页浏览器上的。但是它的很多工作方式都是与VoIP一样（毕竟是VoIP的一部分）。

如果你想用WebRTC做出了hello world这种简单网页以外的事情，如果你是从web开发转过来的，那么你就有很多新东西要学。而这也是我写本文的原因。

下面是WebRTC开发与web开发之间的10大主要区别。

#1 WebRTC是P2P的

没有开玩笑。你可以直接从一个浏览器发送音频，视频，或者任何你想发送的随机数据给另一个浏览器。通过安全的连接传送。不会通过任何后端服务器（除非你需要进行中继—会在#6中更详细地讨论）。

你看到这个三角形了吗？对于VoIP来说很容易搞懂。但是对于web来说简直就像魔法一样。它为多种与VoIP没有关系的新服务类型开辟出了条条大路—像WebTorrent和Peer5；可以直接传送私密消息的能力；低延迟游戏控制器；以及数不过来的其他选择。

但是这个三角到底意味着什么呢？

它意味着你不需要通过一个web服务器来发送你的媒体。你要么直接在浏览器之间发送它，要么将其发送给一个媒体服务器。

它还意味着如果你不想发生什么意想不到的事情，你就需要跟踪很多东西，并且监控哪些甚至没有发送到你服务器上的数据。

#2 它不全是JavaScript和JSON

是的，我承认在上一篇文章中我说了WebRTC完全是关于JavaScript的这类话。

但是如果你的知识只局限于JavaScript的话，那么你在WebRTC的世界中将会非常痛苦。

举个例子来说，媒体服务器基本上都是由C/C++或者Java开发的。如果你需要对它们进行debug，那么你就需要能够明白这些语言。

第二部分与JSON更有关联—WebRTC中有一部分十分的讨人厌但是却很有用。那就是SDP，用在请求-响应协商过程中。

除了很难进行解释以外，SDP还很难使用JavaScript进行解析。它不是以JSON大对象的形式创造的，所以获取或者更改SDP中内容的代码并不是不重要。

#3 存在一个叫做UDP的东西

在今天，网页是在TCP顶端搭建的。它以HTTP作为开始。之后到了Websockets（也是在TCP顶端），而现在是HTTP/2（还是TCP）。

有很多允许进行UDP传输的尝试—QUIC就是其中一个。但是并没有成熟。对于绝大多数web开发者来说只是不正规的事情而已。

WebRTC中，所有的媒体都是尽可能通过UDP发送的。如果有需要的话，它也可以在TCP上工作，但是我们尽量不这么做，因为使用UDP的话你会得到更好的媒体质量。

上表展示了UDP和TCP之间的区别。这取决于媒体是如何发送的。我们使用不可靠的连接来确保最好的效果。

#4 游戏规则是妥协

那个叫做UDP的东西？它会带来不可靠性。换句话说就是你收到的不一定就是你发送的内容。再加上编解码器是一个大量占用资源的家伙，我们所处的游戏规则就是妥协。

在VoIP（以及WebRTC）中，任何我们做出的可以改进某方面的决定到最后都会让其他方面变得更糟。

想要获得更好的压缩率？那你就得损伤一部分质量。

不想损伤质量？那就得占用更多CPU。

想要更低的延迟？损伤质量（或者使用更多CPU资源）。

尽管CPU越来越好，可用带宽好像也越来越高，但是我们对媒体流的需求也在同时的增长。有时甚至比CPU和带宽的发展还要快。

所以还是需要不断地妥协。

你需要知道并理解媒体和网络，才可以决定什么时候妥协，什么时候提供资源。

#5 尽最大努力是另一条游戏规则

下面是我在有一次打电话的时候听到的：

“我们想要我们的视频质量比Skype和Hangouts要好很多”。

我觉得这个目标没有什么不好。

但是我又听到他说了别的：

·两个创始人对视频压缩没有经验或者不完全理解

·对于发展中国家的用例来说，不稳定的电话接收是最好的

·而且他们认为他们完全可以使用WebRTC来自己达到这些

根本不可能啊。

WebRTC（和VoIP）需要你尽最大努力。

这是为什么WebRTC要估计可以使用的带宽，然后一点点地占据可用带宽来提高视频质量。

这也是为什么在网络开始不稳定的时候（丢包），WebRTC 会降低比特率，并且降低媒体质量来适应现在可用的网络资源。

有的时候这个过程运行得很好，有些时候也不尽人意。

而且是的，大多数最终结果都取决于你设计的有多好以及你服务的基础设备有多好。

#6 NAT穿越会伴随你的工作生涯

我们都知道网络是有NAT和防火墙的。这不是什么新鲜事，但是如果你是一个web开发者，那么NAT和防火墙可能并没有给你找过任何麻烦。

这是因为对于“普通”的网络，浏览器会连接到服务器。并且作为我们当今网页的主要概念，NAT和防火墙知道会发生这些，并且允许其发生。

端到端连接，是像WebRTC那样直接在浏览器直接运行。而且连接是使用UDP的（再说一遍，在浏览器中通常都不用UDP连接），而这对于防火墙和配置防火墙的IT人员来说就是不允许的了。

对于WebRTC来说，这意味着我们需要额外添加STUN/TURN服务器。有些时候你会听到一个词叫做“ICE”。ICE是一个算法而不是一个服务器，它会用到STUN和TURN。STUN和TURN是用来进行NAT穿透的两个协议，它们两个每个都会使用自己的服务器。通常来说，STUN和TURN服务器都会用同一个代码实现，并且使用一个进程部署。

WebRTC会尽其所能确保会话可以成功连接。但是直到今天，它所做的工作也不够。有很多时候会话都无法正常连接—矛盾的是，这恰恰是配置防火墙的那个人的工作职责。

#7 缩放服务器的范围大小是可笑的

对于WebRTC来说，服务器缩放与普通网络来说有些不同。

两个主要原因如下：

1. 数量通常来说会更小。web服务器可以处理5位连接或者更多，而WebRTC处理3位的连接就已经很困难了。这对于进行HD视频是一个非常大的消耗。

2. WebRTC需要保持有状态性。服务一个连接以及重启连接通常都是很明显的—比其他相关网页要多的多。这使WebRTC的可用性，容错性，更新和相似的工作上都更难管理。

你如果想搞清楚如何改变服务器的范围，你就需要搞懂每个WebRTC服务器是如何工作的才行。

#8 带宽是昂贵的资源

对于网页来说事情相对简单。网页的平均大小每年都在上升。在2016年的时候达到了2.3MB以上。但是这个网页是从不同服务器上提取的不同资源建成的。而某些可以缓存到本地浏览器上。

一个5分钟的2Mbps HD视频要占据75MB大小的空间。

如果你只是进行1:1视频通话，10%的TURN中继系数—如果每天进行1000通，平均每通5分钟，那么每天就会占据15GB的TURN服务器带宽。你很可能一天会打多个电话，而且通话时间也有可能比5分钟要多。

如果使用媒体服务器来进行群组通话或者录制的话，这个带宽消耗会更高。

当你在考虑你的商业模型时，一定要考虑带宽的消费。

#9 地理位置是媒体传输的一切

对于大多数情况和大多数服务俩说，你都可以与运行数据的数据中心很远。

我的网站主机可能在美国的某个地方，然后它会连接到CDN服务商来管理静态文件。我甚至都没有操心过这件事，而且整体质量还不错。

但是在实时直播媒体领域可就不是这么一回事了。

从纽约到巴黎会用掉100ms或者更多的时间，作为实时传输，我们希望可以尽可能多的减少这个延迟。

想象两个人在巴黎使用WebRTC进行通话，但是通话信息是通过设在纽约的TURN服务器进行中继的。都不用提丢包率高的问题，这么高的延迟就已经够受的了。

WebRTC来说，即使是很小范围的服务，可能也需要全球部署基础服务器。

#10 不同的浏览器的表现情况不一样

作为一个网页开发人员，你可能处理过因为浏览器在HTML和CSS时工作的不一样的问题。

对于WebRTC来说也是这样。差别就是从事WebRTC会更经常的遇到这种问题，而且会把事情分成两个级别：

1. API表现—不是所有的浏览器都支持同一套API。

2. 网络表现—WebRTC的价值在于你可以在两个浏览器之间进行通话。所以如果两个浏览器不一样的话，你就有可能不能顺利的建立起连接。不同浏览器处理SDP的方式不一样，他们支持的编解码器也有可能会不一样，等等。

随着时间的推进，这个问题应该会得到解决。浏览器供应商会将注意力从添加功能上变成确保所有功能都可以跨浏览器交互。

但是在那之前，我们作为开发者就需要不断追着浏览器跑，并且做好任何突发问题的准备。

#11 你比你想的其实知道更多

WebRTC主要跟VoIP有很多关联。所以这就代表了VoIP开发者在理解WebRTC上要比你领先很多。

他们的问题是他们与你所受到的训练和学习是不一样的。他们学习的时候被教说一个通话中存在一个主叫和一个被叫。然后你需要保持一个通话，传输一个通话等等……他们所受到的训练有太多是关于电话的，而对通信没有什么作用。

而你不是这么学出来的。你不需要去忘记一些东西。我在整个的学习过程中就必须要去忘记掉很多以前学的知识。

这意味着你已经知道了WebRTC中很重要的一件事，那就是没有哪种会话的创建是对的或者错的。而且你在明白到底如何使用它之前可以随意进行实验，尝试，甚至破坏。这是非常有利的一点。