HTTP2和HTTPS來不來了解一下？

Java3y發表於2019-03-04
HTTP

一、前言

只有光頭才能變強

HTTP博文回顧：

本文力求簡單講清每個知識點，希望大家看完能有所收穫

二、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預設是短連線：

HTTP2和HTTPS來不來了解一下？

簡單來說就是：每次與伺服器互動，都需要新開一個連線！

HTTP2和HTTPS來不來了解一下？
HTTP2和HTTPS來不來了解一下？

試想一下：請求一張圖片，新開一個連線，請求一個CSS檔案，新開一個連線，請求一個JS檔案，新開一個連線。HTTP協議是基於TCP的，TCP每次都要經過三次握手，四次揮手，慢啟動…這都需要去消耗我們非常多的資源的！

在HTTP1.1中預設就使用持久化連線來解決：建立一次連線，多次請求均由這個連線完成！(如果阻塞了，還是會開新的TCP連線的)

HTTP2和HTTPS來不來了解一下？

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

  • HTTP 1.1增加host欄位
  • HTTP 1.1中引入了Chunked transfer-coding，範圍請求，實現斷點續傳(實際上就是利用HTTP訊息頭使用分塊傳輸編碼，將實體主體分塊傳輸)
  • HTTP 1.1管線化(pipelining)理論，客戶端可以同時發出多個HTTP請求，而不用一個個等待響應之後再請求
    • 注意：這個pipelining僅僅是限於理論場景下，大部分桌面瀏覽器仍然會選擇預設關閉HTTP pipelining！
    • 所以現在使用HTTP1.1協議的應用，都是有可能會開多個TCP連線的！

參考資料：

2.1.2HTTP2基礎

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

HTTP2和HTTPS來不來了解一下？

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

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

HTTP2和HTTPS來不來了解一下？
HTTP2和HTTPS來不來了解一下？

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和HTTPS來不來了解一下？

HTTP2所有效能增強的核心在於新的二進位制分幀層(不再以文字格式來傳輸了)，它定義瞭如何封裝http訊息並在客戶端與伺服器之間傳輸。

HTTP2和HTTPS來不來了解一下？

看上去協議的格式和HTTP1.x完全不同了，實際上HTTP2並沒有改變HTTP1.x的語義，只是把原來HTTP1.x的header和body部分用frame重新封裝了一層而已

HTTP2和HTTPS來不來了解一下？

HTTP2連線上傳輸的每個幀都關聯到一個“流”。流是一個獨立的，雙向的幀序列可以通過一個HTTP2的連線在服務端與客戶端之間不斷的交換資料。

HTTP2和HTTPS來不來了解一下？

實際上運輸時：

HTTP2和HTTPS來不來了解一下？

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

  • 使用HPACK對HTTP/2頭部壓縮
  • 伺服器推送
  • 流量控制
    • 針對傳輸中的流進行控制(TCP預設的粒度是針對連線)
  • 流優先順序（Stream Priority）它被用來告訴對端哪個流更重要。

2.2HTTP2總結

HTTP1.1新改動：

  • 持久連線
  • 請求管道化
  • 增加快取處理（新的欄位如cache-control）
  • 增加Host欄位、支援斷點傳輸等

HTTP2新改動：

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

參考資料：

2.3HTTPS再次回顧

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

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

  • 對稱加密：
    • 加密和解密都是用同一個金鑰
  • 非對稱加密：
    • 加密用公開的金鑰，解密用私鑰
    • (私鑰只有自己知道，公開的金鑰大家都知道)
  • 數字簽名：
    • 驗證傳輸的內容是對方傳送的資料
    • 傳送的資料沒有被篡改過
  • 數字證照（Certificate Authority）簡稱CA
    • 認證機構證明是真實的伺服器傳送的資料。

