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的問題，我們已經進行了早期討論。