一. 一般的問題

1. 為什么要修改 HTTP？
   HTTP/1.1 在 Web 上已經(jīng)服務了 15 年以上，但是它的缺點正在開始顯現(xiàn)。加載網(wǎng)頁比以往任何時候都需要更多資源(請參閱HTTP Archive’s page size statistics)，并且要高效地加載所有這些資源非常困難，因為事實上，HTTP 只允許每個 TCP 連接有一個未完成的請求。

過去，瀏覽器使用多個 TCP 連接來發(fā)出并行請求。但是，這是有局限性的。如果使用的連接過多，則將適得其反(TCP 擁塞控制將被無效化，導致的用塞事件將會損害性能和網(wǎng)絡)，并且從根本上講是不公平的(因為瀏覽器會占用許多本不該屬于它的資源)。同時，大量請求意味著“在線”上有大量重復數(shù)據(jù)。

這兩個因素都意味著 HTTP/1.1 請求有很多與之相關的開銷。如果請求過多，則會影響性能。

這使得業(yè)界誤解了“最佳實踐”，進行諸如 spriting 圖片合并，data: inlining 內聯(lián)數(shù)據(jù)，Domain Sharding 域名分片和 Concatenation 文件合并之類的事情。這些 hack 行為表明協(xié)議本身存在潛在問題，在使用的時候會出現(xiàn)很多問題。

2. 誰制定了 HTTP/2？

HTTP/2 是由 IETF 的 HTTP 工作組開發(fā)的，該工作組維護 HTTP 協(xié)議。它由許多 HTTP 實現(xiàn)者，用戶，網(wǎng)絡運營商和 HTTP 專家組成。

請注意，雖然我們的郵件列表托管在 W3C 網(wǎng)站上，但這并不是 W3C 的努力。但是，Tim Berners-Lee 和 W3C TAG 與 WG 的工作進度保持同步。

大量的人為這項工作做出了貢獻，最活躍的參與者包括來自諸如 Firefox，Chrome，Twitter，Microsoft 的 HTTP stack，Curl 和 Akamai 等“大型”項目的工程師，以及許多諸如 Python、Ruby 和 NodeJS 之類的 HTTP 實現(xiàn)者。

要了解有關 IETF 的更多信息，請參見Tao of the IETF。您還可以在 Github 的貢獻者圖中了解誰為規(guī)范做出了貢獻，以及誰在我們的實現(xiàn)列表中參與該項目。

3. HTTP/2 與 SPDY 有什么關系？
   HTTP/2 第一次出現(xiàn)并被討論的時候，SPDY 正逐漸受到實現(xiàn)者(例如 Mozilla 和 nginx)的青睞時，并且被當成對 HTTP/1.x 的重大改進。

在征求提案和進行選擇過程之后，選擇 SPDY/2 作為 HTTP/2 的基礎。此后，根據(jù)工作組的討論和實現(xiàn)者的反饋，進行了許多更改。在整個過程中，SPDY 的核心開發(fā)人員都參與了 HTTP/2 的開發(fā)，包括 Mike Belshe 和 Roberto Peon。2015 年 2 月，Google 宣布了其計劃刪除對 SPDY 的支持，轉而支持 HTTP/2。

4. 是 HTTP/2.0 還是 HTTP/2？
   工作組決定刪除次版本（“.0”），因為它在 HTTP/1.x 中引起了很多混亂。換句話說，HTTP 版本僅表示網(wǎng)絡兼容性，而不表示功能集或“亮點”。

5. HTTP/2 和 HTTP/1.x 的主要區(qū)別是什么？
   在高版本的 HTTP/2 中：

是二進制的，而不是文本的
完全多路復用，而不是有序和阻塞
因此可以使用一個連接進行并行處理
使用頭壓縮??來減少開銷
允許服務器主動將響應"推送"到客戶端緩存中

6. 為什么 HTTP/2 是二進制的？