3y的通訊之路：

  • 遠古時代：3y和女朋友聊天傳輸資料之間沒有任何的加密，直接傳輸
    • 內容被看得一清二楚，毫無隱私可言
  • 上古時期：使用對稱加密的方式來保證傳輸的資料只有兩個人知道
    • 此時有個問題：金鑰不能通過網路傳輸(因為沒有加密之前，都是不安全的)，所以3y和女朋友先約見面一次，告訴對方密碼是多少，再對話聊天。
  • 中古時期：3y不單單要跟女朋友聊天，還要跟爸媽聊天的哇(同樣不想洩漏了自己的通訊資訊)。那有那麼多人，難道每一次都要約來見面一次嗎？(說明維護多個對稱金鑰是麻煩的！)—>所以用到了非對稱加密
    • 3y自己保留一份密碼，獨一無二的(私鑰)。告訴3y女朋友，爸媽一份密碼(這份密碼是公開的，誰都可以拿—>公鑰)。讓他們給我發訊息之前，先用那份我告訴他們的密碼加密一下，再傳送給我。我收到資訊之後，用自己獨一無二的私鑰解密就可以了！
  • 近代：此時又出現一個問題：雖然別人不知道私鑰是什麼，拿不到你原始傳輸的資料，但是可以拿到加密後的資料，他們可以改掉某部分的資料再傳送給伺服器，這樣伺服器拿到的資料就不是完整的了。
    • 3y女朋友給3y發了一條資訊”3y我喜歡你“，然後用3y給的公鑰加密，發給3y了。此時不懷好意的人擷取到這條加密的資訊，他破解不了原資訊。但是他可以修改加密後的資料再傳給3y。可能3y拿到收到的資料就是”3y你今晚跪鍵盤吧“
  • 現代：拿到的資料可能被篡改了，我們可以使用數字簽名來解決被篡改的問題。數字簽名其實也可以看做是非對稱加密的手段一種，具體是這樣的：得到原資訊hash值，用私鑰對hash值加密，另一端用公鑰解密，最後比對hash值是否變了。如果變了就說明被篡改了。(一端用私鑰加密，另一端用公鑰解密，也確保了來源)
  • 目前現在：好像使用了數字簽名就萬無一失了，其實還有問題。我們使用非對稱加密的時候，是使用公鑰進行加密的。如果公鑰被偽造了，後面的數字簽名其實就毫無意義了。講到底：還是可能會被中間人攻擊~此時我們就有了CA認證機構來確認公鑰的真實性！

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

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

HTTP2和HTTPS來不來了解一下？

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

HTTP2和HTTPS來不來了解一下？

過程是這樣子的：

HTTP2和HTTPS來不來了解一下？
HTTP2和HTTPS來不來了解一下？
  • 使用者向web伺服器發起一個安全連線的請求
  • 伺服器返回經過CA認證的數字證照，證照裡面包含了伺服器的public key(公鑰)
  • 使用者拿到數字證照，用自己瀏覽器內建的CA證照解密得到伺服器的public key
  • 使用者用伺服器的public key加密一個用於接下來的對稱加密演算法的金鑰，傳給web伺服器
    • 因為只有伺服器有private key可以解密，所以不用擔心中間人攔截這個加密的金鑰
  • 伺服器拿到這個加密的金鑰，解密獲取金鑰，再使用對稱加密演算法，和使用者完成接下來的網路通訊
HTTP2和HTTPS來不來了解一下？

所以相比HTTP，HTTPS 傳輸更加安全

  • （1） 所有資訊都是加密傳播，黑客無法竊聽。
  • （2） 具有校驗機制，一旦被篡改，通訊雙方會立刻發現。
  • （3） 配備身份證照，防止身份被冒充。

參考資料：

三、總結

我只是在學習的過程中，把自己遇到的問題寫出來，整理出來，希望可以對大家有幫助。如果文章有錯的地方，希望大家可以在評論區指正，一起學習交流~

參考資料：

  • 《圖解HTTP》

如果文章有錯的地方歡迎指正，大家互相交流。習慣在微信看技術文章，想要獲取更多的Java資源的同學，可以關注微信公眾號:Java3y。

文章的目錄導航：

相關文章