WebRTC入门篇：WebRTC以及测试驱动开发（TDD）指导

一步一步指导如何搭建你的第一个WebRTC数据通道服务。

当我们初次接触WebRTC的时候，由于缺少合适的资源和资料，所以入门的门槛非常非常高。所有内容不是太复杂了，就是基于过于简单的WebRTC框架，或者就是太精密了以至于我们之前所学的东西在搭建实际工程的时候都用不上。

作为现在最令人激动的科技之一，这些缺点都是WebRTC难以启齿的地方。我们相信这项技术的价值是被低估了的，部分原因是对于开发者来说想要用WebRTC搭建任何一个有实际意义的工程都是十分困难的。

本文的目的是揭开WebRTC软件开发的神秘面纱。我们希望当你仔细读完整篇文章之后，你会对WebRTC有一个整体的认识，也会知道如何开发一个端到端通信的应用。

简单普及WebRTC

在我们进入教程的核心内容之前，如果你之前没有从事过相关工作或者想要复习进修，让我们先来介绍一下WebRTC的基础概念。当然如果你已经对WebRTC的基础知识有了一定的掌握，那么也可以选择跳过这一段。

WebRTC是一项可以让数据，视频，甚至屏幕共享通过P2P连接的形式进行传播的技术，意味着数据不需要通过服务器进行传输。它是一系列协议和API的大集合，以及一些开发者中一些不成文的规定。WebRTC协议被内置在Chrome和Firefox浏览器中，并且包括这三个部分：

# getUserMedia，其功能是允许网页浏览器获得摄像头和麦克风的使用权限，并且捕获媒体。

# RTCPeerConnection，负责管理端到端连接

# RTCDataChannel，其功能是允许浏览器分享任意数据

在P2P连接被创建之前，一个叫做信令的处理工作必须先要进行。为了完成让每个用户都具有另一端用户的IP地址以及其他任何用户想要共享的涉及数据/视频的信息，信令会在用户和信令服务器之间进行多次的往返。这项工作是如何完成的并不是由WebRTC标准所定义的，而是由开发者想要如何设定信令而决定的。本篇文章会利用Socket.io来讲解信令的内容。

下面看这张图表，但是不要将过多的精力放在其中的具体内容里：

我们可以看到，只是为了实现一个端到端的连接就需要有这么复杂的过程。注意下面的这些步骤是按顺序发生的：

1 对等端A向对等端B发送“连接请求”（offer）

2 对等端B向A发送“应答”作为响应（answer）

3 对等端A向B发出“候选（candidate）”

4 对等端B将“候选”送回给A

让我们来简化一下，首先来看一下术语：

‘offer’—包含了关于用户和用户想要发送的信息

‘answer’—与offer一样，只不过是作为响应

‘candidate’—ICE候选的缩略，包括IP地址和端口对

‘local/remote description’—这两项都需要同时在两端进行设置才能开启连接（包含 你自己和另一个用户的信息）

ICE候选告知另一端用户如何将信息传递到你电脑的浏览器上。这些都是幕后完成的。下面是图表中一些其他需要注意的地方：

1 注意信令是不对称的，其中一个用户必须发起它，另一端必须接收（适用于双端连接的情况）

2 上图缺少了STUN和TURN服务器。这两个服务器在处于不同本地网络的两用户之间的连接建立起到了至关重要的作用。

OK，这些应该对你开始本教程剩下的内容来说应该够用了。在你学习本教程的时候你也可以倒回来多看这张图几遍，并且将其作为参考。在网上你也可以找到很多这方面的资料，可以更加地深入研究，但是上文对于现在来说已经够用了。

教程

在本篇教程中，我们会做出一个聊天软件，通过WebRTC的端到端连接能够让两个用户互相进行视频，音频以及文字聊天。我们会用到cold-brew的库来采用测试驱动开发策略，所以我们强烈建议你在阅读本教程的时候跟着我们一起写代码。

但如果你想直接看到结果的话，也可以从我们的GitHub资源库里复制源代码。

我们也知道这篇教程很长，但是我们保证只要你完成了它，你就会获得关于WebRTC开发重要的知识和基础。

现在让我们开始吧！

从头开始

我们在这篇教程中用的是mac和linux终端命令。这里对Windows用户说声抱歉，麻烦你们自己调整一下。

首先，创建工程目录。我们在这里管它叫“cold-brew-tutorial”。

现在我们要创建之后需要用到的所有文件：

在文件搭建的最后一步，我们来创建一个package.json：

现在你的目录应该像这个样子了：

接下来需要做的第一件事是安装所有需要的依赖文件。

首先让我们来安装客户端依赖：

接下来是服务器端依赖：

最后是我们的测试依赖：

这里我们会用到一个新的库叫做“cold-brew”来做WebRTC的测试驱动开发。

我们设置的最后一步是设置运行测试以及服务器的脚本。打开你的pack.json文件并且找到脚本：

我们会分别用到三个测试脚本：一个用来聊天，一个用来视频，以及一个用来同时运行二者。还有一个简单的开始脚本来运行我们的服务器：

有了这里这个过渡支架，我们就已经做好了编写应用的准备。

设置服务器

下面我们需要设置服务器，用来伺服index.html文件到浏览器。

但是在写服务器代码之前，先让我们在chat.spec.js文件中设定一个测试：

从现在开始，只要我们展示了一段代码，就会在代码下面注明这段代码应该写在哪个文件里面。注意我们要用supertest库向服务器发送请求，并且确保我们得到了正确的反馈。如果现在就运行测试，只会得到失败的测试结果。这其实是“正确的”，因为我们还没有在我们的服务器中写任何的东西，所以测试一定是失败的。

现在已经有了测试，可以开始写真正的服务器代码了。我们会创建一个简单的快速服务器来在‘/’路线伺服index.html以及静态的伺服所有其他内容。

现在我们运行测试脚本，应该就能通过了。

设置HTML

接下来我们要为我们的聊天应用写html。还是像刚才那样，在我们真的开始写html代码之前，先编写一个测试脚本以确保把服务器给了正确的html页。

我们首先需要做：

然后，进行下图所示的步骤：

就像上一次一样，如果现在就运行测试的话是一定会失败的，因为我们还没有写html代码。

现在让我们写应用的基础html页。我们来创建一个文字聊天p，包括所有应用必需的信息部分：

当你再次运行测试脚本，你应该就会看到两个绿色的对勾！这就对了！这些测试可能看起来不是必需的，但是它们可以让我们不必为后期开发面临潜在问题所担忧。

未完待续。。。