來源：杰哥的IT之旅
作者：阿拉斯加

最近卷了一篇 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 能夠查知報文是否遭到篡改，從而保證報文的完整性；

下面再用圖解來形象的說明一下，此圖比上面數字證書的圖更加的詳細一些：

在上面說明了 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 性能能調優，關于減少請求次數，減少服務器壓力等等；

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

往期推薦

阿里云投入 20 億發力操作系統

數學在左，人生在右

Redis很厲害，使用規范來啦

低代碼會讓程序員更加內卷嗎？

點分享

點收藏

點點贊

點在看

總結

以上是生活随笔為你收集整理的HTTPS 协议到底比 HTTP 协议多些什么？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。