目錄

HTTP1.1簡述與特性

1. 報文清晰易讀

2. 靈活和易于擴展

3. ?狀態

Cookie和Session

4. 明?傳輸、不安全

HTTP協議發展過程

HTTP/1.1的不足

HTTP/2.0

HTTP/3.0

HTTPS協議

HTTP協議和HTTPS協議的區別

HTTPS中的加密方式

HTTPS中建立連接的方式

---

前言：

到時候我想要寫一篇文章就是：在瀏覽器中輸入URL并按下回車會發生什么？

然后將幾篇文章全部串聯到一起，現在幾天的任務就是將這里的每個小部分進行一個詳細的介紹

HTTP1.1簡述與特性

Web 上的通信都是建?在 HTTP 協議上的：

1. 客戶端發起 HTTP 請求；

2. 服務器做出響應處理后，返回 HTTP 響應報?；

HTTP協議主要有以下特點：（注意這里指的是HTTP1.1協議的特性，對于更高級版本的HTTP協議里，很多特性已經不再適合。）

• 報文格式簡單，易于閱讀
• 靈活和易于擴展
• ?狀態
• 明?傳輸、不安全

下面我將詳細介紹以下HTTP協議的這幾個特點：

1. 報文清晰易讀

HTTP基本報?格式為header+body，頭部信息也是key-value簡單?本的形式，易于理解。

HTTP/1.1 的報文格式非常便于閱讀，因為它：

1. 是文本格式： 請求行、狀態行和頭部都是由可讀的 ASCII/ISO-8859-1 字符組成的文本行。
2. 結構清晰： 頭部是簡單的 "Key: Value" 形式，每行一個頭部字段，以空行結束頭部，后面跟著報文體（如果存在）。

這使得開發者、系統管理員等可以很方便地使用 telnet、curl -v 或者查看網絡抓包工具（如 Wireshark）中的文本視圖來直接閱讀、理解和調試 HTTP/1.1 報文。

2. 靈活和易于擴展

HTTP協議?的各種請求?法、URI/URL、狀態碼、頭字段等每個組成要求都沒有被固定死，允許開發?員? 定義和擴充; HTTP?作在應?層（OSI第七層），下層可以隨意變化;

HTTPS就是在HTTP與TCP之間增加了SSL/TSL安全傳輸層，HTTP/3把TCP換成了基于UDP的QUIC。

常見狀態碼詳細介紹

HTTP 協議規范（以及后續的 RFC 文檔）定義了大量的標準狀態碼，用于表示服務器對客戶端請求的處理結果。這些狀態碼被分組在不同的類別中：

HTTP 狀態碼（Status Code）只包含在 HTTP 響應報文中。它是響應報文的起始行（Status-Line）的一部分。

如果客戶端收到了來自目標地址的有效的 HTTP 響應報文，并且其中包含了 HTTP 狀態碼，那么這基本上可以確定您已經成功連接到了目標服務器。

1xx

1xx 類狀態碼屬于提示信息，是協議處理中的一種中間狀態，實際用到的比較少。

2xx

2xx 類狀態碼表示服務器成功處理了客戶端的請求，也是我們最愿意看到的狀態。 「200 OK」是最常見的成功狀態碼，表示一切正常。如果是非 HEAD 請求，服務器返回的響應頭都 會有 body 數據。 「204 No Content」也是常見的成功狀態碼，與 200 OK 基本相同，但響應頭沒有 body 數據。 「206 Partial Content」是應用于 HTTP 分塊下載或斷點續傳，表示響應返回的 body 數據并不是資源 的全部，而是其中的一部分，也是服務器處理成功的狀態。

3xx

3xx 類狀態碼表示客戶端請求的資源發送了變動，需要客戶端用新的 URL 重新發送請求獲取資源， 也就是重定向。 「301 Moved Permanently」表示永久重定向，說明請求的資源已經不存在了，需改用新的 URL 再次 訪問。 「302 Found」表示臨時重定向，說明請求的資源還在，但暫時需要用另一個 URL 來訪問。

