HTTPS 協議到底比 HTTP 協議多些什麼？_傑哥的IT之旅

來源：公眾號【傑哥的IT之旅】

作者：阿拉斯加

ID：Jake_Internet

原文地址：HTTPS 協議到底比 HTTP 協議多些什麼？

大家好，我是傑哥。最近捲了一篇 HTTP 協議的相關知識，大綱如下：

HTTP 簡介

HTTP 協議是 Hyper Text Transfer Protocol（超文字傳輸協議）的縮寫，是用於從全球資訊網（WWW:World Wide Web ）伺服器傳輸超文字到本地瀏覽器的傳送協議。

HTTP 是一個基於 TCP/IP 通訊協議來傳遞資料（HTML 檔案，圖片檔案，查詢結果等）。

HTTP 是一個屬於應用層的面向物件的協議，由於其簡捷、快速的方式，適用於分散式超媒體資訊系統。它於 1990 年提出，經過幾年的使用與發展，得到不斷地完善和擴充套件。目前在 WWW 中使用的是 HTTP/1.0 的第六版，HTTP/1.1 的規範化工作正在進行之中，而且 HTTP-NG(Next Generation of HTTP) 的建議已經提出。

HTTP 協議工作於客戶端-服務端架構為上，瀏覽器作為 HTTP 客戶端通過 URL 向 HTTP 服務端即 WEB 伺服器傳送所有請求，Web 伺服器根據接收到的請求後，向客戶端傳送響應資訊。

HTTP 特點：

簡單快速：客戶向伺服器請求服務時，只需傳送請求方法和路徑。請求方法常用的有 GET、HEAD、POST。每種方法規定了客戶與伺服器聯絡的型別不同。由於 HTTP 協議簡單，使得 HTTP 伺服器的程式規模小，因而通訊速度很快；
靈活：HTTP 允許傳輸任意型別的資料物件。正在傳輸的型別由 Content-Type 加以標記；
無連線：無連線的含義是限制每次連線只處理一個請求。伺服器處理完客戶的請求，並收到客戶的應答後，即斷開連線。採用這種方式可以節省傳輸時間；
無狀態：HTTP 協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺少狀態意味著如果後續處理需要前面的資訊，則它必須重傳，這樣可能導致每次連線傳送的資料量增大。另一方面，在伺服器不需要先前資訊時它的應答就較快；
支援 B/S 及 C/S 模式；

HTTP 有以上這麼多的優點，那麼問題來了，HTTP 協議有什麼弊端嗎? 答案是肯定的，原因也很簡單，如果HTTP 是完美的，還需要一個叫做 HTTPS 協議的安全協議幹什麼呢?

HTTP 弊端：

當我們往伺服器傳送比較隱私的資料（比如說你的銀行卡，身份證）時，如果使用 http 進行通訊。那麼安全性將得不到保障；

首先資料在傳輸的過程中，資料可能被中間人抓包拿到，那麼資料就會被中間人竊取；

其次資料被中間人拿到後，中間人可能對資料進行修改或者替換，然後發往伺服器；

最後伺服器收到資料後，也無法確定資料有沒有被修改或替換，當然，如果伺服器也無法判斷資料就真的是來源於客戶端；

總結下來，HTTP 存在三個弊端：

無法保證訊息的保密性；
無法保證訊息的完整性和準確性；
無法保證訊息來源的可靠性；

HTTPS 簡介

如何解決 HTTP 弊端呢？HTTPS 就是為了解決上述問題應運而生的。

HTTPS（全稱：Hyper Text Transfer Protocol over Secure Socket Layer），是以安全為目標的 HTTP 通道，簡單講是 HTTP 的安全版。

即 HTTP 下加入 SSL 層，HTTPS 的安全基礎是 SSL，因此加密的詳細內容就需要 SSL。現在它被廣泛用於全球資訊網上安全敏感的通訊，例如交易支付方面。

