[[429463]]

本文轉(zhuǎn)載自微信公眾號(hào)「杰哥的IT之旅」，作者阿拉斯加。轉(zhuǎn)載本文請(qǐng)聯(lián)系杰哥的IT之旅公眾號(hào)。

大家好，我是杰哥。最近卷了一篇 HTTP 協(xié)議的相關(guān)知識(shí)，大綱如下：

HTTP 簡(jiǎn)介

HTTP 協(xié)議是 Hyper Text Transfer Protocol(超文本傳輸協(xié)議)的縮寫(xiě)，是用于從萬(wàn)維網(wǎng)(WWW:World Wide Web )服務(wù)器傳輸超文本到本地瀏覽器的傳送協(xié)議。

HTTP 是一個(gè)基于 TCP/IP 通信協(xié)議來(lái)傳遞數(shù)據(jù)(HTML 文件，圖片文件，查詢(xún)結(jié)果等)。

HTTP 是一個(gè)屬于應(yīng)用層的面向?qū)ο蟮膮f(xié)議，由于其簡(jiǎn)捷、快速的方式，適用于分布式超媒體信息系統(tǒng)。它于 1990 年提出，經(jīng)過(guò)幾年的使用與發(fā)展，得到不斷地完善和擴(kuò)展。目前在 WWW 中使用的是 HTTP/1.0 的第六版，HTTP/1.1 的規(guī)范化工作正在進(jìn)行之中，而且 HTTP-NG(Next Generation of HTTP) 的建議已經(jīng)提出。

HTTP 協(xié)議工作于客戶(hù)端-服務(wù)端架構(gòu)為上，瀏覽器作為 HTTP 客戶(hù)端通過(guò) URL 向 HTTP 服務(wù)端即 WEB 服務(wù)器發(fā)送所有請(qǐng)求，Web 服務(wù)器根據(jù)接收到的請(qǐng)求后，向客戶(hù)端發(fā)送響應(yīng)信息。

HTTP 特點(diǎn)：

• 簡(jiǎn)單快速：客戶(hù)向服務(wù)器請(qǐng)求服務(wù)時(shí)，只需傳送請(qǐng)求方法和路徑。請(qǐng)求方法常用的有 GET、HEAD、POST。每種方法規(guī)定了客戶(hù)與服務(wù)器聯(lián)系的類(lèi)型不同。由于 HTTP 協(xié)議簡(jiǎn)單，使得 HTTP 服務(wù)器的程序規(guī)模小，因而通信速度很快;
• 靈活：HTTP 允許傳輸任意類(lèi)型的數(shù)據(jù)對(duì)象。正在傳輸?shù)念?lèi)型由 Content-Type 加以標(biāo)記;
• 無(wú)連接：無(wú)連接的含義是限制每次連接只處理一個(gè)請(qǐng)求。服務(wù)器處理完客戶(hù)的請(qǐng)求，并收到客戶(hù)的應(yīng)答后，即斷開(kāi)連接。采用這種方式可以節(jié)省傳輸時(shí)間;
• 無(wú)狀態(tài)：HTTP 協(xié)議是無(wú)狀態(tài)協(xié)議。無(wú)狀態(tài)是指協(xié)議對(duì)于事務(wù)處理沒(méi)有記憶能力。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大。另一方面，在服務(wù)器不需要先前信息時(shí)它的應(yīng)答就較快;
• 支持 B/S 及 C/S 模式;

HTTP 有以上這么多的優(yōu)點(diǎn)，那么問(wèn)題來(lái)了，HTTP 協(xié)議有什么弊端嗎? 答案是肯定的，原因也很簡(jiǎn)單，如果HTTP 是完美的，還需要一個(gè)叫做 HTTPS 協(xié)議的安全協(xié)議干什么呢?

HTTP 弊端：

當(dāng)我們往服務(wù)器發(fā)送比較隱私的數(shù)據(jù)(比如說(shuō)你的銀行卡，身份證)時(shí)，如果使用 http 進(jìn)行通信。那么安全性將得不到保障;

首先數(shù)據(jù)在傳輸?shù)倪^(guò)程中，數(shù)據(jù)可能被中間人抓包拿到，那么數(shù)據(jù)就會(huì)被中間人竊取;

其次數(shù)據(jù)被中間人拿到后，中間人可能對(duì)數(shù)據(jù)進(jìn)行修改或者替換，然后發(fā)往服務(wù)器;

最后服務(wù)器收到數(shù)據(jù)后，也無(wú)法確定數(shù)據(jù)有沒(méi)有被修改或替換，當(dāng)然，如果服務(wù)器也無(wú)法判斷數(shù)據(jù)就真的是來(lái)源于客戶(hù)端;

