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

[[277185]]

今天我們不講 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只使用 對稱加密，能否滿足安全的需要呢?由于這種情況只有一個密鑰，服務端怎么把這個密鑰交給客戶端呢?線上傳輸肯定會泄漏。

所以單單有對稱加密是不能滿足需求?？磥淼脫Q個路子。

非對稱加密

使用非對稱加密的私鑰加密數據，發給客戶端。客戶端用公鑰解密就得到了數據?？雌饋砗孟駴]有什么問題。

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

第三方公正

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

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

工作模式

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

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

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

服務端響應客戶端，這個響應中包含了證書的鏈接，用于交換密鑰。

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

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

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

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

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

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

總結

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

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

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

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

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