原作者：Levent-Levi（原文链接）
翻译：刘通
今天我们想要帮助你在webrtc-internals中找到当前处于活跃状态的连接。
为了确保这篇文章所写内容尽可能的准确，我决定请来Philipp Hancke来作为此篇文章的共同作者。
在我们开始之前，你要知道在chrome://webrtc-internals里面各参数的意义。如果你不知道的话，那么你应该好好读一下我们上一篇文章，其中解释了webrtc-internals中各个参数的意义。
好，重要事先说：
为什么这些很重要呢？
尽管你会经常的查询你连接和通道的数据，但你了解这些连接是如何建立的吗？
WebRTC允许通过这三条途径之一进行连接：
1 直接P2P
2 通过使用STUN（为了寻找公共IP地址）
3 通过使用TURN（为了让你所有的媒体都能穿过它进行传输）
那么你的连接使用的是那种连接方式？最终这则通话是通过TCP上的TURN进行的吗？
在两个时候这会对我们有用：
1 当我们想要搞明白在通话中发生了什么的时候，ICE协商是如何发生的，最终哪个候选项被使用，我们需要重新协商或者更换候选项吗—我们需要知道如何找到活跃的连接。
2 当我们想要从程序上了解它时—尤其是当我们在手机这些WebRTC数据时，以及尝试从其中确定测试结果时，或者在用户直播产品中我们的网络的表现如何时。
什么是WebRTC中的活跃连接？
WebRTC是使用ICE协议来寻找可能藏在NAT路由器后方的两个对等端的连接方法（如果你非常想了解细节的话，在RFC5245中有描述）。为了建立一个连接，每个对等端都会手机很多个候选地址。
其中的主机候选项表明了本地ip地址和端口。当你在webrtc-internals中扩展onicecandidate或者addIceCandidate事件时，本地ip和端口具有一个“typ host”。
类似，在serverreflexive候选项中，对等端询问STUN服务器它的公共ip地址。这些公共ip地址有“typ srflx”以及一个额外的raddr域展现了其发起的本地ip地址。
最后但是并不是不重要，这里面有传输候选项。在这里，对等端要求TURN服务器打开一个端口并传输数据。这些会随着“typ relay”展示在onicecandidate以及addIceCandidate中。为了让事情变得更加复杂，WebRTC用户既可以使用UDP，也可以使用TCP或者TLS来连接到TURN服务器。
让我们假设你在webrtc-internals中看见了很多onicecandidate和addIceCandidate通话。有一些情况中这些并不会发生，但是通常WebRTC都会使用一种叫“trickle ice”的技术。
一旦候选项被改变了，WebRTC引擎就会组建一组本地和远端候选，并且开始发送STUN包来检查是否产生了应答。尽管这些细节会隐藏在webrtc-internals之中。
上面的截屏是从Wireshark那里取来的，这是一个可以用来监测网络的小工具。它显示了在连接设定阶段一个TURN信息在会话中传输的情况。
我们如何在webrtc-internals中找到当前活跃的连接？
打开我们的建立WebRTC本地端到端连接示例，将你的扬声器静音并且开始一段通话。当然也要打开chrome://webrtc-internals。现在让我们看看能不能一起找到活跃的连接。
现在我们正在运行“本地端到端连接”的示例，有一些事情需要记住—它不使用STUN和TURN服务器，所以候选项交换的数量会比较小。我们故意选择这种情况，所以我们就不用梳理过乱的情况。你将要看到的只是在第一次连接的onicecandidate事件中4个候选项，以及在addIceCandidate事件中一个单独的候选项。
现在，那些候选对是被使用的呢？幸运的是，webrtc-internals会将活跃的对等对用粗体显示。通常这些的id会是“Conn-audio-1-0”。让我们展开它来看看为什么这些被加粗显示了：
其中最重要的是当前活跃连接的googActiveConnection的属性是真，在其他连接中是假。在这里我们看到很多属性，其中部分在前一篇文章我们已经讨论过了：
1 bytesReceived，bytesSent和packetsSent规定了通过此连接发送的字节数和数据包数。packetsReceived仍然是MIA但因为它不是规范的一部分，所以可能以后不会发生改变了。
2 googReadab规定了STUN包是否在此端被接收，googWritable规定响应是否被发送。这些google的属性被替换成requestsReceived，responsesSent，requestsReceived以及responsesSent标准计数器。
3 googLocalAddress和googRemoteAddress展现了本地IP和端口。当你需要使用Wireshark dump在webrtc-internals中对信息进行修正的时候就很有用了。googLocalCandidateType和googRemoteCandidateType给你更多关于是否是local，serverreflexive或者relayed的候选。
4 localCandidateId和remoteCandidateId告诉你本地和远端候选数据的名字。这些可以让你掌握更多的细节。
让我们在localCandidateId处和remoteCandidateId处查找一下本地和远端候选项。因为这里只有一个候选对，所以也是比较简单。
尽管有不同的类型，两个候选项都有着同样的信息：
# ipAddress是数据包发送到的地址或者从哪里发来的地址
# networkType让你可以辨别网络接口的类型
# portNumber告诉你数据包是发送到哪个端口或者从哪个端口发来的
# transport指定了候选项的传输协议，显示在候选项行中。通常这项是udp，除非使用的是ICE-TCP
# candidateType显示了是否是host，srflx，prflx或者relay候选。更多详细内容请参见规范。
# priority是在RFC 5245中定义的候选项优先级
其中最有趣的部分是优先级。当按照RFC 5245中定义的优先级来实现时，高八位规定了种类优先级。因为对于有candidateType传输的本地候选项，我们可以推测出在客户和TURN服务器之间的传输类型，所以优先级会引起很多人的兴趣。Chrome在传输候选项使用两级优先级，TURN/TCP优先级是1，TURN/TLS优先级是0。使用这种方法计算优先级意味着中继连接的优先级都比非中继连接的优先级要低，并且TURN服务器只会被当做后备选项来使用。正如我们之前所讨论过的，使用TURN/TCP（或者TURN/TLS）会较大幅度地改变WebRTC的表现。如果你觉得这块有些难理解，请不要担心，规范目前已经为了解释这个已经进行了更新。
在ICE重启时会发生什么？
目前为止，我们用了一个很简单的示例。让我们用philipp最喜欢的话题之一，ICE重启，来让事情变得更复杂一点。关闭之前的示例，让我们进到这个示例中来。接下来进行一个通话。你会在chrome://webrtc-internals中看到一个活跃的候选对。点击“重启ICE”按键。注意数据是如何在候选对Conn-audio-1-0发生变化的，ip地址如何变化的，以及STUN计数器是如何重启的。我们之前看到的数据现在（通常）与标识符Conn-audio-1-1一起被呈现在报告中。候选对之后不会再被使用，但是会保持在getStats（因此也会在webrtc-internals）中。
这是我们所没有预想到的。这看起来是底层的webrtc.org正在对报告重命名，活跃候选项通常是有Conn-audio-1-0 的id。它想一直以来就持续在那里的，但是也有一些缺点。其中，假设bytesSent数总会随着重启而增加，是不安全的，与我们上一篇文章中所写的ssrc型报告中错误的重设bytesSent计数器是类似的。