301 和 302 都會在響應頭里使用字段 Location ，指明后續要跳轉的 URL，瀏覽器會自動重定向新的

URL。 「304 Not Modified」不具有跳轉的含義，表示資源未修改，重定向已存在的緩沖文件，也稱緩存重定 向，用于緩存控制。

4xx

4xx 類狀態碼表示客戶端發送的報文有誤，服務器無法處理，也就是錯誤碼的含義。 「400 Bad Request」表示客戶端請求的報文有錯誤，但只是個籠統的錯誤。 「403 Forbidden」表示服務器禁止訪問資源，并不是客戶端的請求出錯。 「404 Not Found」表示請求的資源在服務器上不存在或未找到，所以無法提供給客戶端。

5xx

5xx 類狀態碼表示客戶端請求報文正確，但是服務器處理時內部發生了錯誤，屬于服務器端的錯誤 碼。 「500 Internal Server Error」與 400 類型，是個籠統通用的錯誤碼，服務器發生了什么錯誤，我們并 不知道。 「501 Not Implemented」表示客戶端請求的功能還不支持，類似“即將開業，敬請期待”的意思。「502 Bad Gateway」通常是服務器作為網關或代理時返回的錯誤碼，表示服務器自身工作正常，訪問 后端服務器發生了錯誤。 「503 Service Unavailable」表示服務器當前很忙，暫時無法響應服務器，類似“網絡服務正忙，請稍 后重試”的意思。

3. ?狀態

無狀態

服務器不會保留任何關于客戶端在之前請求中的信息或狀態。每一次 HTTP 請求都是完全獨立的，服務器處理當前的請求時，不會記住或依賴于客戶端之前發送的任何請求。

簡單來說，就像服務器得了“短期失憶癥”。客戶端每發送一個請求給服務器，服務器就像是第一次見到這個客戶端一樣，它只根據當前請求報文中的信息來進行處理和響應。

無狀態帶來了什么影響？

優點：

最大的優點就是：服務器設計簡單： 服務器不需要為每個客戶端維護大量的狀態信息，大大簡化了服務器的設計。

缺點：

• 每次請求需要攜帶足夠的信息： 由于服務器不記事兒，客戶端每次發送請求時，必須攜帶所有必要的信息來完成本次請求。例如，如果要訪問需要登錄才能看到的頁面，每次請求都需要帶上身份認證信息。
  ?
• 需要額外的機制來管理會話狀態： 對于需要保持用戶狀態的應用（如購物車、用戶登錄），僅僅依賴無狀態的 HTTP 是不夠的。為了記住用戶是誰、購物車里有什么，需要在 HTTP 協議之上引入其他的技術或方法來管理狀態。

通過 Cookie（在客戶端存儲標識符）和 Session（在服務器端存儲具體狀態），我們就可以在無狀態的 HTTP 協議上構建有狀態的 Web 應用。

Cookie和Session

Cookie（客戶端）中常見的保存內容包括：

1. 會話標識符 (Session ID)： 這是最常見和核心的用途。Cookie 中通常存儲一個由服務器生成的唯一的 Session ID，用于在服務器端查找對應的 Session 數據。這個 Session ID 是服務器在用戶第一次訪問時生成的，并通過 HTTP 響應頭部的 Set-Cookie 發送給瀏覽器。之后，瀏覽器在向同一個網站發送后續請求時，會自動在請求頭部的 Cookie 字段中帶上這個 Session ID 發送給服務器。
   ?
2. 用戶偏好設置： 比如用戶選擇的語言、主題、頁面布局、是否記住用戶名等簡單的配置信息。
   ?
3. 跟蹤信息： 用于網站分析或廣告跟蹤，記錄用戶的訪問行為、來源、最后訪問時間等標識符或簡單數據。
   ?
