github-starred/frp

Fork 0

mirror of https://github.com/fatedier/frp.git synced 2026-05-15 08:05:49 -06:00

[GH-ISSUE #964] 我想问下p2p点对点穿透的问题 #768

New issue

Closed

opened 2026-05-05 12:29:27 -06:00 by gitea-mirror · 7 comments

gitea-mirror commented

2026-05-05 12:29:27 -06:00

Owner

Originally created by @bianchengxiaobei on GitHub (Nov 4, 2018).
Original GitHub issue: https://github.com/fatedier/frp/issues/964

一端是Full cone的nat类型，一端是4G的对称nat类型，能否穿透成功？

Originally created by @bianchengxiaobei on GitHub (Nov 4, 2018). Original GitHub issue: https://github.com/fatedier/frp/issues/964 一端是Full cone的nat类型，一端是4G的对称nat类型，能否穿透成功？

gitea-mirror closed this issue

2026-05-05 12:29:28 -06:00

gitea-mirror commented

2026-05-05 12:29:29 -06:00

Author

Owner

@IoTServ commented on GitHub (Nov 5, 2018):

full cone 跟所有类型都可以，此外，对称型跟Restricted Cone NAT型也可以，不知道这些情况frp支持怎么样

@IoTServ commented on GitHub (Nov 5, 2018): full cone 跟所有类型都可以，此外，对称型跟Restricted Cone NAT型也可以，不知道这些情况frp支持怎么样

gitea-mirror commented

2026-05-05 12:29:30 -06:00

Author

Owner

@bianchengxiaobei commented on GitHub (Nov 5, 2018):

我试过4G的对称nat，他的端口是无规律跳跃的。
比如full cone端和4G端通过一台公网服务器，都知道对方的nat的公网ip和端口，但是由于4G是对称的，当他发送给full cone打洞消息的时候，端口就会改变，而且我做过实验，端口改变是跳跃无规律的。那full cone该发送打洞到哪个地址？
所以这时候就不好打洞，说难听点，更本不现实。65535-1024，卧槽，50000多个端口，鬼知道哪个？

@bianchengxiaobei commented on GitHub (Nov 5, 2018): 我试过4G的对称nat，他的端口是无规律跳跃的。比如full cone端和4G端通过一台公网服务器，都知道对方的nat的公网ip和端口，但是由于4G是对称的，当他发送给full cone打洞消息的时候，端口就会改变，而且我做过实验，端口改变是跳跃无规律的。那full cone该发送打洞到哪个地址？所以这时候就不好打洞，说难听点，更本不现实。65535-1024，卧槽，50000多个端口，鬼知道哪个？

gitea-mirror commented

2026-05-05 12:29:31 -06:00

Author

Owner

@IoTServ commented on GitHub (Nov 5, 2018):

我试过4G的对称nat，他的端口是无规律跳跃的。
比如full cone端和4G端通过一台公网服务器，都知道对方的nat的公网ip和端口，但是由于4G是对称的，当他发送给full cone打洞消息的时候，端口就会改变，而且我做过实验，端口改变是跳跃无规律的。那full cone该发送打洞到哪个地址？
所以这时候就不好打洞，说难听点，更本不现实。65535-1024，卧槽，50000多个端口，鬼知道哪个？

你想想，4G设备主动连接full cone那个端口能不能通？是通的吧，因为不管连的人的ip、端口是哪个都通，对称型去连也一样

@IoTServ commented on GitHub (Nov 5, 2018): > 我试过4G的对称nat，他的端口是无规律跳跃的。 > 比如full cone端和4G端通过一台公网服务器，都知道对方的nat的公网ip和端口，但是由于4G是对称的，当他发送给full cone打洞消息的时候，端口就会改变，而且我做过实验，端口改变是跳跃无规律的。那full cone该发送打洞到哪个地址？ > 所以这时候就不好打洞，说难听点，更本不现实。65535-1024，卧槽，50000多个端口，鬼知道哪个？你想想，4G设备主动连接full cone那个端口能不能通？是通的吧，因为不管连的人的ip、端口是哪个都通，对称型去连也一样

gitea-mirror commented

2026-05-05 12:29:31 -06:00

Author

Owner

@bianchengxiaobei commented on GitHub (Nov 5, 2018):

4G主动连接full cone端，但是full cone这端的nat没有“洞”，因为full cone更本不知道对称端的nat层的地址。所以full cone会把4g发的消息丢弃掉。

@bianchengxiaobei commented on GitHub (Nov 5, 2018): 4G主动连接full cone端，但是full cone这端的nat没有“洞”，因为full cone更本不知道对称端的nat层的地址。所以full cone会把4g发的消息丢弃掉。

gitea-mirror commented

2026-05-05 12:29:31 -06:00

Author

Owner

@IoTServ commented on GitHub (Nov 5, 2018):

晚上我回去试一下，大概9点，现在在上班

@IoTServ commented on GitHub (Nov 5, 2018): 晚上我回去试一下，大概9点，现在在上班

gitea-mirror commented

2026-05-05 12:29:32 -06:00

Author

Owner

@cccooo commented on GitHub (Nov 19, 2018):

如果是symmetric nat就比较复杂，机器连接的端口都不是固定的，peer A to peer B连接的端口和服务端连接端口不一致，解决的方法最简单就是通过服务器统一端口转发，那不算是p2p，用stcp就可以了。
如果双方是symmetric nat，可以猜测peer开放在nat上端口，如 https://github.com/jflyup/nat_traversal 里面的算法，多尝试几次，按peer在nat上变动的端口规律去猜测端口，或者增大并行尝试连接数，也有很大几率会成功。
如果一方有固定端口，那就需要服务端通知非固定端口那一方去主动连接，也是可行的

@cccooo commented on GitHub (Nov 19, 2018): 如果是symmetric nat就比较复杂，机器连接的端口都不是固定的，peer A to peer B连接的端口和服务端连接端口不一致，解决的方法最简单就是通过服务器统一端口转发，那不算是p2p，用stcp就可以了。如果双方是symmetric nat，可以猜测peer开放在nat上端口，如 https://github.com/jflyup/nat_traversal 里面的算法，多尝试几次，按peer在nat上变动的端口规律去猜测端口，或者增大并行尝试连接数，也有很大几率会成功。如果一方有固定端口，那就需要服务端通知非固定端口那一方去主动连接，也是可行的

gitea-mirror commented

2026-05-05 12:29:32 -06:00

Author

Owner

@bianchengxiaobei commented on GitHub (Nov 19, 2018):

4g是无规律的，连接两台不同ip的公网，一个10000，一个50000，中间差几w。。。。
不可能猜端口了，几w个性能消耗不起。只能通过转发了。

@bianchengxiaobei commented on GitHub (Nov 19, 2018): 4g是无规律的，连接两台不同ip的公网，一个10000，一个50000，中间差几w。。。。不可能猜端口了，几w个性能消耗不起。只能通过转发了。