HTTP2和HTTPS來不來了解一下？

1、前言

只有光頭才能變強

HTTP博文回顧：

• PC端：HTTP就是這麼簡單
• PC端：HTTP面試題都在這裏
• 微信公衆號端：HTTP就是這麼簡單
• 微信公衆號端：HTTP面試題都在這裏

本文力求簡單講清每一個知識點，但願你們看完能有所收穫

2、HTTP協議的此生來世

最近在看博客的時候，發現有的面試題已經考HTTP/2了，因而我就順着去了解一下。

到如今爲止，HTTP協議已經有三個版本了：

• HTTP1.0
• HTTP1.1
• HTTP/2

下面就簡單聊聊他們三者的區別，以及整理一些必要的額外知識點。

2.1HTTP版本之間的區別

2.1.1HTTP1.0和HTTP1.1區別

HTTP1.0和HTTP1.1最主要的區別就是：

• HTTP1.1默認是持久化鏈接！

在HTTP1.0默認是短鏈接：

簡單來講就是：每次與服務器交互，都須要新開一個鏈接！

試想一下：請求一張圖片，新開一個鏈接，請求一個CSS文件，新開一個鏈接，請求一個JS文件，新開一個鏈接。HTTP協議是基於TCP的，TCP每次都要通過三次握手，四次揮手，慢啓動...這都須要去消耗咱們很是多的資源的！

在HTTP1.1中默認就使用持久化鏈接來解決：創建一次鏈接，屢次請求均由這個鏈接完成！(若是阻塞了，仍是會開新的TCP鏈接的)

相對於持久化鏈接還有另外比較重要的改動：

• HTTP 1.1增長host字段
• HTTP 1.1中引入了Chunked transfer-coding，範圍請求，實現斷點續傳(實際上就是利用HTTP消息頭使用分塊傳輸編碼，將實體主體分塊傳輸)

• HTTP 1.1管線化(pipelining)理論，客戶端能夠同時發出多個HTTP請求，而不用一個個等待響應以後再請求

  • 注意：這個pipelining僅僅是限於理論場景下，大部分桌面瀏覽器仍然會選擇默認關閉HTTP pipelining！
  • 因此如今使用HTTP1.1協議的應用，都是有可能會開多個TCP鏈接的！

參考資料：

• http://www.javashuo.com/article/p-hdudtelh-hr.html

2.1.2HTTP2基礎

在說HTTP2以前，不如先直觀比較一下HTTP2和HTTP1.1的區別：

• https://http2.akamai.com/demo

上面也已經說了，HTTP 1.1提出了管線化(pipelining)理論，可是僅僅是限於理論的階段上，這個功能默認仍是關閉了的。

管線化(pipelining)和非管線化的區別：

HTTP Pipelining實際上是把多個HTTP請求放到一個TCP鏈接中一一發送，而在發送過程當中不須要等待服務器對前一個請求的響應；只不過， 客戶端仍是要按照發送請求的順序來接收響應！

---

就像在超市收銀臺或者銀行櫃檯排隊時同樣，你並不知道前面的 顧客是乾脆利索的仍是會跟收銀員/櫃員磨蹭到世界末日（無論怎麼說，服務器（即收銀員/櫃員）是要按照順序處理請求的，若是 前一個請求很是耗時（顧客磨蹭），那麼後續請求都會受到影響。

• 在HTTP1.0中，發送一次請求時，須要等待服務端響應了才能夠繼續發送請求。
• 在HTTP1.1中，發送一次請求時，不須要等待服務端響應了就能夠發送請求了，可是回送數據給客戶端的時候，客戶端仍是須要按照響應的順序來一一接收
• 因此說，不管是HTTP1.0仍是HTTP1.1提出了Pipelining理論，仍是會出現阻塞的狀況。從專業的名詞上說這種狀況，叫作線頭阻塞（Head of line blocking）簡稱：HOLB

2.1.3HTTP1.1和HTTP2區別

HTTP2與HTTP1.1最重要的區別就是解決了線頭阻塞的問題！其中最重要的改動是：多路複用 (Multiplexing)

