在像 bittorrent 这样的对等协议的情况下,NAT 遍历是如何工作的。

How NAT traversal works in case of peer to peer protocols like bittorrent.

我了解 NAT 穿越以及 STUN、TURN 和 ICE 及其使用。我想知道这些是否在像 bittorrent 这样的对等文件共享应用程序中实现。跟踪器是否通过帮助使用 STUN 创建直接连接或通过 TURN 中继来促进 NAT 后面的对等点相互通信。在分布式哈希 Table(DHT) 的情况下,一个对等点如何与 NAT 后面的另一个对等点通信?

BitTorrent 不需要连接到群中的任何特定成员,它不是两个特定端点想要相互交谈的 p2p 聊天协议。它只关心swarm的连接图有足够高的连接度。

换句话说,让 NAT 后面的客户端相互通信在某种程度上是可取的,但还没有达到将主要资源(例如流量转发)花费在该目标上的程度。在单个节点级别上,故障是一种选择。 因此它不使用 sip/turn/etc.

当然,随着不可访问节点比例的增加,整体集群级别的性能仍然会下降。如果没有人可以接受传入的连接,则 BitTorrent 无法工作。

各种客户使用以下方法的某种组合来改进批量传输连接的连接性:

  • PCP, NAT-PMP or UPnP-IGD negotiation with the gateway to forward a port只要申请是运行.
  • 对于 TCP,可以使用 source port binding (outgoing connections) and port reuse (listen + outgoing) socket options to use the same local port for all connections to exploit end-point independent (EIM) NAT mappings(也称为全锥 NAT)。
  • 与 UDP 类似,应该将单个套接字与 sendto/recvfrom 或等效 API 结合使用,以通过单个端口多路复用所有应用程序级连接,而不是为每个对等创建一个套接字。
  • 主要undocumented ut_holepunch extension使用相互可达的群成员代替眩晕服务器。
  • 一个可选的基于 UDP 的传输协议 (µTP),可以与前面的要点结合使用。一般nat穿越用udp
  • 更容易实现
  • IPv6 capability signalling,原则上允许客户端升级他们的连接,然后通过 PEX/DHT.
  • 八卦 v6 对等点
  • 提示用户执行手动端口转发

在 DHT 的情况下,仅使用前两点(网关协商和端口重用)。尝试对单个请求-回复周期进行 nat 遍历的开销将 >100%,不值得。