我們前面說過了 CDN的知識，也通過抓包分析了 TCP建立鏈接的過程。今天一起聊一聊應(yīng)用層的協(xié)議 HTTP/HTTPS;這是應(yīng)用工程師日常中接觸最久的協(xié)議了。但是你真的了解他嗎?

[[277185]]

今天我們不講 HTTP協(xié)議 的幾種請求方式，主要介紹HTTP及HTTPS整個發(fā)送數(shù)據(jù)的過程。

消息結(jié)構(gòu)

還記得前面講的 DNS 的過程嗎?通過DNS我們拿到了服務(wù)端的IP地址，然后通過TCP協(xié)議，完成了瀏覽器與應(yīng)用服務(wù)器的連接建立。HTTP協(xié)議是建立在TCP協(xié)議之上的(上層協(xié)議必然依賴下層協(xié)議)，連接建立后，自然是開始通信。那么通信的格式是什么呢?

看上面這張圖，HTTP的請求與響應(yīng)格式基本如此。我們分開來說。

對于 請求消息 ，由三部分構(gòu)成：請求行、請求頭、請求的Body;所謂的請求行，就是：POST / HTTP/1.1 這部分內(nèi)容。接下來的就是請求頭，也就是我們常說的HTTP頭;然后換行后緊接著的內(nèi)容就是請求的Body，也就是正兒八經(jīng)發(fā)送給應(yīng)用的參數(shù)。

對于 響應(yīng)消息 ，也是由三部分構(gòu)成：狀態(tài)行、響應(yīng)頭、響應(yīng)的Body;關(guān)于響應(yīng)行就是標(biāo)記本次請求獲得的結(jié)果是什么，這里主要有：20X、30X、40X、50X這幾個范圍的狀態(tài)碼，需要熟記。響應(yīng)頭里邊重要的主要有跟緩存相關(guān)的東西，這部分內(nèi)容會知道瀏覽器、CDN等緩存體的緩存行為，需要有一定的了解;最后的實體就是你請求的想要的結(jié)構(gòu)，比如：HTML、Json等等。

傳輸過程

消息構(gòu)建后，如何發(fā)送進行傳輸呢?我們上面圖片中看到的是字符串內(nèi)容，HTTP本身是不能進行網(wǎng)絡(luò)傳輸?shù)?，它必須依賴的底層的TCP協(xié)議建立的連接來發(fā)送數(shù)據(jù)。因此它實際上就是把這些構(gòu)建好的字符串傳給下層的TCP，至于TCP如何傳輸?shù)目梢钥瓷掀恼拢@里不展開了。

WebService 收到數(shù)據(jù)后會對數(shù)據(jù)進行處理然后交給應(yīng)用服務(wù)器，應(yīng)用服務(wù)器自然是將請求的Body作為輸入，然后根據(jù)要求產(chǎn)生輸出。輸出的行為受到請求頭中部分信息的控制，比如：格式(Content-Type)、編碼(Accept-Charset)等。而產(chǎn)生的輸出各個地方也會根據(jù)響應(yīng)頭進行處理。

看到這里大家有沒有發(fā)現(xiàn)幾個問題：HTTP依賴底層的TCP連接，也就是每個HTTP都需要進行三次握手，效率是不是會非常慢?這種方式總需要瀏覽器端主動發(fā)起鏈接，服務(wù)端想主動推送些什么很無能為力;

針對上面這些問題，HTTP2.0 協(xié)議也就誕生了，當(dāng)然上面這些問題在 HTTP1.1 時代也有些解決方案。HTTP2.0 主要解決了協(xié)議頭進行壓縮，傳輸同樣含義的內(nèi)容，占用帶寬更少速度更快;將上面的單向鏈接的方式改成二進制流的方式，服務(wù)端有能力主動推送數(shù)據(jù);一個鏈接里邊支持傳輸多種數(shù)據(jù)流。

關(guān)于 HTTP2.0 的內(nèi)容不是文本主要想說的，大家可以自行了解下。接下來又到了 核心部分，關(guān)于 HTTPS 為什么安全、以及如何加密的解釋。這部分內(nèi)容算是面試的重要考點。

HTTPS為什么可靠

現(xiàn)在大網(wǎng)站基本都適用了HTTPS協(xié)議，那么它跟HTTP是什么關(guān)系呢?它其實就是HTTP加上TLS(SSL)安全層，合在一起就叫 HTTPS。為什么有了這層處理數(shù)據(jù)就安全了呢?

很簡單，要想安全就得加密。加密的方式現(xiàn)在無非就是：對稱加密 與 非對稱加密。

對稱加密： 加密與解密都是使用相同的密鑰，因此這種方式加密數(shù)據(jù)，密鑰一定不能丟失。

