大佬教程收集整理的这篇文章主要介绍了为什么 WebRTC 不能与对称 NAT 一起使用？，大佬教程大佬觉得挺不错的，现在分享给大家，也给大家做个参考。
假设我们有两个对等方 - A 和 B - 试图通过对称 NAT 建立 WebRTC 对等方连接。他们通过信令交换了 ICE 候选者。
A 的公共地址：IP_A : Port_A
B 的公共地址：IP_B : PorT_B
首先，A尝试连接到B
IP_A : Port_A ---> IP_B : PorT_B
但是请求被 B 的 NAT 拒绝了。只有 B 的 stuN 服务器才能在该地址连接 B。
接下来轮到B了。
IP_B : PorT_B ---> IP_A : Port_A
但是这里，不是应该建立连接吗？因为，当 A 第一次向 B 发送请求时，Peer A 的 NAT 表应该已经注册了 Peer B 的地址。因此，必须接受来自 B 的任何响应。但是，当然，它似乎不起作用。那么，我错在哪里？
我想我自己找到了答案。对称 NAT 的限制比我想象的还要严格。看维基百科的解释，
对称 NAT
问题是，对称 NAT 在向 Peer B 发送请求时，会为 Peer A 使用不同的 IP : Port 组合，而不是由眩晕。但是 Peer B 的远程描述仍然指向 IP_A : Port_A。因此，地址不匹配并且连接永远不会发生。也许港口预测系统仍然可以完成这项工作，我认为 :D
,如果您从映射/过滤的角度考虑，它会更有意义。其他 NAT 术语不能很好地描述事情的实际工作方式。我的答案来自RFC 4787和WebRTC for the Curious: ConnecTing
映射是指您的 NAT 为出站数据包分配 IP/端口。远程对等方可以将流量发送到此映射。过滤是关于谁可以使用这些映射的规则。
过滤和映射然后可以是地址相关和独立的。如果映射依赖于地址，则意味着每次联系新 IP/端口时都会创建一个新映射。如果映射与地址无关，则意味着无论您将流量发送到何处，都会重新使用它。这些规则同样适用于过滤。
对于您的原始问题，地址相关映射+过滤似乎导致了问题！
我仍然希望您描述的设置能够正常工作。 WebRTC 有 Peer Reflexive Candidates。 WebRTC 可以在 ICE 连接检查期间发现新的候选者。由于 ICE 已通过身份验证，我们可以接受来自尚未交换的 IP/端口的流量，我们只需要声明 ICE 用户片段和密码就是我们所期望的。
以上是大佬教程为你收集整理的为什么 WebRTC 不能与对称 NAT 一起使用？全部内容，希望文章能够帮你解决为什么 WebRTC 不能与对称 NAT 一起使用？所遇到的程序开发问题。
如果觉得大佬教程网站内容还不错，欢迎将大佬教程推荐给程序员好友。
本图文内容来源于网友网络收集整理提供，作为学习参考使用，版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ：384754419，请注明来意。