與諸如 HTTP/1.x 之類的文本協(xié)議相比，二進制協(xié)議解析起來更高效，更“緊湊”，并且最重要的是，它們比二進制協(xié)議更不容易出錯，因為它們對空格處理，大寫，行尾，空白行等的處理很有幫助。例如，HTTP/1.1 定義了四種不同的解析消息的方式。在 HTTP/2 中，只有一個代碼路徑。

HTTP/2 在 telnet 中不可用，但是我們已經(jīng)有了一些工具支持，例如 Wireshark 插件。

7. 為什么 HTTP/2 需要多路復用？
   HTTP/1.x 存在一個稱為“隊頭阻塞”的問題，指的是一次連接（connection）中，只提交一個請求的效率比較高，多了就會變慢。

HTTP/1.1 試圖通過管道修復此問題，但是并不能完全解決問題（較大或較慢的響應仍會阻止其他問題）。此外，由于許多中間件和服務器未正確處理管線化，因此很難部署它。

這迫使客戶使用多種試探法（通常是猜測法）來決定通過哪些連接提交哪些請求；由于頁面加載的數(shù)據(jù)量通常是可用連接數(shù)的 10 倍（或更多），因此會嚴重影響性能，通常會導致被阻止的請求“泛濫”。

多路復用通過允許同時發(fā)送多個請求和響應消息來解決這些問題。甚至有可能將一條消息的一部分與另一條消息混合在一起。所以在這種情況下，客戶端只需要一個連接就能加載一個頁面。

8. 為什么只有一個 TCP 連接？
   使用 HTTP/1，瀏覽器打開每個站點需要 4 個到 8 個連接?，F(xiàn)在很多網(wǎng)站都使用多點傳輸，因此這可能意味著單個頁面加載會打開 30 多個連接。

一個應用程序打開如此多的連接，已經(jīng)遠遠超出了當初設計 TCP 時的預想。由于每個連接都會響應大量的數(shù)據(jù)，這會造成中間網(wǎng)絡中的緩沖區(qū)溢出的風險，從而導致網(wǎng)絡擁塞事件并重新傳輸。

此外，使用這么多連接還會強占許多網(wǎng)絡資源。這些資源都是從那些“遵紀守法”的應用那“偷”的（VoIP 就是個很好的例子）。

9. 服務器推送的好處是什么？
   當瀏覽器請求頁面時，服務器將在響應中發(fā)送 HTML，然后需要等待瀏覽器解析 HTML 并發(fā)出對所有嵌入資源的請求，然后才能開始發(fā)送 JavaScript，圖像和 CSS。

服務器推送可以通過“推送”它認為客戶端需要的響應到其緩存中，來避免服務器的這種往返延遲。

但是，“推送”響應不是“神奇的”——如果使用不正確，可能會損害性能。正確使用 Server Push 是正在進行的實驗和研究領域。

10. 為什么我們需要頭壓縮？
    Mozilla 的 Patrick McManus 通過計算平均頁面加載消息頭的效果，生動地展示了這一點。

假設一個頁面包含大約 80 個資源需要加載（在當今的 Web 中是保守的），并且每個請求具有 1400 字節(jié)的消息頭（這并不罕見，這要歸功于 Cookie，Referer 等），至少要 7 到 8 個來回去“在線”獲得這些消息頭。這還不包括響應時間——那只是從客戶端那里獲取到它們所花的時間而已。

這是因為 TCP 的慢啟動機制造成的，根據(jù)已確認的數(shù)據(jù)包數(shù)量，從而對新連接上發(fā)送數(shù)據(jù)的進行限制——有效地限制了最初的幾次來回可以發(fā)送的數(shù)據(jù)包數(shù)量。

相比之下，即使對報頭進行輕微的壓縮，這些請求也可以在一次往返（甚至一個數(shù)據(jù)包）內搞定。

這種額外開銷是相當大的，尤其是考慮到對移動客戶端的影響時，即使在網(wǎng)絡狀況良好的條件下，移動客戶端的往返延遲通常也要幾百毫秒。

11. 為什么選擇 HPACK？
    SPDY/2 建議每個方都使用單獨的 GZIP 上下文進行消息頭壓縮，該方法易于實現(xiàn)且效率很高。

