本章節主要探討三個問題：
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 解密后的原始數據，二者均不參與加密邏輯。
