2. HTTP的現(xiàn)狀

互聯(lián)網上幾乎所有內容都采用HTTP 1.1作為通信協(xié)議。人們在該協(xié)議上投入了大量精力，基于它的基礎架構也因此日臻完善。正因如此，在HTTP協(xié)議之上構建新的方案會比從底層建立新的協(xié)議容易得多。

2.1. HTTP 1.1過于龐大

HTTP剛誕生的時候只被當作是一個相對簡單直觀的協(xié)議，但時間證明這種初始設計并不如意。定義HTTP 1.0規(guī)范的RFC 1945共有60頁，發(fā)布于1996年。僅僅3年之后，定義HTTP 1.1規(guī)范的RFC 2616卻一下增長到了176頁。然而，當我們在IETF在進行該規(guī)范更新工作時，它被拆分成了總頁數(shù)更多的六個文檔（這就是RFC 7230及其文件族的誕生）。不管怎么樣，HTTP 1.1包含了太多細節(jié)和可選的部分，這讓它變得過于龐大。

2.2. 過多的可選項

HTTP 1.1不僅包含了非常多的細枝末節(jié)，還為將來的擴展預留的很多選項。這種事無巨細的風格導致在現(xiàn)在的軟件生態(tài)中，幾乎沒有任何實現(xiàn)真正實現(xiàn)了協(xié)議中提及的所有細節(jié)，甚至要弄清楚“所有細節(jié)”到底包括哪些細節(jié)都非常困難。正因為如此，很多最初不常用的功能在后來的實現(xiàn)中很少會被支持，而有些最初實現(xiàn)了的功能，卻又很少被使用。

隨著時間推移，這些當初看似被邊緣化的功能逐漸被用上，客戶端和服務器的互用性（interoperability）問題就被暴露了出來。HTTP管線化（HTTP Pipelining）就是一個非常好的例子。

2.3. 未能被充分利用的TCP

HTTP 1.1很難榨干TCP協(xié)議所能提供的所有性能。HTTP客戶端和瀏覽器必須要另辟蹊徑的去找到新的解決方案來降低頁面載入時間。

與此同時，人們也嘗試去用新的協(xié)議來替代TCP，但結果證明這也非常困難。無奈之下，我們只能嘗試同時改進TCP協(xié)議本身和基于TCP的上層協(xié)議。

簡言之，我們也能通過更好的利用TCP來減少傳輸過程中的暫停，并充分挖掘利用那些本可以用于發(fā)送/接受更多數(shù)據的時間。下面幾段將會著重討論這些問題。

2.4. 傳輸大小和資源數(shù)量

如果仔細觀察打開那些最流行的網站首頁所需要下載的資源的話，會發(fā)現(xiàn)一個非常明顯的趨勢。 近年來加載網站首頁需要的下載的數(shù)據量在逐漸增加，并已經超過了1.9MB。但在這里我們更需要關注的是：顯示每個頁面所需下載的平均資源數(shù)也超過了100個。

正如下圖所示，這種趨勢已經持續(xù)了很長一段時間，并卻沒有減緩的跡象。該圖表中綠色直線展示了傳輸數(shù)據大小的增長，紅色直線展示了平均請求資源數(shù)量的增長。