握手耗时怎么算
TLS 握手成本等于从 ClientHello 到最后一个 Finished 的时间差，其中包含网络往返与密钥运算两部分。TLS 1.2 的完整握手为两个往返（ServerHello 到 ServerHelloDone 一个、客户端密钥交换到 Finished 一个），TLS 1.3 把密钥交换并入 Hello 扩展后压到一个往返。会话恢复走另一条更短的路径，统计时要把完整握手与会话恢复分开，否则平均值没有意义。
基本信息
| 适用平台 | Wireshark / tshark，客户端与服务端两侧均可测量 |
|---|---|
| 测量口径 | 首个 ClientHello 到首个 Finished 的时间差 |
| 影响项 | 网络往返、服务端密钥运算、证书链长度、是否走恢复路径 |
| 统计建议 | 按完整握手与恢复路径分别统计，输出分位数而非仅均值 |
典型使用场景
- 首屏或首访慢，需要判断握手占了多少延迟
- 跨地域链路与同城链路对比，量化距离带来的代价
- 评估开启会话恢复或 TLS 1.3 后的实际收益
- 排查握手偶发超时，定位是网络往返还是服务端处理变慢
- 为容量规划提供依据：按每秒新建连接数估算握手带来的计算负载
- 对比改造前后两次抓包，验证优化手段是否真的生效
测量与对照
测量与对照
tls.handshake.type == 1 # ClientHello
tls.handshake.type == 20 # Finished
# 同一流内取首个 ClientHello 与最后一个 Finished 的时间差
# 完整握手(1.2): CH → SH,Cert,SKE,SHD → CKE,CCS,FIN → CCS,FIN
# 会话恢复: CH(带票据) → SH,CCS,FIN
# 分别统计两条路径的次数与耗时，均值之外给出 P95时间线逐段读法
| 区段 | 含义 | 异常信号 |
|---|---|---|
| CH 到 SH | 一个往返加服务端首段处理 | 明显偏大指向网络往返或服务端排队 |
| SH 到客户端下一帧 | 证书传输与客户端处理链 | 证书链过长会在这里体现 |
| 到 Finished | 剩余往返与密钥运算 | 耗时稳定但偏大常见于弱算力服务端 |
| 整段总时长 | 握手总成本 | 与其他流对比出现离群值需单独复查 |
握手时间天然包含至少一个网络往返，把它与服务端处理时间混在一起会高估服务端；两侧同时抓包并用同一条流对齐，才能把两段拆开。
TLS 1.3 启用 HelloRetryRequest 时会多出一个往返，这种「多一轮」是协议正常行为，不应作为性能退化证据。