一.協議基礎

http基於TCP/IP協議的一種傳輸協議，如果承載TSL/SSL協議層之上便就成為了https。

有關兩者的詳細比較和關聯後面在介紹原理的時候會詳細說明。

二.快取體系

對於http我們接觸最多，使用最多也就是快取，通常所說的web快取實際上更多的指的是http的快取，當然還有瀏覽器本身自己的快取機制。快取的使用不當或者對http快取機制的理解不深入就會導致很多問題，比如：我強制重新整理了為毛載入的還是快取資料？

至於為什麼，我先不講，先來了解下快取機制和原理，知己知彼方可百戰不殆。在解析每一種機制之前，我都習慣性聯想分類。比如提到快取體系，我們就應該想到快取的儲存，畢竟快取也是資料。然後就是快取的過期機制，畢竟任何快取不可能持久存在，特麼的愛情還能過期呢。最後，就是快取的重新整理，畢竟每個時間段的快取內容是不一樣的。

總結起來，就是三個方面：快取的儲存策略，快取的過期策略，快取的重新整理策略。

快取儲存：

用來確定http的響應內容是否可以被客戶端儲存。

關鍵的屬性Cache-Control，他包含的屬性：

1. public:標記認證內容也可以被快取。一般來說經過http認證的內容，是不會自動快取的，但是加上這個就可以了。（response）

2. private：資料只能儲存到私有的cache，對某個使用者專用，不能共享（response）

3. no-cache：不建議快取到客戶端，但是還是可以快取的。

4.max-age：快取的時間，相對時間，從請求時間到過期時間的間隔，單位是秒。

5.no-store：不允許任何內容被快取到客戶端。

以上是幾個常用的儲存策略，坦白講其實就是客戶端或者服務端對http協議快取的一種控制。

快取過期：

他的作用就是什麼時候該請求服務端重新撈取資料了。簡單這樣理解後，那麼問題來了，我特麼怎麼知道什麼時候該請求什麼時候該從本地快取拿資料？

這個問題吐槽到重點了，那就一起看看唄。

Cache-Control:private

Expires:當前時間+max-age

看到這裡我們疑惑了，上面剛講到cache-control裡面有一個max-age。這個屬性就是設定快取的有效時間，換句話說，如果過了這個時間段就會去請求伺服器。所以問題又來了，如果這兩個同時設定了這不是搞事情嗎？該聽說的呢？別怕，cache-control裡面的東西永遠都是優先順序高的，換句話說，如果max-age設定了，expires設定了也白搭。

快取重新整理：

其實說到這一塊的時候，個人認為才說到重點。我們搞快取是為了什麼？此時腦海中應該立馬想到一個字：快！

的確，在某種意義上來講的確是快，比如我們經常會發現第二次開啟同一個介面要比第一次大開快很多，資料感覺像是假的似的，一下子全部展現。其實這就是用了快取，更有甚至連網都沒有，資料竟然都能展現，這也是快取。

好了，說了這麼多廢話，http快取的重新整理機制到底是怎樣的呢？結合以上兩點，其實我們應該心裡有點譜了，沒錯就是你想的那樣！

首先，客戶端發現，艾瑪，快取到期了，趕緊去請求伺服器吧。

伺服器說：你捉急是沒有用滴，我得慢慢來考察，第一，你真的過期了嗎？第二，請求的內容真的有變化嗎？

針對服務端的這兩個疑惑，服務端是怎麼做到的呢？

1. 對於是否真的過期，客戶端會給服務端一個標識last-modified-since，通過時間的對比去判斷是否真的過期。

2. 對於資料是否改變，客戶端會帶過來一個欄位if-none-match，每一次服務端都會有一個對應Etag欄位，對比兩個欄位的值去判斷實體資料是否發生了變化從而決定要不要返回給客戶端資料。

三.原理

1. http的工作原理

http請求是一個標準的客戶端服務請求模式，也是常說的C/S結構：

說到這裡還是得提一下，http是如何建立在TCP/IP協議之上的，TCP/IP協議是如何協調工作的。

2.http的工作流程：

第一步：地址解析，從url中解析協議名稱，主機名，埠號和對應的頁面地址。

第二步：封裝http的請求資料包：這一步主要是封裝自己的資訊，比如在post請求時，我們會塞進一個data資料。

第三步：封裝tcp包，建立連線：因為是基於tcp的協議，網路連線是tcp來完成的，必然要封裝成tcp包，然後tcp再做自己工作，比如封裝ip包，一層層往下傳。

第四步：傳送請求：資料整好了，連線也完事了，那就傳送action了。

第五步：服務端響應：接受到請求，然後給出響應。

