Closed ayanami-desu closed 1 year ago
握手服务器选择就近的试试
现在使用的是cloud.tencent.com 换成近一点是指离我的位置还是国外服务器的位置
是指国外服务器。可以在服务器上通过ping(简易)或curl(更精确)测量延迟。
总延迟是 往返次数×(你到服务器延迟+服务器到握手服务器延迟)。 通过选用离你的服务器更近的握手服务器,可以尽可能地减少一部分延迟;换用支持tls1.3的握手服务器会减少往返次数,也会大大降低延迟。对tls的支持性可以用openssl命令行工具测试。
提升握手延时(理论上是累加shadow-tls服务端到伪装域名站点之间的握手延时)是一定会出现的,这是设计如此。但是可以通过上层协议的改进来减少握手延时的影响,比如提前完成握手建立连接,在用户使用的时候直接有现成的连接,还可以再加上多路复用等。非常感谢 @ihciah 的这个协议,让未来变得更有趣和希望了!
提升握手延时(理论上是累加shadow-tls服务端到伪装域名站点之间的握手延时)是一定会出现的,这是设计如此。但是可以通过上层协议的改进来减少握手延时的影响,比如提前完成握手建立连接,在用户使用的时候直接有现成的连接,还可以再加上多路复用等。非常感谢 @ihciah 的这个协议,让未来变得更有趣和希望了!
提前握手如果能实现,听起来不错
不过 shdow-tls 到后端程序的进程间通信,也是延迟增加的原因吧
总延迟是 往返次数×(你到服务器延迟+服务器到握手服务器延迟)。 通过选用离你的服务器更近的握手服务器,可以尽可能地减少一部分延迟;换用支持tls1.3的握手服务器会减少往返次数,也会大大降低延迟。对tls的支持性可以用openssl命令行工具测试。
请问下有可能支持 TFO 吗,现在 shadow-tls 服务端似乎不支持,谢谢。
补充说明:上述几项测试的延迟与握手无关,是握手完毕后,对同一条 TCP 复用的延迟。ss+mws 方式直接连接或通过 trijan,naiveproxy,ss 进行测试都是稳定的最低延迟,没有现象指向这是 gost 的问题。只有 shadow-tls 出现大概率随机延迟增加现象。
继续补充说明:
gost ss+mws
组合,没有延迟增加现象。我想这种延迟增加应该不是 rust 的特点,但当下我先选择使用 singbox 的 shadowtls 实现。
继续补充说明:
- 延迟增加总是出现在使用 mux 时,当借助 surge 使用 http connection reuse 时,rust 实现的 shadowtls 没有出现延迟增加现象。
- 两侧均使用 singbox shadowtls 结合之前提到的
gost ss+mws
组合,没有延迟增加现象。我想这种延迟增加应该不是 rust 的特点,但当下我先选择使用 singbox 的 shadowtls 实现。
感谢反馈!
后面我尝试加一下 NODELAY 的开关看看有没有用。
当前版本已经默认启动 NODELAY,麻烦看下问题还存在吗? @wen-long
当前版本已经默认启动 NODELAY,麻烦看下问题还存在吗? @wen-long
最新版本没问题了,同环境测试,m1 shadow-tls-aarch64-apple-darwin + linux shadow-tls-x86_64-unknown-linux-musl
感谢🙏
服务器ping延时200ms,原先正常使用v2ray,连接网站的延迟差不多也是200,使用shadow-tls后变成400+。请问这不可避免吗?还是说可以后续优化。