HTTP/2概述

HTTP/2意在減輕為維護HTTP/1.1複雜的底層架構而帶來的痛苦，以提高HTTP/1.1的效能。儘管HTTP/2仍然對HTTP/1.1向下相容，但它已不再是一個基於文字的協議。當客戶端通過HTTP/1.1請求建立一個連線時，所有請求將會被升級。從這一點上看，HTTP/2是用“二進位制資料幀”來說話的。

HTTP/2多路複用

HTTP/2多路複用使得一個單獨連線可以處理多個雙向流，因而客戶端可以通過一個單獨連線同時下載多個不同的資源。

HTTP/2頭部壓縮

HTTP 1.x協議族都是基於文字的，因此它們都相當冗長。有時候同一個HTTP頭的集合被一遍又一遍地進行交換。HTTP/2在整個請求過程中保持HTTP頭 表不變，因而大大降低了所需的頻寬。重要的是，這只是在去耦合，而不是經典意義上的壓縮。

HTTP/2推送

你可能會認為，HTTP/2推送是某種WebSocket的延續或升級，但實際上並不是這樣。WebSocket是客戶端和伺服器之間全雙工通訊的一種方法，一旦TCP連線被建立起來，伺服器就可以向客戶端傳送資料，而HTTP/2則解決的是與此不同的問題。

HTTP/2推送一種主動向客戶端傳送資源的技術，不必由客戶端發出請求。這實際上意味著，伺服器端知道，一個網站需要一些圖片，伺服器會在客戶端發出請求前的很長時間內，就一次性將這些圖片傳送到客戶端。

Java HTTP客戶端支援HTTP/2

根據維基百科關於HTTP/2的一個頁面的說法，在編寫的時候，以下Java客戶端庫已能夠建立HTTP/2連線。

Jetty

Netty

OkHttp

Vert.x

Firefly

但在這篇文章中，我們關注的是Java 9提供的HTTP/2支援。JEP 110 指定了具體要求，同時宣告該專案仍處於孵化狀態，這實際上意味著，它將不會取代Java 9中現有的UrlConnection API。 只有在Java 10釋出後，標準Java HTTP/2客戶端才會被移動到java.net包之下。但同時，它會處於jdk.incubtor名稱空間下。

JEP 110為新的、內建的HTTP/2客戶端提出了具體要求，因此它提供了一個高級別的、簡便易用的API和與現有選項相似（或更高）的效能。

第一步是匯入模組jdk.incubator.httpclient。

對於這個例子來說，我們要使用Undertow做為相容HTTP/2的web伺服器。它用來回應客戶端傳送的訊息。

新的API處處遵循生成器模式，而作為初始化HTTP請求入口的HttpClient也不例外。

以阻塞模式傳送請求

一旦我們有了一個HttpClient例項，就可以通過一個生成器建立更多的HttpClient例項。

請求被處理多久，send方法就會阻塞多久，但還是有一種方法來非同步交換HTTP訊息：以非阻塞模式傳送請求。

以非阻塞模式傳送請求

在下面的例子中，10個隨機整數被非同步傳送到我們的HTTP回顯伺服器，而當所有請求被初始化後，主執行緒等待它們完成。

處理push-promise架構

以上全部例子都可以是過時的HTTP/1.1請求。除了建立HttpClient以外，沒有看到任何HTTP/2所特有的東西。

這個客戶端API中與HTTP/2最有關聯的功能很可能是當HTTP/2推送被使用時它處理多個響應的方式。

結論

HTTP/2進行了一些必要改進，使舊的基於文字的協議變得煥然一新，並拋棄了令人討厭的HTTP/1.1中的很多工作流程，但是它並未解決所有已知的問題。

從Java 9方面來看，新的HTTP/2客戶端貌似不錯，但它的下一個版本才會是合格的產品。同時，如果需要HTTP/2支援的話，上面的庫都可以使用。