第六步:服務端關閉tcp的連線：一次通訊完成之後，若conection的設定不是keep-live的話，服務端會自動關閉tcp的連線。

3.http協議的不足

通過對以上http的瞭解，我們似乎並沒有看到他的不足之處，但是有心的同學會發現，在說到tcp和ip的時候，提到tcp是為了儘量保證資料的完整性，這說明ip層會發生資料丟失的情況，而這種情況存在tcp層只是儘量並沒有完全做到保證資料的完整性。這個問題會不會在http這層也出現呢？當然，很多東西是遺傳的，包括缺陷。的確，在http這一層存在資料的不安全性，並且因為http是協議變的簡單化，方便化，同時也帶來了ip層沒有的缺陷，比如我們的傳輸資料都是明文，一旦是明文就會出現一下問題：

內容可能被竊聽！

內容可能被篡改！

沒有身份驗證可能會被冒充！

而以上的三種問題恰恰是http協議的不足。

http協議的所有傳輸內容都是明文，即便是自己加密了，但是加密的內容也依舊是明文，這就避免不了被竊聽！

再者，http協議傳輸的過程中沒有身份驗證這一說，這樣就不免半路殺出一個不明身份就行身份冒充！

最後，http協議傳輸的過程中也並沒有進行資料完整性的校驗，不免有些人在中途進行內容篡改！（MITM）

總之以上存在缺陷成就了一批網路黑客，也成就了一批猖狂的病毒！

4.https的技術

針對http的協議缺陷，正義的我們是不會視而不見的，因此https誕生了！說到這，請鼓掌！

通過上圖我們看到了新的玩意，TLS和SSL，有關這兩個下面的原理會講道。

針對於以上缺陷，https增加了兩種技術：加密技術和身份驗證。

加密技術：

有關加密的具體方法我之前有講過，這裡不再多一一介紹。主要用到以DES為代表的對稱加密演算法和以RSA為代表的非對稱加密演算法。

對稱加密演算法一般很難破解，但是不太好保管，安全性也不是很高，為啥呢？因為客戶端和服務端拿到的金鑰是一樣的，不可能每次都把key給改了，而不改的話，一直用同一個key的話也會存在安全隱患。

因此https的加密的方式採取的是混合方式。交換金鑰的時候採取非對稱的，建立通訊交換報文的時候採取對稱加密的方法。

身份驗證技術：

就是用公鑰生成可信賴的證書。因為非對稱加密存在一個問題就是沒法驗證拿到的公鑰就是服務端公開的公鑰。

為了解決以上問題，CA應用而生（Certifity Authority），數字證書認證機構。盜一張圖：

這張圖一看便懂，ca的資訊我們也能看到有哪些。

CA的使用流程：

1. 相關人去CA機構進行公鑰申請。

2.CA機構會驗證申請者的資訊真實性，合法性。

3. 通過稽核後，CA機構會做數字簽名，給其證書。證書裡面包含申請者的資訊，數字簽名後的公鑰，有效時間和簽名。

4. 客戶端https建立連線的時候像服務端要證書。

5. 讀取證書資訊，拿公鑰進行解密校驗。

6.客戶端會內建CA的資訊，如果不存在或者資訊不對，證明CA非法。

備註：遵循私鑰永遠都是服務端一方掌握。

5.https的原理：

協議實現：

TLS，記錄協議負責在傳輸連線上交換底層資訊，並加以配置加密。每一條tls記錄包含標頭和訊息內容兩部分。標頭包含型別，版本和長度。咋一看和報文資料很像。

TLS有四個核心協議：

握手協議：單項最常見，驗證服務端身份。雙向驗證，客戶端和服務端都需要驗證。

金鑰變更協議

應用協議

警報協議

協議使用：

1.通過SSLContext來指定你選擇的協議：

2.通過X509TrustManager檢查證書：

備註：這裡明白著就是跳過證書的檢查了。如果不跳過會是怎樣？

3.再者就是客戶端讀取證書然後呼叫：

寫到上面程式碼，我記憶深刻，之前在做瀏覽器證書校驗的時候，hostnameverify這一步一直過不了，原因是我們服務端證書的白名單也新增我們的hostname。

當然，你可以說不設定不就可以了嗎？答案是不可以，因為你不重寫HostnameVerify的verfiy方法，他預設所有返回都是false。這樣就悲劇了。解決的方案有兩種，第一種加白名單，第二種客戶端跳過驗證，例如：

四.總結：

作者：最有文化的碼農
連結：https://www.jianshu.com/p/b5db358a0444
來源：簡書
簡書著作權歸作者所有，任何形式的轉載都請聯絡作者獲得授權並註明出處。