mirror of
https://github.com/fatedier/frp.git
synced 2026-05-15 08:05:49 -06:00
[GH-ISSUE #4159] [Feature Request] xtcp打洞时如果是全锥形(或地址受限锥形)nat和对称形nat使用mode0的方式 #3277
Labels
No labels
In Progress
WIP
WaitingForInfo
bug
doc
duplicate
easy
enhancement
future
help wanted
invalid
lifecycle/stale
need-issue-template
need-usage-help
no plan
proposal
pull-request
question
todo
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/frp#3277
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @meiweimuli on GitHub (Apr 15, 2024).
Original GitHub issue: https://github.com/fatedier/frp/issues/4159
Describe the feature request
xtcp打洞时如果一边是全锥型(或地址受限锥形)nat，另一边是对称型nat，从对称型这边直接给全锥型发消息，连接就能创建成功了吧。
现在frp首选的方式还是mode1和mode2的预测端口。
Describe alternatives you've considered
No response
Affected area
@fatedier commented on GitHub (Apr 15, 2024):
实际上，这并不是非常重要。
你如果阅读了代码，应该能看到我们只区分了 HardNAT 和 EasyNAT，而不是具体的各种类似
全锥型、地址受限锥形等等类型。探测具体的这些类型，并不是一件简单的事情，依赖 STUN server 的实现，有时甚至会让问题变得更复杂。如果 mode0 能够成功，那么 mode1/mode2 大概率也能够成功（为了 cover 边界情况，会主动把 mode0 再放到尝试策略的最后），我们需要的是 p2p 打洞的成功率，一旦成功，这次策略会被记录，这个链路也可以被持续复用，下次优先尝试，没有额外的成本。所以简化的模型就已经足够。
设计之初，测试过部分 STUN Server，很多并没有完全按照协议来实现，结果并不可靠，并且还依赖响应超时来识别类型，流程多的时候，探测类型耗时也会很长，对用户很不友好。考虑过让用户在自己确认自己 NAT 类型的情况下，主动提供辅助信息来调整策略优先级，但并不是必须，暂时不会增加这个复杂度。且所谓的 全锥形(或地址受限锥形) 的比例应该并不高。
@meiweimuli commented on GitHub (Apr 15, 2024):
mode2确实已经有超过0.98的成功率了，已经够用了。