shadow-tls
shadow-tls copied to clipboard
ihciah
使用shadow-tls后连接网站的延迟翻倍
服务器ping延时200ms，原先正常使用v2ray，连接网站的延迟差不多也是200，使用shadow-tls后变成400+。请问这不可避免吗？还是说可以后续优化。
总延迟是 往返次数×(你到服务器延迟+服务器到握手服务器延迟)。 通过选用离你的服务器更近的握手服务器，可以尽可能地减少一部分延迟；换用支持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 以外的其他语言的开源实现来对比就好了。
补充说明：上述几项测试的延迟与握手无关，是握手完毕后，对同一条 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
最新版本没问题了，同环境测试，m1 shadow-tls-aarch64-apple-darwin + linux shadow-tls-x86_64-unknown-linux-musl
感谢🙏