HTTPS 是应⽤层协议，需要先完成 TCP 连接建⽴，然后⾛ TLS 握⼿过程后，才能建⽴信信安全的连接
HTTPS = HTTP + SSL/TLS。 HTTPS 的本质是在 HTTP 协议之上增加了一个安全层，这个安全层最初由 SSL 协议实现，后来演进为更安全的 TLS 协议。
SSL 是 TLS 的前身。 TLS 是 SSL 的标准化、更安全的升级版。SSL 已经因为安全漏洞而被彻底废弃。
出于习惯和兼容性，人们（包括很多开发者）仍然会混用 “SSL” 和 “TLS”，甚至在技术文档中看到 “SSL/TLS” 的写法。但在技术层面，我们应该使用“TLS”。
RSA握手过程
传统的 TLS 握手基本都是使用 RSA 算法来实现密钥交换的，在将 TLS 证书部署服务端时，证书文件中包含一对公私钥，其中公钥会在 TLS 握手阶段传递给客户端，私钥则一直留在服务端，一定要确保私钥不能被窃取。
在 RSA 密钥协商算法中，客户端会生成随机密钥，并使用服务端的公钥加密后再传给服务端。根据非对称加密算法，公钥加密的消息仅能通过私钥解密，这样服务端解密后，双方就得到了相同的密钥，再用它加密应用消息。
好的，我们来详细讲解一下 TLS 四次握手。这其实是 TLS 协议建立安全连接的核心过程，通常被称为TLS 握手协议。
为了更直观，我们先看一张经典的流程图，然后分步骤拆解：
上图展示了最经典的RSA 密钥交换流程。下面我们对每一步进行详细解释。
TLS 四次握手详解
“四次握手”指的是在建立 TCP 连接后，为了建立 TLS 安全层，客户端和服务器之间主要进行四轮消息交换（并非严格意义上的4条消息，而是4个来回的数据包组）。
第一阶段：ClientHello
- 发起方： 客户端
- 目的： 向服务器发起加密通信请求，并告知自身的能力和偏好。
- 主要内容：
- 客户端随机数 (Client Random)： 一个由客户端生成的随机数，用于后续生成主密钥。
- 支持的协议版本： 如 TLS 1.2 或 TLS 1.3。
- 支持的密码套件列表： 按优先级排列。一个密码套件定义了后续将使用的密钥交换算法、批量加密算法和消息认证码算法。例如
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256。 - 支持的压缩方法。
- 会话ID： 用于恢复之前的会话（会话恢复）。
- 扩展字段： 如服务器名称指示 (SNI)，用于虚拟主机。
第二阶段：ServerHello + Server Certificate + ServerHelloDone
- 发起方： 服务器
- 目的： 响应客户端，确定通信参数，并证明自己的身份。
- 包含多条消息：
- ServerHello：
- 服务器随机数 (Server Random)： 服务器生成的随机数，同样用于后续生成主密钥。
- 选定的协议版本： 从客户端支持的版本中选择。
- 选定的密码套件： 从客户端提供的列表中选择一个。
- 会话ID： 如果支持会话恢复，会提供新的或旧的会话ID。
- Server Certificate：
- 服务器的数字证书。这个证书由受信任的证书颁发机构 (CA) 签发，包含了服务器的公钥、域名等信息。客户端会用预置的 CA 根证书来验证这个证书的合法性，从而确认服务器的身份并获取其公钥。
- ServerKeyExchange(可选)： 如果选定的密码套件需要（例如使用DHE或ECDHE这种前向安全的密钥交换算法），服务器会发送自己的临时公钥参数。这是实现前向安全的关键。
- CertificateRequest(可选)： 如果服务器需要验证客户端身份（双向认证），会请求客户端证书。
- ServerHelloDone：
- 通知客户端，服务器这边的初始协商消息已发送完毕。
- ServerHello：
关键点：至此，客户端已经拥有了Client Random、Server Random，并通过证书获得了服务器的公钥（或临时公钥参数）。
第三阶段：Client Key Exchange + Change Cipher Spec + Finished
- 发起方： 客户端
- 目的： 进行密钥交换，并切换到加密模式，验证握手过程是否完整和未被篡改。
- 包含多条消息：
- Client Certificate(可选)： 如果服务器要求，客户端发送自己的证书。
- ClientKeyExchange：
- 这是密钥交换的核心。根据之前协商的算法，内容不同：
- RSA 密钥交换： 客户端生成一个预备主密钥 (Premaster Secret)，并用服务器证书中的公钥加密，发送给服务器。
- DHE/ECDHE 密钥交换： 客户端使用服务器传来的参数，生成自己的临时公钥，发送给服务器。双方随后使用迪菲-赫尔曼算法，在不传输 Premaster Secret 的情况下，各自计算出一个相同的 Premaster Secret。
- 这是密钥交换的核心。根据之前协商的算法，内容不同：
- CertificateVerify(可选)： 如果发送了客户端证书，用私钥签名一段数据，供服务器验证。
- ChangeCipherSpec：
- 一个简单的协议，通知服务器：“我后面的消息都要用我们刚协商好的加密算法和密钥来加密了”。
- Finished：
- 这是握手过程中第一条被加密的消息！它包含一个特殊的消息认证码 (MAC)，是对之前所有握手消息的摘要，并用刚刚生成的主密钥加密后发送。服务器解密并验证这个 MAC，可以确保整个握手过程没有被篡改（防中间人攻击），且密钥协商正确。
关键点：此时，客户端和服务器都拥有了Client Random、Server Random和Premaster Secret。双方用这三个参数，通过一个伪随机函数 (PRF) 计算出相同的主密钥 (Master Secret)。主密钥再进一步派生出用于实际加密数据的会话密钥（如对称加密密钥、MAC 密钥等）。
第四阶段：Change Cipher Spec + Finished
- 发起方： 服务器
- 目的： 切换到加密模式，并确认握手完成。
- 包含消息：
- ChangeCipherSpec：
- 服务器回应客户端：“好的，我也切换到加密模式了”。
- Finished：
- 服务器也发送自己的加密 Finished 消息。客户端对其进行验证。
- ChangeCipherSpec：
握手完成
至此，TLS 四次握手全部完成。双方已：
- 协商了加密算法等参数。
- 验证了服务器（和/或客户端）的身份。
- 安全地交换/生成了共享的会话密钥。
- 确认了握手过程的完整性。
接下来，应用程序数据（HTTP、FTP等）将使用协商好的会话密钥进行加密传输。
重要补充：TLS 1.3 的简化
TLS 1.3 对握手过程做了革命性简化，将传统的“四次握手”减少到了“一次往返” (1-RTT)，有时甚至“零往返” (0-RTT)。核心变化是：
- 客户端在
ClientHello中就“猜测”服务器可能支持的密钥交换参数，并发送自己的公钥。 - 服务器在
ServerHello中确认参数，并发送证书和自己的公钥，紧接着就可以发送Finished消息。 - 客户端验证后回复
Finished。
这大大提升了连接速度。我们通常说的“四次握手”更多是指 TLS 1.2 及之前的经典模式。
总结
| 步骤 | 主要消息 | 核心目的 |
|---|---|---|
| 第一次 | ClientHello | 客户端说：“我想加密通信，我支持这些算法。” |
| 第二次 | ServerHello, Certificate, ServerHelloDone | 服务器说：“我们用这个算法，这是我的身份证（证书）。” |
| 第三次 | ClientKeyExchange, ChangeCipherSpec, Finished | 客户端说：“这是我的密钥材料，我切换加密了，这是校验码。” |
| 第四次 | ChangeCipherSpec, Finished | 服务器说：“我也切换加密了，这是我的校验码。” |
这个过程完美融合了非对称加密（用于身份认证和密钥交换）和对称加密（用于高效加密应用数据）的优势，并引入了随机数和消息认证来防止重放和篡改攻击，是网络安全通信的基石。
TLS 1.2握手的时间线分析
让我们重新从RTT（往返时间）角度分析握手过程：
第一轮往返：协商参数
- 客户端 → 服务器：
ClientHello- （开始第一个RTT计时）
- 服务器 → 客户端：
ServerHello、Certificate、ServerHelloDone- （第一个RTT结束）
这不是完整的四次，而是第一轮往返。客户端发出Hello，服务器回应。
第二轮往返：密钥交换
- 客户端 → 服务器：
ClientKeyExchange、ChangeCipherSpec、Finished- （开始第二个RTT计时）
- 服务器 → 客户端：
ChangeCipherSpec、Finished- （第二个RTT结束，握手完成）
所以正确的描述是：TLS 1.2握手需要2个完整的RTT。
为什么会有"四次握手"的说法？
术语上的混淆来源：
消息流视角：从消息序列看确实是4条主要消息流
- ClientHello
- ServerHello + Certificate + ServerHelloDone
- ClientKeyExchange + ChangeCipherSpec + Finished
- ChangeCipherSpec + Finished
协议层视角：但物理传输上，第2、3条消息通常在同一数据包中，第4、5条也是
历史原因：早期文献和教学中常用"四次握手"来形象描述这4个关键步骤序列
发起 HTTP 请求时，需要经过 TCP 三次握手和 TLS 四次握手 (TLS 1.2)的过程，因此共需要 3 个 RTT 的时延才能发出请求数据。
什么是RTT？
RTT（Round Trip Time，往返时延）：数据包从客户端发送到服务器，再返回客户端所需的时间。它是网络延迟的核心度量单位。
一个RTT = 客户端发出请求到收到响应的完整来回时间
HTTPS连接建立的完整过程（3个RTT）
RTT 1️⃣：TCP三次握手（1个RTT）
客户端 服务器 |----- SYN ------>| |<---- SYN+ACK ---| (此时完成1个RTT) |----- ACK ------>|- SYN：客户端说“我想连接”
- SYN+ACK：服务器说“好的，可以连接”
- ACK：客户端说“收到，开始通信”
到这一步，TCP连接建立，耗时1个RTT。
RTT 2️⃣：TLS握手前两轮（1个RTT）
客户端 服务器 |--- ClientHello -->| |<-- ServerHello ---| |<-- Certificate ---| |<-- ServerKeyExchange-| |<-- ServerHelloDone -| (此时完成第2个RTT) |--- 后续TLS消息 --->|- ClientHello：客户端支持的TLS版本、加密套件等
- ServerHello：服务器选择加密套件、发送证书等
从ClientHello到ServerHelloDone，又耗时1个RTT。
RTT 3️⃣：TLS握手最后交换（1个RTT）
客户端 服务器 |--- ClientKeyExchange->| |--- ChangeCipherSpec ->| |--- Finished --------->| |<-- ChangeCipherSpec --| |<-- Finished ----------| (此时完成第3个RTT)- 客户端发送密钥交换信息
- 双方确认切换到加密通信
- 验证握手完整性
最后这部分交换，再耗时1个RTT。
可视化时间线
时间轴： 0ms Client Server ├─SYN─────────────►│ │ │ │◄────SYN+ACK──────┤ │ │ RTT 1完成 (TCP握手) ├─ACK─────────────►│ │ │ ├─ClientHello─────►│ │ │ │◄─ServerHello等───┤ RTT 2完成 (TLS第1轮) │ │ ├─ClientKeyExchange►│ │ │ │◄─Finished───────┤ RTT 3完成 (TLS第2轮) │ │ ├─HTTP Request────►│ ★现在可以发送实际数据了！ │ │ │◄─HTTP Response───┤关键点：在TLS 1.2中，必须完成全部3个RTT后，才能发送第一个加密的HTTP请求。
