0-RTT 可能没有生效

[spongebob888]

测试发现0-RTT可能没有生效

背景

TUIC/QUIC 有两种方式降低连接延迟

1. QUIC自带的连接复用
2. 0-RTT 握手

什么时候启动连接复用

当QUIC连接 保持活跃时，所有的新连接不会创建新的握手，因此延迟是0-RTT，实验也验证了这一点

TUIC 有心跳机制可以保证连接一直活跃不断开，从而维持复用机制。但这引入了特征

什么时候启动0-RTT 握手

1. 当一段时间（数小时）之前和服务器发生过1-RTT 握手但是随后连接断开了。
2. 客户端和服务器都没有重启，从而有共享的PSK信息
3. 此时进行代理连接将进行0-RTT握手， 若0-RTT 握手失败将退化为1-RTT握手

实验验证，TUIC可能存在bug，0-RTT握手成功了，但是数据传输存在1个RTT单位的延迟

实验

客户端

版本：1.4.5

{
    "relay": {

        "server": "",

        "ip":"",

        "uuid": "",

        "password": "",

        "udp_relay_mode": "native",

  
        "congestion_control": "bbr",


        "alpn": ["h3", "spdy/3.1"],


        "zero_rtt_handshake": true,


        "disable_sni": false,


        "timeout": "60s",

 
        "heartbeat": "1000s",

        "disable_native_certs": false,

        "send_window": 16777216,


        "receive_window": 8388608,


        "gc_interval": "3s",

        "gc_lifetime": "15s"
    },

    "local": {

        "server": "[::]:1089",


        "dual_stack": true,

        "max_packet_size": 1500
    },


    "log_level": "debug"
}

服务端

版本：1.4.5

{

    "server": "[::]:443",


    "users": {
        "": ""
    },

    "certificate": "",

    "private_key": "",

    "congestion_control": "bbr",

    "alpn": ["h3", "spdy/3.1"],

    "udp_relay_ipv6": true,


    "zero_rtt_handshake": true,

    "dual_stack": true,

 
    "auth_timeout": "3s",


    "task_negotiation_timeout": "3s",


    "max_external_packet_size": 1500,

    "send_window": 16777216,

    "receive_window": 8388608,

    "gc_interval": "3s",

    "gc_lifetime": "15s",

    "log_level": "debug"
}

验证连接复用

快速执行下列指令两次可以 触发连接复用并显示延迟

curl http://echo.free.beeceptor.com --socks5 127.0.0.1:1089 -v --trace-time

根据时间戳可以算出延迟时间，确实是1个RTT
从而连接复用是正常的

验证0-RTT握手

执行上述指令后，静息一段时间（半分钟到一分钟）连接将自动断开

继续执行curl指令，此时将启用0-RTT握手

curl http://echo.free.beeceptor.com --socks5 127.0.0.1:1089 -v --trace-time

根据时间戳计算，延迟是连接复用情况下的两倍，从而0-RTT 没有实现

客户端日志显示：

[relay] [authenticate] waiting for connection to be fully established

则表示进行了0-RTT握手

可能的原因

handle_task.rs 中验证之前执行了 zero_rtt_accepted.await 会导致阻塞，因为必须接收到serverhello 之后该调用才能返回，此时才能
确定0-rtt握手是否成功。从而导致了额外的rtt。

tuic/tuic-client/src/connection/handle_task.rs

Line 18 in 38032e9

zero_rtt_accepted.await;

[spongebob888]

三次curl 执行输出

➜ curl http://echo.free.beeceptor.com --socks5 127.0.0.1:1089 -v --trace-time
22:08:13.325415 *   Trying 127.0.0.1:1089...
22:08:14.084777 * Host echo.free.beeceptor.com:80 was resolved.
22:08:14.084901 * IPv6: (none)
22:08:14.084930 * IPv4: 147.182.252.2
22:08:14.084960 * SOCKS5 connect to 147.182.252.2:80 (locally resolved)
22:08:14.362598 * SOCKS5 request granted.
22:08:14.362726 * Connected to 127.0.0.1 () port 1089
22:08:14.362789 * using HTTP/1.x
22:08:14.362848 * Connected to 127.0.0.1 (127.0.0.1) port 1089
22:08:14.362907 * using HTTP/1.x
22:08:14.363023 > GET / HTTP/1.1
22:08:14.363023 > Host: echo.free.beeceptor.com
22:08:14.363023 > User-Agent: curl/8.11.1
22:08:14.363023 > Accept: */*
22:08:14.363023 > 
22:08:14.363284 * Request completely sent off
22:08:14.564531 < HTTP/1.1 200 OK
22:08:14.564617 < Access-Control-Allow-Origin: *
22:08:14.564687 < Content-Type: application/json
22:08:14.564756 < Date: Thu, 27 Mar 2025 14:08:14 GMT
22:08:14.564821 < Vary: Accept-Encoding
22:08:14.564891 < Transfer-Encoding: chunked
22:08:14.564960 < 
{
  "method": "GET",
  "protocol": "http",
  "host": "echo.free.beeceptor.com",
  "path": "/",
  "ip": "xx.xx.xx.xx:49064",
  "headers": {
    "Host": "echo.free.beeceptor.com",
    "User-Agent": "curl/8.11.1",
    "Accept": "*/*",
    "Accept-Encoding": "gzip"
  },
  "parsedQueryParams": {}