4. 狀態標志： 例如，用戶是否已經看過某個新手引導、某個彈窗廣告，或者接受了 Cookie 政策等。
   ?
5. “記住我”功能相關的 Token： 為了實現長期登錄（“記住我”），Cookie 中會存儲一個由服務器生成的、用于下次訪問時自動登錄的 Token 或標識符，而不是直接存儲用戶名和密碼（非常不安全）。

Cookie 保存的是用于在客戶端和服務器之間傳遞或在客戶端本地持久化少量信息的文本數據，主要用于用戶識別、狀態管理和個性化設置等方面，絕對不應該在 Cookie 中直接存儲敏感信息，特別是用戶的密碼。

Cookie 一般可以被設置為在客戶端長久保存，幾天、幾個月甚至幾年。

Session（服務器端）： Session 機制則負責在服務器端存儲用戶的具體狀態信息。服務器接收到客戶端發送的請求后，從 Cookie 中讀取 Session ID。然后根據這個 Session ID，在服務器端的內存、數據庫、文件或緩存（如 Redis）中查找對應的用戶狀態數據（例如：用戶是否已登錄、用戶的用戶名、購物車中的商品列表、用戶的權限等）。

Session 的目的是為了在一次連續的、相對短暫的用戶訪問過程中維持狀態。一旦用戶離開、長時間不活動或明確結束會話，相關的 Session 數據就會被清理，以確保服務器資源的有效利用和數據安全。

服務器端的 Session 是臨時存在的

4. 明?傳輸、不安全

HTTP 報文（特別是頭部信息、請求 URL、以及報文體如果是文本格式的內容）在客戶端和服務器之間傳輸時，是不經過加密的，直接以文本（字符串）的形式在網絡上傳輸。

• 易于理解和調試： 正因為是明文，開發者或管理員可以使用抓包工具（如 Wireshark）或者在瀏覽器開發者工具中直接看到 HTTP 請求和響應的詳細內容，非常便于理解和調試。

• 安全性風險： 這是明文傳輸最大的問題。由于數據是直接可讀的，如果傳輸的內容包含敏感信息，比如：登錄的用戶名和密碼，用戶在表單中輸入的個人信息，請求的 URL 本身（可能包含敏感參數）。

任何能夠截獲網絡流量的第三方（比如在同一個 Wi-Fi 下的人、互聯網服務提供商、網絡路由器等）都可以直接讀取這些信息，造成數據泄露的風險。

為了解決 HTTP 的明文傳輸帶來的安全問題，就引入了 HTTPS。HTTPS 是在 HTTP 和 TCP 之間增加了一層 SSL/TLS 加密層。這樣一來，即使 HTTP 報文內容是明文的，但在通過網絡傳輸之前，整個報文會被 SSL/TLS 層加密，變成只有服務器（擁有私鑰）才能解密的密文。傳輸過程中的第三方截獲到的將是無法解讀的亂碼，大大提高了通信的安全性。

HTTP協議發展過程

?前為?，HTTP 常?的版本有 HTTP/1.1 ， HTTP/2.0 ， HTTP/3.0 ，不同版本的 HTTP 特性是不?樣的。我們上面介紹到的HTTP/1.1的很多特點已經不適用 HTTP/2.0 ， HTTP/3.0了。

關于HTTP1.1之前的版本我們就來進行簡單了解一下就行啦：

HTTP/0.9

HTTP/0.9 是最早的HTTP版本，在1991年就已經發布，只?持 GET ?法，也沒有請求頭，服務器只能返回 HTML格式的內容。

HTTP/1.0

HTTP/1.0 是HTTTP 協議的第?個正式版本, 主要具有以下特性：

引?了請求頭和響應頭，?持多種請求?法和狀態碼

不?持持久連接，每次請求都需要建?新的連接，屬于短連接

