原作者：Cold Brew（原文链接）
翻译：刘通
一步一步指导如何搭建你的第一个WebRTC数据通道服务。
当我们初次接触WebRTC的时候，由于缺少合适的资源和资料，所以入门的门槛非常非常高。所有内容不是太复杂了，就是基于过于简单的WebRTC框架，或者就是太精密了以至于我们之前所学的东西在搭建实际工程的时候都用不上。
作为现在最令人激动的科技之一，这些缺点都是WebRTC难以启齿的地方。我们相信这项技术的价值是被低估了的，部分原因是对于开发者来说想要用WebRTC搭建任何一个有实际意义的工程都是十分困难的。
本文的目的是揭开WebRTC软件开发的神秘面纱。我们希望当你仔细读完整片文章之后，你会对WebRTC有一个整体的认识，也会知道如何开发一个端到端通信的应用。
简单普及WebRTC
在我们进入教程的核心内容之前，如果你之前没有从事过相关工作或者想要复习进修，让我们先来介绍一下WebRTC的基础概念。当然如果你已经对WebRTC的基础知识有了一定的掌握，那么也可以选择跳过这一段。
WebRTC是一项可以让数据，视频，甚至屏幕共享通过P2P连接的形式进行传播的技术，意味着数据不需要通过服务器进行传输。它是一系列协议和API的大集合，以及一些开发者中一些不成文的规定。WebRTC协议被内置在Chrome和Firefox浏览器中，并且包括这三个部分：
# getUserMedia，其功能是允许网页浏览器获得摄像头和麦克风的使用权限，并且捕获媒体。
# RTCPeerConnection，负责管理端到端连接
# RTCDataChannel，其功能是允许浏览器分享任意数据
在P2P连接被创建之前，一个叫做信令的处理工作必须先要进行。为了完成让每个用户都具有另一端用户的IP地址以及其他任何用户想要共享的涉及数据/视频的信息，信令会在用户和信令服务器之间进行多次的往返。这项工作是如何完成的并不是由WebRTC标准所定义的，而是由开发者想要如何设定信令而决定的。本篇文章会利用Socket.io来讲解信令的内容。
下面看这张图表，但是不要将过多的精力放在其中的具体内容里：
https://github.com/satanas/simple-signaling-server
我们可以看到，只是为了实现一个端到端的连接就需要有这么复杂的过程。注意下面的这些步骤是按顺序发生的：
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，这些应该对你开始本教程剩下的内容来说应该够用了。在你学习本教程的时候你也可以倒回来多看这张图几遍，并且将其作为参考。在网上你也可以找到很多这方面的资料，可以更加的深入研究，但是上文对于现在来说已经够用了。
未完待续。。。
