WebRTC在您离开时依然运行，Pion 中自动重选机制概述

视频通话的网络连接听起来很简单。你把视频发送到服务器，服务器再把视频发送回来。但这种思维模型在现实世界中会失效。一个最初在稳定的家庭Wi-Fi上建立的连接，可能会因为有人走出家门而突然需要切换到蜂窝网络。真正的挑战不仅仅是连接两个点！而是在你所依赖的网络发生变化时，保持连接。

有了自动重选机制，Pion 现在可以完全无缝地处理这个问题，让你的媒体流畅传输，不会出现任何中断。它的工作原理是定期检测是否有新的连接候选可用，并自动切换到质量最高的候选连接，利用了WebRTC中的一项名为重选（renomination）的功能。

WebRTC 如何建立连接？

WebRTC 中两个对等体之间的连接是通过在信令阶段交换候选者来建立的。这些候选者可以是主机候选者、服务器反射候选者、对等体反射候选者或中继候选者。各种候选者的详细信息在 WebRTC for the Curious 中有更详细的解释，但相关的细节是，对于每个候选者，两个对等体都会打开端口进行通信。

最终，控制方对等体选择一个候选者，并告知受控方对等体在绑定请求中使用它。这个候选者就成为媒体流经的选定候选者。此后，未使用的端口将被关闭。

但是等等！这个握手过程相当慢。为了加速并更快地开始媒体流传输，WebRTC 允许媒体在正式选定候选者之前通过任何候选者进行传输。这减少了对等体之间的一些往返，从而降低了连接延迟，这个过程被称为激进提名。

使用重新提名变更候选者

现在，如果我们从未提交候选者会怎么样？能够通过任何有效的候选者发送媒体流是很奇特的，事实上也相当有用，因为它意味着我们有多种利用的途径。这被称为重新提名。

在重新提名下，控制端告诉被控制端，它希望能够重新提名候选者。当被控制端收到绑定请求时，它不会关闭端口，而是保持打开状态。这允许控制端随意选择新的候选者，而被控制端将接受通过该候选者的媒体流，从而有效地使我们能够在媒体流传输过程中切换候选者。

这听起来协商起来可能很复杂，但实际上就是在连接握手中设置一个标志，以确保双方都了解重新提名的意愿，这意味着在Pion中实现此功能相当于跟踪一个计数器。

现在Pion正在利用WebRTC的积极提名状态，保持候选对象开放，并且有能力选择一个新的候选对象。

自动化处理

理想情况下，WebRTC 连接可以自动完成此操作，因此用户无需进行选择。毕竟，手动重新提名候选者看起来很有用，但用户体验很繁琐。让我们使其自动化！

为了实现这一点，我们需要解决两个问题：了解当前候选者何时变差，以及发现何时出现全新的候选者。

检测候选者何时变差：事实证明，这已经内置于 WebRTC 中。在首次连接建立阶段，候选者会被 ping、评估并根据往返时间、丢包率和候选者类型进行排名。同样的排名可以定期执行，而不仅仅是在初始化时执行。因此，连接可以循环运行此过程，并在网络状态发生变化时自动重新提名候选者。

发现新的候选者：当一个全新的候选者上线时会发生什么？例如，如果我在通话中途连接到 Wi-Fi 网络，手机会收到一个全新的 IP 地址。

这也内置于 WebRTC 中，以 trickle ICE 的形式！如果启用了 trickle ICE，候选者交换可以在初始连接握手后继续进行，直到双方声明他们已经穷尽了候选者搜索。在自动重新提名的基础上，我们更进一步，禁用穷尽声明，而是定期检查新的候选者。当一个新的候选者到达时，我们使用正常的 trickle ICE 机制在两个对等方之间交换它。