shadow-tls
shadow-tls copied to clipboard
使用shadow-tls后连接网站的延迟翻倍
服务器ping延时200ms,原先正常使用v2ray,连接网站的延迟差不多也是200,使用shadow-tls后变成400+。请问这不可避免吗?还是说可以后续优化。
握手服务器选择就近的试试
现在使用的是cloud.tencent.com 换成近一点是指离我的位置还是国外服务器的位置
是指国外服务器。可以在服务器上通过ping(简易)或curl(更精确)测量延迟。
总延迟是 往返次数×(你到服务器延迟+服务器到握手服务器延迟)。 通过选用离你的服务器更近的握手服务器,可以尽可能地减少一部分延迟;换用支持tls1.3的握手服务器会减少往返次数,也会大大降低延迟。对tls的支持性可以用openssl命令行工具测试。
提升握手延时(理论上是累加shadow-tls服务端到伪装域名站点之间的握手延时)是一定会出现的,这是设计如此。但是可以通过上层协议的改进来减少握手延时的影响,比如提前完成握手建立连接,在用户使用的时候直接有现成的连接,还可以再加上多路复用等。非常感谢 @ihciah 的这个协议,让未来变得更有趣和希望了!
提升握手延时(理论上是累加shadow-tls服务端到伪装域名站点之间的握手延时)是一定会出现的,这是设计如此。但是可以通过上层协议的改进来减少握手延时的影响,比如提前完成握手建立连接,在用户使用的时候直接有现成的连接,还可以再加上多路复用等。非常感谢 @ihciah 的这个协议,让未来变得更有趣和希望了!
提前握手如果能实现,听起来不错
不过 shdow-tls 到后端程序的进程间通信,也是延迟增加的原因吧
总延迟是 往返次数×(你到服务器延迟+服务器到握手服务器延迟)。 通过选用离你的服务器更近的握手服务器,可以尽可能地减少一部分延迟;换用支持tls1.3的握手服务器会减少往返次数,也会大大降低延迟。对tls的支持性可以用openssl命令行工具测试。
请问下有可能支持 TFO 吗,现在 shadow-tls 服务端似乎不支持,谢谢。
在 m1 上使用确实有此问题。
使用 ttfb.sh 脚本结合 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 以外的其他语言的开源实现来对比就好了。
![image](https://user-images.githubusercontent.com/4262398/208625673-a266e603-b590-4377-b6b2-98b0c7c6f95f.png)
补充说明:上述几项测试的延迟与握手无关,是握手完毕后,对同一条 TCP 复用的延迟。ss+mws 方式直接连接或通过 trijan,naiveproxy,ss 进行测试都是稳定的最低延迟,没有现象指向这是 gost 的问题。只有 shadow-tls 出现大概率随机延迟增加现象。
继续补充说明:
- 延迟增加总是出现在使用 mux 时,当借助 surge 使用 http connection reuse 时,rust 实现的 shadowtls 没有出现延迟增加现象。
- 两侧均使用 singbox shadowtls 结合之前提到的
gost ss+mws
组合,没有延迟增加现象。
我想这种延迟增加应该不是 rust 的特点,但当下我先选择使用 singbox 的 shadowtls 实现。
继续补充说明:
- 延迟增加总是出现在使用 mux 时,当借助 surge 使用 http connection reuse 时,rust 实现的 shadowtls 没有出现延迟增加现象。
- 两侧均使用 singbox shadowtls 结合之前提到的
gost ss+mws
组合,没有延迟增加现象。我想这种延迟增加应该不是 rust 的特点,但当下我先选择使用 singbox 的 shadowtls 实现。
感谢反馈!
- 我检查了下代码没找到明显问题(比如已经读到了足够转发的数据却 hold 住之类)
- 使用 Mux 才延迟增加,不确定是不是对照组 buffer size、TCP_NODELAY 等影响;以及确实和 Mux 本身实现有关。我看了下 singbox 的实现,在数据包处理上和本实现有差异。 a. singbox 在收包时先收 5B 的 header,之后根据 header 里的 length 收 body。同一封装内的数据是一口气到达的。 b. 本实现直接 read 到固定大小 buffer 之后 parse 处理。同一封装内的数据不一定一起到达。 在保证数据流正确性上两者一致,但前者更容易使同时发出的流量同时到达,后者会尽量使数据更快到达但并不一定同时。
- x86_64-apple-darwin 和 aarch64-apple-darwin 在编译器之上的代码层面没有差异(指在 shadow-tls 和 monoio 里没有相应的条件编译)
后面我尝试加一下 NODELAY 的开关看看有没有用。
当前版本已经默认启动 NODELAY,麻烦看下问题还存在吗? @wen-long
当前版本已经默认启动 NODELAY,麻烦看下问题还存在吗? @wen-long
最新版本没问题了,同环境测试,m1 shadow-tls-aarch64-apple-darwin + linux shadow-tls-x86_64-unknown-linux-musl
感谢🙏