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

• HTTP 協(xié)議概述
• POST 請求和 GET 請求
• Cookie 和 Session
• 數(shù)據(jù)傳輸時的加密
• HTTPS 簡介

HTTP 協(xié)議

在 OSI 七層模型中鼓寺，HTTP 協(xié)議位于最頂層的應用層中。通過瀏覽器訪問網(wǎng)頁就直接使用了 HTTP 協(xié)議勋磕。使用 HTTP 協(xié)議時妈候，客戶端首先與服務端的 80 端口建立一個 TCP 連接，然后在這個連接的基礎上進行請求和應答挂滓，以及數(shù)據(jù)的交換苦银。

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

由 HTTP 協(xié)議加載出來的網(wǎng)頁团秽，通常使用 HTML 語言來描述，因此 HTML 也可以理解為網(wǎng)頁的一種數(shù)據(jù)格式。HTML 是一段純文本习勤，可以指定網(wǎng)頁中的文字踪栋、圖像、音頻視頻圖片图毕、鏈接夷都，以及它們的顏色、位置等予颤。無論計算機的底層結構如何囤官，也無論網(wǎng)絡底層使用了哪些協(xié)議，使用 HTML 展示出來的效果基本上是一致的蛤虐。從這個角度來說 HTML 位于 OSI 七層模型的表現(xiàn)層党饮。

POST 請求和 GET 請求

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

GET 請求通常用于查詢刑顺、獲取數(shù)據(jù)，而 POST 請求則用于發(fā)送數(shù)據(jù)饲常，除了用途上的區(qū)別蹲堂，它們還有以下這些不同：

1. GET 請求可以被緩存歇拆，可以被收藏為書簽迎变，但 POST 不行。
2. GET 請求會保留在瀏覽器的歷史記錄中鸭叙，POST 不會霹娄。
3. GET 請求的長度有限制（不同的瀏覽器不一樣能犯，大約在幾 Kb 左右），URL 的數(shù)據(jù)類型只能是 ASCII 字符犬耻，POST 請求沒有限制踩晶。
4. GET 請求的參數(shù)在 URL 中，因此絕不能用 GET 請求傳輸敏感數(shù)據(jù)枕磁。POST 請求數(shù)據(jù)則寫在 HTTP 的請求頭中渡蜻，安全性略高于 GET 請求。

注意：

POST 請求僅比 GET 請求略安全一點计济，它的數(shù)據(jù)不在 URL 中茸苇，但依然以明文的形式存放于 HTTP 的請求頭中。

Cookie 和 Session

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

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

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

當服務器接收到 cookie 后，會根據(jù) cookie 中的 SessionID 來找到這個客戶的 session橘忱。如果沒有赴魁，則會生成一個新的 SessionID 發(fā)送給客戶端。

加密

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

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

舉一個對稱加密的例子芦岂。假設這里的加密算法是加法，解密算法是減法垫蛆。如果明文數(shù)據(jù)是 10禽最，秘鑰是 1，那么加密數(shù)據(jù)就是 10 + 1 = 11袱饭，如果接收方不知道秘鑰川无，就不知道密文 11 應該減去幾。反之虑乖，如果接收方知道秘鑰是 1懦趋，就可以通過 11 - 1 = 10 計算出明文數(shù)據(jù)。

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

在非對稱加密中，利用公鑰加密的數(shù)據(jù)能且只能通過私鑰解密继找，通過私鑰加密的數(shù)據(jù)能且只能通過公鑰解密遂跟。

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

HTTPS

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

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

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

HTTPS 協(xié)議旨在解決以上三個風險入偷，因此它可以：

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

HTTPS 的結構如圖所示：

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

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

1. 客戶端使用公鑰將信息加密薄霜，密文發(fā)送給服務端
2. 服務端用自己的私鑰解密某抓，再將返回數(shù)據(jù)用私鑰加密發(fā)回客戶端
3. 客戶端用公鑰解密

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

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

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

TCP/IP（六）：HTTP 與 HTTPS 簡介（原）