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

Posted 2023-02-23

【中文标题】在像 bittorrent 这样的点对点协议的情况下，NAT 遍历是如何工作的。

【英文标题】：How NAT traversal works in case of peer to peer protocols like bittorrent.

【发布时间】：2016-05-21 20:41:21

【问题描述】：

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

【参考方案1】：

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

换句话说，让 NAT 后面的客户端相互通信是可取的，但不会达到将主要资源（例如流量转发）用于该目标的程度。失败是一种选择。

因此它不使用 sip/turn/etc.

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

只要应用程序正在运行，PCP、NAT-PMP 或 UPnP-IGD 就与到 forward a port 的网关协商。 对于 TCP，可以使用source port binding（传出连接）和port reuse（侦听+传出）套接字选项为所有连接使用相同的本地端口，从而利用end-point independent (EIM) NAT mappings（也称为全锥形NAT）。 与 UDP 类似，应将单个套接字与 sendto/recvfrom 或等效 API 结合使用，以通过单个端口多路复用所有应用程序级连接，而不是为每个对等方创建一个套接字。 主要是 undocumented ut_holepunch extension，它使用可相互访问的 swarm 成员代替 stun 服务器。 一个可选的基于 UDP 的传输协议 (µTP)，可以与前面的几点结合使用。一般nat遍历用udp比较容易实现 IPv6 capability signalling，原则上允许客户端升级他们的连接，然后通过 PEX/DHT 八卦 v6 对等方。 提示用户执行手动端口转发

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

【讨论】：

你知道 libtorrent 是否与 TURN/STUN/ICE 服务器兼容？

@Gubatron 问题不清楚。你的意思是 libtorrent 是否可以充当 stun 服务器，或者它是否可以充当客户端来利用这些服务器进行 nat 遍历？

@the8472 可能是后者。