Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[Enhancement] 节点存活检查建议 #651

Open
Mitsuhaxy opened this issue Sep 26, 2024 · 3 comments
Open

[Enhancement] 节点存活检查建议 #651

Mitsuhaxy opened this issue Sep 26, 2024 · 3 comments

Comments

@Mitsuhaxy
Copy link

Mitsuhaxy commented Sep 26, 2024 •
edited
Loading

Improvement Suggestion

对TCP4/6(DNS)的必要性有一些疑问。
TCP检查用HTTP 204code，UDP用DNS检查能否提升一点检查效率，特别是节点较多的情况，每次检查都有几百条连接。

Potential Benefits

建议取消TCP4/6(DNS)检查，可以少量优化性能，但不多，该建议优先级较低。
@dae-prow
Copy link
Contributor

dae-prow bot commented Sep 26, 2024

Thanks for opening this issue!

@mzz2017
Copy link
Contributor

mzz2017 commented Sep 26, 2024

@Mitsuhaxy 或许可以启发式探活，节点延时越高则本次触发探活概率越低，每次每个类型最多触发50个节点的探活

@Mitsuhaxy
Copy link
Author

Mitsuhaxy commented Nov 21, 2024 •
edited
Loading

@Mitsuhaxy 或许可以启发式探活，节点延时越高则本次触发探活概率越低，每次每个类型最多触发50个节点的探活

在引入新的DNS上游类型后，是否考虑重新设计节点检测方式，建议设置三种检测类型：
一、TCP检测，用于判断普通TCP流量走向
二、UDP检测，用于判断普通UDP流量走向（或许可以使用STUN检测，允许优先使用FULLCONE NAT类型的节点）
三、DNS检测，同时检测DoUDP、DoTCP、DoH、DoT、DoQ、DoH3，用于判断DNS服务器可用性

关于启发式探活或许设置为ln(delay)*delay，单位为秒
节点A：延迟50ms，下次探测时间为ln50*50=195.60s
节点B：延迟120ms，下次探测时间为ln120*120=574.50s
节点C：延迟230ms，下次探测时间为ln230*230=1250.75s

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@Mitsuhaxy @mzz2017