session - XMPP 可以在 NAT 环境中工作吗？

Question

XMMP 服务器使用 NAT 向客户端提供的公共(public)端点(IP + 端口)向 NAT 后面的客户端发送推送通知。但是这个端点被 NAT 分配给这个特定的客户端多长时间，如果 NAT 将相同的端点分配给另一个客户端会发生什么？如何解决这个问题？

Answer 1

XMPP 使用标准的 TCP 连接。只要连接存在，NAT 就会保持关联(除非它们被严重破坏)。

更新:我的发言的最后一部分可以扩大一点。确实存在严重损坏的 NAT 实现。通常这些只是一小部分，但许多(大多数？)流行的 XMPP 客户端确实确保它们通过空闲连接发送某种保活。

您可以使用三种 keepalive 我将在此处按带宽/处理要求的顺序列出它们:

TCP keepalives 是一个很好的轻量级选项，特别是一旦启用它们，它们就会由操作系统自动处理。如何启用它们取决于您的语言和框架，但在最低级别，您需要启用 SO_KEEPALIVE socket 上的选项。

TCP keepalive 有两个问题。一是您无法从应用程序中控制它们(除非您编写特定于平台的代码)。第二个问题是，一些 NAT 实现非常糟糕，以至于它们也会忽略 TCP keepalives!但是你现在希望下降到一个很小的百分比。

所以另一个选择是whitespace keepalives .由于这些涉及跨流的数据，因此即使是忽略保活的损坏的 NAT，您也应该是安全的。

空白保活只涉及在 XMPP 流空闲时发送空格字符 (' ')。 XML 和 XMPP 允许元素之间有无限的空白，并且它会被接收者简单地忽略。

最后，您可以使用成熟的 XMPP pings (XEP-0199) .这些涉及结束一个实际的 <iq/> 'get' 节到服务器，然后它必须回复。这可以确保数据双向流动，并且即使是最坏的 NAT 实现也应该使您的连接保持活跃。

好的，我应该提一下，还有一个更糟糕的 NAT 类别。我已经看到 NAT 出于多种原因会简单地“忘记”您的映射，包括它们的映射表已满，或者只是在一个计时器之后。您无法解决这些问题，它们不适用于任何长期存在的 TCP 连接。那时您可能会做的最好的事情是使用 BOSH (本质上是 XMPP over HTTP)。

结论:如果您担心您的应用程序可能在其中一些设备后面运行，我建议使用以下算法(可能会调整确切时间，但我建议将这些作为最小值):

如果 60 秒内没有发送任何数据，请发送一个空格字符。

如果您在 120 秒内没有收到任何数据，请向您的服务器发送 XMPP ping。

如果服务器在合理的时间内没有回复 ping，请重新连接。

由于损坏的 NAT 设备的行为超出了任何标准协议(protocol)规范，因此自然不可能设计出一个完美的解决方案，始终与所有这些设备一起工作。您只需要接受这些只是一小部分，而这些对于工作的 NAT 设备都无关紧要(尽管根据您的应用程序的需要，还有其他类型的网络中断可能使定期保持事件/ping 成为一个好主意)。