TLS 握手的目标是协商安全参数、验证服务端身份并得到后续加密通信使用的密钥。以常见的 TLS 1.3 完整握手为例，客户端发送 ClientHello，列出支持的版本、密码套件、随机数、密钥份额等；服务端选定参数，返回 ServerHello 和自己的密钥份额，双方由密钥交换计算出共享秘密。
服务端随后发送证书链及 CertificateVerify 等消息证明其持有相应私钥，并通过 Finished 消息校验握手 transcript。客户端检查证书后也发送 Finished。双方据协商结果导出流量密钥，之后应用数据通过记录层加密并做完整性保护。不同协商扩展、客户端证书、PSK 会改变消息流程；0-RTT 仅适用于特定恢复场景并有重放风险。
TLS 1.3 删除/调整了旧版本中的部分算法和握手方式，不能把 TLS 1.2 的消息顺序照搬为 TLS 1.3。密钥交换提供会话密钥材料，证书签名负责身份认证；后续数据主要使用对称算法，兼顾效率。
握手协商还会确定应用协议，例如通过 ALPN 选择 HTTP/2 或 HTTP/1.1。握手消息由 transcript 参与认证，防止中间人悄悄改写协商参数。实际抓包时若看到握手失败，应结合告警类型、双方支持的版本/密码套件、证书链以及系统时钟分析；单独看到“TLS error”不足以确定原因。不要通过关闭证书验证来绕过错误。
常见追问
TLS 握手为什么要随机数和密钥份额？
它们参与协商新鲜的会话密钥，使每次连接的密钥具有独立性。仅交换证书公钥并不等于双方已经建立了加密会话。
证书和会话密钥分别做什么？
证书把公钥与身份绑定，并由证书链建立信任；会话密钥用于保护当前连接的数据。两者用途不同。
TLS 1.3 能否恢复会话？
可以通过 PSK 等方式恢复，减少握手往返。启用 0-RTT 时早期数据可能被重放，因此应用不能不加区分地对其执行非幂等操作。
TLS 握手成功就代表 HTTP 请求安全了吗？
握手确保到被验证对端的连接安全，但服务器应用、终端设备、代理配置和用户权限仍可能有问题；TLS 不替代身份授权和业务安全。