一.前言
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 官方博客
