HTTP / 1.x與HTTP / 2

首先，讓我們看看有哪些高層差異：

• HTTP / 2是二進位制的，而不是文字的

與HTTP / 1.x等文字協議相比，二進位制協議更有效地解析，在通道上更緊湊，最重要的是，與HTTP / 1.x等文字協議相比，它們更不容易出錯，因為它們通常具有一些像空白處理，大寫，行結尾，空白等等的“幫助” 。

例如，HTTP / 1.1定義了四種不同的解析訊息的方法; 在HTTP / 2中，只有一個程式碼路徑。

• HTTP / 2是完全多路複用的，而不是有序和阻塞的

HTTP / 1.x有一個稱為“行頭阻塞”(head-of-line blocking)的問題，實際上一次只有一個請求在連線上活動。

HTTP / 1.1試圖通過流水線修復此問題，但它沒有完全解決問題（大的或慢的響應仍然可以阻止在後面的請求）。此外，發現流水線很難部署，因為許多中介和伺服器不能正確處理它。

這迫使客戶端使用一些啟發式方法（通常是猜測）來確定哪些請求放在哪個連線到源的時候; 由於頁面載入10次（或更多）可用連線的數量是常見的，這會嚴重影響效能，通常會形成阻塞請求的“瀑布”。

多路複用通過允許多個請求和響應訊息同時在傳輸中來解決這些問題; 甚至可以將一條訊息的一部分與另一條訊息混合在一起。

反過來，這允許客戶端每個源只使用一個連線來載入頁面。

• HTTP / 2可以使用一個連線進行並行 使用HTTP / 1，瀏覽器可以在每個源的4到8個連線之間開啟。由於許多站點使用多個源，這可能意味著單個頁面載入開啟超過30個連線。

一個應用程式開啟這麼多連線同時打破了許多基於TCP的假設; 由於每個連線都會在響應中傳輸大量資料，因此存在中間網路中的緩衝區溢位，導致擁塞事件和重新傳輸的真實風險。

您可以在此處檢視HTTP / 2如何工作的演示：

此外，使用如此多的連線不公平地壟斷網路資源，將其從其他更好的應用程式（例如，VoIP）“竊取”。

• HTTP / 2使用Header壓縮來減少開銷

如果你假設一個頁面有大約80個資源（在今天的Web上是保守的），並且每個請求有1400個位元組的標題（並不罕見），它至少需要7-8個來回為了讓他們傳送至客戶端，這不是在計算響應時間。

這是因為TCP的慢啟動機制，它根據已確認的資料包數量在新連線上發出新的資料包 - 有效地限制了前幾次往返可以傳送的資料包數量。

相比之下，即使是Header上的稍微壓縮也允許這些請求在一次往返中傳送完,甚至可能是隻一個數據包。

這種開銷很大，特別是當您考慮對移動客戶端的影響時，即使在良好的條件下，移動客戶端通常也會看到幾百毫秒的往返延遲。

• HTTP / 2允許伺服器主動將響應“推送”到客戶端快取中

當瀏覽器請求頁面時，伺服器在響應中傳送HTML，然後需要等待瀏覽器解析HTML併發出對所有嵌入資源的請求，然後才能開始傳送JavaScript，影象和CSS。

伺服器推送可能允許伺服器通過將其認為客戶端需要的響應“推送”到其快取中來避免這種延遲的往返。

但是，推動響應並不“神奇” - 如果使用不當，可能會損害效能。目前，許多人仍將繼續與Webhooks合作。

它如何影響在HTTP / 1.1上構建的現有REST API？

HTTP的主要語義已保留在HTTP / 2中。這意味著，它仍然有HTTP方法，如GET，POST，HTTP headers和URIs識別資源。

HTTP / 2相對於HTTP / 1.1的變化是HTTP語義（例如“我想POST主機domain.com上的資源/ foo”）通過網路傳輸的方式。這意味著在HTTP / 1.1上構建的REST API將繼續像以前一樣透明地工作，而不會對應用程式進行任何更改。

執行應用程式的Web容器將代表應用程式將新的線路格式轉換為通常的HTTP語義，並且應用程式只會看到更高級別的HTTP語義，無論它是通過HTTP / 1.1還是HTTP /2傳輸。

由於HTTP / 2 傳輸格式更有效（特別是由於多路複用和壓縮），HTTP / 2之上的REST API也將從中受益。

HTTP / 2，HTTP / 2 Push中存在的另一個主要改進是針對相關資源的有效下載，並且在大多數REST API用例中可能沒用，也許只有像服務這樣的物件儲存可以從中受益（如Amazon S3） ）。

HTTP / 2的典型要求是通過TLS部署。這需要部署者從HTTP移動到HTTPS。這意味著多一些開銷

HTTP / 2的好處解釋

HTTP / 2帶來的關鍵改進包括多路複用流，報頭壓縮，伺服器推送和二進位制協議，而不是文字協議。這些和其他積極的變化允許實現良好的網頁載入結果，包括那些附加了大量附加檔案的結果（例如樣式，指令碼，影象，字型等）。

HTTP / 2是HTTP協議的新版本，它還為伺服器到伺服器通訊提供了許多新功能：

• 使用推送請求的雙向通訊

HTTP / 2的“伺服器推送”允許伺服器主動將內容傳送到客戶端的快取以供將來使用。

例如，這有助於避免在獲取HTML和連結的樣式表和CSS之間的往返; 伺服器可以立即開始傳送這些內容，而無需等待客戶端請求它們。

它對於有些人需要的主動更新或使客戶端快取無效也很有用

