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

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

HTTP 協(xié)議

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

HTTP 工作原理

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

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

POST 請求和 GET 請求

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

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

GET 請求可以被緩存，可以被收藏為書簽，但 POST 不行。

GET 請求會保留在瀏覽器的歷史記錄中，POST 不會。

GET 請求的長度有限制（不同的瀏覽器不一樣，大約在幾 Kb 左右），URL 的數(shù)據(jù)類型只能是 ASCII 字符，POST 請求沒有限制。

GET 請求的參數(shù)在 URL 中，因此絕不能用 GET 請求傳輸敏感數(shù)據(jù)。POST 請求數(shù)據(jù)則寫在 HTTP 的請求頭中，安全性略高于 GET 請求。

注意：

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

Cookie 和 Session

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

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

cookie 相對來說不安全，瀏覽器可以分析本地的 cookie 進(jìn)行 cookie 欺騙。

session 可以設(shè)置超時時間，超過這個時間后就失效，以免長期占用服務(wù)端內(nèi)存。

單個 cookie 的大小有限制（4 Kb），每個站點(diǎn)的 cookie 數(shù)量一般也有限制（20個）。

客戶端每次都會把 cookie 發(fā)送到服務(wù)端，因此服務(wù)端可以知道 cookie，但是客戶端不知道 session。

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

加密

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

加密和解密過程

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

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

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

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

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

HTTPS

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

竊聽風(fēng)險：第三方節(jié)點(diǎn)可以獲知通信內(nèi)容。

篡改風(fēng)險：第三方節(jié)點(diǎn)可以修改通信內(nèi)容。

冒充風(fēng)險：第三方節(jié)點(diǎn)可以冒充他人身份參與通信。

比如你在手機(jī)上打開應(yīng)用內(nèi)的網(wǎng)頁時，有時會看到網(wǎng)頁底部彈出了廣告，這實(shí)際上就說明你的 HTTP 內(nèi)容被竊聽、并篡改了。

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

保證所有信息加密傳輸，無法被第三方竊取。

為信息添加校驗(yàn)機(jī)制，如果被第三方惡意破壞，可以檢測出來。

配備身份證書，防止第三方偽裝參與通信。

HTTPS 的結(jié)構(gòu)如圖所示：

HTTPS 協(xié)議

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

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

客戶端使用公鑰將信息加密，密文發(fā)送給服務(wù)端

服務(wù)端用自己的私鑰解密，再將返回?cái)?shù)據(jù)用私鑰加密發(fā)回客戶端

客戶端用公鑰解密

這里的證書是服務(wù)器證明自己身份的工具，它由權(quán)威的證書頒發(fā)機(jī)構(gòu)（CA）發(fā)給申請者。如果證書是虛假的，或者是自己給自己頒發(fā)的證書，服務(wù)器就會不認(rèn)可這個證書并發(fā)出警告：

12306 的自簽名證書

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

先用非對稱加密傳輸密碼，然后用這個密碼對稱加密數(shù)據(jù)，使得第三方無法獲得通信內(nèi)容

發(fā)送方將數(shù)據(jù)的哈希結(jié)果寫到數(shù)據(jù)中，接收方解密后對比數(shù)據(jù)的哈希結(jié)果，如果不一致則說明被修改。由于傳輸數(shù)據(jù)加密，第三方無法修改哈希結(jié)果。

由權(quán)威機(jī)構(gòu)頒發(fā)證書，再加上證書校驗(yàn)機(jī)制，避免第三方偽裝參與通信。

參考文章

HTTPS科普掃盲帖

SSL/TLS協(xié)議運(yùn)行機(jī)制的概述

RSA 加密

HTTP 方法：GET 對比 POST

文／bestswifter（簡書作者）
原文鏈接：http://www.jianshu.com/p/6e7521041e92
著作權(quán)歸作者所有，轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)，并標(biāo)注“簡書作者”。

總結(jié)

以上是生活随笔為你收集整理的TCP/IP（六）：HTTP 与 HTTPS 简介的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。