SSL/TLS握手需拆解为5个异步状态节点嵌入事件循环：ClientHello→ServerHello+Certificate→ServerKeyExchange→ClientKeyExchange→ChangeCipherSpec+Finished，每步依赖前序响应且支持I/O等待与CPU密集操作。
SSL/TLS 握手不是原子操作，而是一组严格时序依赖的网络交互步骤；在异步环境中，它必须被拆解为可挂起、可恢复、可调度的多个状态节点，嵌入事件循环中逐阶段推进——否则就会因阻塞协程或错失 I/O 就绪通知，导致连接卡死、超时或证书校验被跳过。
握手本质是状态驱动的多轮网络对话
整个握手流程（以 TLS 1.2 完整握手为例）天然划分为 5 个逻辑状态：ClientHello → ServerHello + Certificate → ServerKeyExchange（如需）→ ClientKeyExchange → ChangeCipherSpec + Finished。每个状态都依赖前一状态的响应数据（比如客户端必须收到服务器证书后，才能做签名验证和密钥加密），且中间任意一步可能触发 I/O 等待（如证书链下载、OCSP 响应获取）或 CPU 密集型操作（如 RSA 解密、ECDSA 验证）。这些不能“一口气跑完”，必须交由事件循环分阶段调度。
事件循环中需显式建模握手状态机
asyncio 或 Swoole 协程等运行时不会自动识别 TLS 状态。开发者需手动维护一个状态变量（如 handshake_state = "waiting_for_cert"），并在每次 I/O 完成回调中检查当前状态、解析响应内容、执行对应动作（如调用 ssl_context.verify_certificate()）、更新状态、再发起下一轮读/写。常见疏漏包括：
- 未对 Certificate 消息做完整链验证（只验了 leaf cert，忽略 intermediate 和 root CA 信任锚）
- 在 ServerHello 后未等待 CertificateVerify（若启用客户端证书）就直接发 ClientKeyExchange
- 将证书解析（X.509 解码）放在协程主线程中同步执行，阻塞事件循环达数十毫秒
证书校验必须与网络阶段解耦，且支持异步加载
证书校验不等于“看一眼 CN 字段”。真实场景中需完成三项关键动作，且每项都可能异步：
- 链式信任验证：从服务端证书出发，逐级向上查找并下载缺失的 intermediate CA（需额外 HTTP 请求），最终锚定到本地信任库中的 root CA
- 吊销状态检查：通过 OCSP Stapling（推荐）或 CRL 分发点发起查询，该过程涉及 DNS 查询 + HTTPS 请求，不可同步阻塞
- 域名匹配与有效期检查：虽为纯内存操作，但必须在收到完整证书链后才可执行，不能提前假设
若把上述任一环节写成同步调用（如 ssl.SSLContext.load_verify_locations() 后直接 cert.verify()），在高并发异步服务中极易引发连接池饥饿或协程堆积。
正确做法：用 awaitable 状态跃迁代替线性调用
理想实现应让每个握手阶段返回一个可 await 的对象，例如：
-
await handshake.next_state("ClientHello")→ 触发发送并挂起，直到 socket 可读 -
await handshake.wait_for_certificate()→ 自动处理证书链补全与 OCSP 获取，完成后才进入密钥交换 -
await handshake.verify_peer_identity(hostname="api.example.com")→ 内部封装 DNS、HTTP、X.509 解析，全部非阻塞
这种设计把 TLS 状态机真正变成事件循环的“一等公民”，而非套在协程外的黑盒同步块。
