实用的 NAT 穿越，实现可靠的网络连接 [英] Practical NAT traversal for reliable network connections

问题描述

我看过很多类似的问题，以及相应的维基百科文章(NAT traversal、STUN、TURN, TCP 打孔)，但是海量的信息并不能真正帮助我解决这个非常简单的问题:

I've seen and read a lot of similar questions, and the corresponding Wikipedia articles (NAT traversal, STUN, TURN, TCP hole punching), but the overwhelming amount of information doesn't really help me with my very simple problem:

我正在编写一个 P2P 应用程序，我希望我的应用程序在 NAT 后面的两个用户能够相互连接.连接必须可靠(与 TCP 的可靠性相当)所以我不能只切换到 UDP.该解决方案应适用于当今的通用系统，无需重新配置.如果有帮助，该解决方案可能涉及可连接的第 3 方，只要它不必代理整个数据(例如，获取对等方的外部 (WAN) IP 地址).

I'm writing a P2P application, and I want two users of my application behind NAT to be able to connect to each other. The connection must be reliable (comparable to TCP's reliability) so I can't just switch to UDP. The solution should work on today's common systems without reconfiguration. If it helps, the solution may involve a connectible 3rd-party, as long as it doesn't have to proxy the entire data (for example, to get the peers' external (WAN) IP addresses).

据我所知，我唯一的选择是使用可靠的 UDP"库 + UDP 漏洞冲孔.是否有(C/C++)库?我在 enet-do-you-use-when-you-need-reliable-udp/107684#107684">相关问题，但它只处理解决方案的前半部分.

As far as I know, my only option is to use a "reliable UDP" library + UDP hole punching. Is there a (C/C++) library for this? I found enet in a related question, but it only takes care of the first half of the solution.

还有什么吗?我看过的东西:

Anything else? Things I've looked at:

1. Teredo 隧道 - 需要操作系统和/或用户配置的支持
2. UPnP 端口转发 - UPnP 并非在任何地方都存在/启用
3. TCP 打孔 似乎是实验性的，仅在某些情况下有效
4. SCTP 的支持甚至低于 IPv6.SCTP over UDP 只是花哨的可靠 UDP(见上文)
5. RUDP - 几乎没有主流支持
6. 根据我对 STUN、STUNT、TURN 和 ICE 的理解，他们都不会在这里帮助我.

1. Teredo tunnelling - requires support from the operating system and/or user configuration
2. UPnP port forwarding - UPnP isn't present/enabled everywhere
3. TCP hole punching seems to be experimental and only work in certain circumstances
4. SCTP is even less supported than IPv6. SCTP over UDP is just fancy reliable UDP (see above)
5. RUDP - nearly no mainstream support
6. From what I could understand of STUN, STUNT, TURN and ICE, none of them would help me here.

推荐答案

ICE 收集了一个要连接的候选 IP/端口目标列表.每个 peer 收集这些信息，然后每个 peer 按顺序对每个候选者运行连接检查，直到检查通过或检查失败.

ICE collects a list of candidate IP/port targets to which to connect. Each peer collects these, and then each runs a connectivity check on each of the candidates in order, until either a check passes or a check fails.

当 Alice 尝试连接到 Bob 时，她以某种方式获得了可能的方式列表 - 由 Bob 确定 - 她可以连接到 Bob.ICE 称这些候选人为.例如，Bob 可能会说:我的本地套接字的 192.168.1.1:1024/udp，我的外部 NAT 绑定(通过 STUN 找到)是 196.25.1.1:4454/udp，您可以在 1.2 调用媒体中继(中间盒).3.4:6675/udp".Bob 将其放入 SDP 数据包(对这些不同候选者的描述)中，并以某种方式将其发送给 Alice.(在 SIP 中，ICE 的原始用例，SDP 在 SIP INVITE/200/ACK 交换中携带，建立 SIP 会话.)

When Alice tries to connect to Bob, she somehow gets a list of possible ways - determined by Bob - she may connect to Bob. ICE calls these candidates. Bob might say, for example: "my local socket's 192.168.1.1:1024/udp, my external NAT binding (found through STUN) is 196.25.1.1:4454/udp, and you can invoke a media relay (a middlebox) at 1.2.3.4:6675/udp". Bob puts that in an SDP packet (a description of these various candidates), and sends that to Alice in some way. (In SIP, the original use case for ICE, the SDP's carried in a SIP INVITE/200/ACK exchange, setting up a SIP session.)

ICE 是可插拔的，您可以配置候选的精确性质/数量.您可以尝试直接链接，然后询问 STUN 服务器进行绑定(这会打NAT 中的漏洞，并告诉您该漏洞的外部 IP/端口，您将其放入会话描述中)，然后回过头来询问 转向服务器以中继您的数据.

ICE is pluggable, and you can configure the precise nature/number of candidates. You could try a direct link, followed by asking a STUN server for a binding (this punches a hole in your NAT, and tells you the external IP/port of that hole, which you put into your session description), and falling back on asking a TURN server to relay your data.

ICE 的一个缺点是您的同行交换了 SDP 描述，您可能会或可能会不喜欢.另一个是 TCP 支持仍处于草案形式，这可能或者对您来说可能不是问题.[更新:ICE 现在正式成为RFC 6544.]

One downside to ICE is that your peers exchange SDP descriptions, which you may or may not like. Another is that TCP support's still in draft form, which may or may not be a problem for you. [UPDATE: ICE is now officially RFC 6544.]

游戏经常使用UDP，因为旧数据没用.(这就是为什么 RTP 通常运行在 UDP 之上.)一些 P2P 应用程序经常使用中间件或中间件网络.

Games often use UDP, because old data is useless. (This is why RTP usually runs over UDP.) Some P2P applications often use middleboxes or networks of middleboxes.

IRC 使用中间件网络:IRC 服务器形成网络，客户端连接到附近的服务器.从一个客户端到另一个客户端的消息可能会通过服务器网络传输.

IRC uses a network of middleboxes: IRC servers form networks, and clients connect to a near server. Messages from one client to another may travel through the network of servers.

如果没有这一切，你可以看看 BitTorrent 的架构，看看他们如何处理 NAT 问题.正如 CodeShadow 在下面的评论中指出的那样，BitTorrent 依赖于网络中可访问的对等点:在某种意义上，一些对等点形成了一个中间盒网络.如果这些中间件可以充当中继器，那么您将拥有一个类似 IRC 的架构，但该架构是动态设置的.

Failing all that, you could take a look at BitTorrent's architecture and see how they handle the NAT problem. As CodeShadow points out in the comments below, BitTorrent relies on reachable peers in the network: in a sense some peers form a network of middleboxes. If those middleboxes could act as relays, you'd have an IRC-like architecture, but one that's set up dynamically.

这篇关于实用的 NAT 穿越，实现可靠的网络连接的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！