【譯】HTTP/2 為更快速的網站而生
阿新 • • 發佈：2020-03-24
最近在做一個內部的服務對接，使用了Google的gRPC框架，gRPC是基於HTTP/2和protocol buffers實現的，所以額外去了解了一下HTTP/2，找到這這邊文章。這篇文章雖然是寫於2015年時間比較久遠，但是對於HTTP/2的介紹很全面，於是花了些時間翻譯了一下。
原文地址：https://cascadingmedia.com/insites/2015/03/http-2.html
http://fengwc.cn/article/http2-faster-web/
HTTP/2 誕生的意義
國際網際網路工程任務組（The Internet Engineering Task Force，簡稱 IETF）在2015年2月通過了HTTP/2標準，自從1999年HTTP/1.1被列為標準後，HTTP/2是對HTTP(Hypertext Transfer Protocol)第一個大版本的更新。HTTP/2可以與HTTP/1.1高度相容，但是卻有更低的延遲。總而言之，HTTP/2就是為更快速的網站而生。起源於SPDY
自從2009年底Google開發一個實驗性質的協議SPDY(pronounced speedy)，SPDY是Google的一個標誌並不是一個縮寫。HTTP/2期初是就以SPDY的實驗特性為基礎的。實際上，很多SPDY的核心開發者都參與了HTTP/2的研發工作。直到2015年2月，Google宣佈SPDY將被廢棄，並主推HTTP/2，並在2016年完全替代。HTTP/1.1
隊頭阻塞（Head-of-Line Blocking）
奢侈的連線
然而使用開啟多個連線來輔助加速的方式，從計算機網路的角度來看，每開啟一個連線都是非常奢侈的。由於建立連線的花銷非常大，目前的瀏覽器都會對HTTP/1.1的最大連線數進行限制，一般為6-8個。但是很多網站，會去請求80個乃至更多的資源，因此，這個限制也會導致很大的效能瓶頸。HTTP管線化(HTTP pipelining)
HTTP/1.1嘗試通過HTTP管線化技術來解決這一效能瓶頸。不幸的是，一個體積很大的或慢response仍然會阻塞後面所有的請求。HTTP管線化技術並不是實施起來很困難，而是現階段不可能實現。由於服務端中介軟體和伺服器都不能很好的支援HTTP管線化，所以也沒有任何一個瀏覽器去支援這一技術。HTTP/2多路複用
其他的HTTP/2效能優化點
除了多路複用之外，HTTP/2使用的是二進位制傳輸而不是像HTTP/1使用文字。相較於文字協議，二進位制解析起來更加的高效，具有更高的壓縮率，且更不容易出錯。HTTP/2對請求的頭部資訊進行了壓縮，這些都是HTTP/1所欠缺的。
服務端推（Server Push）
服務端推是HTTP/2的一個機制，服務端可以主動傳送資料而不需要客戶端的請求。舉個例子，如果一個請求獲取你的網站首頁，服務端將會吧首頁連帶著logo和樣式檔案等一併返回，因為服務端知道這些檔案客戶端將會需要。這種機制的本質相當於，將這些資源與DOM文件進行內部關聯，除此之外，推送的資源將會在客戶端進行快取。服務端推技術的一個缺點是：當客戶端已經快取了資源就會造成資源浪費，這也是為什麼我推薦使用服務端暗示（Server Hints）。
服務端暗示（Server Hints）
服務端暗示技術將會在客戶端請求之前對將會需求的資源進行識別。但是伺服器並不會傳送完整的資源內容，僅僅是傳送URL。客戶端之後如果需要請求這些資源會先去校驗快取，然後去請求這些資源。服務端暗示技術並不是HTTP/2的新特性，但是就像前面所描述的那樣，這個技術非常值得一提的是，不會有服務端推技術可能會造成資源冗餘的缺點。服務端暗示是使用HTTP Link頭來實現，並且與已經存在的連結預取語義上重複。舉個例子，一個HTTP Link頭看起來是這樣的：
Link: <https://example.com/images/large-background.jpg>; rel=prefetch如果HTML文件在head標籤中包含連結預取屬性的link，那麼則不需要服務端進行實現。例子如下
<link rel="prefetch" href="https://example.com/images/large-background.jpg">要了解更多關於rel="prefetch", 可以檢視Mozilla連結預取FAQ。
更新一步瞭解服務端暗示技術
preload rel屬性通過宣告一個資源和它的fetch屬性來實現。這個規範通過使用額外的處理策略來拓展功能，從而當下一次導航的時候可以更高效的獲取資源。舉個例子：<!-- fetch and preprocess for next navigation --> <link rel="preload" href="//example.com/next-page.html" as="html" loadpolicy="next"> <!-- fetch and do not preprocess for next navigation --> <link rel="preload" href="//example.com/next-component.html" as="html" loadpolicy="next inert">"next inert"載入策略在一些瀏覽器實現上等同於rel=prefetch，"next"載入策略在一些瀏覽器實現語義上等同於rel=prerender。 該規範的實現拓展了先前的預取和預渲染功能 瞭解更多，可以檢視Ilya Grigorik編輯，W3C釋出的Resource Hints
HTTP/2安全批評
儘管HTTP/2的主要目的是使網站的速度更快，但是它也因為沒有強制使用加密連線受到了大量的批評。因而領先的瀏覽器廠商因此很久沒有去支援沒有加密的HTTP/2。所以HTTP/2需要使用加密連線的方式來落地這一技術。可以來看我的另一篇文章HTTPS Everywhere，除非你不認為HTTPS是未來的網站的一個很好的發展方向。瀏覽器支援情況
HTTP/2正在或即將被所有主流的瀏覽器支援 Chrome 40支援了HTTP/2第14草案，但是預設情況下沒有啟用。HTTP/2第17草案(最終草案)被Chrome Canary 43（預釋出開發版）所使用。目前僅僅基於TLS（加密）的HTTP/2才被支援。 想要在Chrome瀏覽器啟用啟用HTTP/2，可以訪問連結：chrome://flags/#enable-spdy4火狐瀏覽器已經支援了HTTP/2並且從36版本開始預設是開啟的。34版本中火狐瀏覽器開始實驗性質地支援HTTP/2。目前僅僅實施了基於TLS的HTTP/2。
IE11僅僅在 Windows 10 beta版本支援HTTP/2，預設情況下是啟用的，目前也是僅僅支援基於TLS的HTTP/2。
Spartan瀏覽器被期待支援基於TLS的HTTP/2，微軟為Windows 10打造的新瀏覽器。 Safari在Mac OS X Yosemite (10.10)和iOS 8預設支援SPDY。預計在2015年底去全面支援HTTP/2。 Opera預設也是支援SPDY。一旦HTTP/2草案在Chrome瀏覽器中預設支援的時候，Opera也會全面支援。服務端支援情況
支援HTTP/2
IIS (Internet Information Services) 在Windows 10 beta版本中支援HTTP/2。 OpenLiteSpeed在1.3.8和1.4.5中支援HTTP/2草案17.支援SPDY, 但是不支援HTTP/2
Apache通過mod_spdy模組支援老版本的SPDY，但是目前這個模組已經停止開發了。 LiteSpeed Web Server目前支援SPDY/3.1。 Nginx通過模組提供實驗性質的而支援SPDY (草案 3.1)，並且計劃在2015年底開始支援HTTP/2。沒有打算支援HTTP/2的伺服器
lighttpd 在1.x的版本中沒有支援SPDY或者HTTP/2的計劃。其他支援HTTP/2的伺服器
其他支援HTTP/2的比較有名的伺服器可以在GitHub HTTP/2 wiki找到。結語
正如我們的探索，HTTP/2對於Web是一個跨世紀的更新。因此在接下來的幾年裡將會被更加廣泛的使用，網站和其他的Web服務想比以前將會變得更快更穩定。特別感謝這些具有前瞻性的瀏覽器開發者，HTTP/2也會提高使用者的隱私和安全性。然而還有很長的一段路要走，我認為HTTP/2是這個網際網路發展邁出的一大步。 如果你對於HTTP/2有任何的問題和想法，我將在我的Twitter進行回覆@BenjaminPatch。致謝
特別感謝Ilya Grigorik，一位Google優秀的Web效能工程師，感謝他對於這邊文章提供的支援。Ilya也是《High-Performance Browser Networking》的作者，對於Web開發這來說是很好的學習網路和瀏覽器效能的資源。&n