為了解決 HTTP/1.0 每次請求都需要建?新的連接的問題， HTTP/1.1 提出了?連接（持久連接），只要客戶端和 服務器任意?端沒有明確提出斷開連接，則保持TCP連接狀態。

?

HTTP/1.1的不足

首先說一下HTTP/1.1的一些其他缺點，當然這是相對于HTTP/2.0的改進來說的啦。

1. 在 HTTP/1.1 中，為了確保通信的正確性和可靠性，客戶端通常會等待接收到一個請求的完整響應后，才在同一個持久連接上發送下一個請求。

關于HTTP請求，我想先補充一下：訪問一個網頁（輸入一次網址）需要發出多次 HTTP 請求這個知識。

一個標準的 HTTP 請求是為了獲取一個特定的“資源”（Resource）。在很多情況下，這個“資源”對應于服務器上的一個文件（比如一個 HTML 文件、一個 CSS 文件、一個圖片文件）。

一個網頁是由多個文件進行組成的，所以訪問一個網頁需要多次發出HTTP請求，而我們的HTTP1.1協議的請求必須等到上一個HTTP請求的響應到達才可以發送下一個。這就導致瀏覽器渲染頁面時候渲染得很慢，因為數據可能需要一段時間才能完全準備好。

雖然HTTP/1.1 理論上有一個叫做**管線化（Pipelining）**的功能，允許客戶端在收到上一個請求的響應之前就發送下一個請求。如果管線化被完全啟用且工作正常，那么就不需要等收到響應再發送下一個請求。但是幾乎沒有瀏覽器會采用HTTP/1.1的管線化。

因為HTTP1.1的管線化要求數據必須順序響應，比如請求了1，2，3，響應也必須按照1，2，3來響應。

在 HTTP/1.1 開啟管線化后，接收響應的順序和請求順序不一致（比如請求 1, 2, 3，響應收到 2, 1, 3），通常會導致直接的錯誤，瀏覽器也很難進行有效的暫存和重組。

原因在于 HTTP/1.1 是基于文本流的協議，并且在同一個連接上，客戶端解析響應必須是嚴格按照順序來的。感覺HTTP/1.1的管線化很雞肋，所以一般不開啟HTTP1.1的管線化也正常！

為了提高HTTP/1.1請求響應速度，我們可以采用如下優化方式：

1. 建立多條tcp連接，這是現代瀏覽器在處理 HTTP/1.1 網頁時默認采用的策略。它們通常會限制對同一個域名同時建立的連接數（一般是 6-8 個）。

2. 將一些文件內容盡可能合并，減少需要傳輸的文件數量，例如，將多個 CSS 文件合并成一個 CSS 文件，將多個 JS 文件合并成一個 JS 文件，將多個小圖片合并成一個雪碧圖 - Sprite Image）。

雪碧圖：

• 將網頁中多個小圖片（例如各種圖標、按鈕背景、小裝飾圖等）合并到一張大的圖片文件中。
• 在網頁中使用這些小圖片時，不再分別引用原始的單個圖片文件。而是將需要使用小圖片元素的背景圖片設置為這張大的雪碧圖。
• 然后，通過 CSS 的 background-position 屬性，精確地控制元素的背景圖片顯示區域，只顯示雪碧圖中的某個特定小圖片部分。同時設置元素的 width 和 height 來定義這個顯示區域的大小。

HTTP/2.0

二進制分幀層 (Binary Framing Layer)：

• 特點： 這是 HTTP/2 最基礎的變化。HTTP/2 不再是 HTTP/1.1 那樣的純文本協議，而是在應用層和傳輸層之間增加了一個二進制分幀層。HTTP/2 的所有通信都被分解為更小的、帶有標識符和長度前綴的二進制幀 (Frames)。
• 工作原理： 不同類型的消息（如頭部、數據）都被封裝在不同類型的幀中。這些幀擁有流標識符 (Stream Identifier)，用于區分它們屬于哪個請求或響應。
• 帶來的改進： 這是實現 HTTP/2 其他所有高級特性的基礎。將報文分割成幀使得多路復用、優先級控制等成為可能，改變了 HTTP/1.1 基于文本和順序解析的模式。

