传输层TCP 与 安全层SSL/TLS
本章节主要探讨三个问题：
1. SSL/TSL 的区别和联系是什么？
2. 我们常说的 “三次握手” 发生在哪个阶段，SSL/TSL层有参与吗?
3. HTTPS混合加密发生在哪个层?
一、SSL 和 TLS
联系
- 继承关系：TLS 直接基于 SSL 3.0 设计，可以视为 SSL 的升级版，TLS 1.0 最初命名为 SSL 3.1，后因标准化需要更名为 TLS。
- 核心目标一致：两者的核心目标都是为网络通信提供安全及数据完整性保障，它们都位于 TCP/IP 协议与各种应用层协议之间，为数据通讯提供安全支持。
区别
- 开发者：SSL 由 Netscape 开发，而 TLS 是 IETF 在 SSL 的基础上进行开发的。
- 版本：SSL 有 SSL 1.0、2.0、3.0 等版本，其中 SSL 3.0 是最后一个版本；TLS 有 TLS 1.0、1.1、1.2、1.3 等版本，TLS 1.3 是目前最新的版本。
- 安全性：SSL 存在一些已知的安全漏洞，如 SSL 2.0 和 SSL 3.0 都有安全问题，已逐渐被弃用；
TLS 解决了 SSL 中存在的许多安全问题，引入了更强的加密算法和更安全的握手过程，安全性更高。 - 握手过程：SSL 的握手过程相对简单，TLS 的握手过程则更加安全和复杂。
- 加密算法：SSL 支持一些较弱的加密算法，TLS 支持更强的加密算法，如 AES、ChaCha20 等。
- 兼容性：现代系统通常禁用 SSL，普遍使用 TLS。
二、SSL/TLS 会参与三次握手吗？
答：不会，三次握手仅发生在传输层的 TCP 协议中，与安全层（SSL/TLS）没有直接关联。
要理解这一点，需要先明确 TCP 三次握手的本质、以及 TCP 与 SSL/TLS 在网络分层中的位置和分工。
1. 先理清核心概念：TCP 三次握手的作用
TCP（传输控制协议）是传输层的核心协议，其设计目标是为应用层提供可靠的、面向连接的字节流服务。
而 “三次握手” 是 TCP 建立连接的核心机制，目的是：
- 确认客户端和服务器的 “发送能力” 和 “接收能力” 均正常；
- 协商双方初始的序列号（ISN），为后续数据传输的有序性、去重提供基础；
- 最终建立起一条双向的、可靠的传输通道。
简单来说，三次握手是 TCP “建立连接” 的专属流程，只和传输层相关，在 SSL/TLS 启动之前就已经完成。
2. 再看分层关系：TCP（传输层）是 SSL/TLS（安全层）的 “基础”
根据 TCP/IP 分层模型（或 OSI 模型的简化理解），各层的依赖关系是 “下层为上层提供服务”：
- 传输层（TCP）：先通过三次握手建立可靠连接，为上层（如 SSL/TLS）提供 “稳定的字节流传输通道”；
- 传输安全层（SSL/TLS）：在 TCP 连接建立后，才在这个 “基础通道” 上启动自己的 “握手流程”（即 SSL/TLS 握手），协商加密算法、交换随机数、验证证书、生成会话密钥；
- 应用层（如 HTTPS）：SSL/TLS 握手完成后，才基于加密通道传输 HTTP 数据（即 HTTPS = HTTP + SSL/TLS）。
三者的启动顺序是：
TCP 三次握手（建立连接）→ SSL/TLS 握手（建立安全通道）→ HTTP 数据传输（应用层通信）
3. 关键区别：TCP 三次握手 vs. SSL/TLS 握手
很多人会混淆这两个 “握手”，但它们的层级、目的完全不同，对比如下：
| 对比维度 | TCP 三次握手 | SSL/TLS 握手 |
|---|---|---|
| 所属层级 | 传输层（TCP 协议） | 传输层与应用层之间（安全层） |
| 发生时机 | 通信刚开始，SSL/TLS 启动前 | TCP 连接建立后，HTTP 数据传输前 |
| 核心目的 | 建立可靠的连接（确认收发能力、协商序列号） | 建立安全的加密通道（协商算法、验证身份、生成密钥） |
| 参与方交互次数 | 3 次交互（客户端→服务器→客户端） | 视版本不同（如 TLS 1.2 约 4-6 次，TLS 1.3 优化为 2 次） |
总结
- 三次握手只属于传输层的 TCP 协议，是建立可靠连接的前提，和 SSL/TLS（安全层）无关；
- SSL/TLS 是在 TCP 连接的基础上，额外增加的 “安全增强层”，它有自己独立的 “握手流程”，但不是三次握手；
- 整个 HTTPS 的通信流程，是 “TCP 三次握手打底 → SSL/TLS 握手加安全 → HTTP 传输数据” 的层层依赖关系。
三、HTTPS混合加密发生在哪个层?
HTTPS 的混合加密（即 “非对称加密 + 对称加密” 的组合机制）完全发生在 TLS 层，
更具体地说，是在 TLS 协议的 “握手阶段” 和 “记录阶段” 中协同实现的，与 TCP 层（传输层）或 HTTP 层（应用层）无直接关联。
要理解这一点，需要先明确 HTTPS 混合加密的核心逻辑 ——用非对称加密解决 “对称密钥的安全传输问题”，用对称加密解决 “大量数据的高效加密问题”，而这两个步骤的执行载体，正是 TLS 协议的分层设计：
1. 混合加密的两个关键步骤，均由 TLS 层实现
TLS 协议本身分为 “握手协议” 和 “记录协议” 两层，混合加密的两个核心动作分别在这两层中完成：
（1）非对称加密：用于 TLS 握手阶段，安全交换 “对称密钥的种子”
在 TLS 握手开始后，客户端和服务器会通过非对称加密完成两件关键事：
- 服务器向客户端发送 “数字证书”（含服务器的公钥），客户端通过信任链验证证书合法性（确认服务器身份，防止中间人攻击）；
- 客户端生成一个临时的 “预主密钥（Pre-Master Secret）”，用服务器证书中的公钥（非对称加密的公钥） 加密后发送给服务器；
- 服务器用自己的私钥（非对称加密的私钥） 解密，得到 “预主密钥”。
至此，客户端和服务器通过 “非对称加密” 安全共享了 “预主密钥”—— 这一步的核心是 “避免对称密钥在传输中被窃取”，而整个过程完全在 TLS 握手协议中执行，TCP 层仅负责传输这些加密后的握手数据（不理解数据含义），HTTP 层此时尚未参与。
（2）对称加密：用于 TLS 记录阶段，高效加密 HTTP 数据
TLS 握手完成后，客户端和服务器会基于 “预主密钥”+“客户端随机数（Client Random）”+“服务器随机数（Server Random）”，通过相同的算法（如 HKDF）生成最终的 “会话密钥（Session Key）”—— 这个 “会话密钥” 就是对称加密的密钥。
之后进入 “TLS 记录阶段”：所有 HTTP 层的原始数据（如请求头、响应体）会先交给 TLS 记录协议，由其完成三件事：
- 对 HTTP 数据进行分段（按 TLS 规定的最大长度切割）；
- 用 “会话密钥” 通过对称加密算法（如 AES-GCM）对分段数据加密；
- 对加密后的数据添加 “消息认证码（MAC）” 或 “认证标签（Tag）”，确保数据完整性（防止被篡改）。
最终，这些加密后的 “TLS 记录数据” 会被交给 TCP 层，由 TCP 传输到对方；对方接收后，再通过 TLS 记录协议用相同的 “会话密钥” 解密、验证完整性，最后将原始 HTTP 数据交给应用层（HTTP 层）。
简言之：对称加密的核心是 “高效处理大量 HTTP 数据”，其加密 / 解密动作由 TLS 记录协议执行，HTTP 层只负责处理解密后的原始数据，完全感知不到加密过程。
2. 为什么混合加密不会发生在其他层？
- TCP 层（传输层）：TCP 的作用是 “可靠传输字节流”，仅负责数据的分段、重传、有序交付，不具备任何加密能力，也不理解 TLS/HTTP 数据的含义，无法参与加密；
- HTTP 层（应用层）：HTTP 本身是 “明文协议”，没有加密逻辑；HTTPS 的 “安全” 本质是给 HTTP 套了一层 TLS “保护壳”——HTTP 数据是 “被 TLS 加密的对象”，而非加密的执行者。
总结
HTTPS 的混合加密是 TLS 层的核心功能：
- 非对称加密在 TLS 握手阶段，解决 “对称密钥的安全共享”；
- 对称加密在 TLS 记录阶段，解决 “HTTP 数据的高效加密”；
整个过程中，TCP 层仅负责传输 TLS 加密后的数据，HTTP 层仅负责处理 TLS 解密后的原始数据，二者均不参与加密逻辑。