HTTPS 通過非對稱加密演算法可以使得我們傳的明文資訊，無法通過逆推得出明文。接下來我們來看看在具體的工作流程是怎麼樣的？

工作原理：

HTTPS 的建立過程

這裡把 HTTPS 建立到斷開分為 6 個階段，12 過程。下面將對 12 個過程一一做解釋:

1、客戶端 — Hello：客戶端通過傳送 Client Hello 報文開始 SSL 通訊。報文中包含客戶端支援的 SSL 的指定版本、加密元件（Cipher Suite）列表（所使用的加密演算法及密匙長度等）；

2、伺服器 — Hello：伺服器可進行 SSL 通訊時，會以 Server Hello 報文作為應答。和客戶端一樣，在報文中包含 SSL 版本以及加密元件。伺服器的加密元件內容是從接收到的客戶端加密元件內篩選出來的；

3、伺服器 — 發證書：伺服器傳送證書報文。報文中包含公開密匙證書；

4、伺服器 — 我說完了：最後伺服器傳送 Server Hello Done 報文通知客戶端，最初階段的 SSL 握手協商部分結束；

5、客戶端 — 傳送祕鑰：SSL 第一次握手結束之後，客戶端以 Client Key Exchange 報文作為迴應。報文包含通訊加密中使用的一種被稱為 Pre-master secret 的隨機密碼串。該報文已用步驟 3 中的公開密匙進行加密；

6、客戶端 — 就用這個祕鑰了：該報文會提示伺服器，在此報文之後的通訊會採用 Pre-master secret 密匙加密；

7、客戶端 — 我說完了：該報文包含連線至今全部報文的整體校驗值。這次握手協商是否能夠成功，要以伺服器是否能夠正確解密該報文作為判定標準；

8、伺服器 — 傳送 c Change Cipher Spec 報文（我正在接收祕鑰）；

9、伺服器 — 傳送 d Finished 報文（我收完祕鑰了）；

10、客戶端 — 開始傳送正文：伺服器端傳送 HTTP 請求，傳送相關內容；

11、伺服器 — 開始接收正文：客戶端接收 HTTP 請求，並處理相關內容；

12、客戶端 — 斷開連結：最後由客戶端斷開連線。斷開連線時，傳送 close_notify 報文。上圖做了一些省略，這步之後再發送 TCP FIN 報文來關閉與 TCP 的通訊；

另外，在以上流程圖中，應用層傳送資料時會附加一種叫做 MAC（MessageAuthentication Code）的報文摘要。MAC 能夠查知報文是否遭到篡改，從而保證報文的完整性；

下面再用圖解來形象的說明一下，此圖比上面數字證書的圖更加的詳細一些（圖片來源於《圖解 HTTP》）

在上面說明了 HTTPS 的建立以及通訊中的過程。既然實際工作流程是這個樣子的，是怎樣的演算法能實現這樣的功能，是怎樣的方式能做到非對稱加密？在數學角度是如何計算的？那麼對應的理論基礎是什麼？是什麼支撐的 HTTPS 使得他能進行加密傳輸？

HTTPS 的理論原理：

HTTPS 採用了一些加解密，數字證書，數字簽名的技術來實現。下面先介紹一下這些技術的基本概念。

為了保證訊息的保密性，就需要用到加密和解密。加解密演算法目前主流的分為對稱加密和非對稱加密。

對稱加密（共享密匙加密）

客戶端和伺服器公用一個密匙用來對訊息加解密，這種方式稱為對稱加密。客戶端和伺服器約定好一個加密的密匙。客戶端在發訊息前用該密匙對訊息加密，傳送給伺服器後，伺服器再用該密匙進行解密拿到訊息。

圖示加密過程：

這裡採用的對稱加密演算法：

M：明文，我們本意要傳輸的內容；
C：祕鑰，在對稱加密演算法中需要用祕鑰加密，用祕鑰解密（加密演算法可以很簡單，加減乘除，也可以很複雜）；
N：密文，明文用祕鑰加密得到的內容，被稱為密文，在網路上傳輸的也是密文；