22:08:14.565114 * Connection #0 to host 127.0.0.1 left intact

➜ curl http://echo.free.beeceptor.com --socks5 127.0.0.1:1089 -v --trace-time
22:08:15.775458 *   Trying 127.0.0.1:1089...
22:08:15.791926 * Host echo.free.beeceptor.com:80 was resolved.
22:08:15.791986 * IPv6: (none)
22:08:15.792014 * IPv4: 147.182.252.2
22:08:15.792071 * SOCKS5 connect to 147.182.252.2:80 (locally resolved)
22:08:15.792815 * SOCKS5 request granted.
22:08:15.792894 * Connected to 127.0.0.1 () port 1089
22:08:15.792988 * using HTTP/1.x
22:08:15.793097 * Connected to 127.0.0.1 (127.0.0.1) port 1089
22:08:15.793188 * using HTTP/1.x
22:08:15.793375 > GET / HTTP/1.1
22:08:15.793375 > Host: echo.free.beeceptor.com
22:08:15.793375 > User-Agent: curl/8.11.1
22:08:15.793375 > Accept: */*
22:08:15.793375 > 
22:08:15.793776 * Request completely sent off
22:08:15.996016 < HTTP/1.1 200 OK
22:08:15.996086 < Access-Control-Allow-Origin: *
22:08:15.996118 < Content-Type: application/json
22:08:15.996172 < Date: Thu, 27 Mar 2025 14:08:15 GMT
22:08:15.996220 < Vary: Accept-Encoding
22:08:15.996286 < Transfer-Encoding: chunked
22:08:15.996323 < 
{
  "method": "GET",
  "protocol": "http",
  "host": "echo.free.beeceptor.com",
  "path": "/",
  "ip": "xx.xx.xx.xx:49074",
  "headers": {
    "Host": "echo.free.beeceptor.com",
    "User-Agent": "curl/8.11.1",
    "Accept": "*/*",
    "Accept-Encoding": "gzip"
  },
  "parsedQueryParams": {}
22:08:15.996450 * Connection #0 to host 127.0.0.1 left intact

➜  temp curl http://echo.free.beeceptor.com --socks5 127.0.0.1:1089 -v --trace-time
22:08:28.213632 *   Trying 127.0.0.1:1089...
22:08:28.229561 * Host echo.free.beeceptor.com:80 was resolved.
22:08:28.229633 * IPv6: (none)
22:08:28.229682 * IPv4: 147.182.252.2
22:08:28.229746 * SOCKS5 connect to 147.182.252.2:80 (locally resolved)
22:08:28.231160 * SOCKS5 request granted.
22:08:28.231217 * Connected to 127.0.0.1 () port 1089
22:08:28.231269 * using HTTP/1.x
22:08:28.231328 * Connected to 127.0.0.1 (127.0.0.1) port 1089
22:08:28.231400 * using HTTP/1.x
22:08:28.231522 > GET / HTTP/1.1
22:08:28.231522 > Host: echo.free.beeceptor.com
22:08:28.231522 > User-Agent: curl/8.11.1
22:08:28.231522 > Accept: */*
22:08:28.231522 > 
22:08:28.231874 * Request completely sent off
22:08:28.899706 < HTTP/1.1 200 OK
22:08:28.899774 < Access-Control-Allow-Origin: *
22:08:28.899824 < Content-Type: application/json
22:08:28.899866 < Date: Thu, 27 Mar 2025 14:08:28 GMT
22:08:28.899898 < Vary: Accept-Encoding
22:08:28.899949 < Transfer-Encoding: chunked
22:08:28.900019 < 
{
  "method": "GET",
  "protocol": "http",
  "host": "echo.free.beeceptor.com",
  "path": "/",
  "ip": "xx.xx.xx.xx:51372",
  "headers": {
    "Host": "echo.free.beeceptor.com",
    "User-Agent": "curl/8.11.1",
    "Accept": "*/*",
    "Accept-Encoding": "gzip"
  },
  "parsedQueryParams": {}