從那時起，一個重要的攻擊方式 CRIME 誕生了，這種方式可以攻擊加密文件內部的所使用的壓縮流（如 GZIP）。

使用 CRIME，攻擊者有能力將數(shù)據(jù)注入加密流中，并可以“探測”明文并恢復它。由于這是 Web，因此 JavaScript 使這成為可能，而且已經(jīng)有了通過對受到 TLS 保護的 HTTP 資源的使用CRIME來還原出 cookies 和認證令牌（Toekn）的案例。

結果，我們無法使用 GZIP 壓縮。沒有找到適合該用例并且可以安全使用的其他算法，我們創(chuàng)建了一種新的，專門針對報頭的壓縮方案，該方案以粗粒度壓縮模式運行；由于 HTTP 標頭通常在消息之間不改變，因此仍然可以提供合理的壓縮效率，并且更加安全。

12. HTTP/2 可以使 Cookie(或其他頭字段)變得更好嗎？
    這一努力被許可在網(wǎng)絡協(xié)議的一個修訂版本上運行 —— 例如，HTTP 消息頭、方法等等如何才能在不改變 HTTP 語義的前提下放到“網(wǎng)絡上”。

這是因為 HTTP 被廣泛使用。如果我們使用此版本的 HTTP 引入一種新的狀態(tài)機制（例如之前討論過的例子）或更改了核心方法（值得慶幸的是，尚未提出該方法），則意味著新協(xié)議與現(xiàn)有 Web 不兼容。

特別是，我們希望能夠在不損失任何信息的情況下從 HTTP/1 轉換為 HTTP/2。如果我們開始“清理”報頭（并且大多數(shù)人會同意，因為 HTTP 報頭很亂），將會出現(xiàn)很多與現(xiàn)有 Web 互操作性的問題。

這樣做只會對新協(xié)議的普及造成麻煩。

綜上所述，HTTP 工作組負責所有 HTTP，而不僅僅是 HTTP/2。這樣，我們可以研究與版本無關的新機制，只要它們與現(xiàn)有 Web 向后兼容即可。

13. 非瀏覽器的 HTTP 用戶呢？
    如果非瀏覽器應用程序已經(jīng)在使用 HTTP，則它們也應該能夠使用 HTTP/2。

先前收到過 HTTP “APIs” 在 HTTP/2 中具有良好性能等特點這樣的反饋，那是因為 API 不需要在設計中考慮諸如請求開銷之類的問題。

話雖如此，我們正在考慮的改進的主要焦點是典型的瀏覽用例，因為這是該協(xié)議的核心用例。

我們的章程對此表示：

The resulting specification(s) are expected to meet these goals for common existing deployments of HTTP; in particular, Web browsing (desktop and mobile), non-browsers ("HTTP APIs"), Web serving (at a variety of scales), and intermediation (by proxies, corporate firewalls, "reverse" proxies and Content Delivery Networks). Likewise, current and future semantic extensions to HTTP/1.x (e.g., headers, methods, status codes, cache directives) should be supported in the new protocol.

正在制定的規(guī)范需要滿足現(xiàn)在已經(jīng)普遍部署了的 HTTP 的功能要求；具體來說主要包括，Web 瀏覽（桌面端和移動端），非瀏覽器（“HTTP APIs” 形式的），Web 服務（大范圍的），還有各種網(wǎng)絡中介（借助代理，企業(yè)防火墻，反向代理以及內容分發(fā)網(wǎng)絡實現(xiàn)的）。同樣的，對 HTTP/1.x 當前和未來的語義擴展 (例如，消息頭，方法，狀態(tài)碼，緩存指令) 都應該在新的協(xié)議中支持。


Note that this does not include uses of HTTP where non-specified behaviours are relied upon (e.g., connection state such as timeouts or client affinity,and "interception" proxies); these uses may or may not be enabled by the final product.

值得注意的是，這里沒有包括將 HTTP 用于非特定行為所依賴的場景中（例如超時，連接狀態(tài)以及攔截代理）。這些可能并不會被最終的產(chǎn)品啟用。