總結(jié)下來(lái)，HTTP 存在三個(gè)弊端：

• 無(wú)法保證消息的保密性;
• 無(wú)法保證消息的完整性和準(zhǔn)確性;
• 無(wú)法保證消息來(lái)源的可靠性;

HTTPS 簡(jiǎn)介

如何解決 HTTP 弊端呢?HTTPS 就是為了解決上述問(wèn)題應(yīng)運(yùn)而生的。

HTTPS(全稱(chēng)：Hyper Text Transfer Protocol over Secure Socket Layer)，是以安全為目標(biāo)的 HTTP 通道，簡(jiǎn)單講是 HTTP 的安全版。

即 HTTP 下加入 SSL 層，HTTPS 的安全基礎(chǔ)是 SSL，因此加密的詳細(xì)內(nèi)容就需要 SSL?，F(xiàn)在它被廣泛用于萬(wàn)維網(wǎng)上安全敏感的通訊，例如交易支付方面。

HTTPS 通過(guò)非對(duì)稱(chēng)加密算法可以使得我們傳的明文信息，無(wú)法通過(guò)逆推得出明文。接下來(lái)我們來(lái)看看在具體的工作流程是怎么樣的?

工作原理：

HTTPS 的建立過(guò)程

這里把 HTTPS 建立到斷開(kāi)分為 6 個(gè)階段，12 過(guò)程。下面將對(duì) 12 個(gè)過(guò)程一一做解釋:

1、客戶(hù)端 — Hello：客戶(hù)端通過(guò)發(fā)送 Client Hello 報(bào)文開(kāi)始 SSL 通信。報(bào)文中包含客戶(hù)端支持的 SSL 的指定版本、加密組件(Cipher Suite)列表(所使用的加密算法及密匙長(zhǎng)度等);

2、服務(wù)器 — Hello：服務(wù)器可進(jìn)行 SSL 通信時(shí)，會(huì)以 Server Hello 報(bào)文作為應(yīng)答。和客戶(hù)端一樣，在報(bào)文中包含 SSL 版本以及加密組件。服務(wù)器的加密組件內(nèi)容是從接收到的客戶(hù)端加密組件內(nèi)篩選出來(lái)的;

3、服務(wù)器 — 發(fā)證書(shū)：服務(wù)器發(fā)送證書(shū)報(bào)文。報(bào)文中包含公開(kāi)密匙證書(shū);

4、服務(wù)器 — 我說(shuō)完了：最后服務(wù)器發(fā)送 Server Hello Done 報(bào)文通知客戶(hù)端，最初階段的 SSL 握手協(xié)商部分結(jié)束;

5、客戶(hù)端 — 發(fā)送秘鑰：SSL 第一次握手結(jié)束之后，客戶(hù)端以 Client Key Exchange 報(bào)文作為回應(yīng)。報(bào)文包含通信加密中使用的一種被稱(chēng)為 Pre-master secret 的隨機(jī)密碼串。該報(bào)文已用步驟 3 中的公開(kāi)密匙進(jìn)行加密;

6、客戶(hù)端 — 就用這個(gè)秘鑰了：該報(bào)文會(huì)提示服務(wù)器，在此報(bào)文之后的通信會(huì)采用 Pre-master secret 密匙加密;

7、客戶(hù)端 — 我說(shuō)完了：該報(bào)文包含連接至今全部報(bào)文的整體校驗(yàn)值。這次握手協(xié)商是否能夠成功，要以服務(wù)器是否能夠正確解密該報(bào)文作為判定標(biāo)準(zhǔn);

8、服務(wù)器 — 發(fā)送 c Change Cipher Spec 報(bào)文(我正在接收秘鑰);

9、服務(wù)器 — 發(fā)送 d Finished 報(bào)文(我收完秘鑰了);

10、客戶(hù)端 — 開(kāi)始發(fā)送正文：服務(wù)器端發(fā)送 HTTP 請(qǐng)求，發(fā)送相關(guān)內(nèi)容;

11、服務(wù)器 — 開(kāi)始接收正文：客戶(hù)端接收 HTTP 請(qǐng)求，并處理相關(guān)內(nèi)容;

12、客戶(hù)端 — 斷開(kāi)鏈接：最后由客戶(hù)端斷開(kāi)連接。斷開(kāi)連接時(shí)，發(fā)送 close_notify 報(bào)文。上圖做了一些省略，這步之后再發(fā)送 TCP FIN 報(bào)文來(lái)關(guān)閉與 TCP 的通信;

