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支持的話，上面的庫都可以使用。