使用shadow-tls后连接网站的延迟翻倍 about shadow-tls

[ihciah]

握手服务器选择就近的试试

[ayanami-desu]

现在使用的是cloud.tencent.com
换成近一点是指离我的位置还是国外服务器的位置

[ihciah]

是指国外服务器。可以在服务器上通过ping(简易)或curl(更精确)测量延迟。

[ihciah]

总延迟是 往返次数×(你到服务器延迟+服务器到握手服务器延迟)。
通过选用离你的服务器更近的握手服务器，可以尽可能地减少一部分延迟；换用支持tls1.3的握手服务器会减少往返次数，也会大大降低延迟。对tls的支持性可以用openssl命令行工具测试。

[hayden-pan]

提升握手延时（理论上是累加shadow-tls服务端到伪装域名站点之间的握手延时）是一定会出现的，这是设计如此。但是可以通过上层协议的改进来减少握手延时的影响，比如提前完成握手建立连接，在用户使用的时候直接有现成的连接，还可以再加上多路复用等。非常感谢 @ihciah 的这个协议，让未来变得更有趣和希望了！

[vcheckzen]

提升握手延时（理论上是累加shadow-tls服务端到伪装域名站点之间的握手延时）是一定会出现的，这是设计如此。但是可以通过上层协议的改进来减少握手延时的影响，比如提前完成握手建立连接，在用户使用的时候直接有现成的连接，还可以再加上多路复用等。非常感谢 @ihciah 的这个协议，让未来变得更有趣和希望了！

提前握手如果能实现，听起来不错

不过 shdow-tls 到后端程序的进程间通信，也是延迟增加的原因吧

[mieqq]

总延迟是 往返次数×(你到服务器延迟+服务器到握手服务器延迟)。
通过选用离你的服务器更近的握手服务器，可以尽可能地减少一部分延迟；换用支持tls1.3的握手服务器会减少往返次数，也会大大降低延迟。对tls的支持性可以用openssl命令行工具测试。

请问下有可能支持 TFO 吗，现在 shadow-tls 服务端似乎不支持，谢谢。

[wen-long]

在 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 以外的其他语言的开源实现来对比就好了。

[wen-long]

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

[wen-long]

继续补充说明：

1. 延迟增加总是出现在使用 mux 时，当借助 surge 使用 http connection reuse 时，rust 实现的 shadowtls 没有出现延迟增加现象。
2. 两侧均使用 singbox shadowtls 结合之前提到的 gost ss+mws 组合，没有延迟增加现象。

我想这种延迟增加应该不是 rust 的特点，但当下我先选择使用 singbox 的 shadowtls 实现。

[ihciah]

继续补充说明：

1. 延迟增加总是出现在使用 mux 时，当借助 surge 使用 http connection reuse 时，rust 实现的 shadowtls 没有出现延迟增加现象。
2. 两侧均使用 singbox shadowtls 结合之前提到的 gost ss+mws 组合，没有延迟增加现象。

我想这种延迟增加应该不是 rust 的特点，但当下我先选择使用 singbox 的 shadowtls 实现。

感谢反馈！

1. 我检查了下代码没找到明显问题（比如已经读到了足够转发的数据却 hold 住之类）
2. 使用 Mux 才延迟增加，不确定是不是对照组 buffer size、TCP_NODELAY 等影响；以及确实和 Mux 本身实现有关。我看了下 singbox 的实现，在数据包处理上和本实现有差异。
   a. singbox 在收包时先收 5B 的 header，之后根据 header 里的 length 收 body。同一封装内的数据是一口气到达的。
   b. 本实现直接 read 到固定大小 buffer 之后 parse 处理。同一封装内的数据不一定一起到达。
   在保证数据流正确性上两者一致，但前者更容易使同时发出的流量同时到达，后者会尽量使数据更快到达但并不一定同时。
3. x86_64-apple-darwin 和 aarch64-apple-darwin 在编译器之上的代码层面没有差异（指在 shadow-tls 和 monoio 里没有相应的条件编译）

后面我尝试加一下 NODELAY 的开关看看有没有用。

[ihciah]

当前版本已经默认启动 NODELAY，麻烦看下问题还存在吗？ @wen-long

[wen-long]

当前版本已经默认启动 NODELAY，麻烦看下问题还存在吗？ @wen-long

最新版本没问题了，同环境测试，m1 shadow-tls-aarch64-apple-darwin + linux shadow-tls-x86_64-unknown-linux-musl

感谢🙏