另外，在以上流程圖中，應(yīng)用層發(fā)送數(shù)據(jù)時(shí)會(huì)附加一種叫做 MAC(MessageAuthentication Code)的報(bào)文摘要。MAC 能夠查知報(bào)文是否遭到篡改，從而保證報(bào)文的完整性;

下面再用圖解來(lái)形象的說(shuō)明一下，此圖比上面數(shù)字證書(shū)的圖更加的詳細(xì)一些(圖片來(lái)源于《圖解 HTTP》)

在上面說(shuō)明了 HTTPS 的建立以及通信中的過(guò)程。既然實(shí)際工作流程是這個(gè)樣子的，是怎樣的算法能實(shí)現(xiàn)這樣的功能，是怎樣的方式能做到非對(duì)稱(chēng)加密?在數(shù)學(xué)角度是如何計(jì)算的?那么對(duì)應(yīng)的理論基礎(chǔ)是什么?是什么支撐的 HTTPS 使得他能進(jìn)行加密傳輸?

HTTPS 的理論原理：

HTTPS 采用了一些加解密，數(shù)字證書(shū)，數(shù)字簽名的技術(shù)來(lái)實(shí)現(xiàn)。下面先介紹一下這些技術(shù)的基本概念。

為了保證消息的保密性，就需要用到加密和解密。加解密算法目前主流的分為對(duì)稱(chēng)加密和非對(duì)稱(chēng)加密。

對(duì)稱(chēng)加密(共享密匙加密)

客戶(hù)端和服務(wù)器公用一個(gè)密匙用來(lái)對(duì)消息加解密，這種方式稱(chēng)為對(duì)稱(chēng)加密。客戶(hù)端和服務(wù)器約定好一個(gè)加密的密匙。客戶(hù)端在發(fā)消息前用該密匙對(duì)消息加密，發(fā)送給服務(wù)器后，服務(wù)器再用該密匙進(jìn)行解密拿到消息。

圖示加密過(guò)程：

這里采用的對(duì)稱(chēng)加密算法：

• M：明文，我們本意要傳輸?shù)膬?nèi)容;
• C：秘鑰，在對(duì)稱(chēng)加密算法中需要用秘鑰加密，用秘鑰解密(加密算法可以很簡(jiǎn)單，加減乘除，也可以很復(fù)雜);
• N：密文，明文用秘鑰加密得到的內(nèi)容，被稱(chēng)為密文，在網(wǎng)絡(luò)上傳輸?shù)囊彩敲芪?

比如客戶(hù)端向服務(wù)器傳輸 1(明文)，1 + 3 (3 是秘鑰) = 4 得到密文，進(jìn)行傳輸，服務(wù)器得到 密文 4， 4-3(3 是秘鑰)=1 得到明文，使得客戶(hù)端和服務(wù)器端進(jìn)行通信，反之亦然;

對(duì)稱(chēng)加密的優(yōu)點(diǎn)：

對(duì)稱(chēng)加密解決了 HTTP 中消息保密性的問(wèn)題;

對(duì)稱(chēng)加密的缺點(diǎn)：

• 對(duì)稱(chēng)加密雖然保證了消息保密性，但是因?yàn)榭蛻?hù)端和服務(wù)器共享一個(gè)密匙，這樣就使得密匙特別容易泄露;
• 因?yàn)槊艹仔孤讹L(fēng)險(xiǎn)較高，所以很難保證消息來(lái)源的可靠性、消息的完整性和準(zhǔn)確性;

對(duì)稱(chēng)加密秘鑰泄露風(fēng)險(xiǎn)很高，秘鑰固定，導(dǎo)致很容易被破解，那么有沒(méi)有更好的方式去進(jìn)行加密傳輸，比如說(shuō)每次用的秘鑰都不相同，每次解密的秘鑰也都不相同，或者其他的情況來(lái)增加安全性呢?

非對(duì)稱(chēng)加密(公有密匙加密)

既然對(duì)稱(chēng)加密中，密匙那么容易泄露，那么我們可以采用一種非對(duì)稱(chēng)加密的方式來(lái)解決。采用非對(duì)稱(chēng)加密時(shí)，客戶(hù)端和服務(wù)端均擁有一個(gè)公有密匙和一個(gè)私有密匙。公有密匙可以對(duì)外暴露，而私有密匙只有自己可見(jiàn)。

使用公有密匙加密的消息，只有對(duì)應(yīng)的私有密匙才能解開(kāi)。反過(guò)來(lái)，使用私有密匙加密的消息，只有公有密匙才能解開(kāi)。這樣客戶(hù)端在發(fā)送消息前，先用服務(wù)器的公匙對(duì)消息進(jìn)行加密，服務(wù)器收到后再用自己的私匙進(jìn)行解密。

