在某些消息传递系统中，两个消息传递客户端在聊天或语音呼叫中直接相互发送/接收数据包。我认为基本机制是（例如TCP）：这些客户端程序打开一个侦听TCP套接字并告诉消息传递/协调服务器它们的IP / PORT对。然后，客户端程序从消息传递/协调服务器检索另一方的IP / PORT。然后其中一个（让我们说A）然后用另一个（比如说B）用检索到的IP / PORT对B启动一个TCP。
当被动客户端B（等待TCP SYN数据包）不在NAT或代理之后时，这很好。但如果B在NAT或代理后面，则IP / PORT对实际上是NAT或代理的公共网络接口。
所以我的问题是，当NAT或代理收到TCP SYN时，它的反应是什么？他们如何将TCP SYN中继到其后面的相应主机/进程？
答案 0 :(得分：0)
我怀疑你最初的假设是否正确。他们更可能打开到服务器的活动连接，服务器在它们之间路由数据。它简单得多，你描述的问题就消失了。
答案 1 :(得分：0)
这个问题显然很久以前就被问到了，但仍然......
聊天和语音/视频通话的处理方式完全不同。在聊天的情况下，您可能使用XMPP协议，其中两端将连接到服务器并通过它交换数据。 XMPP驻留在第4层上的TCP上，因为在这种情况下，可靠性优先于延迟。由于客户端是打开并维护连接的客户端，因此在这种情况下不会出现NAT问题。
另一方面，语音/视频通话稍微复杂一些，所以你通常会：
信令通常使用一些高层协议（如SIP（会话启动协议））通过TCP。这种通信将通过服务器。媒体使用诸如RTP（实时传输协议）之类的更高层协议来越过UDP，并且这部分通信通常是点对点的。单个UDP端口可用于发送和接收一个语音/视频信道的流量。此外，您可能希望在通话到位时获得有关通话质量的信息，因此您可以减少使用的带宽以避免/减少数据包丢失。为此，您将使用RTCP（实时传输控制协议）等协议。在这种情况下，NAT遍历至关重要！由于两个客户端都不知道他们的公共IP地址，因此您需要一个内部网络（在公共互联网上）的服务器，它可以告诉“如何从外部看到”，即在NAT后面。在例如WebRTC世界这台服务器都知道ICE。在同伴发现它是如何从互联网上可见之后，它会将该信息放入信令消息的SDP片段中，以便另一端可以通过互联网到达它。请记住，执行NAT的路由器可能还需要一些额外的设置来保持正在使用的语音/视频UDP端口的跟踪（从NAT回流到您的流量）。
最后，在这些情况下还有其他解决方案，但这取决于您的设置。如果您正在为最终用户编写软件，则以前的解释将适用。但是，如果您正在为企业市场编写软件，那么在公司网络边界附加额外服务器（称为EDGE）等解决方案将是一种常见的方法。
我可以写几个小时，但这应该足以开始了......：）