本文是準備面試過程中網絡部分總結整理的最后一篇文章，主要介紹以下知識：

• HTTP 協議概述
• POST 請求和 GET 請求
• Cookie 和 Session
• 數據傳輸時的加密
• HTTPS 簡介

HTTP 協議

在 OSI 七層模型中，HTTP 協議位于最頂層的應用層中。通過瀏覽器訪問網頁就直接使用了 HTTP 協議。使用 HTTP 協議時，客戶端首先與服務端的 80 端口建立一個 TCP 連接，然后在這個連接的基礎上進行請求和應答，以及數據的交換。

HTTP 工作原理

HTTP 有兩個常用版本，分別是 1.0 和 1.1。主要區別在于 HTTP 1.0 中每次請求和應答都會使用一個新的 TCP 連接，而從 HTTP 1.1 開始，運行在一個 TCP 連接上發送多個命令和應答。因此大幅度減少了 TCP 連接的建立和斷開，提高了效率。

由 HTTP 協議加載出來的網頁，通常使用 HTML 語言來描述，因此 HTML 也可以理解為網頁的一種數據格式。HTML 是一段純文本，可以指定網頁中的文字、圖像、音頻視頻圖片、鏈接，以及它們的顏色、位置等。無論計算機的底層結構如何，也無論網絡底層使用了哪些協議，使用 HTML 展示出來的效果基本上是一致的。從這個角度來說 HTML 位于 OSI 七層模型的表現層。

POST 請求和 GET 請求

HTTP 有八種請求（也稱方法），其中最常見的是 GET 請求和 POST 請求。

GET 請求通常用于查詢、獲取數據，而 POST 請求則用于發送數據，除了用途上的區別，它們還有以下這些不同：

1. GET 請求可以被緩存，可以被收藏為書簽，但 POST 不行。
2. GET 請求會保留在瀏覽器的歷史記錄中，POST 不會。
3. GET 請求的長度有限制（不同的瀏覽器不一樣，大約在幾 Kb 左右），URL 的數據類型只能是 ASCII 字符，POST 請求沒有限制。
4. GET 請求的參數在 URL 中，因此絕不能用 GET 請求傳輸敏感數據。POST 請求數據則寫在 HTTP 的請求頭中，安全性略高于 GET 請求。

注意：

  POST 請求僅比 GET 請求略安全一點，它的數據不在 URL 中，但依然以明文的形式存放于 HTTP 的請求頭中。

Cookie 和 Session

HTTP 是一種無狀態的連接，客戶端每次讀取 web 頁面時，服務器都會認為這是一次新的會話。但有時候我們又需要持久保持某些信息，比如登錄時的用戶名、密碼，用戶上一次連接時的信息等。這些信息就由 Cookie 和 Session 保存。

這兩者的根本性區別在于，cookie 保存在客戶端上，而 session 則保存在服務器中。由此我們還可以拓展出以下結論：

1. cookie 相對來說不安全，瀏覽器可以分析本地的 cookie 進行 cookie 欺騙。
2. session 可以設置超時時間，超過這個時間后就失效，以免長期占用服務端內存。
3. 單個 cookie 的大小有限制（4 Kb），每個站點的 cookie 數量一般也有限制（20個）。
4. 客戶端每次都會把 cookie 發送到服務端，因此服務端可以知道 cookie，但是客戶端不知道 session。

當服務器接收到 cookie 后，會根據 cookie 中的 SessionID 來找到這個客戶的 session。如果沒有，則會生成一個新的 SessionID 發送給客戶端。

加密

加密分為兩種，對稱加密和非對稱加密。在解釋這兩者的含義前，先來看一下簡單的加密、解密過程：

加密和解密過程

所謂的對稱，就是指加密秘鑰和解密秘鑰相同，而非對稱自然就是指兩者不同。

舉一個對稱加密的例子。假設這里的加密算法是加法，解密算法是減法。如果明文數據是 10，秘鑰是 1，那么加密數據就是 10 + 1 = 11，如果接收方不知道秘鑰，就不知道密文 11 應該減去幾。反之，如果接收方知道秘鑰是 1，就可以通過 11 - 1 = 10 計算出明文數據。

常見的一個非對稱加密算法是 RSA 算法，它主要利用了“兩個素數求乘積容易，但是將乘積分解為兩個素數很難”這一思想。它的具體原理不在本文討論范圍，有興趣的讀者可以查看文章末尾的參考文章。

在非對稱加密中，利用公鑰加密的數據能且只能通過私鑰解密，通過私鑰加密的數據能且只能通過公鑰解密。

對稱加密的優點在于速度快，但是假設秘鑰由服務器保存，如何安全的讓客戶端得到秘鑰是需要解決的問題。因此實際的網絡傳輸中，通常使用對稱加密與非對稱加密結合的方式，服務端通過非對稱加密將對稱秘鑰發給客戶端。此后雙方使用這個對稱密鑰進行通信。

HTTPS

我們知道 HTTP 協議直接使用了 TCP 協議進行數據傳輸。由于數據沒有加密，都是直接明文傳輸，所以存在以下三個風險：

1. 竊聽風險：第三方節點可以獲知通信內容。
2. 篡改風險：第三方節點可以修改通信內容。
3. 冒充風險：第三方節點可以冒充他人身份參與通信。

比如你在手機上打開應用內的網頁時，有時會看到網頁底部彈出了廣告，這實際上就說明你的 HTTP 內容被竊聽、并篡改了。

HTTPS 協議旨在解決以上三個風險，因此它可以：

1. 保證所有信息加密傳輸，無法被第三方竊取。
2. 為信息添加校驗機制，如果被第三方惡意破壞，可以檢測出來。
3. 配備身份證書，防止第三方偽裝參與通信。

HTTPS 的結構如圖所示：

HTTPS 協議

可見它僅僅是在 HTTP 和 TCP 之間新增了一個 TLS/SSL 加密層，這也印證了一句名言：“一切計算機問題都可以通過添加中間層解決”。

使用 HTTPS 時，服務端會將自己的證書發送給客戶端，其中包含了服務端的公鑰。基于非對稱加密的傳輸過程如下：

1. 客戶端使用公鑰將信息加密，密文發送給服務端
2. 服務端用自己的私鑰解密，再將返回數據用私鑰加密發回客戶端
3. 客戶端用公鑰解密

這里的證書是服務器證明自己身份的工具，它由權威的證書頒發機構（CA）發給申請者。如果證書是虛假的，或者是自己給自己頒發的證書，服務器就會不認可這個證書并發出警告：

12306 的自簽名證書

總結一下 HTTPS 協議是如何避免前文所說的三大風險的：

1. 先用非對稱加密傳輸密碼，然后用這個密碼對稱加密數據，使得第三方無法獲得通信內容
2. 發送方將數據的哈希結果寫到數據中，接收方解密后對比數據的哈希結果，如果不一致則說明被修改。由于傳輸數據加密，第三方無法修改哈希結果。
3. 由權威機構頒發證書，再加上證書校驗機制，避免第三方偽裝參與通信。

參考文章

1. HTTPS科普掃盲帖
2. SSL/TLS協議運行機制的概述
3. RSA 加密
4. HTTP 方法：GET 對比 POST