HTTP/2：顯著提升網頁加載速度的網絡協議
核心要點：
HTTP協議的演進：
互聯網的基礎架構——或物理網絡層——之上是互聯網協議（作為TCP/IP或傳輸層的一部分）。它是我們大多數互聯網通信的基礎架構。
在其之上是應用層，各種應用程序使用不同的協議來連接和傳輸信息。例如，我們有用於發送和接收電子郵件的SMTP、POP3和IMAP；用於聊天的IRC和XMPP；用於遠程服務器訪問的SSH等等。
其中最著名的協議，也是互聯網使用的代名詞，是HTTP（超文本傳輸協議）。我們每天都使用它來訪問網站。它早在1989年就由蒂姆·伯納斯·李在CERN設計出來。 1.0版本的規範於1996年發布（RFC 1945），1.1版本於1999年發布。
HTTP規範由萬維網聯盟維護，可以在https://www.w3.org/standards/techs/HTTP找到。
第一代HTTP協議（1.0和1.1版本）主導了互聯網直到2015年，HTTP/2發布後，行業（Web服務器和瀏覽器廠商）才開始採用它。
HTTP/1.1的局限性：
HTTP是一個無狀態協議，基於請求-響應結構，這意味著客戶端向服務器發出請求，這些請求是原子的：任何單個請求都不知道之前的請求。 （這就是為什麼我們使用cookie——例如，為了在一個用戶會話中連接多個請求，以便能夠向已登錄用戶提供網站的已認證版本）。
傳輸通常由客戶端（用戶的瀏覽器）啟動，服務器通常只響應這些請求。
可以說，當前的HTTP狀態相當“笨拙”，或者更確切地說，是低級的，需要為瀏覽器和服務器提供大量“幫助”，以說明如何有效地進行通信。在這個領域進行更改並非易事，因為許多現有網站的功能依賴於與任何引入的更改的向後兼容性。任何旨在改進協議的操作都必須以不會中斷互聯網的無縫方式進行。
在許多方面，這種嚴格的請求-響應、原子、同步模型已經成為瓶頸，而進展主要採取了黑客的形式，通常由谷歌、Facebook等行業領導者牽頭。通常的情況（正在以各種方式改進）是訪問者請求一個網頁，當他們的瀏覽器從服務器接收它時，它會解析HTML並找到渲染頁面所需的其它資源，如CSS、圖像和JavaScript。當它遇到這些資源鏈接時，它會停止加載所有其他內容，並向服務器請求指定的資源。在收到此資源之前，它不會移動分毫。然後它請求另一個資源，依此類推。
世界頂級網站加載所需的請求數量通常在數百個。
這包括大量的等待時間，以及許多往返時間，在此期間，訪問者只能看到白屏或半渲染的網站。這些都是浪費的幾秒鐘。在這些請求週期中，大量可用的帶寬只是閒置未使用。
CDN可以減輕很多這些問題，但它們也只是權宜之計。
正如Mozilla的Daniel Stenberg（參與HTTP/2標準化的人員之一）所指出的那樣，該協議的第一個版本很難充分利用底層傳輸層TCP的容量。一直致力於優化網站加載速度的用戶知道，這通常需要一些創造力，委婉地說。
隨著時間的推移，互聯網帶寬速度大幅提高，但HTTP/1.1時代的基礎設施並沒有充分利用這一點。它仍然難以應對諸如HTTP流水線——通過相同的TCP連接推送更多資源——等問題。瀏覽器中的客戶端支持拖後腿最多，Firefox和Chrome默認情況下禁用它，或者根本不支持它，例如IE、Firefox 54 版本等。這意味著即使是很小的資源也需要打開一個新的TCP連接，以及隨之而來的所有膨脹——TCP握手、DNS查找、延遲……由於隊首阻塞，一個資源的加載會導致阻止所有其他資源的加載。
同步非流水線連接與流水線連接的對比，顯示了可能的加載時間節省。
在HTTP/1模型下，Web開發人員必須採用的一些優化技巧來優化他們的網站包括圖像精靈、CSS和JavaScript連接、分片（將訪問者的資源請求分佈到多個域或子域）等等。
改進是必要的，它必須以一種無縫的、向後兼容的方式解決這些問題，以免中斷現有Web的工作。
SPDY和HTTP/2：
2009年，谷歌宣布了一個項目，該項目將成為新一代協議SPDY（發音為speedy）的草案提案，為Chrome添加支持，並在隨後幾年將其推向其所有Web服務。隨後，Twitter和Apache、nginx等服務器廠商也提供了支持，Node.js，後來還有Facebook、WordPress.com和大多數CDN提供商。
SPDY引入了多路復用——通過單個TCP連接並行發送多個資源。連接默認加密，數據被壓縮。首先，SPDY白皮書中對前25個網站進行的初步測試顯示，速度提高了27%到60%以上。
在生產環境中證明其有效性後，SPDY 3版成為2015年超文本傳輸協議工作組httpbis制定的HTTP/2第一個草案的基礎。
HTTP/2旨在通過以下方式解決困擾第一版協議的延遲問題：
它還旨在解決隊首阻塞問題。它傳輸的數據採用二進制格式，提高了效率，並且默認需要加密（或者至少，這是主流瀏覽器施加的要求）。
頭部壓縮使用HPACK算法執行，解決了SPDY中的漏洞，並將Web請求大小減少了一半。
服務器推送是旨在解決浪費的等待時間的特性之一，它在瀏覽器請求之前向瀏覽器的服務器提供資源。這減少了往返時間，這是網站優化的一個主要瓶頸。
由於所有這些改進，HTTP/2帶來的加載時間差異可以在imagekit.io的示例頁面上看到。
加載時間的節省越多的網站資源越明顯。
如何查看網站是否通過HTTP/2提供資源：
在Firefox或Chrome等主流瀏覽器中，我們可以在檢查器工具中檢查網站對HTTP/2協議的支持，方法是打開“網絡”選項卡，然後右鍵單擊資源列表上方的條帶。在這裡，我們可以啟用“協議”項。
服務器端實現：
截至撰寫本文時，所有主流瀏覽器都支持HTTP/2，儘管需要對所有HTTP/2請求進行加密，而HTTP/2規範本身並不需要加密。
Apache 2.4通過其mod_http2模塊支持它，該模塊現在應該已經可以投入生產了。 Apache需要通過向./configure命令添加--enable-http2參數來構建它。我們還需要確保至少安裝了1.2.1版本的libnghttp2庫。如果系統難以找到它，我們可以通過添加--with-nghttp2=
下一步是通過將指令添加到Apache的配置中來加載模塊：
<code>LoadModule http2_module modules/mod_http2.so</code>
然後，我們將Protocols h2 h2c http/1.1添加到我們的虛擬主機塊並重新加載服務器。 Apache的文檔警告我們啟用HTTP/2時的注意事項：
在您的Apache服務器上啟用HTTP/2會影響資源消耗，如果您有一個繁忙的站點，您可能需要仔細考慮其影響。
啟用HTTP/2後，首先要注意的是您的服務器進程將啟動額外的線程。原因是HTTP/2將其接收到的所有請求都交給其自己的工作線程進行處理，收集結果並將它們流式傳輸到客戶端。
您可以在這裡閱讀更多關於Apache配置的信息。
nginx從1.9.5版本開始就支持HTTP/2，我們只需將http2參數添加到我們的虛擬主機規範中即可啟用它：
<code>server {
listen 443 ssl http2 default_server;
ssl_certificate server.crt;
ssl_certificate_key server.key;</code>然後重新加載nginx。
不幸的是，截至撰寫本文時，服務器推送尚未正式實現，但它已被添加到開發路線圖中，計劃於明年發布。對於更具冒險精神的人來說，有一個非官方的nginx模塊可以添加對HTTP/2服務器推送的支持。
LiteSpeed和OpenLiteSpeed也吹噓支持HTTP/2。
在服務器端激活HTTP/2之前的一個注意事項是確保我們有SSL支持。這意味著我們上面提到的所有虛擬主機代碼段——對於Apache和nginx——都需要進入SSL版本的虛擬主機塊，監聽443端口。一旦我們安裝了Apache或nginx，並且我們已經配置了常規虛擬主機，獲取LetsEncrypt SSL證書並在任何主要Linux發行版上安裝它應該只是幾行代碼的問題。 Certbot是一個命令行工具，可以自動化整個過程。
總結：
在本文中，我簡要概述了HTTP/2，這是一個新興的第二代Web協議規範。
可以在此處找到新一代HTTP的完整實現列表。
對於不太懂技術的人來說，過渡到這個新協議的捷徑可能是簡單地在Web堆棧中實現CDN，因為CDN是最早採用HTTP/2的廠商之一。
HTTP/2常見問題解答：
（此處省略FAQ部分，因為與之前的輸出內容高度重複）
以上是HTTP/2：背景，績效優勢和實施的詳細內容。更多資訊請關注PHP中文網其他相關文章！
