高併發架構的HTTP知識介紹

咱們前面說過了 CDN的知識，也經過抓包分析了 TCP創建連接的過程。今天一塊兒聊一聊應用層的協議 HTTP/HTTPS；這是應用工程師平常中接觸最久的協議了。可是你真的瞭解他嗎？

今天咱們不講 HTTP協議 的幾種請求方式，主要介紹HTTP及HTTPS整個發送數據的過程。

消息結構

還記得前面講的 DNS 的過程嗎？經過DNS咱們拿到了服務端的IP地址，而後經過TCP協議，完成了瀏覽器與應用服務器的鏈接創建。HTTP協議是創建在TCP協議之上的（上層協議必然依賴下層協議），鏈接創建後，天然是開始通訊。那麼通訊的格式是什麼呢？

看上面這張圖，HTTP的請求與響應格式基本如此。咱們分開來講。

對於 請求消息 ，由三部分構成：請求行、請求頭、請求的Body；所謂的請求行，就是：POST / HTTP/1.1 這部份內容。接下來的就是請求頭，也就是咱們常說的HTTP頭；而後換行後緊接着的內容就是請求的Body，也就是正兒八經發送給應用的參數。

對於 響應消息 ，也是由三部分構成：狀態行、響應頭、響應的Body；關於響應行就是標記本次請求得到的結果是什麼，這裏主要有：20X、30X、40X、50X這幾個範圍的狀態碼，須要熟記。響應頭裏邊重要的主要有跟緩存相關的東西，這部份內容會知道瀏覽器、CDN等緩存體的緩存行爲，須要有必定的瞭解；最後的實體就是你請求的想要的結構，好比：HTML、Json等等。

傳輸過程

消息構建後，如何發送進行傳輸呢？咱們上面圖片中看到的是字符串內容，HTTP自己是不能進行網絡傳輸的，它必須依賴的底層的TCP協議創建的鏈接來發送數據。所以它實際上就是把這些構建好的字符串傳給下層的TCP，至於TCP如何傳輸的能夠看上篇文章，這裏不展開了。

WebService 收到數據後會對數據進行處理而後交給應用服務器，應用服務器天然是將請求的Body做爲輸入，而後根據要求產生輸出。輸出的行爲受到請求頭中部分信息的控制，好比：格式(Content-Type)、編碼(Accept-Charset)等。而產生的輸出各個地方也會根據響應頭進行處理。

看到這裏你們有沒有發現幾個問題：HTTP依賴底層的TCP鏈接，也就是每一個HTTP都須要進行三次握手，效率是否是會很是慢？這種方式總須要瀏覽器端主動發起連接，服務端想主動推送些什麼很無能爲力；

針對上面這些問題，HTTP2.0 協議也就誕生了，固然上面這些問題在 HTTP1.1 時代也有些解決方案。HTTP2.0 主要解決了協議頭進行壓縮，傳輸一樣含義的內容，佔用帶寬更少速度更快；將上面的單向連接的方式改爲二進制流的方式，服務端有能力主動推送數據；一個連接裏邊支持傳輸多種數據流。

關於 HTTP2.0 的內容不是文本主要想說的，你們能夠自行了解下。接下來又到了 核心部分，關於 HTTPS 爲何安全、以及如何加密的解釋。這部份內容算是面試的重要考點。

HTTPS爲何可靠

如今大網站基本都適用了HTTPS協議，那麼它跟HTTP是什麼關係呢？它其實就是HTTP加上TLS(SSL)安全層，合在一塊兒就叫 HTTPS。爲何有了這層處理數據就安全了呢？

很簡單，要想安全就得加密。加密的方式如今無非就是：對稱加密 與 非對稱加密。

對稱加密： 加密與解密都是使用相同的密鑰，所以這種方式加密數據，密鑰必定不能丟失。

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

安全的代價

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

對稱加密

咱們先來看看，若是HTTPS只使用 對稱加密，可否知足安全的須要呢？因爲這種狀況只有一個密鑰，服務端怎麼把這個密鑰交給客戶端呢？線上傳輸確定會泄漏。

因此單單有對稱加密是不能知足需求。看來得換個路子。

非對稱加密

使用非對稱加密的私鑰加密數據，發給客戶端。客戶端用公鑰解密就獲得了數據。看起來好像沒有什麼問題。

可是這裏有個問題，因爲服務端發出來的數據是使用的私鑰，因爲公鑰是公開，這至關於沒有加密。你們都可以看到。而且服務端發出去的公鑰這個過程也可能被串改啊，你怎麼知道你收到的公鑰就是服務器給你的呢？就跟如今不少詐騙公司同樣，看起來有模有樣，實則就是一皮包公司。

第三方公正

爲了解決上述問題，出現了一個所謂的 CA 機構，它怎麼解決這個信任問題呢？它將服務器的公鑰放到 CA證書 裏邊傳給客戶端（這裏指瀏覽器），瀏覽器拿到後驗證一下這個證書是否真實有效，由於CA機構是有限可追溯的。就跟你的護照同樣，可辨別真僞，因此CA證書證實了有效，那麼CA證書中攜帶的公鑰天然也證實了本身的身份。

是否是看起來整個過程很是麻煩？沒有辦法爲了安全，這點代價很是值得。這也是爲何咱們經常說HTTPS的效率略低於HTTP的緣由。

工做模式

瞭解完上面的知識，咱們來看看HTTPS究竟是如何工做的？

1. 客戶端發起了一個https請求，包含版本信息，加密套件候選列表，壓縮算法候選列表，隨機數random_c，擴展字段等信息。這個過程此時是明文的。
2. 而後服務器會進行回覆，根據客戶端支持的算法信息、套件等，服務器選擇一個告訴客戶端，咱們就用這個吧，同時也會返回一個隨機數random_s，後面協商密鑰有用。
3. 服務端響應客戶端，這個響應中包含了證書的連接，用於交換密鑰。
4. 客戶端對收到的數據進行檢查，先把證書給拉下來，而後檢查各類指標，若是不合法，會看到瀏覽器提醒不安全。

若是驗證經過，就會生成一個 隨機數字 Pre-master，並用證書公鑰加密（非對稱加密），發送給服務器。

1. 此時的客戶端已經有了生成證書的所有內容，它會計算協商的密鑰（對稱密鑰），而後告訴服務端之後通訊都採用協商的通訊密鑰和加密算法進行加密通訊。緊接着會用協商的密鑰加密一段數據發給服務端，看看是否可以正常。
2. 上面這步裏邊，客戶端發送了三個請求。服務器先將收到的 Pre-master 用本身的私鑰解密出來。而後驗證客戶端用對稱加密發過來的數據，若是經過，則也會告知客戶端後續的通訊都採用協商的密鑰與算法進行加密通訊。
3. 而且服務端也會用對稱加密生成一段加密信息給客戶端讓客戶端試試（對稱密鑰）。
4. 客戶端使用對稱密鑰正確完成解密。握手結束。開始使用對稱密鑰的方式進行數據傳輸。

總結

因爲不讓文章顯得過於複雜，我只介紹了最簡單的單向認證。這種安全性並非最高，單平常中也足夠了。

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

首先，爲了效率，整個過程只採用了一次非對稱加密來加密 Pre-master；

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

最後，也說了爲何整個過程須要CA機構的參與。

參考鏈接：

• https://www.wosign.com/faq/fa...
• http://www.ruanyifeng.com/blo...