Vir*_*ren 5 sockets networking p2p tcp stun
我浏览了编程 P2P 应用程序SO 帖子。但我想我仍然不清楚 STUN 是如何在引擎盖下工作的。
所以,我想发表我的理解,并希望得到纠正。
根据示例
假设机器 (A) IP 正在192.168.1.2运行(在 STUN 服务器上的 TCP 客户端请求)4900(TCP 客户端请求 STUN 服务器通过 TCP 运行4900)并且 Stun 服务器返回了 Nat 设备的公共 IP,即128.11.12.13 8888
现在我希望机器 B(假设现在 B 通过公共 IP 知道128.11.12.13)通过端口3000(TCP)连接到机器 A
这之后发生了什么——
B 尝试通过 IP 连接 A 128.11.12.13
问题1:但是哪个端口?(它不能直接连接到端口 3000 )
我想答案是我将4900请求转发到3000.
但这里有一件事
问题 2:连接到 4900 上 STUN 服务器的 TCP 客户端怎么样(发送指示等)。如果应用了端口转发,从 Stun 服务器到 TCP 客户端的所有流量现在都将被重定向到端口 3000。对吗?
我在这方面正确吗?
有什么办法解决这个问题,还是我在这里大声思考?:)
实际上,您无法直接连接到端口 3000。您必须连接到在 NAT 上打开的端口,并且它是地址:在 STUN 响应中收到的端口
client A NAT STUN server client B
|---- STUN request --->| | |
| src:192.168.1.2:3000 | | |
| |---- STUN request ---->| |
| | src:128.11.12.13:8888 | |
| | | |
| |<----STUN response-----| |
| | ext:128.11.12.13:8888 | |
|<----STUN response----| | |
| ext:128.11.12.13:8888| | |
| |
|======= APP protocol over rendezvous server =====================>|
| my address is 128.11.12.13:8888 |
| |
|<======= APP protocol over rendezvous server =====================|
| my address is 1.2.3.4:9999 |
| |
|-- direct protocol -->| |
| src:192.168.1.2:3000 | |
| dst:1.2.3.4:9999 |<--------- direct protocol ----------------|
| | dst:128.11.12.13:8888 |
|<-- direct protocol --| |
| dst:192.168.1.2:3000 | |
| | |
Run Code Online (Sandbox Code Playgroud)
STUN 只向客户端提供可能在 NAT 设备上打开的外部 IP 地址和端口。客户端 B 必须尝试连接到此 IP 和端口 (128.11.12.13:8888) 并且客户端 A 必须侦听与 STUN 请求中的源地址:端口相同的 IP:端口 (192.168.1.2:3000) .
如果你很幸运,那么上面的场景效果很好。但是你可能不走运,因为有很多 NAT 类型,特别是对于 TCP,可能会发生一些错误。
编辑(对评论中其他问题的回答):
最好保持与 STUN 服务器的连接打开。NAT 设备在检测到连接关闭时可能会关闭针孔。但这取决于 NAT 设备内部处理,据我所知,这不是标准化的。
客户端 A 上直接协议的侦听套接字必须SO_REUSEADDR设置选项。如果设置了该选项,则可以与 STUN 服务器建立连接,然后在同一端口创建侦听套接字。
| 归档时间: |
|
| 查看次数: |
1553 次 |
| 最近记录: |