22:08:28.900100 * Connection #0 to host 127.0.0.1 left intact
}%

tuic-client 日志

25-03-27 22:08:00  WARN tuic_client::socks5: [socks5] server started, listening on [::]:1089
25-03-27 22:08:13 DEBUG tuic_client::socks5: [socks5] [[::ffff:127.0.0.1]:47954] connection established
25-03-27 22:08:14  INFO tuic_client::socks5: [socks5] [[::ffff:127.0.0.1]:47954] [connect] 147.182.252.2:80
25-03-27 22:08:14  INFO tuic_client::connection::handle_task: [relay] [connect] 147.182.252.2:80
25-03-27 22:08:14  INFO tuic_client::connection: [relay] connection established
25-03-27 22:08:14 DEBUG tuic_client::connection::handle_task: [relay] [authenticate] sending authentication
25-03-27 22:08:14  INFO tuic_client::connection::handle_task: [relay] [authenticate] UUID
25-03-27 22:08:14 DEBUG tuic_client::socks5: [socks5] [[::ffff:127.0.0.1]:47954] connection closed
25-03-27 22:08:15 DEBUG tuic_client::socks5: [socks5] [[::ffff:127.0.0.1]:47966] connection established
25-03-27 22:08:15  INFO tuic_client::socks5: [socks5] [[::ffff:127.0.0.1]:47966] [connect] 147.182.252.2:80
25-03-27 22:08:15  INFO tuic_client::connection::handle_task: [relay] [connect] 147.182.252.2:80
25-03-27 22:08:16 DEBUG tuic_client::socks5: [socks5] [[::ffff:127.0.0.1]:47966] connection closed
25-03-27 22:08:17 DEBUG tuic_client::connection: [relay] packet fragment garbage collecting event
25-03-27 22:08:20 DEBUG tuic_client::connection: [relay] packet fragment garbage collecting event
25-03-27 22:08:23 DEBUG tuic_client::connection: [relay] packet fragment garbage collecting event
25-03-27 22:08:26  WARN tuic_client::connection: [relay] connection error: timed out
25-03-27 22:08:28 DEBUG tuic_client::socks5: [socks5] [[::ffff:127.0.0.1]:50296] connection established
25-03-27 22:08:28  INFO tuic_client::socks5: [socks5] [[::ffff:127.0.0.1]:50296] [connect] 147.182.252.2:80
25-03-27 22:08:28  INFO tuic_client::connection::handle_task: [relay] [connect] 147.182.252.2:80
25-03-27 22:08:28  INFO tuic_client::connection: [relay] connection established
25-03-27 22:08:28 DEBUG tuic_client::connection::handle_task: [relay] [authenticate] waiting for connection to be fully established
25-03-27 22:08:28 DEBUG tuic_client::connection::handle_task: [relay] [authenticate] sending authentication
25-03-27 22:08:28  INFO tuic_client::connection::handle_task: [relay] [authenticate] UUID
25-03-27 22:08:29 DEBUG tuic_client::socks5: [socks5] [[::ffff:127.0.0.1]:50296] connection closed
25-03-27 22:08:31 DEBUG tuic_client::connection: [relay] packet fragment garbage collecting event
25-03-27 22:08:34 DEBUG tuic_client::connection: [relay] packet fragment garbage collecting event
25-03-27 22:08:37 DEBUG tuic_client::connection: [relay] packet fragment garbage collecting event
25-03-27 22:08:40 DEBUG tuic_client::connection: [relay] packet fragment garbage collecting event
25-03-27 22:08:40  WARN tuic_client::connection: [relay] connection error: timed out

[spongebob888]

这个问题在clashrs 中同样存在

[Itsusinn]

我认为README 中的 0 rtt 是让人迷惑的。
我自认为，这里的 0 rtt 指的是流量本身可以在tuic的客户端和服务器间进行 0 rtt 传输；然而对于代理之上的传输，如 issue上下文中的 HTTP/1.1，它本身有自己的rtt, 和自己的连接复用机制，这是tuic无法干涉的。

这个问题在clashrs 中同样存在

你有在clash-meta中测试过吗？

[spongebob888]

0rtt 应该是指Quic的0rtt 握手，定义是清楚的。我做的实验意思是，1rtt情况下连接复用下的明显延迟小于0rtt握手下的延迟。回头我看下能不能修复下，发个pr

[spongebob888]

不需要测试meta

[spongebob888]

如果能解决这个问题就再也不需要心跳机制了

[Itsusinn]

@spongebob888 Will you give it a try？（by using rustls early export）

[spongebob888]

glad to help

[Itsusinn]

blocking on rustls 0.24