拖延症患者的毛病需要治療了，不過基礎的協定部分内容終于要完結了！
我們前面說過了 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到底是如何工作的？
用戶端發起了一個https請求，包含版本資訊，加密套件候選清單，壓縮算法候選清單，随機數random_c，擴充字段等資訊。這個過程此時是明文的。
- 然後伺服器會進行回複，根據用戶端支援的算法資訊、套件等，伺服器選擇一個告訴用戶端，我們就用這個吧，同時也會傳回一個随機數random_s，後面協商密鑰有用。
- 服務端響應用戶端，這個響應中包含了證書的連結，用于交換密鑰。
- 用戶端對收到的資料進行檢查，先把證書給拉下來，然後檢查各種名額，如果不合法，會看到浏覽器提醒不安全。
如果驗證通過，就會生成一個
随機數字 Pre-master
，并用證書公鑰加密（非對稱加密），發送給伺服器。
- 此時的用戶端已經有了生成證書的全部内容，它會計算協商的密鑰（對稱密鑰），然後告訴服務端以後通信都采用協商的通信密鑰和加密算法進行加密通信。緊接着會用協商的密鑰加密一段資料發給服務端，看看是否能夠正常。
- 上面這步裡邊，用戶端發送了三個請求。伺服器先将收到的
Pre-master
- 并且服務端也會用對稱加密生成一段加密資訊給用戶端讓用戶端試試（對稱密鑰）。
- 用戶端使用對稱密鑰正确完成解密。握手結束。開始使用對稱密鑰的方式進行資料傳輸。
總結
由于不讓文章顯得過于複雜，我隻介紹了最簡單的單向認證。這種安全性并不是最高，單日常中也足夠了。
本文從源頭講了為什麼隻有對稱加密搞不定這件事；一步步演化出HTTPS的整個過程。
首先，為了效率，整個過程隻采用了一次非對稱加密來加密
Pre-master
；
其次，用戶端、服務端分别使用了一次對稱加密來進行密鑰有效性的驗證，來防止中間人攻擊；
最後，也說了為什麼整個過程需要CA機構的參與。
參考連接配接：
- https://www.wosign.com/faq/faq2016-0309-04.htm
- http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html