比如客戶端向伺服器傳輸 1（明文），1 + 3 （3 是祕鑰） = 4 得到密文，進行傳輸，伺服器得到密文 4， 4-3（3 是祕鑰）=1 得到明文，使得客戶端和伺服器端進行通訊，反之亦然；

對稱加密的優點：

對稱加密解決了 HTTP 中訊息保密性的問題；

對稱加密的缺點：

對稱加密雖然保證了訊息保密性，但是因為客戶端和伺服器共享一個密匙，這樣就使得密匙特別容易洩露；
因為密匙洩露風險較高，所以很難保證訊息來源的可靠性、訊息的完整性和準確性；

對稱加密祕鑰洩露風險很高，祕鑰固定，導致很容易被破解，那麼有沒有更好的方式去進行加密傳輸，比如說每次用的祕鑰都不相同，每次解密的祕鑰也都不相同，或者其他的情況來增加安全性呢？

非對稱加密（公有密匙加密）

既然對稱加密中，密匙那麼容易洩露，那麼我們可以採用一種非對稱加密的方式來解決。採用非對稱加密時，客戶端和服務端均擁有一個公有密匙和一個私有密匙。公有密匙可以對外暴露，而私有密匙只有自己可見。

使用公有密匙加密的訊息，只有對應的私有密匙才能解開。反過來，使用私有密匙加密的訊息，只有公有密匙才能解開。這樣客戶端在傳送訊息前，先用伺服器的公匙對訊息進行加密，伺服器收到後再用自己的私匙進行解密。

圖示加密過程：

解釋如下：

M：指的是明文，我們本意要傳輸的內容；
D：指的是公鑰，在非對稱加密演算法中需要用公鑰加密；
E：指的是私鑰，在非對稱加密演算法中需要用私鑰解密；
N：指的是密文，明文用祕鑰加密得到的內容，被稱為密文，在網路上傳輸的也是密文；

在伺服器這一次生成公鑰 D 以及私鑰 E，私鑰自己留存。然後將公鑰 D 進行對外公開，想與伺服器端通訊的客戶端用公鑰 D 進行加密傳送給具有私鑰 E 的伺服器，伺服器用私鑰 E 就可以進行密文解密，最終拿到明文。

非對稱加密演算法RSA簡介

RSA 是目前最有影響力的公鑰加密演算法，它能夠抵抗到目前為止已知的絕大多數密碼攻擊，已被 ISO 推薦為公鑰資料加密標準。

今天只有短的 RSA 鑰匙才可能被強力方式解破。到 2008 年為止，世界上還沒有任何可靠的攻擊 RSA 演算法的方式。只要其鑰匙的長度足夠長，用 RSA 加密的資訊實際上是不能被解破的。但在分散式計算和量子計算機理論日趨成熟的今天，RSA 加密安全性受到了挑戰。

RSA 演算法基於一個十分簡單的數論事實：將兩個大質數相乘十分容易，但是想要對其乘積進行因式分解卻極其困難，因此可以將乘積公開作為加密金鑰。

HTTP 效能調優

減少 HTTP 請求數

關於減少 HTTP 請求數，是效能優化的一個非常重要方面，所以在基本所有的優化原則裡，都有這一條原則:減少 HTTP 請求數，先不考慮其他的。

我們先考慮為什麼減少 HTTP 請求可以優化效能：

1、減少 DNS 請求所耗費的時間且不說對錯，因為從基本來說，減少 HTTP 請求數的確可以減少 DNS 請求和解析耗費的時間；

2、減少伺服器壓力這個通常是被考慮最多的，也是我用來講解給別人聽的最大理由，因為每個 HTTP 請求都會耗費伺服器資源，特別是一些需要計算合併等操作的伺服器，耗費伺服器的 CPU 資源可不是開玩笑的事情，硬碟可以用錢買來，CPU 資源可就沒那麼廉價了；

