TURN | WebRTC中文网-最权威的RTC实时通信平台

WebRTC 入门教程（二）| WebRTC信令控制与STUN/TURN服务器搭建

作者：李超，音视频技术专家。本文首发于 RTC 开发者社区，欢迎在社区留言与作者交流。本文将向大家介绍两个方面的知识： WebRTC信令控制 STUN/TURN服务器的搭建在前面的文章中已经向大家介绍了如何构建信令服务器。但构建的信令服务器是如何工作的？那些消息需要信令服务器控制和中转？这些此前并没有做详细的说明，而本文将对这些问题做详细的讨论。另一方面，在真实的网络中，WebRTC是如何进行NAT穿越的呢？如果穿越不成功，我们又该如何保证用户服务的呢？这些知识也将在本文中给出答案。信令 WebRTC 信令控制的架构图如下所示：信令服务器用于交换三种类型的信息：会话控制消息：初始化/关闭，各种业务逻辑消息以及错误报告。网络相关：外部可以识别的IP地址和端口。媒体能力：客户端能控制的编解码器、分辩率，以及它想与谁通讯。下面我们就来详细讨论一下这三类消息：会话控制消息会话控制消息比较简单，像房间的创建与销毁、加入房间、离开房间、开启音频/关闭音频、开启视频/关闭视频等等这些都是会话控制消息。对于一个真正商业的WebRTC信令服务器，还有许多的会话控制消息。像获取房间

为什么你的WebRTC产品需要TURN服务器

作者：LENNART SCHULTE, JÖRG OTT, VARUN SINGH, CHARLOTTA LIUKAS 翻译：刘通端到端通信的一个主要问题是，在许多情况下，这些端点并不在公共互联网中，而是位于网络（和端口）地址转换器（NAT）后面的专用地址空间中。随着互联网从DARPA项目发展成为全球范围的网络，很快就会明白IPv4的232地址空间早晚会用尽。在20世纪90年代，开发了多种策略来延迟IPv4地址耗尽的时间，其中之一就是NAT的设计。NAT将端点的真实IP地址隐藏于世界其他地方，这使得端点之间建立端到端直接连接变得困难。这就是协助框架—包括STUN和TURN（或使用中继NAT穿越）—派上用场的地方。平均约有30%的P2P会议有一个端点通过TURN服务器连接。如果没有TURN中继服务器的帮助，这些用户将无法进行通信。因此，开发者需要知道TURN服务器是什么，以及为什么它对WebRTC通话的重要性。 ICE和STUN 在讨论TURN之前，我们需要定义两个缩略词。 ICE是交互式连通性建立（Interactive Conne

实际中的WebRTC：STUN，TURN以及信令（五）

作者：Sam Dutton（原文链接）翻译：刘通原标题：WebRTC in the real world: STUN, TURN and signaling 前文链接：实际中的WebRTC：STUN，TURN以及信令（一），实际中的WebRTC：STUN，TURN以及信令（二），实际中的WebRTC：STUN，TURN以及信令（三），实际中的WebRTC：STUN，TURN以及信令（四） STUN NAT给设备提供了一个IP地址以使用专用局域网，但是这个地址不能在外部使用。由于没有公用地址，WebRTC对等端就无法进行通信。而WebRTC使用STUN来解决这个问题。 STUN服务器位于公共网络上，并且有一个简单的任务：检查传入请求的IP地址（来自运行在NAT后面的应用程序），并将该地址作为响应发送回去。换句话说，应用程序使用STUN服务器从公共角度发现其IP:端口。这个过程使得WebRTC对等端为自己活得一个可公开访问的地址，然后通过信令机制将其传递给另一个对等端以建立直接链接。（实际上不同NAT工作方式都有所不同，可能有多个NAT层，但是原理是一样的）。因为STU

实际中的WebRTC：STUN，TURN以及信令（四）

作者：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：STUN，TURN以及信令（三）

作者：Sam Dutton（原文链接）翻译：刘通原标题：WebRTC in the real world: STUN, TURN and signaling 前文链接：实际中的WebRTC：STUN，TURN以及信令-1，实际中的WebRTC：STUN，TURN以及信令-2 缩放信令尽管信令服务消耗客户端带宽和CPU相对较少，但是一个很受欢迎的应用程序的信令服务器可能需要处理来自不同位置的大量消息，而且并发性较高。有大量流量的WebRTC应用程序需要能够处理相当大负载的信号服务器。在这里我们不会对其进行详细讨论，但是对于大容量、高性能的消息传递有很多选择，包括： ·eXtensible Messaging and Presence Protocol（XMPP），最初是叫Jabber：一个为即时消息发展而开发的可用于信令的协议。服务器实现包括ejabberd和Openfire。Strophe.js等JavaScript等客户端使用BOSH模拟双向流，但由于各种原因，BOSH可能不如WebSocket高效，同样的原因可能导致无法很好地扩展缩放。（跳离正题

实际中的WebRTC：STUN，TURN以及信令（二）

