握手耗时 78 毫秒意味着什么
首次连接的等待通常来自握手而不是传输：把同城握手压到 78 毫秒、跨洲压到 210 毫秒之后，用户感知到的连上速度才真正变快。
发布于 2026-08-30 ｜ kuailhub.com.cn 技术组
过程还原
一次 HTTPS 连接的建立要经过 TCP、TLS 与应用层协商三个阶段，跨洲链路上 RTT 本身就有 120 毫秒左右，如果 TLS 还要两次往返，等待就会被放大到半秒以上。
快连采用 TLS 1.3 承载与私有握手混合的方案，会话票据可以在 0-RTT 阶段复用，二次连接不再走完整协商；2026 年 8 月 20 日的同城测试中，握手耗时中位数为 78 毫秒，样本 500 次。
跨洲测试的握手耗时中位数为 210 毫秒，与该方向的物理 RTT 基本吻合，说明协议层已经没有明显额外开销；测试条件为上海到法兰克福，样本同样 500 次。
需要说明的是，78 毫秒并不是每次都能达到：设备休眠唤醒、切换 Wi-Fi 与蜂窝网络都会触发重新协商，这类场景下的耗时通常在 200 至 400 毫秒。
从连接建立到首字节返回（TTFB）的完整耗时中，握手只占其中一部分：同城测试下 TTFB 中位数为 142 毫秒，握手占 55%，其余为服务器处理与首包传输。
这项比例在不同方向上差异明显，跨洲 TTFB 中位数为 486 毫秒，握手占 43%，说明协议优化在长链路上的收益占比会自然下降。
数据口径：全部握手耗时数据取自 2026 年 8 月 20 日的自动化测试脚本，每组 500 次取中位数，测试机为同一台 Windows 11 设备。
数据要点
- 同城握手耗时中位数 78 毫秒，跨洲中位数 210 毫秒，2026-08-20 测试各 500 次取中位数。
- 测试机为同一台 Windows 11 设备，避免硬件差异引入的偏差。
- 设备休眠唤醒或切换网络后握手耗时通常为 200 至 400 毫秒，因触发重新协商。
- 协议栈对齐 TLS 1.3 标准，二次连接通过会话票据在 0-RTT 阶段复用。
延伸问题
为什么不用 0-RTT 直接更快？
0-RTT 存在重放风险，客户端在证书校验完成前发送的数据可能被中间人重放，因此快连只在已确认票据的连接上使用它。
参考
握手耗时数据来自 2026 年 8 月 20 日自动化测试记录，样本量与测试机型号已在正文标注。全部数据在同一台 Windows 11 设备上采集，每组 500 次取中位数，跨洲方向为上海至法兰克福。