當然，在某些情況下，客戶端不希望某些東西被推送到它 - 通常是因為它已經有一個副本，或者知道它不會使用它。在這些情況下，它只能用RST_STREAM說“不”。

• 在單個TCP連線中進行多路複用

HTTP / 2使用多路複用來允許許多訊息同時在一個連線上交錯在一起，這樣一個大的響應（或一個需要很長時間讓伺服器思考的響應）不會阻止其他訊息。

此外，它增加了標頭壓縮，因此正常的請求和響應標頭不會佔據您的頻寬 - 即使您請求的內容非常小。這在移動裝置上是一個巨大的勝利，畢竟通過幾次往返，獲取大量請求標頭可以輕鬆地耗費大量資源的頁面載入時間。

• 長時間連線

HTTP / 2旨在使用更少的連線，因此伺服器和網路將享受更少的負載。當網路變得擁擠時，這一點尤其重要，因為HTTP / 1使用多個連線進行並行化會增加問題。

例如，如果您的手機開啟六個到每個伺服器的TCP連線以下載頁面的資源（記住這些天大多數頁面使用多個伺服器），它很容易使行動網路的緩衝區過載，導致它們丟棄資料包，觸發重傳和使問題更嚴重。

HTTP / 2允許每個主機使用單個連線，並鼓勵站點在可能的情況下在一個主機上合併其內容。

• 有狀態的聯絡

如果您的HTTP / 1客戶端傳送請求然後發現它不需要響應，如果它想要節省頻寬,則需要關閉連線,沒有安全的方法來恢復它。

HTTP / 2新增RST_STREAM幀以允許客戶端改變主意; 如果瀏覽器導航離開頁面，或者使用者取消下載，則可以避免在不浪費所有頻寬的情況下開啟新連線。

同樣，這是關於改善感知效能和網路友好性; 通過允許客戶端在這種常見場景中保持連線活動，可以避免額外的往返和資源消耗。

與往常一樣，並非一切都與利益有關，但存在一些可疑的缺點：

• 使用二進位制而不是文字

這也是一個好的，不太好的功能。

關於HTTP / 1的一個好處是能夠開啟telnet，輸入請求（如果伺服器沒有超時！）然後檢視響應。這在HTTP / 2中不實用，因為它是二進位制協議。為什麼？

考慮如何將short int 30000（0x7530）儲存為文字和二進位制檔案：

如您所見，我們使用2個位元組而不是使用5個位元組。它減小了50％以上的尺寸。

雖然二進位制協議具有較低的解析開銷，以及稍微更輕的網路佔用空間，但這一重大變化的真正原因是二進位制協議更簡單，因此更不容易出錯。

那是因為文字協議必須涵蓋諸如如何分隔字串（計算？double-newline？），如何處理空格，額外字元等問題。這導致了很多實現的複雜性; 在HTTP / 1中，至少有三種方法可以告知訊息何時結束，以及一組複雜的規則來確定使用哪種方法。

HTTP / 1的文字性質也是許多安全問題的根源; 因為不同的實現做出關於如何解析訊息的不同決定，所以惡意方可以擺弄他們的方式（例如，通過響應分裂攻擊）。

遠離文字的另一個原因是，任何看起來像HTTP / 1的東西都將被處理為HTTP / 1，當你新增多路複用等基本功能時（將內容與錯誤資訊相關聯會產生災難性後果），你需要做一個乾淨的休息。

當然，對於那些只想除錯協議的窮人來說，所有這些都是一個小小的慰藉。這意味著我們需要新工具和大量工具來解決這個缺點; 首先，Wireshark已經有了一個外掛。

• 更多加密

HTTP / 2不要求您使用TLS（SSL的標準形式，即Web的加密層），但其更高的效能使得使用加密變得更容易，因為它減少了對網站看起來速度的影響。這意味著您可能需要購買SSL證書，續訂等等。當您使用REST API處理許多微服務時，這不是一筆不小的錢。

事實上，許多人認為在“開放”網際網路上部署新協議的唯一安全方法是使用加密; Firefox和Chrome表示他們只支援使用TLS的HTTP / 2。

他們有兩個原因。一個是在Internet上部署新版本的HTTP很難，因為代理和防火牆等許多“中間盒”都假設HTTP / 1不會發生變化，並且如果他們嘗試使用它們就會引入互操作性甚至安全問題解釋HTTP / 2連線。

另一個是Web是一個越來越危險的地方，使用更多加密是緩解大量威脅的一種方法。通過使用HTTP / 2作為站點使用TLS的胡蘿蔔，他們希望Web的整體安全效能夠得到改善。

總結

如果大多數可能基於REST的微服務都在進行伺服器到伺服器的通訊，那麼現有REST API的真正好處就在於此。在今天的微服務架構中，當許多微服務以多種方式在它們之間進行交談但仍使用REST時，HTTP / 2可以提高工作流的速度。

HTTP / 2不定義JavaScript API，也不會幫助您更輕鬆地構建REST API。目前，在Web瀏覽器中執行的JavaScript客戶端只能有限地使用新功能。但是，對於伺服器到伺服器的通訊，HTTP / 2提供了許多方法來超越現有的REST API。

此外，HTTP / 2的網路友好性的缺點是它使TCP擁塞控制更加明顯; 現在瀏覽器每個主機只使用一個連線，初始視窗和資料包丟失更加明顯。

就像HTTP經歷了一段時間的審查，實驗和演變一樣，很明顯社群的注意力轉向TCP及其對效能的影響; 關於在IETF中調整甚至替換TCP的問題，我們已經進行了早期討論。