14. HTTP/2 是否需要加密？
    否。經(jīng)過廣泛討論，工作組尚未對新協(xié)議必須要使用加密（例如 TLS）達成共識，。

但是，一些實現(xiàn)已聲明它們僅在通過加密連接使用 HTTP/2 時才支持 HTTP/2，并且當前沒有瀏覽器支持未加密的 HTTP/2。

15. HTTP/2 如何提高安全性？
    HTTP/2 定義了必需的 TLS 配置文件；這包括了版本，密碼套件黑名單和使用的擴展。

有關詳細信息，請參見規(guī)范。

還討論了其他機制，例如對 HTTP:// URL 使用 TLS（所謂的“機會主義加密”）；參見 RFC 8164。

16. 我現(xiàn)在可以使用 HTTP/2 嗎？
    在瀏覽器中，Edge，Safari，F(xiàn)irefox 和 Chrome 的最新版本都支持 HTTP/2。其他基于 Blink 的瀏覽器也將支持 HTTP/2（例如 Opera 和 Yandex Browser）。有關更多詳細信息，請參見這里。

還有幾種可用的服務器（包括 Akamai，Google 和 Twitter 的主要站點提供的 beta 支持），以及許多可以部署和測試的開源實現(xiàn)。

有關更多詳細信息，請參見實現(xiàn)列表。

17. HTTP/2 會取代 HTTP/1.x 嗎？
    工作組的目的是讓那些使用 HTTP/1.x 的人也可以使用 HTTP/2，并能獲得 HTTP/2 所帶來的好處。他們說過，由于人們部署代理和服務器的方式不同，我們不能強迫整個世界進行遷移，所以 HTTP/1.x 仍有可能要使用了一段時間。

18. 會有 HTTP/3 嗎？
    如果通過 HTTP/2 引入的協(xié)商機制運行良好，支持新版本的 HTTP 就會比過去更加容易。

二. 實現(xiàn)相關的問題

1. 為什么規(guī)則會圍繞 HEADERS frame 的 Continuation？
   存在連續(xù)性是因為單個值（例如 Set-Cookie）可能超過 16KiB-1，這意味著它無法放入單個幀中。決定處理該問題的最不容易出錯的方法是要求所有消息頭數(shù)據(jù)都以一個接一個幀的方式傳遞，這使得解碼和緩沖區(qū)管理也變得更加容易。

2. HPACK 狀態(tài)的最小或最大大小是多少？
   接收方始終控制 HPACK 中使用的內存量，并且可以將其最小設置為 0，最大值與 SETTINGS 幀中的最大可表示整數(shù)（當前為 2^32-1）有關。

3. 如何避免保持 HPACK 狀態(tài)？
   發(fā)送一個 SETTINGS 幀，將狀態(tài)尺寸（SETTINGS_HEADER_TABLE_SIZE）設置到 0，然后 RST 所有的流，直到一個帶有 ACT 設置位的 SETTINGS 幀被接收。

4. 為什么只有一個壓縮/流控制上下文？
   簡單的說一下。

最初的提議里有流分組的概念，它可以共享上下文，流量控制等。雖然這將使代理受益（以及代理用戶的體驗），但這樣做卻增加了相當多的復雜性。所以我們就決定先以一個簡單的東西開始，看看它會有多糟糕的問題，并且在未來的協(xié)議版本中解決這些問題（如果有的話）。

5. 為什么 HPACK 中有 EOS 符號？
   HPACK 的霍夫曼編碼，出于 CPU 效率和安全性的考慮，將霍夫曼編碼的字符串填充到下一個字節(jié)邊界；任何特定的字符串可能需要 0-7 位之間的填充。

如果單獨考慮霍夫曼解碼，那么任何比所需填充長的符號都可以工作；但是，HPACK 的設計允許按字節(jié)比較霍夫曼編碼的字符串。通過要求將 EOS 符號的位用于填充，我們確保用戶可以對霍夫曼編碼的字符串進行字節(jié)比較，以確定是否相等。反過來，這意味著許多 headers 可以在不需要霍夫曼解碼的情況下被解析。

