wen-long

Read this https://www.reddit.com/r/selfhosted/comments/t3ijex/password_protected_doh_server_configuration/ some dns providers like nextdns.io use the method above

不太明白解决方案的代码呢，假设按 30s 3次，服务启动后 ``` 第 0秒一次 计数=1 第31秒一次 计数=2 第61秒一次 计数=3 ，expire 30 第62秒一次 计数=4 ，//失败了 ``` 这种情况是预期的么？

I use port-mirroring_1.4.2_ar71xx which you offered in README.md router band is GL.iNet 6416 openwrt CC,download from https://downloads.openwrt.org/chaos_calmer/15.05/ar71xx/generic/openwrt-15.05-ar71xx-generic-gl-inet-6416A-v1-squashfs-sysupgrade.bin I'm online, maybe you can use teamviewer or something to directly access my...

HTTP2 Multiplexing mux multi http connection to one connection. Thus, speedtest result will always same as a single connection test result. some technique to solve this, like use different domain,...

相关 https://github.com/go-gost/gost/issues/79

在 m1 上使用确实有此问题。 使用 [ttfb.sh](https://github.com/jaygooby/ttfb.sh) 脚本结合 [gost](https://github.com/ginuerzh/gost) `ss+mws` 方式测试延迟，发现 shadowtls 有明显的提升。特别的，shadow-tls-x86_64-apple-darwin 比 shadow-tls-aarch64-apple-darwin 有更为显著的延迟增加。 我也对比 Surge 的 snell+shadowtls 实现观察。发现 Surge 只有小幅提升。 多次测试结果均一致，shadow-tls rust 实现总是有随机性延迟增加，我怀疑是 io api 使用不当导致的。如果能有 surge 以外的其他语言的开源实现来对比就好了。

补充说明：上述几项测试的延迟与握手无关，是握手完毕后，对同一条 TCP 复用的延迟。ss+mws 方式直接连接或通过 trijan,naiveproxy,ss 进行测试都是稳定的最低延迟，没有现象指向这是 gost 的问题。只有 shadow-tls 出现大概率随机延迟增加现象。

继续补充说明： 1. 延迟增加总是出现在使用 mux 时，当借助 surge 使用 http connection reuse 时，rust 实现的 shadowtls 没有出现延迟增加现象。 2. 两侧均使用 [singbox](https://github.com/SagerNet/sing-box) shadowtls 结合之前提到的 `gost ss+mws` 组合，没有延迟增加现象。 我想这种延迟增加应该不是 rust 的特点，但当下我先选择使用 singbox 的 shadowtls 实现。

> 当前版本已经默认启动 NODELAY，麻烦看下问题还存在吗？ @wen-long 最新版本没问题了，同环境测试，m1 shadow-tls-aarch64-apple-darwin + linux shadow-tls-x86_64-unknown-linux-musl 感谢🙏

https://github.com/oschwald/geoip2-golang/blob/main/reader.go#L278 应该也需要上游支持，新增 `ipinfo country_asn.mmdb` 类别