docs: 固定延迟口径——延迟=TLS握手(time_appconnect),TTFB 作参考

明确含义与区别:TLS 握手=纯网络链路往返(不含目标后端),跨站可比,作统一延迟基准;
TTFB=TLS握手+服务器处理,含站点因素,仅作体感参考。禁用 ping/tcp_connect 当延迟
(经 TUN 被本地应答)。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JEHzjEcFzvGwgbxT6Wbt6c

docs/vpn-test-plan.md

@@ -23,12 +23,41 @@
 
 ### 指标
 - **连通性**:HTTP 状态码(能否访问)
-- **延迟 / TTL**:`ping` RTT、`curl time_connect`(TCP+TLS 握手)
+- **延迟**:**TLS 握手时间(`curl time_appconnect`)= 统一延迟口径**;TTFB(`time_starttransfer`)作参考。见下方「延迟口径定义」。
 - **下载速度**:固定大小下载 `speed_download`
 - **上传速度**:POST 固定大小 `speed_upload`(待补)
 - **DNS 解析时间**:`curl time_namelookup`
 - **出口 IP**:是否 = 节点(走隧道)/ 本地(直连)
 
+### 延迟口径定义(统一标准 ⚠️ 必读)
+
+> **本项目所有"延迟"一律指 TLS 握手时间(`time_appconnect`);TTFB 仅作参考。
+> 严禁用 `ping` 或 `tcp_connect` 当延迟** —— 经 TUN 代理时它们被隧道本地协议栈
+> 就地应答(几 ms 的假象),不反映真实到目标的 RTT。
+
+curl 各时间点都是**从请求开始累计**(非各段独立):
+
+```
+开始 → DNS解析 → TCP连接 → [TLS握手完成] → 发请求 → [收到首字节=TTFB] → 传输完 → 总时长
+       namelookup  connect   time_appconnect          time_starttransfer       time_total
+```
+
+| | **TLS 握手(`time_appconnect`)= 延迟口径** | **TTFB(`time_starttransfer`)= 参考** |
+|---|---|---|
+| 测到哪 | TLS/REALITY 握手协商**完成** | 收到响应的**第一个字节** |
+| 含义 | TCP 连接 + TLS 协商往返;握手时服务器只做加密协商、**不碰业务逻辑** → **纯网络链路往返**(client→隧道→节点→目标 的 RTT × 握手轮数) | TLS 握手 + 发请求 + **目标服务器后端处理** + 回首字节 |
+| 比对方多 | — | 比 TLS 握手多 **≈1 个 RTT(请求-响应)+ 目标站后端处理时间** |
+| 受谁影响 | 只受**网络链路**影响 → 跨站可比、稳定 | 网络 **+ 目标站后端快慢/CDN** → 含站点自身因素 |
+| 为何选它 | 不被目标后端污染,横向比较公平,衡量"我们隧道有多快"最干净 | 反映"打开体感",但混入站点因素,不当基准 |
+
+**实测印证**(节点在洛杉矶):`google` TLS握手 424ms、TTFB 640ms,差 ~216ms ≈ 一个
+中国→LA→google 往返(generate_204 后端处理≈0)。换 github 这类后端重的站,TTFB 会被
+明显拉大,而 TLS 握手仍稳定反映链路。
+
+**判定参考**(单程经隧道到国外):TLS 握手 <500ms 优 / 500–1000ms 偏高 / >1000ms 差。
+**真实到节点的直连 RTT**:须在 **VPN 全关后 `ping` 节点**测(开着 TUN ping 是本地假象)。
+> 注:TLS 1.3 握手 1-RTT、TLS 1.2 为 2-RTT,故 TLS 握手 ≈ 链路 RTT × 握手轮数;同隧道内横向对比目标站公平。
+
 ### 站点矩阵
 - **国外(应经隧道)**:google、youtube、github、cloudflare(speed.cloudflare.com)、netflix、openai
 - **国内(开分流应直连)**:baidu、qq、bilibili、aliyun/清华镜像、taobao