作者：Sam Dutton（原文链接）翻译：刘通原标题：WebRTC in the real world: STUN, TURN and signaling 前文连接：实际中的WebRTC：STUN，TURN以及信令-1 WebRTC信令代码下面的W3C代码示例总结了一个完整的信令过程。该代码假定存在一些信令机制，SignalingChannel。我们会在下文中更详细地讨论信令。要查看实际提供/应答和候选项的交流过程，请参阅simpl.info/pc上的“单页”视频聊天示例的控制台日志。如果你想知道更多，请从Chrome的chrome://webrtc-internals页面或者Opera中的opera://webrtc-internals页面下载WebRTC信令和统计数据的完整转储。对等端发现这是“我改如何找到我要交谈的人”的一种高端说法。对于电话来说，我们有电话号码和目录。对于在线视频聊天和消息发送，我们需要身份和状态管理系统，以及用户启动会话的方式。WebRTC应用程序需要一种方式让客户互相通知他们想要开

实际中的WebRTC：STUN，TURN以及信令（一）

作者：Sam Dutton（原文链接）翻译：刘通原标题：WebRTC in the real world: STUN, TURN and signaling WebRTC支持端到端通信，但是WebRTC还是需要服务器： # 对于客户端来说，用于交换元数据来协调通信：这被称为信令 # 处理网络地址转换器（Network Address Translator，NAT）和防火墙在本文中，我们将向您展示如何构建一个信令服务，以及如何使用STUN和TURN服务器来处理现实世界中的连接难题。我们还解释了WebRTC应用程序如何处理多方通话并与VoIP和PSTN（也就是电话）等服务进行交互。什么是信令信令是协调通信的过程。为了使WebRTC应用程序能够建立一个“通话”，其客户需要交换以下信息： &nb

哪种TURN服务器正在被使用？

作者：Philipp Hancke（原文链接）翻译：刘通原标题：What kind of TURN server is being used? TURN作为WebRTC基础设施的重要一员，它负责帮助NAT穿透。但是使用它们有多频繁呢？以及使用情况可以告诉我们什么关于WebRTC开销的内容呢？两星期以前，我的朋友Gustavo Garcia在推特上问有多少WebRTC通话是通过TURN传递的。因为我喜欢钻研数据，所以我回答了他，但是要想在140个字之内说明白很困难。所以我想要在这篇博文中回答以下几个问题： # 失败率是多少？ # 通过TURN服务器传递的通话占比有多少？ # UDP，TCP和TLS TURN变体的相对占比是多少？这些数据对于运行WebRTC平台或者决定开发优先顺序来说都至关重要。首先，这些数据要如何测量？我们在appear.in运行rtcstats来进行这项工作，被提取出的一个特征就是类型，第一个有效ICE候选对的局部类型优先（local type preference）点击此处查看。局部类型优先（RFC 5245）会根据浏览器实现特定的值。对于Chrome来

STUN/TURN快速指南

作者：Fernando Vasquez（原文链接）翻译：刘通原标题：Quick Guide for STUN/TURN and WebRTC 为什么要用STUN/TURN ? 为了能让WebRTC在不同的网络之间穿行，我们就需要穿过防火墙，而且我们还要面对ISP所设置的种种限制。所以为了绕开这些限制，以及在接收端的防火墙上打开一个口让媒体通过，我们就需要依赖STUN/TURN服务器，目的是找到一条正确的路径（STUN），或者是作为一个中继服务器用来传输媒体（TURN）。在这个简单的指南中我们来一起设置一个基本的STUN/TURN服务器。我们一会要使用到STUN/TURN服务器的一个开源实现，Coturn。安装Coturn 我们假设你使用的Ubuntu 14.04 LTS服务器，运行一下指令：（点击此处查看源码）当安装完成之后，在terminal中运行以下指令：（点击此处查看源码）测试你的STUN/TURN服务器为了测试你的TURN服务器，你可以使用WebRTC团队提供的这个工具：https://webrtc.github.io/samples/src/c

将你的TURN服务器部署在与用户近的地方

作者：Philipp Hancke（原文链接）翻译：刘通当亚马逊AWS在伦敦新开设了一个地区时，我们就马上在那里部署了一个新的TURN服务器。那么这与ICE候选收集时间有什么关系呢？正如我之前的一篇博客中写的那样，ICE候选收集时间是对于通话建立时间而言一个很有用的替代值。它比通话建立时间要更容易观察因为其只由一个用户与TURN服务器之间的距离所决定，而不是两个用户各自的所处的位置。显然，这很大程度上取决于，以用户位置为参考你把TURN服务器部署在那里，这也让我在这种早些时候与别人产生了争论。这个时间也决定于你的用户是仅由TURN/UDP配置的，还是由TURN/TCP和TURN/TLS共同配置的，其中不开玩笑，TURN/TCP和TURN/TLS共同配置由于需要握手所以花费时间更长。 &nbs

Search Results for: TURN