圖示加密過(guò)程：

解釋如下：

• M：指的是明文，我們本意要傳輸?shù)膬?nèi)容;
• D：指的是公鑰，在非對(duì)稱(chēng)加密算法中需要用公鑰加密;
• E：指的是私鑰，在非對(duì)稱(chēng)加密算法中需要用私鑰解密;
• N：指的是密文，明文用秘鑰加密得到的內(nèi)容，被稱(chēng)為密文，在網(wǎng)絡(luò)上傳輸?shù)囊彩敲芪?

在服務(wù)器這一次生成公鑰 D 以及私鑰 E，私鑰自己留存。然后將公鑰 D 進(jìn)行對(duì)外公開(kāi)，想與服務(wù)器端通信的客戶(hù)端用公鑰 D 進(jìn)行加密發(fā)送給具有私鑰 E 的服務(wù)器，服務(wù)器用私鑰 E 就可以進(jìn)行密文解密，最終拿到明文。

非對(duì)稱(chēng)加密算法RSA簡(jiǎn)介

RSA 是目前最有影響力的公鑰加密算法，它能夠抵抗到目前為止已知的絕大多數(shù)密碼攻擊，已被 ISO 推薦為公鑰數(shù)據(jù)加密標(biāo)準(zhǔn)。

今天只有短的 RSA 鑰匙才可能被強(qiáng)力方式解破。到 2008 年為止，世界上還沒(méi)有任何可靠的攻擊 RSA 算法的方式。只要其鑰匙的長(zhǎng)度足夠長(zhǎng)，用 RSA 加密的信息實(shí)際上是不能被解破的。但在分布式計(jì)算和量子計(jì)算機(jī)理論日趨成熟的今天，RSA 加密安全性受到了挑戰(zhàn)。

RSA 算法基于一個(gè)十分簡(jiǎn)單的數(shù)論事實(shí) ：將兩個(gè)大質(zhì)數(shù)相乘十分容易，但是想要對(duì)其乘積進(jìn)行因式分解卻極其困難，因此可以將乘積公開(kāi)作為加密密鑰。

HTTP 性能調(diào)優(yōu)

減少 HTTP 請(qǐng)求數(shù)

關(guān)于減少 HTTP 請(qǐng)求數(shù)，是性能優(yōu)化的一個(gè)非常重要方面，所以在基本所有的優(yōu)化原則里，都有這一條原則:減少 HTTP 請(qǐng)求數(shù)，先不考慮其他的。

我們先考慮為什么減少 HTTP 請(qǐng)求可以?xún)?yōu)化性能：

1、減少 DNS 請(qǐng)求所耗費(fèi)的時(shí)間且不說(shuō)對(duì)錯(cuò)，因?yàn)閺幕緛?lái)說(shuō)，減少 HTTP 請(qǐng)求數(shù)的確可以減少 DNS 請(qǐng)求和解析耗費(fèi)的時(shí)間;

2、減少服務(wù)器壓力這個(gè)通常是被考慮最多的，也是我用來(lái)講解給別人聽(tīng)的最大理由，因?yàn)槊總€(gè) HTTP 請(qǐng)求都會(huì)耗費(fèi)服務(wù)器資源，特別是一些需要計(jì)算合并等操作的服務(wù)器，耗費(fèi)服務(wù)器的 CPU 資源可不是開(kāi)玩笑的事情，硬盤(pán)可以用錢(qián)買(mǎi)來(lái)，CPU 資源可就沒(méi)那么廉價(jià)了;

3、減少 HTTP 請(qǐng)求頭，當(dāng)我們對(duì)服務(wù)器發(fā)起一個(gè)請(qǐng)求的時(shí)候，我們會(huì)攜帶著這個(gè)域名下的 Cookie 和一些其他的信息在 HTTP 頭部里，然后服務(wù)器響應(yīng)請(qǐng)求的時(shí)候也會(huì)帶回一些 Cookie 之類(lèi)的頭部信息，這些信息有的時(shí)候會(huì)很大，在這種請(qǐng)求和響應(yīng)的時(shí)候會(huì)影響帶寬性能;

DNS 請(qǐng)求和解析

簡(jiǎn)單來(lái)說(shuō)，例如：www.taobao.com 這樣一個(gè) URL，其中 www 部分被稱(chēng)為主機(jī)名(hostname)，taobao 這部分則是二級(jí)域，com 則是一級(jí)域，如果是這樣一個(gè)網(wǎng)址：www.ali.tao.com 那么 ali 就是三級(jí)域。