3、減少 HTTP 請求頭，當我們對伺服器發起一個請求的時候，我們會攜帶著這個域名下的 Cookie 和一些其他的資訊在 HTTP 頭部裡，然後伺服器響應請求的時候也會帶回一些 Cookie 之類的頭部資訊，這些資訊有的時候會很大，在這種請求和響應的時候會影響頻寬效能；

DNS 請求和解析

簡單來說，例如：www.taobao.com 這樣一個 URL，其中 www 部分被稱為主機名(hostname)，taobao 這部分則是二級域，com 則是一級域，如果是這樣一個網址：www.ali.tao.com 那麼 ali 就是三級域。

當我們去請求一個 URL 的時候，首先會到本地伺服器裡去尋找快取中是否有解析結果，如果沒有解析結果就去根域名伺服器請求，根域名伺服器返回給本地域名伺服器一個所查詢的域的主域名伺服器的 IP 地址，然後我們再去請求剛才返回的 IP 地址的域名伺服器，然後返回下一級域名的 IP 地址，直到我們找到域名中所指的伺服器 IP，然後將結果快取起來供下次使用並返回此結果。

一個第一次請求的 URL 的 DNS 解析過程可能耗費是很高的，但是解析一次之後結果就會被快取起來，之後再請求的時候就不用走上面這一套複雜的解析過程了。

減少伺服器壓力

過多的 HTTP 請求對於伺服器來說是很危險的，如果你的伺服器不是很強，請把這一條考慮放在第一位，其他的優化策略都只是優化，而這裡涉及到的是伺服器，你要保證你的伺服器能正常運轉。

但是這是淘寶網，我們有足夠的速度來提供足夠的使用者體驗。如果你的伺服器提供不了這種速度，也承受不了這種頻繁的非同步請求的話，這種優化就要慎重了，延遲可能造成導航不可用，這也是針對場景來協調的。

淘寶現在在廣泛部署 CDN，CDN 可以給我們提供足夠的後臺資源保障，在 CDN 和後臺環境不斷完善的情況下，考慮重點應該更加專注於前臺傳輸速度和展現解析速度的提升。

減少 HTTP 請求頭

HTTP 頭是個龐大的傢伙，你開啟 taobao.com 的首頁，alert 一下 document.cookie，會發現淘寶網的 cookie 比較大，每次你請求淘寶的伺服器都會往返一次這些資料，還有一些其他的頭部資訊，佔用的空間也不小，可想而知這種消耗有多大。

然後其實自從用了 CDN，這一切都無需考慮太多，因為 CDN 和淘寶主站不在一個域名下，cookie 不會互相汙染，而 CDN 的域名下基本是沒有 cookie 和頭部資訊的，所以每次請求靜態資源的時候，不會帶著主站的 cookie 到處跑，而只是傳輸資源的主題內容，所以這對於效能的影響在使用 cdn 之後會變得很小。但是如果你的靜態資源伺服器和主伺服器在一個域名下，那就要控制好 cookie 和其他頭部資訊的大小了，因為每次傳送都會傳送它們。

總結

我們這次針對於網路協議 HTTP 和 HTTPS 有了一個初步的瞭解，瞭解了 HTTP 的優缺點，正是由於 HTTP 的某些不足，才出現了 HTTPS，我們通過圖例瞭解了其工作原理，還是比較複雜的，需要進一步的理解加深，然後我們談到了 HTTP 效能能調優，關於減少請求次數，減少伺服器壓力等等；

總之對於不同的場景應該考慮不同的側重點，應該不同的網站規模和型別進行適度的優化，不能盲目追求標準和最佳實踐。

本文完。

原創不易，如果你覺得這篇文章對你有點用的話，麻煩你為本文點個贊、評論或轉發一下，因為這將是我輸出更多優質文章的動力，感謝！

對了，掘友們記得給我點個免費的關注喲！防止你迷路下次就找不到我了。

我們下期再見！