多路復用 (Multiplexing)：

• 特點： 允許在單個 TCP 連接上同時發送和接收多個 HTTP 請求和響應，并且它們可以亂序發送和到達。
• 工作原理： 通過二進制分幀和流（Stream）的概念實現。每個請求/響應都在一個獨立的邏輯流中進行，由唯一的 Stream ID 標識。不同流的幀可以在同一個 TCP 連接上交錯發送。客戶端和服務器根據幀的 Stream ID 將它們重新組裝成完整的請求或響應。
• 帶來的改進 (解決 HTTP/1.1 隊頭阻塞和多連接開銷)： 這是 HTTP/2 解決 HTTP/1.1 應用層隊頭阻塞問題的核心機制。一個請求/響應的延遲不會阻塞同一連接上的其他請求/響應。同時，它大幅減少了 HTTP/1.1 中為了提高并行度而不得不建立多個 TCP 連接的開銷（三次握手、四次揮手、慢啟動等），降低了延遲和服務器資源消耗。

頭部壓縮 (Header Compression - HPACK)：

• 特點： 有效地壓縮 HTTP 頭部，減少重復數據的傳輸。
• 工作原理： HTTP/2 使用 HPACK 壓縮算法。它在客戶端和服務器之間維護和更新一個共享的頭部信息表，包括靜態表（預定義常見的頭部字段）和動態表（記錄本次連接中發送過的頭部）。傳輸頭部時，如果頭部字段是表中已有的，只需發送其索引；如果是新的字段，則發送其值并更新表。此外，還使用了 Huffman 編碼對字符串進行壓縮。
• 帶來的改進 (解決頭部冗余)： 大幅減少了重復發送的頭部數據量，特別是在請求同一個網站的多個資源時，頭部通常非常相似，壓縮效果顯著，節省了帶寬，提高了傳輸效率。

強制使用 HTTPS (De Facto Requirement for HTTPS)：

• 特點： 雖然 HTTP/2 規范本身允許在明文 TCP 上運行（稱作 h2c），但目前絕大多數主流瀏覽器（如 Chrome, Firefox, Edge, Safari）只支持在 TLS/SSL 加密連接上運行 HTTP/2（稱作 h2）。
• 帶來的影響： 實際上促使了網站向 HTTPS 遷移，因為只有使用了 HTTPS，才能享受到 HTTP/2 帶來的性能優勢，從而提高了整個 Web 的安全性。

HTTP/3.0

HTTP/2.0仍然可能面臨傳輸層（TCP 層面）的隊頭阻塞問題。

因為 HTTP/2 的所有流（Streams）的數據幀都是在同一個 TCP 連接上進行傳輸的，它們的數據是被混合（多路復用）在一起發送的。如果 TCP 連接中的一個數據包丟失了，并且這個數據包中包含了多個 HTTP/2 流的幀數據，那么 TCP 層面的阻塞會導致所有這些流以及后續流的數據都無法及時遞交給 HTTP/2 層進行處理和重組，直到丟失的數據包被恢復。

HTTP/3： 基于 UDP 的 QUIC 協議，提供了傳輸層面的多路復用。QUIC 的流是獨立的，一個流的丟包不會阻塞其他流的數據傳輸。因此，HTTP/3 徹底解決了隊頭阻塞問題（包括應用層和傳輸層）。但是目前HTTP/3.0應用不廣泛，目前用的最多的還是HTTP/2.0。

HTTPS協議

HTTP協議和HTTPS協議的區別

HTTP：超文本傳輸協議

HTTPS：超文本安全傳輸協議

HTTPS 本質上不是一個全新的、獨立的協議，它更準確地說是一個 在安全層上運行的 HTTP 協議。它是在標準的 HTTP 協議與底層的傳輸協議（主要是 TCP）之間插入了 TLS/SSL（傳輸層安全/安全套接層） 協議。

