HTTP/2 對 Web 性能的影響（上）

一.前言

HTTP/2 於 2015 年 5 月正式推出。自誕生以來，它就一直在影響着網絡性能最佳實踐。在本篇文章中，咱們將討論 HTTP/2 的二進制幀、延遲削減、潛在利弊以及相應的應對措施。

超文本傳輸協議（簡稱 HTTP）正是萬維網與網絡空間的基石。如今，HTTP 聽起來已經有些過期，畢竟該協議中使用最普遍的版本——HTTP 1.1，已快迎來它的第二十個年頭。時光回溯到1997年，HTTP1.1剛剛出現的年代，當時，軟驅與調制解調器仍是 PC 設備的必備周邊產品，Java 也僅僅是一個剛剛嶄露頭角的、前途一片光明的編程語言。

而今，2015 年 5 月，HTTP/2 正式亮相，致力於解決 HTTP 1.1 在現代網絡時代下沒法應對的某些重大性能難題。過去一年以來，愈來愈多的瀏覽器、Web 服務器、商用代理以及主要內容交付網絡開始支持 HTTP/2。

遺憾的是，對於負責編寫 Web 代碼的開發人員而言，HTTP/2 的過渡工做並不簡單，所謂的速度提高也不會自行出現，必要的 Web APM 工具和廠商仍然是當今時代不可或缺的，例如 OneAPM Browser Insight、Newrelic、APPdynamic 等等。

如何才能採用這個新協議打造高性能 Web 應用，該怎樣處理那些尚不支持該協議的現有工具——例如 debug 代理工具，這些問題對全部人來講還是一個挑戰。今天的文章將向您介紹 HTTP/2，以及其如何改變 Web 性能的最佳實踐。

二.二進制幀：HTTP/2的「基本單位」

HTTP 1.1 的一大優點（至少相較於非安全鏈接而言）在於其支持在端口 80 的telnet 會話中利用文本與 Web 服務器進行交互：在大多數 Web 服務器上輸入 GET/HTTP/1.1，都能返回一個 HTML 文檔。因爲這是一項文本協議，所以其調試工做相對簡單。

相對於 HTTP1.1 這個文本協議，HTTP/2 中的請求與響應則經過二進制幀流的形式來表現，咱們將其稱爲 HTTP/2 RFC 中的「基本協議單位」。每一幀都擁有本身的類型，用於實現不一樣的做用。考慮到 HTTP 1.1 將會「永遠」存在（畢竟 Gopher 協議都還在用呢！），所以 HTTP/2 的做者們要求，HTTP/2 請求的二進制幀都必須被映射到 HTTP 1.1 請求上去，從而確保其向下兼容的能力。

固然，HTTP/2 當中也有一些其餘新特性，沒法映射至 HTTP 1.1。例如，服務器推送（也叫「緩存推送」）和流重置都是利用二進制幀類型實現的新特性。幀也能夠支持優先級排序，容許客戶端向服務器發送排序，從而優先處理一部分資產類別。

除了使用 Wireshark 2.0 以外，對個別二進制幀進行查看的最簡便方法就是利用谷歌 Chrome 瀏覽器的 net-internals 標籤（在瀏覽器地址欄中輸入chrome://net-internals/#http2）。因爲理解大型網頁的數據一般比較困難，Rebecca Murphey 特地編寫了一款極爲實用的可視化工具，從而將其顯示在命令行中。

除此以外，這個用於獲取資產的協議還能夠顯示在 Chrome Web 的開發者工具當中--只需右鍵點擊列標題，接着選擇「協議」便可：

在谷歌Chrome開發者工具中查看協議類型。

這裏列出的全部 HTTP/2 請求都使用經過傳輸層安全（TLS）創建的安全鏈接。各主流瀏覽器都要求 HTTP/2 鏈接是安全的。這樣作是有切實理由的：TLS 的一套稱爲應用層協議協商（ALPN）的擴展，讓服務器知道瀏覽器支持 HTTP2（除了其餘協議之外），從而避免了額外的數據往來。這也能保住那些沒法解讀 HTTP/2 的服務，例如代理——只看得見傳輸線路上的加密數據。

三.多路複用減小延遲

HTTP 1.1 的一大問題是延遲，換而言之就是它花在提出請求和接受響應上的時間。隨着典型網頁中圖片數量、JavaScript 和 CSS 的使用量不斷增長，這個問題日益嚴重。每獲取一項資產，一般都得新建一個 TCP 鏈接。

這種需求由於兩個理由很重要：每臺主機能同時打開的 TCP 鏈接數受瀏覽器的限制；新建鏈接都會引起性能損失。若是物理服務器離用戶很遠（如：一位新加坡用戶向美國東海岸數據中心請求一個頁面），延遲會變多。這不是罕見的狀況——近期一份報告表示全球 70% 以上的互聯網流通都會經過北佛吉尼亞一些不知名的數據中心。

其實對於 Web 頁面的優化從前端頁面方面反而可能見效比較大，咱們都知道頁面資源對響應速度的影響是很是巨大的，常見的圖片壓縮、css 聚合均可以幫助咱們優化 Web 性能，問題就是如何找到相應的頁面慢加載元素。

這也是國內外 APM 行業興起的最初緣由之一。

拿國內的一個頁面優化工具 Browser Insight 舉例，這種經過頁面插碼來獲取真實用戶體驗的 APM 工具，雖然部署起來有些麻煩，可是這類的工具也沒有更好的部署方法，手動的反而更穩定。

以下圖，咱們能看到，經過這個工具其中一個頁面資源瀑布流圖的功能，能夠看到頁面上每一個元素的加載問題，並且這些都是用戶的真實體驗，因此優化起來就更有目的性了。

HTTP 1.1 提供了多種方案以解決延遲問題，包括通道傳輸與 Keep-Alive header。然而，通道傳輸從未被普遍採納過，而 Keep-Alive header 則飽受 head line 阻塞的困擾：只有在當前請求必須完全完成後，下一請求才能被髮送出去。

在 HTTP/2 當中，多條資產請求能夠重複利用單一 TCP 鏈接。與使用 Keep-Alive header 的 HTTP 1.1 請求不一樣，HTTP/2 的請求與響應二進制幀以交錯方式進行，線頭阻塞問題也不復存在。創建鏈接的成本（即著名的的‘三方握手’）在每臺主機上只進行一次。多路複用對於安全鏈接來講尤其重要，由於屢次 TLS 協商方案的性能成本將會獲得顯著提升。

在 HTTP/2 中，單一主機內的多資產請求只使用單一 TCP 鏈接。

四.總結

其實 Web 性能優化已經不是一個新的話題了，從 21 世紀初期直到如今，不少成熟的互聯網公司已經開始關注除了產品、研發以外的工做，例如用戶體驗、性能優化等與產品使用者息息相關的事情，伴隨着的就是 APM 行業的全面興起。

本文主要和你們聊了一些關於 http1 和 http2 有關的基礎內容，以後還會有一篇，預計與你們分享一些 http2 使用利弊、以及正在進行的相關工做等等。

Browser Insight 是一個基於真實用戶的 Web 前端性能監控平臺，可以幫你們定位網站性能瓶頸，網站加速效果可視化；支持瀏覽器、微信、App 瀏覽 HTML 和 HTML5 頁面。想閱讀更多技術文章，請訪問 OneAPM 官方技術博客。
本文轉自 OneAPM 官方博客