當(dāng)我們?nèi)フ?qǐng)求一個(gè) URL 的時(shí)候，首先會(huì)到本地服務(wù)器里去尋找緩存中是否有解析結(jié)果，如果沒(méi)有解析結(jié)果就去根域名服務(wù)器請(qǐng)求，根域名服務(wù)器返回給本地域名服務(wù)器一個(gè)所查詢(xún)的域的主域名服務(wù)器的 IP 地址，然后我們?cè)偃フ?qǐng)求剛才返回的 IP 地址的域名服務(wù)器，然后返回下一級(jí)域名的 IP 地址，直到我們找到域名中所指的服務(wù)器 IP，然后將結(jié)果緩存起來(lái)供下次使用并返回此結(jié)果。

一個(gè)第一次請(qǐng)求的 URL 的 DNS 解析過(guò)程可能耗費(fèi)是很高的，但是解析一次之后結(jié)果就會(huì)被緩存起來(lái)，之后再請(qǐng)求的時(shí)候就不用走上面這一套復(fù)雜的解析過(guò)程了。

減少服務(wù)器壓力

過(guò)多的 HTTP 請(qǐng)求對(duì)于服務(wù)器來(lái)說(shuō)是很危險(xiǎn)的，如果你的服務(wù)器不是很強(qiáng)，請(qǐng)把這一條考慮放在第一位，其他的優(yōu)化策略都只是優(yōu)化，而這里涉及到的是服務(wù)器，你要保證你的服務(wù)器能正常運(yùn)轉(zhuǎn)。

但是這是淘寶網(wǎng)，我們有足夠的速度來(lái)提供足夠的用戶(hù)體驗(yàn)。如果你的服務(wù)器提供不了這種速度，也承受不了這種頻繁的異步請(qǐng)求的話(huà)，這種優(yōu)化就要慎重了，延遲可能造成導(dǎo)航不可用，這也是針對(duì)場(chǎng)景來(lái)協(xié)調(diào)的。

淘寶現(xiàn)在在廣泛部署 CDN，CDN 可以給我們提供足夠的后臺(tái)資源保障，在 CDN 和后臺(tái)環(huán)境不斷完善的情況下，考慮重點(diǎn)應(yīng)該更加專(zhuān)注于前臺(tái)傳輸速度和展現(xiàn)解析速度的提升。

減少 HTTP 請(qǐng)求頭

HTTP 頭是個(gè)龐大的家伙，你打開(kāi) taobao.com 的首頁(yè)，alert 一下 document.cookie，會(huì)發(fā)現(xiàn)淘寶網(wǎng)的 cookie 比較大，每次你請(qǐng)求淘寶的服務(wù)器都會(huì)往返一次這些數(shù)據(jù)，還有一些其他的頭部信息，占用的空間也不小，可想而知這種消耗有多大。

然后其實(shí)自從用了 CDN，這一切都無(wú)需考慮太多，因?yàn)?CDN 和淘寶主站不在一個(gè)域名下，cookie 不會(huì)互相污染，而 CDN 的域名下基本是沒(méi)有 cookie 和頭部信息的，所以每次請(qǐng)求靜態(tài)資源的時(shí)候，不會(huì)帶著主站的 cookie 到處跑，而只是傳輸資源的主題內(nèi)容，所以這對(duì)于性能的影響在使用 cdn 之后會(huì)變得很小。但是如果你的靜態(tài)資源服務(wù)器和主服務(wù)器在一個(gè)域名下，那就要控制好 cookie 和其他頭部信息的大小了，因?yàn)槊看蝹魉投紩?huì)傳送它們。

總結(jié)

我們這次針對(duì)于網(wǎng)絡(luò)協(xié)議 HTTP 和 HTTPS 有了一個(gè)初步的了解，了解了 HTTP 的優(yōu)缺點(diǎn)，正是由于 HTTP 的某些不足，才出現(xiàn)了 HTTPS，我們通過(guò)圖例了解了其工作原理，還是比較復(fù)雜的，需要進(jìn)一步的理解加深，然后我們談到了 HTTP 性能能調(diào)優(yōu)，關(guān)于減少請(qǐng)求次數(shù)，減少服務(wù)器壓力等等;

總之對(duì)于不同的場(chǎng)景應(yīng)該考慮不同的側(cè)重點(diǎn)，應(yīng)該不同的網(wǎng)站規(guī)模和類(lèi)型進(jìn)行適度的優(yōu)化，不能盲目追求標(biāo)準(zhǔn)和最佳實(shí)踐。