为 webRTC 使用特定端口

Posted 2023-04-15

【中文标题】为 webRTC 使用特定端口

【英文标题】：Use specific ports for webRTC

【发布时间】：2015-06-16 07:32:21

【问题描述】：

当使用 webRTC 创建点对点音频连接时，如果用户在路由器后面，我们使用的 STUN 服务器将返回公共 IP。现在在 ICE 对象中，我可以看到 rport 始终介于 50000 和更高之间。

有没有办法使用特定的端口，这样用户就不必打开所有这些端口？

【问题讨论】：

当您使用其中一种浏览器实现时不会。但是，如果您使用原生 API 编写，我相信您可以在那里限制端口。

你确定端口是由浏览器而不是由 STUN 服务器定义的吗？

ICE 候选收集器使用特定的端口范围，并且只使用该范围内的端口（或者它只是任何端口）。

【参考方案1】：

有没有办法使用特定的端口，这样用户就不必打开所有这些端口？

我认为你有一个误解。 STUN 和 ICE（包括其 WebRTC 衍生产品）的全部意义在于避免任何人不得不在其 NAT 上打开端口。相反，STUN 和 ICE 会动态打开端口。

这是它的工作原理（非常简短的描述）。

客户端在随机端口（例如 50001）上打开一个套接字

使用该套接字联系 STUN 服务器以发现该套接字的外部 IP：端口映射。 （例如 192.168.1.2:50001 映射到 1.2.3.4:50001）。端口不一定必须在内部地址和外部地址之间匹配，但它们通常会匹配，因此我将在本示例中保持这一点。

通过外部机制（SIP、XMPP、Jingle、cups with strings），交换两个节点的候选地址列表。这包括收集到的所有已知的内部和外部地址（例如 192.168.1.2:50001 和 1.2.3.4:50001）。

使用在步骤 1 中打开的同一个套接字，双方直接在彼此之间发送 (STUN) 消息（UDP 数据包）。第一对消息可能被路由器/防火墙阻止。但是由于一方向远程地址发起了出站数据包，因此允许来自该地址的后续数据包返回。这称为“打孔步骤”。因此，端口是动态打开的，无需路由器进行任何特定配置。

希望这会有所帮助。

【讨论】：

我明白了。但是除非我手动打开路由器上的端口，否则 webRTC 将无法正常工作。这是数百万人使用的标准 FritzBox 路由器，我不认为我有花哨的设置。如果我自己不打开端口，STUN 将无法工作（我看到 ICE 候选者的内部和外部地址，但无法进行通信）并且它会退回到 TURN（然后工作）。如果端口是开放的，STUN 可以工作，不需要 TURN。如果您知道这是为什么 - 我将非常感谢。

如果仅提供 STUN 服务器时连接失败，但存在 TURN 时连接成功，这可能是因为您的路由器/ISP 的行为类似于“对称 NAT”（也称为地址相关映射）。这是一种技术上的说法，即端口映射行为是不可预测的。当您打开 NAT 上的端口以定向到您的 PC/设备时，端口映射将变得一致。

使用代码 here 运行 stunclient --mode full stun.stunprotocol.org 以验证您的 NAT 行为。

什么是cups-with-strings控制机制？... Doh！

这里要注意的是入站出站端口的区别。端口应该对外开放，这就是第 1 步的工作方式。如果出站端口被阻塞，则无法使用，打孔也无法使用。

【参考方案2】：

除非您在自己的应用程序中使用 webrtc API，否则您无法以编程方式进行。浏览器将从本地范围中选择特定的本地端口；然后它将在 SDP 和 ICE 候选人信息中通知您。

STUN 服务器仅帮助发现客户端是否位于 NAT/防火墙后面；然后 ICE 使用此信息建立对等连接。

我听说某处可能有一种方法可以通过 Chrome 策略模板（企业用来限制 Chrome 设置）来控制该端口范围 - http://www.chromium.org/administrators/policy-templates。可能值得研究...