翻译：刘通
在JumpSuit开发的有些时候中，我意识到想要做一个我们所期望得到的游戏是不可能的：WebSockets因为处于TCP的顶端，所以非常的慢。
尽管现在可以使用WebSockets他们来写还算快节奏的游戏，就像Agar.io和Slither.io获得的成功那样。但是如果你需要有很低的延迟，那么WebSockets就满足不了了。
所以我就开始寻找其他的解决办法。
WebRTC是目前对于浏览器来说唯一一个可以不用Flash与外界使用UDP进行数据交换的技术。尽管它是一个相对新兴的事物，但是浏览器支持已经足够好了，使Facebook Messenger，Skype以及Google Hangouts都在使用它。
但是，WebRTC是被设计用来在浏览器之间做P2P VoIP通话的，而不是创建游戏服务器。但出人意料的是，游戏开发也可以从WebRTC获得巨大的好处。
数据通道十分的出色
在音频和视频方面，WebRTC可以通过创建DataChannel来传送数据。
虽然音频和视频都是通过RTP传输的，但是数据通道使用的是SCTP。SCTP因为自身可配置的优点而十分出色：你可以选择你的数据报是ordered和/或reliable的。
快节奏游戏因为对于快速的需求所以使用的是UDP，而代价是有序性和可靠性。
但有些数据包依然需要可靠的发送，比如聊天信息。遗漏了聊天信息很显然是不可以的！所以当使用UDP的时候，我们以在其顶端实行可靠性作为首尾。
因为SCTP是可配置的，所以我们可以以不同设定来打开多个数据通道，而这点可以为我们节省大量的工作！
通常我们有：
# 为游戏状态数据和用户输入提供的不可靠且不有序数据通道
# 为聊天信息，分数和死亡次数提供的可靠且有序数据通道
网络架构
假设我们现在需要一个用户—服务器架构，就像绝大多数当代游戏一样。
WebRTC将各个对等端连接起来。因为WebRTC是一个网页协议，所以这里的对等端通常都是浏览器—但是谁也没说过游戏服务器不能够做对等端啊。有很多库可以满足在服务器上使用WebRTC，其中大多数是Chromium代码的封装器。
我们也需要多个游戏服务器：如果我们所写的游戏很成功，我们就可以认为对于单独一个服务器来说负载过大了。另外，我们想要让任意用户都可以作为游戏服务器的主机。这么做的好处是，你不需要去购买主机，而且也可以让用户自己开发模组（mod），大大增加了游戏的寿命。缺点是你不能完全地控制你的游戏。
通常这是通过设立一个主服务器来完成，主服务器知道每个游戏服务器的地址。为了能够进行最少的配置而完成上面所说的工作，我们可以将游戏服务器直接注册在主服务器上。然后，用户就可以连入主服务器来所取游戏服务器的地址。
WebRTC对等端在最初是并不知道其他对等端的，所以它们需要一些方法来进行认知。连接是由交换数据元来取得的，例如地址，所支持的编译码器等等。WebRTC不能指定这些信息是如何交换的。举个例子，这允许了用户对其进行复制粘贴。但是我像你保证这是不切实际的。所以我们要创建一个服务器，可以通过WebSockets来传递信息。这个服务器被称作信令服务器。
我们的信令服务器是很特殊的：它也是主服务器！当一个服务器连入它时，主服务器会发送一个由特定ID所识别的服务器清单，并且还伴随着关于他们的其他信息（比如地理位置，游戏模组等等）。
一旦他们准备好了，浏览器会被要求连入他们所选择的游戏服务器。他们用SDP完成这一要求，其中信令/主服务器路由到游戏服务器处。基于反应，游戏服务器会将其自己的SDP路由到浏览器。在几个来回之后，连接就得以被建立。
这就是我们的网络开起来是什么样子的：
我建了Enslavism，一个框架可以十分简单的创建架构。
WebRTC其他的好处
NAT穿越
就如上面讨论过的，主服务器的角色是通过将游戏服务器的地址给用户，让用户和游戏服务器相交流。重要的是，因为游戏服务器是直接注册在主服务器上的，从主服务器视角看地址是稳定的，但从用户角度不是。举个例子，在prod中我们的主服务器和一个游戏服务器在同一个主机上。对于主服务器来说，游戏服务器的地址因此是127.0.0.1，但当然这个地址对于客户来说是没有用的。
所以我们需要执行一些内容来获取正确的IP—由于存在很多种情况，工作量会很大。我实话实说吧，我们只能在基本的几种情况下工作。
另一方面，选取最佳IP是WebRTC连接进程的一部分，而且它是自动的，所以我们不需要亲自完成这件事情！
加密
我们还有另外一个问题：我们想要我们的游戏通过HTTPS被服务。而且我们想每个人都可以简单的成为一个服务器的主机。玩家应该在我们的网页上连入第三方的WebSocket。但是由于SOP的原因，玩家不能从一个HTTPS网页连入一个不安全的WebSocket。
显然，我们并不想让人们必须通过复杂的步骤来做服务器主机。我们尽自己所能可以做到的事是通过HTTP伺服网页自身，以及通过HTTPS伺服每个源。虽然不是完美的方案，但总比没有强。
在prod我们必须使用绝对参考将每个相关参考替换成一个源，否则其就会通过HTTP获取。相反的，在dev中我们需要我们的服务器对参考进行修补使其包含从机器自身来的源。
这个问题在WebRTC中不存在，因为它默认是安全的。
写在最后
我希望这篇博客会对你使用WebRTC进行网页游戏开发起到帮助。但是我必须提醒你，现在服务器端的WebRTC库还并不是十分完善。我建议你在搭建游戏之前进行详细深入的调查。