非對稱加密： 有兩把密鑰，私鑰與公鑰。使用私鑰加密的數(shù)據(jù)必須使用公鑰進行解密，反之依然。

安全的代價

看起來 非對稱加密 非常安全。不過對稱加密的效率非常高。HTTPS正是綜合使用這兩種加密方式，讓整個傳輸過程變得安全。接下來看看這個過程是如何完成的。

對稱加密

我們先來看看，如果HTTPS只使用 對稱加密，能否滿足安全的需要呢?由于這種情況只有一個密鑰，服務(wù)端怎么把這個密鑰交給客戶端呢?線上傳輸肯定會泄漏。

所以單單有對稱加密是不能滿足需求。看來得換個路子。

非對稱加密

使用非對稱加密的私鑰加密數(shù)據(jù)，發(fā)給客戶端?？蛻舳擞霉€解密就得到了數(shù)據(jù)?？雌饋砗孟駴]有什么問題。

但是這里有個問題，由于服務(wù)端發(fā)出來的數(shù)據(jù)是使用的私鑰，由于公鑰是公開，這相當(dāng)于沒有加密。大家都能夠看到。并且服務(wù)端發(fā)出去的公鑰這個過程也可能被串改啊，你怎么知道你收到的公鑰就是服務(wù)器給你的呢?就跟現(xiàn)在很多詐騙公司一樣，看起來有模有樣，實則就是一皮包公司。

第三方公正

為了解決上述問題，出現(xiàn)了一個所謂的 CA 機構(gòu)，它怎么解決這個信任問題呢?它將服務(wù)器的公鑰放到 CA證書 里邊傳給客戶端(這里指瀏覽器)，瀏覽器拿到后驗證一下這個證書是否真實有效，因為CA機構(gòu)是有限可追溯的。就跟你的護照一樣，可辨別真?zhèn)危訡A證書證明了有效，那么CA證書中攜帶的公鑰自然也證明了自己的身份。

是不是看起來整個過程非常麻煩?沒有辦法為了安全，這點代價非常值得。這也是為什么我們常常說HTTPS的效率略低于HTTP的原因。

工作模式

了解完上面的知識，我們來看看HTTPS到底是如何工作的?

客戶端發(fā)起了一個https請求，包含版本信息，加密套件候選列表，壓縮算法候選列表，隨機數(shù)random_c，擴展字段等信息。這個過程此時是明文的。

然后服務(wù)器會進行回復(fù)，根據(jù)客戶端支持的算法信息、套件等，服務(wù)器選擇一個告訴客戶端，我們就用這個吧，同時也會返回一個隨機數(shù)random_s，后面協(xié)商密鑰有用。

服務(wù)端響應(yīng)客戶端，這個響應(yīng)中包含了證書的鏈接，用于交換密鑰。

客戶端對收到的數(shù)據(jù)進行檢查，先把證書給拉下來，然后檢查各種指標(biāo)，如果不合法，會看到瀏覽器提醒不安全。

如果驗證通過，就會生成一個 隨機數(shù)字 Pre-master，并用證書公鑰加密(非對稱加密)，發(fā)送給服務(wù)器。

此時的客戶端已經(jīng)有了生成證書的全部內(nèi)容，它會計算協(xié)商的密鑰(對稱密鑰)，然后告訴服務(wù)端以后通信都采用協(xié)商的通信密鑰和加密算法進行加密通信。緊接著會用協(xié)商的密鑰加密一段數(shù)據(jù)發(fā)給服務(wù)端，看看是否能夠正常。

上面這步里邊，客戶端發(fā)送了三個請求。服務(wù)器先將收到的 Pre-master 用自己的私鑰解密出來。然后驗證客戶端用對稱加密發(fā)過來的數(shù)據(jù)，如果通過，則也會告知客戶端后續(xù)的通信都采用協(xié)商的密鑰與算法進行加密通信。

并且服務(wù)端也會用對稱加密生成一段加密信息給客戶端讓客戶端試試(對稱密鑰)。

客戶端使用對稱密鑰正確完成解密。握手結(jié)束。開始使用對稱密鑰的方式進行數(shù)據(jù)傳輸。

總結(jié)

由于不讓文章顯得過于復(fù)雜，我只介紹了最簡單的單向認(rèn)證。這種安全性并不是最高，單日常中也足夠了。

本文從源頭講了為什么只有對稱加密搞不定這件事;一步步演化出HTTPS的整個過程。

首先，為了效率，整個過程只采用了一次非對稱加密來加密 Pre-master;

其次，客戶端、服務(wù)端分別使用了一次對稱加密來進行密鑰有效性的驗證，來防止中間人攻擊;

最后，也說了為什么整個過程需要CA機構(gòu)的參與。