作者：Sam Dutton（原文链接）
翻译：刘通
原标题：WebRTC in the real world: STUN, TURN and signaling
前文链接：实际中的WebRTC：STUN，TURN以及信令（一），实际中的WebRTC：STUN，TURN以及信令（二），实际中的WebRTC：STUN，TURN以及信令（三）
使用RTCDataChannel进行信令服务
启动WebRTC会话需要信令服务。
但是，一旦两个对等端建立了连接，RTCDataChannel理论上就可以作为信令通道。这可能会减少信令的延迟—因为消息是直接传递的—并有助于降低信令服务器的带宽和处理成本。
信令中的陷阱
# 在setLocalDescription()被调用之前，RTCPeerConnection并不会开始收集候选：这是在JSEP IETF草案中规定的。
# 利用Trickle ICE（见上文）：候选到达后立即调用addIceCandidate()。
现成的信令服务器
如果你不想自己做WebRTC信令服务器，则可以使用上面例子中使用Socket.io的WebRTC信令服务器，并与WebRTC客户端JavaScript库集成：
# webRTC.io：WebRTC最先出现的几个抽象库之一。
# easyRTC：完整的WebRTC包。
# Signalmaster：一个与SimpleWebRTC JavaScript客户端库一起使用的信号服务器。
如果你一点代码都不想写的话，还可以从像vLine，OpenTok和Asterisk等公司获得完整的商业WebRTC平台。
爱立信在WebRTC早期的时候建立了一个在Apache上使用PHP的信令服务器。虽说这现在已经过时了，但是如果你正在考虑类似的东西，那么还是值得看一下代码的。
信令安全
加密对于所有WebRTC组件来说都是强制性的。
但是信令机制并不是由WebRTC标准定义的，所以保护信令安全的责任就全在你的身上了。如果攻击者设法劫持了信令，他们就可以停止会话，重新定向连接和记录，更改或注入其他内容。
确保信令安全的最重要因素是使用安全协议，即HTTPS和WSS（即TLS），确保消息不会因未加密而截获。另外要小心，不要以可以被其他呼叫方能够获取的方式用同一个信令服务器广播信令消息。
在信令之后：使用ICE来对付NAT和防火墙
对于元数据信令，WebRTC应用程序使用中介服务器，但对于实际的媒体和数据流，一旦建立对话的话，RTCPeerConnection就会尝试点对点地直接连接客户端。
在简单的情况中，每个WebRTC端点都有一个唯一的地址，可以与其他对等端进行交换以便直接通信。
如果没有NAT和防火墙的话
实际上大多数设备都是处在一层或者多层NAT之后的，其中一些是就有可以阻挡某些端口和协议的防病毒软件，还有很多设备是在代理和公司防火墙之后的。防火墙和NAT实际上可以由相同的设备实现，比如说家庭WiFi路由器。
现实情况
WebRTC应用程序可以使用ICE框架来客服实际网络的复杂性。为了实现这一点，你的应用程序必须将ICE服务器的URL传递给RTCPeerConnection，就像下面所描述的那样。
ICE试图找到连接对方的最佳途径。它会并行地尝试所有可能性，并选择最有效的选项。ICE首先尝试使用从设备操作系统和网卡获取的主机地址进行连接；如果不成功的话（对于NAT后面的设备就会失败），ICE会使用STUN服务器获取外部地址，如果还是失败的话，则通过TURN中继服务器路由数据。
换句话说：
# STUN服务器是用来获取外部地址的。
# TURN服务器是用来在直接连接（点到点）失败的情况下进行中继数据流量的
每个TURN服务器都支持STUN：TURN服务器也是一个增加了内置中继功能的STUN服务器。ICE还可以应付NAT设置的复杂性：实际上，NAT“打孔”可能不仅仅需要一个公共IP:端口地址。
STUN和/或TURN服务器的URL（可选择地）由iceServers配置对象中的WebRTC应用程序指定，该配置对象是RTCPeerConnection构造函数的第一个参数。对于apprtc.appspot.com来说，值看起来是这样的：
注意：上面显示的TURN证书是有时间限制的，并在2013年9月到期。TURN服务器运行起来很昂贵，你需要为自己的服务器付费或者找一个服务提供商。要测试证书，你可以使用候选收集样本，并检查是否获得了具有类型中继的候选。
一旦RTCPeerConnection具有该信息，ICE的作用就会自动发生：RTCPeerConnection使用ICE框架来计算对等端之间的最佳路径，并根据需要使用STUN和TURN服务器。