6. 是否可以在不實現(xiàn) HTTP/1.1 的情況下實現(xiàn) HTTP/2？
   是的，大部分情況都可以。

對于 TLS（h2）上的 HTTP/2 ，如果您未實現(xiàn) http1.1 ALPN 標識符，則無需支持任何 HTTP/1.1 功能。

對于基于 TCP（h2c）的 HTTP/2 ，您需要實現(xiàn)初始 Upgrade 升級請求。

只支持 h2c 的客戶端需要生成一個針對 OPTIONS 的請求，因為 “*” 或者一個針對 “/” 的 HEAD 請求，它們相當安全且易于構造。希望僅實現(xiàn) HTTP/2 的客戶端將需要將沒有 101 狀態(tài)碼的 HTTP/1.1 響應視為錯誤。

只支持 h2c 的服務器可以使用一個固定的 101 響應來接收一個包含升級（Upgrade）消息頭字段的請求。沒有 h2c 升級令牌的請求可以通過包含 Upgrade 頭字段的 505（不支持 HTTP 版本）狀態(tài)碼拒絕。不希望處理 HTTP/1.1 響應的服務器應在發(fā)送連接序言后，應該立即用 REFUSED_STREAM 錯誤碼拒絕 stream 1，以鼓勵客戶端通過 upgraded 的 HTTP/2 連接重試請求。

7. 第 5.3.2 節(jié)中的優(yōu)先級示例不正確嗎？
   是正確的。流 B 的權重為 4，流 C 的權重為 12。要確定這些流中的每一個接收的可用資源的比例，請將所有權重相加（16），然后將每個流的權重除以總權重。因此，流 B 獲得了四分之一的可用資源，流C獲得了四分之三。因此，如規(guī)范所述：流 B 理想地接收分配給流 C 的資源的三分之一。

8. HTTP/2 連接需要 TCP_NODELAY 么？
   有可能需要。即使對于僅使用單個流下載大量數(shù)據(jù)的客戶端實現(xiàn)，仍將有必要向相反方向發(fā)送一些數(shù)據(jù)包以實現(xiàn)最大傳輸速度。如果未設置 TCP_NODELAY（仍允許 Nagle 算法），則傳出數(shù)據(jù)包可能會保留一段時間，以允許它們與后續(xù)數(shù)據(jù)包合并。

例如，如果這樣一個數(shù)據(jù)包告訴對等端有更多可用的窗口來發(fā)送數(shù)據(jù)，那么將其發(fā)送延遲數(shù)毫秒（或更長時間）會對高速連接造成嚴重影響。

三. 部署問題

1. 如果 HTTP/2 是加密的，我該如何調試？
   有很多方法可以訪問應用程序數(shù)據(jù)，但最簡單的方法是 NSS keylogging 與 Wireshark 插件（包含在最新開發(fā)版本中）結合使用。這個方法對 Firefox 和 Chrome 均可適用。

2. 如何使用 HTTP/2 服務器推送
   HTTP/2 服務器推送允許服務器無需等待請求即可向客戶端提供內容。這可以改善檢索資源的時間，特別是對于具有大帶寬延遲產(chǎn)品的連接，其中網(wǎng)絡往返時間占了在資源上花費的大部分時間。

推送基于請求內容而變化的資源可能是不明智的。目前，瀏覽器只會推送請求，如果他們不這樣做，就會提出匹配的請求（請參閱 RFC 7234 的第 4 節(jié)）。

某些緩存不考慮所有請求頭字段中的變化，即使它們在 Vary 頭字段中。為了使推送資源被接收的可能性最大化，內容協(xié)商是最好的選擇?；?accept-encoding 報頭字段的內容協(xié)商受到緩存的廣泛尊重，但是可能無法很好地支持其他頭字段。文章來源地址http://www.zghlxwxcb.cn/news/detail-608545.html

到了這里，關于HTTP/2 中的常見問題的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！