作者：Tsahi Levent-Levi（原文链接）
翻译：刘通
原标题：Why Developing With WebRTC is Different than Web Development?
上个星期我写了一篇WebRTC和VoIP开发的不同之处的文章。这星期让我们来看看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 会降低比特率，并且降低媒体质量来适应现在可用的网络资源。
有的时候这个过程运行的很好，有些时候也不尽人意。
而且是的，大多数最终结果都取决于你设计的有多好以及你服务的基础设备有多好。
