概念
應用層協議協商(Application-Layer Protocol Negotiation,簡稱ALPN)是一個傳輸層安全協議(TLS) 的擴展, ALPN 使得應用層可以協商在安全連接層之上使用什麼協議, 避免了額外的往返通訊, 並且獨立於應用層協議。 ALPN 用於 HTTP/2 連接, 和HTTP/1.x 相比, ALPN 的使用增強了網頁的壓縮率減少了網絡延時。 ALPN 和 HTTP/2 協議是伴隨着 Google 開發 SPDY 協議出現的。
ALPN 擴展與HTTP2
HTTP/2 協議本身並沒有要求它必須基於 HTTPS(TLS)部署,但是出於以下三個原因,實際使用中,HTTP/2 和 HTTPS 幾乎都是捆綁在一起:
- HTTP 數據明文傳輸,數據很容易被中間節點窺視或篡改,HTTPS 可以保證數據傳輸的保密性、完整性和不被冒充;
- 正因爲 HTTPS 傳輸的數據對中間節點保密,所以它具有更好的連通性。基於 HTTPS 部署的新協議具有更高的連接成功率;
- 當前主流瀏覽器,都只支持基於 HTTPS 部署的 HTTP/2;
如果前面兩個原因還不足以說服你,最後這個絕對有說服力,除非你的 HTTP/2 服務只打算給自己客戶端用。
下面介紹在 HTTPS 中,瀏覽器和服務端之間怎樣協商是否使用 HTTP/2。
基於 HTTPS 的協議協商非常簡單,多了 TLS 之後,雙方必須等到成功建立 TLS 連接之後才能發送應用數據。而要建立 TLS 連接,本來就要進行 CipherSuite 等參數的協商。引入 HTTP/2 之後,需要做的只是在原本的協商機制中把對 HTTP 協議的協商加進去。
Google 在 SPDY 協議中開發了一個名爲 NPN(Next Protocol Negotiation,下一代協議協商)的 TLS 擴展。隨着 SPDY 被 HTTP/2 取代,NPN 也被官方修訂爲 ALPN(Application Layer Protocol Negotiation,應用層協議協商)。二者的目標和實現原理基本一致,這裏只介紹後者。如圖:
可以看到,客戶端在建立 TLS 連接的 Client Hello 握手中,通過 ALPN 擴展列出了自己支持的各種應用層協議。其中,HTTP/2 協議名稱是 h2
。
如果服務端支持 HTTP/2,在 Server Hello 中指定 ALPN 的結果爲 h2
就可以了;如果服務端不支持 HTTP/2,從客戶端的 ALPN 列表中選一個自己支持的即可
參考資料:https://zh.wikipedia.org/wiki/%E5%BA%94%E7%94%A8%E5%B1%82%E5%8D%8F%E8%AE%AE%E5%8D%8F%E5%95%86