當您建立一個安全的 HTTPS 連接時，實際使用的是 TLS 協議（通常是 TLS 1.2 或 TLS 1.3）

TLS 是 SSL 的繼任者（或升級版本）。它是基于 SSL 3.0 演變而來的。SSL 版本（特別是 SSL 2.0 和 SSL 3.0）由于存在已知的嚴重安全漏洞，已經被棄用了。我們現在可以認為HTTPS = HTTP + TLS。

• 安全性 (Security):

  • HTTP: 數據在客戶端和服務器之間以明文形式傳輸。這意味著任何能夠截獲網絡流量的第三方（如網絡管理員、ISP、攻擊者）都可以直接讀取傳輸的數據內容，包括敏感信息（用戶名、密碼、支付信息等）。數據也容易被篡改而客戶端無法得知。
    ?
  • HTTPS: 數據在傳輸前會經過 TLS/SSL 加密。截獲的數據是加密后的密文，難以解讀。TLS/SSL 還提供數據完整性檢查，確保數據在傳輸過程中沒有被篡改。此外，通過服務器身份認證（通常基于數字證書），客戶端可以確認正在通信的服務器是合法的，防止中間人攻擊。

• 協議層級 (Protocol Stack):

  • HTTP: 直接運行在 TCP 協議之上。
  • HTTPS: 運行在 TLS/SSL 協議之上，而 TLS/SSL 又運行在 TCP/UDP 協議之上。簡而言之，是 HTTP -> TLS/SSL -> TCP/UDP。

• URL 前綴 (URL Scheme):

  • HTTP: 使用 http://。
  • HTTPS: 使用 https://。

• 默認端口 (Default Port):

  • HTTP: 默認使用端口 80。
  • HTTPS: 默認使用端口 443。

• 證書要求 (Certificate Requirement):

  • HTTP: 不需要任何證書。
  • HTTPS: 服務器必須擁有由受信任的證書頒發機構 (CA) 頒發的 SSL/TLS 數字證書。這個證書用于證明服務器的身份。雖然獲取證書曾需要付費，但現在有許多機構提供免費證書（如 Let's Encrypt）。

• 連接建立過程 (Connection Process):

  • HTTP: TCP 三次握手即可開始傳輸 HTTP 數據。
  • HTTPS: 在 TCP 三次握手之后，還需要進行 TLS/SSL 握手過程。這個握手過程用于協商加密算法、交換密鑰、進行身份驗證等。這會增加一些初始連接建立的延遲。

HTTP 本身不加密，HTTPS 的加密是由 TLS/SSL 層完成的，通過復雜的握手過程（利用非對稱加密和證書認證）來安全地協商出會話期間用于數據傳輸的對稱密鑰，然后使用該對稱密鑰對所有 HTTP 數據進行快速加密傳輸。

HTTPS中的加密方式

對稱加密

對稱加密也稱為私鑰加密，使?相同的密鑰來進?加密和解密。 在加密過程中，明?數據通過應?特定的算法和密鑰進?加密，?成密?數據。解密過程則是將密?數據應? 同樣的算法和密鑰進?解密，恢復為明?數據。 由于加密和解密都使?相同的密鑰，因此對稱加密算法的速度通常較快，但密鑰的安全性很重要。如果密鑰泄漏，攻擊者可以輕易地解密數據。

對稱加密指的就是，雙方都知道加密的算法，并且都擁有解密的鑰匙，但是這個鑰匙如果不小心被攻擊者知道的話，即使雙方通信時使用的是加密好的文件，攻擊者也可以用偷來的鑰匙進行解開。你可能會想為什么這個私鑰有機會被攻擊者偷到呢？因為這個私鑰一定是需要一方通過網絡明文傳遞給另一方的，這樣就給了攻擊者可乘之機。

?對稱加密

