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

Question

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

Answer 1

BitTorrent 不需要连接到 swarm 中的任何特定成员，它不是一个 p2p 聊天协议(protocol)，两个特定端点想要相互交谈。它只关心swarm的连接图是否有足够高的连接度。
换句话说，让 NAT 后面的客户端相互通信是可取的，但不是为了实现该目标而花费大量资源(例如流量转发)。在单个节点级别故障是一种选择。
因此它不使用 sip/turn/etc。
当然，在聚合集群级别的性能仍然会随着不可达节点的增加而降低。如果没有人可以接受传入的连接，那么 BitTorrent 就不起作用。
各种客户端使用以下方法的某种组合来改进批量传输连接的连接性:

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 的传输协议(protocol) (µTP)，可以与前面的几点结合使用。一般nat遍历用udp更容易实现

IPv6 capability signalling ，原则上允许客户端升级他们的连接，然后通过 PEX/DHT 八卦 v6 对等点。

提示用户执行手动端口转发

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