本文是準備面試過程中網路部分總結整理的最後一篇文章，主要介紹以下知識：
- HTTP 協議概述
- POST 請求和 GET 請求
- Cookie 和 Session
- 資料傳輸時的加密
- HTTPS 簡介
HTTP 協議
在 OSI 七層模型中，HTTP 協議位於最頂層的應用層中。通過瀏覽器訪問網頁就直接使用了 HTTP 協議。使用 HTTP 協議時，客戶端首先與服務端的 80 埠建立一個 TCP 連線，然後在這個連線的基礎上進行請求和應答，以及資料的交換。
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 請求則用於傳送資料，除了用途上的區別，它們還有以下這些不同：
- GET 請求可以被快取，可以被收藏為書籤，但 POST 不行。
- GET 請求會保留在瀏覽器的歷史記錄中，POST 不會。
- GET 請求的長度有限制（不同的瀏覽器不一樣，大約在幾 Kb 左右），URL 的資料型別只能是 ASCII 字元，POST 請求沒有限制。
- GET 請求的引數在 URL 中，因此絕不能用 GET 請求傳輸敏感資料。POST 請求資料則寫在 HTTP 的請求頭中，安全性略高於 GET 請求。
注意：
POST 請求僅比 GET 請求略安全一點，它的資料不在 URL 中，但依然以明文的形式存放於 HTTP 的請求頭中。 複製程式碼
Cookie 和 Session
HTTP 是一種無狀態的連線，客戶端每次讀取 web 頁面時，伺服器都會認為這是一次新的會話。但有時候我們又需要持久保持某些資訊，比如登入時的使用者名稱、密碼，使用者上一次連線時的資訊等。這些資訊就由 Cookie 和 Session 儲存。
這兩者的根本性區別在於，cookie 儲存在客戶端上，而 session 則儲存在伺服器中。由此我們還可以擴充出以下結論：
- cookie 相對來說不安全，瀏覽器可以分析本地的 cookie 進行 cookie 欺騙。
- session 可以設定超時時間，超過這個時間後就失效，以免長期佔用服務端記憶體。
- 單個 cookie 的大小有限制（4 Kb），每個站點的 cookie 數量一般也有限制（20個）。
- 客戶端每次都會把 cookie 傳送到服務端，因此服務端可以知道 cookie，但是客戶端不知道 session。
當伺服器接收到 cookie 後，會根據 cookie 中的 SessionID 來找到這個客戶的 session。如果沒有，則會生成一個新的 SessionID 傳送給客戶端。
加密
加密分為兩種，對稱加密和非對稱加密。在解釋這兩者的含義前，先來看一下簡單的加密、解密過程：
所謂的對稱，就是指加密祕鑰和解密祕鑰相同，而非對稱自然就是指兩者不同。
舉一個對稱加密的例子。假設這裡的加密演算法是加法，解密演算法是減法。如果明文資料是 10，祕鑰是 1，那麼加密資料就是 10 + 1 = 11，如果接收方不知道祕鑰，就不知道密文 11 應該減去幾。反之，如果接收方知道祕鑰是 1，就可以通過 11 - 1 = 10 計算出明文資料。
常見的一個非對稱加密演算法是 RSA 演算法，它主要利用了“兩個素數求乘積容易，但是將乘積分解為兩個素數很難”這一思想。它的具體原理不在本文討論範圍，有興趣的讀者可以檢視文章末尾的參考文章。
在非對稱加密中，利用公鑰加密的資料能且只能通過私鑰解密，通過私鑰加密的資料能且只能通過公鑰解密。
對稱加密的優點在於速度快，但是假設祕鑰由伺服器儲存，如何安全的讓客戶端得到祕鑰是需要解決的問題。因此實際的網路傳輸中，通常使用對稱加密與非對稱加密結合的方式，服務端通過非對稱加密將對稱祕鑰發給客戶端。此後雙方使用這個對稱金鑰進行通訊。
HTTPS
我們知道 HTTP 協議直接使用了 TCP 協議進行資料傳輸。由於資料沒有加密，都是直接明文傳輸，所以存在以下三個風險：
- 竊聽風險：第三方節點可以獲知通訊內容。
- 篡改風險：第三方節點可以修改通訊內容。
- 冒充風險：第三方節點可以冒充他人身份參與通訊。
比如你在手機上開啟應用內的網頁時，有時會看到網頁底部彈出了廣告，這實際上就說明你的 HTTP 內容被竊聽、並篡改了。
HTTPS 協議旨在解決以上三個風險，因此它可以：
- 保證所有資訊加密傳輸，無法被第三方竊取。
- 為資訊新增校驗機制，如果被第三方惡意破壞，可以檢測出來。
- 配備身份證書，防止第三方偽裝參與通訊。
HTTPS 的結構如圖所示：
可見它僅僅是在 HTTP 和 TCP 之間新增了一個 TLS/SSL 加密層，這也印證了一句名言：“一切計算機問題都可以通過新增中間層解決”。
使用 HTTPS 時，服務端會將自己的證書傳送給客戶端，其中包含了服務端的公鑰。基於非對稱加密的傳輸過程如下：
- 客戶端使用公鑰將資訊加密，密文傳送給服務端
- 服務端用自己的私鑰解密，再將返回資料用私鑰加密發回客戶端
- 客戶端用公鑰解密
這裡的證書是伺服器證明自己身份的工具，它由權威的證書頒發機構（CA）發給申請者。如果證書是虛假的，或者是自己給自己頒發的證書，伺服器就會不認可這個證書併發出警告：
總結一下 HTTPS 協議是如何避免前文所說的三大風險的：
- 先用非對稱加密傳輸密碼，然後用這個密碼對稱加密資料，使得第三方無法獲得通訊內容
- 傳送方將資料的雜湊結果寫到資料中，接收方解密後對比資料的雜湊結果，如果不一致則說明被修改。由於傳輸資料加密，第三方無法修改雜湊結果。
- 由權威機構頒發證書，再加上證書校驗機制，避免第三方偽裝參與通訊。