?對稱加密也稱為公鑰加密，使??對不同但相關的密鑰：公鑰和私鑰。 公鑰?于加密數據，私鑰?于解密數據。如果使?公鑰加密數據，只有擁有相應私鑰的?才能解密數據；如果 使?私鑰加密數據，可以使?相應公鑰解密。 除了加密和解密，?對稱加密還?于【數字簽名】，可以驗證消息的來源和完整性。

非對稱加密實際上是把制作這把鎖的方法公開，任何人都可以按照你說的方法來制造這把鎖并且把想要保密的內容鎖上，然后只有你自己有這把鑰匙打開！鑰匙一直掌握在你自己的手中，沒有進行傳播，不可能出現泄露。

你可能會想就是為什么制作鎖的方式公布出去了之后，難道不能通過這個鎖推斷出鑰匙是什么樣子的嗎？這就涉及數學中的陷門單向函數

????????例如 RSA 算法。生成密鑰時，你選擇兩個非常大的素數作為私鑰的一部分，然后將它們相乘得到一個更大的合數，這個合數就是公鑰的一部分。乘法是容易的。但給定一個非常大的合數，想要找出它的兩個原始素數因子（分解因數），在目前沒有任何已知的快速算法，計算量會隨著數字的增大呈指數級增長。

HTTPS中的 非對稱加密+對稱加密

HTTPS 中采用的加密算法是?非對稱加密 + 對稱加密 的混合加密方式。

1. 在握手階段 (Handshake Phase)：

   • 主要使用非對稱加密。這是為了安全地協商和交換用于后續數據傳輸的對稱密鑰。因為非對稱加密的公鑰(鎖的制作方法)是公開的，發送方可以用公鑰加密一個密鑰，只有擁有對應私鑰的接收方能解密得到，這樣發送方和接收方就都獲得了對稱加密算法中的私鑰，并且這個私鑰沒有在網絡中以明文的方式傳播，所以黑客是獲取不到對稱加密的私鑰的。
     ?
   • 同時，非對稱加密（通過數字簽名）也用于驗證服務器的身份（客戶端使用 CA 的公鑰驗證服務器證書上的簽名）。

2. 在數據傳輸階段 (Data Transfer Phase)：

   • 一旦握手完成，雙方就使用在握手階段協商和生成好的對稱密鑰來對實際傳輸的大量 HTTP 數據（請求頭、體、響應頭、體）進行對稱加密。

為什么采用混合方式？

• 非對稱加密雖然安全（密鑰交換和身份驗證），但計算開銷大，速度慢，不適合用來加密大量的數據。
• 對稱加密計算開銷小，速度快，適合用來加密大量的數據，但它的問題在于如何安全地在通信雙方之間共享密鑰。

HTTPS 的混合加密正是解決了這個矛盾：利用非對稱加密的安全性來解決對稱密鑰的共享問題（安全地交換對稱密鑰），然后利用對稱加密的高效性來解決大量數據加密的問題。

HTTPS中建立連接的方式

HTTPS 連接的建立過程可以分解為兩個主要步驟：

1. 底層 TCP 連接建立 ：

   • 這是任何基于 TCP 的網絡通信（包括 HTTP 和 HTTPS）都需要的第一步。
   • 客戶端和服務器之間進行經典的 TCP 三次握手 (Three-Way Handshake)：
     • 客戶端 -> 服務器: SYN (同步序列號)
     • 服務器 -> 客戶端: SYN-ACK (同步序列號并確認)
     • 客戶端 -> 服務器: ACK (確認)
   • 握手成功后，客戶端和服務器之間就建立了一個可靠的、雙向的 TCP 連接。
2. TLS/SSL 安全連接建立
   • 客戶端向服務器索要并驗證服務器的公鑰（非對稱加密）。
   • 雙?協商?產「會話秘鑰」（對稱加密）。
   • 雙?采?「會話秘鑰」進?加密通信。