HTTPS 協(xié)議到底比 HTTP 協(xié)議多些什么?
來源：公眾號【杰哥的IT之旅】
作者：阿拉斯加
ID：Jake_Internet
大家好，我是躍哥。作為一名 Java后端，在面試的時候經(jīng)常會被內(nèi)卷，問一些 Java 之外的問題，比如網(wǎng)絡(luò)。這不，Https 和 Http 的區(qū)別，大家都不陌生吧，面試也經(jīng)常被問到吧？今天躍哥就借這杰哥的文和大家一起聊聊HTTP 協(xié)議的相關(guān)知識，大綱如下：
HTTP 簡介
HTTP 協(xié)議是 Hyper Text Transfer Protocol（超文本傳輸協(xié)議）的縮寫，是用于從萬維網(wǎng)（WWW:World Wide Web ）服務(wù)器傳輸超文本到本地瀏覽器的傳送協(xié)議。
HTTP 是一個基于 TCP/IP 通信協(xié)議來傳遞數(shù)據(jù)（HTML 文件，圖片文件，查詢結(jié)果等）。
HTTP 是一個屬于應用層的面向?qū)ο蟮膮f(xié)議，由于其簡捷、快速的方式，適用于分布式超媒體信息系統(tǒng)。它于 1990 年提出，經(jīng)過幾年的使用與發(fā)展，得到不斷地完善和擴展。目前在 WWW 中使用的是 HTTP/1.0 的第六版，HTTP/1.1 的規(guī)范化工作正在進行之中，而且 HTTP-NG(Next Generation of HTTP) 的建議已經(jīng)提出。
HTTP 協(xié)議工作于客戶端-服務(wù)端架構(gòu)為上，瀏覽器作為 HTTP 客戶端通過 URL 向 HTTP 服務(wù)端即 WEB 服務(wù)器發(fā)送所有請求，Web 服務(wù)器根據(jù)接收到的請求后，向客戶端發(fā)送響應信息。
HTTP 特點：
簡單快速：客戶向服務(wù)器請求服務(wù)時，只需傳送請求方法和路徑。請求方法常用的有 GET、HEAD、POST。每種方法規(guī)定了客戶與服務(wù)器聯(lián)系的類型不同。由于 HTTP 協(xié)議簡單，使得 HTTP 服務(wù)器的程序規(guī)模小，因而通信速度很快；
靈活：HTTP 允許傳輸任意類型的數(shù)據(jù)對象。正在傳輸?shù)念愋陀?Content-Type 加以標記；
無連接：無連接的含義是限制每次連接只處理一個請求。服務(wù)器處理完客戶的請求，并收到客戶的應答后，即斷開連接。采用這種方式可以節(jié)省傳輸時間；
無狀態(tài)：HTTP 協(xié)議是無狀態(tài)協(xié)議。無狀態(tài)是指協(xié)議對于事務(wù)處理沒有記憶能力。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數(shù)據(jù)量增大。另一方面，在服務(wù)器不需要先前信息時它的應答就較快；
支持 B/S 及 C/S 模式；
HTTP 有以上這么多的優(yōu)點，那么問題來了，HTTP 協(xié)議有什么弊端嗎? 答案是肯定的，原因也很簡單，如果HTTP 是完美的，還需要一個叫做 HTTPS 協(xié)議的安全協(xié)議干什么呢?
HTTP 弊端：
當我們往服務(wù)器發(fā)送比較隱私的數(shù)據(jù)（比如說你的銀行卡，身份證）時，如果使用 http 進行通信。那么安全性將得不到保障；
首先數(shù)據(jù)在傳輸?shù)倪^程中，數(shù)據(jù)可能被中間人抓包拿到，那么數(shù)據(jù)就會被中間人竊取；
其次數(shù)據(jù)被中間人拿到后，中間人可能對數(shù)據(jù)進行修改或者替換，然后發(fā)往服務(wù)器；
最后服務(wù)器收到數(shù)據(jù)后，也無法確定數(shù)據(jù)有沒有被修改或替換，當然，如果服務(wù)器也無法判斷數(shù)據(jù)就真的是來源于客戶端；
總結(jié)下來，HTTP 存在三個弊端：
無法保證消息的保密性；
無法保證消息的完整性和準確性；
無法保證消息來源的可靠性；
HTTPS 簡介
如何解決 HTTP 弊端呢？HTTPS 就是為了解決上述問題應運而生的。
HTTPS（全稱：Hyper Text Transfer Protocol over Secure Socket Layer），是以安全為目標的 HTTP 通道，簡單講是 HTTP 的安全版。
即 HTTP 下加入 SSL 層，HTTPS 的安全基礎(chǔ)是 SSL，因此加密的詳細內(nèi)容就需要 SSL。現(xiàn)在它被廣泛用于萬維網(wǎng)上安全敏感的通訊，例如交易支付方面。
HTTPS 通過非對稱加密算法可以使得我們傳的明文信息，無法通過逆推得出明文。接下來我們來看看在具體的工作流程是怎么樣的？
工作原理：
HTTPS 的建立過程
這里把 HTTPS 建立到斷開分為 6 個階段，12 過程。下面將對 12 個過程一一做解釋:
1、客戶端 — Hello：客戶端通過發(fā)送 Client Hello 報文開始 SSL 通信。報文中包含客戶端支持的 SSL 的指定版本、加密組件（Cipher Suite）列表（所使用的加密算法及密匙長度等）；
2、服務(wù)器 — Hello：服務(wù)器可進行 SSL 通信時，會以 Server Hello 報文作為應答。和客戶端一樣，在報文中包含 SSL 版本以及加密組件。服務(wù)器的加密組件內(nèi)容是從接收到的客戶端加密組件內(nèi)篩選出來的；
3、服務(wù)器 — 發(fā)證書：服務(wù)器發(fā)送證書報文。報文中包含公開密匙證書；
4、服務(wù)器 — 我說完了：最后服務(wù)器發(fā)送 Server Hello Done 報文通知客戶端，最初階段的 SSL 握手協(xié)商部分結(jié)束；
5、客戶端 — 發(fā)送秘鑰：SSL 第一次握手結(jié)束之后，客戶端以 Client Key Exchange 報文作為回應。報文包含通信加密中使用的一種被稱為 Pre-master secret 的隨機密碼串。該報文已用步驟 3 中的公開密匙進行加密；
6、客戶端 — 就用這個秘鑰了：該報文會提示服務(wù)器，在此報文之后的通信會采用 Pre-master secret 密匙加密；
7、客戶端 — 我說完了：該報文包含連接至今全部報文的整體校驗值。這次握手協(xié)商是否能夠成功，要以服務(wù)器是否能夠正確解密該報文作為判定標準；
8、服務(wù)器 — 發(fā)送 c Change Cipher Spec 報文（我正在接收秘鑰）；
9、服務(wù)器 — 發(fā)送 d Finished 報文（我收完秘鑰了）；
10、客戶端 — 開始發(fā)送正文：服務(wù)器端發(fā)送 HTTP 請求，發(fā)送相關(guān)內(nèi)容；
11、服務(wù)器 — 開始接收正文：客戶端接收 HTTP 請求，并處理相關(guān)內(nèi)容；
12、客戶端 — 斷開鏈接：最后由客戶端斷開連接。斷開連接時，發(fā)送 close_notify 報文。上圖做了一些省略，這步之后再發(fā)送 TCP FIN 報文來關(guān)閉與 TCP 的通信；
另外，在以上流程圖中，應用層發(fā)送數(shù)據(jù)時會附加一種叫做 MAC（MessageAuthentication Code）的報文摘要。MAC 能夠查知報文是否遭到篡改，從而保證報文的完整性；
下面再用圖解來形象的說明一下，此圖比上面數(shù)字證書的圖更加的詳細一些（圖片來源于《圖解 HTTP》）
在上面說明了 HTTPS 的建立以及通信中的過程。既然實際工作流程是這個樣子的，是怎樣的算法能實現(xiàn)這樣的功能，是怎樣的方式能做到非對稱加密？在數(shù)學角度是如何計算的？那么對應的理論基礎(chǔ)是什么？是什么支撐的 HTTPS 使得他能進行加密傳輸？
HTTPS 的理論原理：
HTTPS 采用了一些加解密，數(shù)字證書，數(shù)字簽名的技術(shù)來實現(xiàn)。下面先介紹一下這些技術(shù)的基本概念。
為了保證消息的保密性，就需要用到加密和解密。加解密算法目前主流的分為對稱加密和非對稱加密。
對稱加密（共享密匙加密）
客戶端和服務(wù)器公用一個密匙用來對消息加解密，這種方式稱為對稱加密。客戶端和服務(wù)器約定好一個加密的密匙。客戶端在發(fā)消息前用該密匙對消息加密，發(fā)送給服務(wù)器后，服務(wù)器再用該密匙進行解密拿到消息。
圖示加密過程：
這里采用的對稱加密算法：
M：明文，我們本意要傳輸?shù)膬?nèi)容；
C：秘鑰，在對稱加密算法中需要用秘鑰加密，用秘鑰解密（加密算法可以很簡單，加減乘除，也可以很復雜）；
N：密文，明文用秘鑰加密得到的內(nèi)容，被稱為密文，在網(wǎng)絡(luò)上傳輸?shù)囊彩敲芪模?/p>
比如客戶端向服務(wù)器傳輸 1（明文），1 + 3 （3 是秘鑰） = 4 得到密文，進行傳輸，服務(wù)器得到 密文 4， 4-3（3 是秘鑰）=1 得到明文，使得客戶端和服務(wù)器端進行通信，反之亦然；
對稱加密的優(yōu)點：
對稱加密解決了 HTTP 中消息保密性的問題；
對稱加密的缺點：
對稱加密雖然保證了消息保密性，但是因為客戶端和服務(wù)器共享一個密匙，這樣就使得密匙特別容易泄露；
因為密匙泄露風險較高，所以很難保證消息來源的可靠性、消息的完整性和準確性；
對稱加密秘鑰泄露風險很高，秘鑰固定，導致很容易被破解，那么有沒有更好的方式去進行加密傳輸，比如說每次用的秘鑰都不相同，每次解密的秘鑰也都不相同，或者其他的情況來增加安全性呢？
非對稱加密（公有密匙加密）
既然對稱加密中，密匙那么容易泄露，那么我們可以采用一種非對稱加密的方式來解決。采用非對稱加密時，客戶端和服務(wù)端均擁有一個公有密匙和一個私有密匙。公有密匙可以對外暴露，而私有密匙只有自己可見。
使用公有密匙加密的消息，只有對應的私有密匙才能解開。反過來，使用私有密匙加密的消息，只有公有密匙才能解開。這樣客戶端在發(fā)送消息前，先用服務(wù)器的公匙對消息進行加密，服務(wù)器收到后再用自己的私匙進行解密。
圖示加密過程：
解釋如下：
M：指的是明文，我們本意要傳輸?shù)膬?nèi)容；
D：指的是公鑰，在非對稱加密算法中需要用公鑰加密；
E：指的是私鑰，在非對稱加密算法中需要用私鑰解密；
N：指的是密文，明文用秘鑰加密得到的內(nèi)容，被稱為密文，在網(wǎng)絡(luò)上傳輸?shù)囊彩敲芪模?/p>
在服務(wù)器這一次生成公鑰 D 以及私鑰 E，私鑰自己留存。然后將公鑰 D 進行對外公開，想與服務(wù)器端通信的客戶端用公鑰 D 進行加密發(fā)送給具有私鑰 E 的服務(wù)器，服務(wù)器用私鑰 E 就可以進行密文解密，最終拿到明文。
非對稱加密算法RSA簡介
RSA 是目前最有影響力的公鑰加密算法，它能夠抵抗到目前為止已知的絕大多數(shù)密碼攻擊，已被 ISO 推薦為公鑰數(shù)據(jù)加密標準。
今天只有短的 RSA 鑰匙才可能被強力方式解破。到 2008 年為止，世界上還沒有任何可靠的攻擊 RSA 算法的方式。只要其鑰匙的長度足夠長，用 RSA 加密的信息實際上是不能被解破的。但在分布式計算和量子計算機理論日趨成熟的今天，RSA 加密安全性受到了挑戰(zhàn)。
RSA 算法基于一個十分簡單的數(shù)論事實 ：將兩個大質(zhì)數(shù)相乘十分容易，但是想要對其乘積進行因式分解卻極其困難，因此可以將乘積公開作為加密密鑰。
HTTP 性能調(diào)優(yōu)
減少 HTTP 請求數(shù)
關(guān)于減少 HTTP 請求數(shù)，是性能優(yōu)化的一個非常重要方面，所以在基本所有的優(yōu)化原則里，都有這一條原則:減少 HTTP 請求數(shù)，先不考慮其他的。
我們先考慮為什么減少 HTTP 請求可以優(yōu)化性能：
1、減少 DNS 請求所耗費的時間且不說對錯，因為從基本來說，減少 HTTP 請求數(shù)的確可以減少 DNS 請求和解析耗費的時間；
2、減少服務(wù)器壓力這個通常是被考慮最多的，也是我用來講解給別人聽的最大理由，因為每個 HTTP 請求都會耗費服務(wù)器資源，特別是一些需要計算合并等操作的服務(wù)器，耗費服務(wù)器的 CPU 資源可不是開玩笑的事情，硬盤可以用錢買來，CPU 資源可就沒那么廉價了；
3、減少 HTTP 請求頭，當我們對服務(wù)器發(fā)起一個請求的時候，我們會攜帶著這個域名下的 Cookie 和一些其他的信息在 HTTP 頭部里，然后服務(wù)器響應請求的時候也會帶回一些 Cookie 之類的頭部信息，這些信息有的時候會很大，在這種請求和響應的時候會影響帶寬性能；
DNS 請求和解析
簡單來說，例如：www.taobao.com 這樣一個 URL，其中 www 部分被稱為主機名(hostname)，taobao 這部分則是二級域，com 則是一級域，如果是這樣一個網(wǎng)址：www.ali.tao.com 那么 ali 就是三級域。
當我們?nèi)フ埱笠粋€ URL 的時候，首先會到本地服務(wù)器里去尋找緩存中是否有解析結(jié)果，如果沒有解析結(jié)果就去根域名服務(wù)器請求，根域名服務(wù)器返回給本地域名服務(wù)器一個所查詢的域的主域名服務(wù)器的 IP 地址，然后我們再去請求剛才返回的 IP 地址的域名服務(wù)器，然后返回下一級域名的 IP 地址，直到我們找到域名中所指的服務(wù)器 IP，然后將結(jié)果緩存起來供下次使用并返回此結(jié)果。
一個第一次請求的 URL 的 DNS 解析過程可能耗費是很高的，但是解析一次之后結(jié)果就會被緩存起來，之后再請求的時候就不用走上面這一套復雜的解析過程了。
減少服務(wù)器壓力
過多的 HTTP 請求對于服務(wù)器來說是很危險的，如果你的服務(wù)器不是很強，請把這一條考慮放在第一位，其他的優(yōu)化策略都只是優(yōu)化，而這里涉及到的是服務(wù)器，你要保證你的服務(wù)器能正常運轉(zhuǎn)。
但是這是淘寶網(wǎng)，我們有足夠的速度來提供足夠的用戶體驗。如果你的服務(wù)器提供不了這種速度，也承受不了這種頻繁的異步請求的話，這種優(yōu)化就要慎重了，延遲可能造成導航不可用，這也是針對場景來協(xié)調(diào)的。
淘寶現(xiàn)在在廣泛部署 CDN，CDN 可以給我們提供足夠的后臺資源保障，在 CDN 和后臺環(huán)境不斷完善的情況下，考慮重點應該更加專注于前臺傳輸速度和展現(xiàn)解析速度的提升。
減少 HTTP 請求頭
HTTP 頭是個龐大的家伙，你打開 taobao.com 的首頁，alert 一下 document.cookie，會發(fā)現(xiàn)淘寶網(wǎng)的 cookie 比較大，每次你請求淘寶的服務(wù)器都會往返一次這些數(shù)據(jù)，還有一些其他的頭部信息，占用的空間也不小，可想而知這種消耗有多大。
然后其實自從用了 CDN，這一切都無需考慮太多，因為 CDN 和淘寶主站不在一個域名下，cookie 不會互相污染，而 CDN 的域名下基本是沒有 cookie 和頭部信息的，所以每次請求靜態(tài)資源的時候，不會帶著主站的 cookie 到處跑，而只是傳輸資源的主題內(nèi)容，所以這對于性能的影響在使用 cdn 之后會變得很小。但是如果你的靜態(tài)資源服務(wù)器和主服務(wù)器在一個域名下，那就要控制好 cookie 和其他頭部信息的大小了，因為每次傳送都會傳送它們。
總結(jié)
我們這次針對于網(wǎng)絡(luò)協(xié)議 HTTP 和 HTTPS 有了一個初步的了解，了解了 HTTP 的優(yōu)缺點，正是由于 HTTP 的某些不足，才出現(xiàn)了 HTTPS，我們通過圖例了解了其工作原理，還是比較復雜的，需要進一步的理解加深，然后我們談到了 HTTP 性能能調(diào)優(yōu)，關(guān)于減少請求次數(shù)，減少服務(wù)器壓力等等；
總之對于不同的場景應該考慮不同的側(cè)重點，應該不同的網(wǎng)站規(guī)模和類型進行適度的優(yōu)化，不能盲目追求標準和最佳實踐。
0、重磅！兩萬字長文總結(jié)，梳理 Java 入門進階哪些事（推薦收藏）