• 多路複用意味着線頭阻塞將不在是一個問題，容許同時經過單一的 HTTP/2 鏈接發起多重的請求-響應消息，合併多個請求爲一個的優化將再也不適用。

  • (咱們知道：HTTP1.1中的Pipelining是沒有付諸於實際的)，以前爲了減小HTTP請求，有不少操做將多個請求合併，好比：Spriting(多個圖片合成一個圖片)，內聯Inlining(將圖片的原始數據嵌入在CSS文件裏面的URL裏），拼接Concatenation(一個請求就將其下載完多個JS文件)，分片Sharding(將請求分配到各個主機上)......

使用了HTTP2多是這樣子的：

HTTP2全部性能加強的核心在於新的二進制分幀層(再也不以文本格式來傳輸了)，它定義瞭如何封裝http消息並在客戶端與服務器之間傳輸。

看上去協議的格式和HTTP1.x徹底不一樣了，實際上HTTP2並無改變HTTP1.x的語義，只是把原來HTTP1.x的header和body部分用frame從新封裝了一層而已

HTTP2鏈接上傳輸的每一個幀都關聯到一個「流」。流是一個獨立的，雙向的幀序列能夠經過一個HTTP2的鏈接在服務端與客戶端之間不斷的交換數據。

實際上運輸時：

HTTP2還有一些比較重要的改動：

• 使用HPACK對HTTP/2頭部壓縮

• 服務器推送

  • HTTP2推送資料：http://www.javashuo.com/article/p-krvnzeap-gh.html

• 流量控制

  • 針對傳輸中的流進行控制(TCP默認的粒度是針對鏈接)
• 流優先級（Stream Priority）它被用來告訴對端哪一個流更重要。

2.2HTTP2總結

HTTP1.1新改動：

• 持久鏈接
• 請求管道化
• 增長緩存處理（新的字段如cache-control）
• 增長Host字段、支持斷點傳輸等

HTTP2新改動：

• 二進制分幀
• 多路複用
• 頭部壓縮
• 服務器推送

參考資料：

• HTTP2 GitBook電子書(中文版)：https://legacy.gitbook.com/book/ye11ow/http2-explained/details
• HTTP/2.0 相比1.0有哪些重大改進？https://www.zhihu.com/question/34074946
• HTTP/2 新特性淺析：http://www.javashuo.com/article/p-ydnlfgiq-hn.html
• HTTP2學習資料：https://imququ.com/post/http2-resource.html
• HTTP2簡介和基於HTTP2的Web優化：http://caibaojian.com/toutiao/6641
• http2原理入門：https://blog.qingf.me/?p=600
• HTTP/2 對如今的網頁訪問，有什麼大的優化呢？體如今什麼地方？https://www.zhihu.com/question/24774343/answer/96586977
• HTTP/2筆記之流和多路複用：http://www.blogjava.net/yongboy/archive/2015/03/19/423611.aspx

2.3HTTPS再次回顧

以前在面試的時候被問到了HTTPS，SSL這樣的知識點，也沒答上來，這裏也簡單整理一下。

首先仍是來解釋一下基礎的東東：

• 對稱加密：

  • 加密和解密都是用同一個密鑰

• 非對稱加密：

  • 加密用公開的密鑰，解密用私鑰
  • (私鑰只有本身知道，公開的密鑰你們都知道)

• 數字簽名：

  • 驗證傳輸的內容是對方發送的數據
  • 發送的數據沒有被篡改過

• 數字證書 (Certificate)

  • 認證機構證實是真實的服務器發送的數據。

3y的通信之路：

• 遠古時代：3y和女友聊天傳輸數據之間沒有任何的加密，直接傳輸

  • 內容被看得一清二楚，毫無隱私可言

• 上古時期：使用對稱加密的方式來保證傳輸的數據只有兩我的知道

  • 此時有個問題：密鑰不能經過網絡傳輸(由於沒有加密以前，都是不安全的)，因此3y和女友先約見面一次，告訴對方密碼是多少，再對話聊天。

• 中古時期：3y不僅僅要跟女友聊天，還要跟爸媽聊天的哇(一樣不想泄漏了本身的通信信息)。那有那麼多人，難道每一次都要約來見面一次嗎？(說明維護多個對稱密鑰是麻煩的！)--->因此用到了非對稱加密

  • 3y本身保留一份密碼，獨一無二的(私鑰)。告訴3y女友，爸媽一份密碼(這份密碼是公開的，誰均可以拿--->公鑰)。讓他們給我發消息以前，先用那份我告訴他們的密碼加密一下，再發送給我。我收到信息以後，用本身獨一無二的私鑰解密就能夠了！

• 近代：此時又出現一個問題：雖然別人不知道私鑰是什麼，拿不到你原始傳輸的數據，可是能夠拿到加密後的數據，他們能夠改掉某部分的數據再發送給服務器，這樣服務器拿到的數據就不是完整的了。

  • 3y女友給3y發了一條信息」3y我喜歡你「，而後用3y給的公鑰加密，發給3y了。此時不懷好意的人截取到這條加密的信息，他破解不了原信息。可是他能夠修改加密後的數據再傳給3y。可能3y拿到收到的數據就是」3y你今晚跪鍵盤吧「
• 現代：拿到的數據可能被篡改了，咱們可使用數字簽名來解決被篡改的問題。數字簽名其實也能夠看作是非對稱加密的手段一種，具體是這樣的：獲得原信息hash值，用私鑰對hash值加密，另外一端用公鑰解密，最後比對hash值是否變了。若是變了就說明被篡改了。(一端用私鑰加密，另外一端用公鑰解密，也確保了來源)
• 目前如今：好像使用了數字簽名就萬無一失了，其實還有問題。咱們使用非對稱加密的時候，是使用公鑰進行加密的。若是公鑰被僞造了，後面的數字簽名其實就毫無心義了。講到底：仍是可能會被中間人攻擊~此時咱們就有了CA認證機構來確認公鑰的真實性！

對於數字簽名和CA認證仍是不太瞭解參考一下

• 阮一峯：http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html
• 什麼是數字簽名和證書？https://www.jianshu.com/p/9db57e761255

---

回到咱們的HTTPS，HTTPS其實就是在HTTP協議下多加了一層SSL協議(ps:如今都用TLS協議了)

HTTPS採用的是混合方式加密：

過程是這樣子的：

• 用戶向web服務器發起一個安全鏈接的請求
• 服務器返回通過CA認證的數字證書，證書裏面包含了服務器的public key(公鑰)
• 用戶拿到數字證書，用本身瀏覽器內置的CA證書解密獲得服務器的public key

• 用戶用服務器的public key加密一個用於接下來的對稱加密算法的密鑰，傳給web服務器

  • 由於只有服務器有private key能夠解密，因此不用擔憂中間人攔截這個加密的密鑰
• 服務器拿到這個加密的密鑰，解密獲取密鑰，再使用對稱加密算法，和用戶完成接下來的網絡通訊

因此相比HTTP，HTTPS 傳輸更加安全

• （1） 全部信息都是加密傳播，黑客沒法竊聽。
• （2） 具備校驗機制，一旦被篡改，通訊雙方會馬上發現。
• （3） 配備身份證書，防止身份被冒充。

參考資料：

• 數字簽名、數字證書、SSL、https是什麼關係？https://www.zhihu.com/question/52493697/answer/131015846
• 淺談SSL/TLS工做原理：https://zhuanlan.zhihu.com/p/36981565
• HTTPS:https://tech.upyun.com/article/192/HTTPS%E7%B3%BB%E5%88%97%E5%B9%B2%E8%B4%A7%EF%BC%88%E4%B8%80%EF%BC%89%EF%BC%9AHTTPS%20%E5%8E%9F%E7%90%86%E8%AF%A6%E8%A7%A3.html
• 網站HTTP升級HTTPS徹底配置手冊：https://www.cnblogs.com/powertoolsteam/p/http2https.html

3、總結

我只是在學習的過程當中，把本身遇到的問題寫出來，整理出來，但願能夠對你們有幫助。若是文章有錯的地方，但願你們能夠在評論區指正，一塊兒學習交流~

參考資料：

• 《圖解HTTP》

若是文章有錯的地方歡迎指正，你們互相交流。習慣在微信看技術文章，想要獲取更多的Java資源的同窗，能夠 關注微信公衆號:Java3y。爲了你們方便，剛新建了一下 qq羣：742919422，你們也能夠去交流交流。謝謝支持了！但願能多介紹給其餘有須要的朋友

文章的目錄導航：

• https://zhongfucheng.bitcron.com/post/shou-ji/wen-zhang-dao-hang