# 2. HTTP的現狀
互聯網上幾乎所有內容都采用HTTP 1.1作為通信協議。人們在該協議上投入了大量精力，基于它的基礎架構也因此日臻完善。正因如此，在HTTP協議之上構建新的方案會比從底層建立新的協議容易得多。
## 2.1. HTTP 1.1過于龐大
HTTP剛誕生的時候只被當作是一個相對簡單直觀的協議，但時間證明這種初始設計并不如意。定義HTTP 1.0規范的RFC 1945共有60頁，發布于1996年。僅僅3年之后，定義HTTP 1.1規范的RFC 2616卻一下增長到了176頁。然而，當我們在IETF在進行該規范更新工作時，它被拆分成了總頁數更多的六個文檔（這就是RFC 7230及其文件族的誕生）。不管怎么樣，HTTP 1.1包含了太多細節和可選的部分，這讓它變得過于龐大。
## 2.2. 過多的可選項
HTTP 1.1不僅包含了非常多的細枝末節，還為將來的擴展預留的很多選項。這種事無巨細的風格導致在現在的軟件生態中，幾乎沒有任何實現真正實現了協議中提及的所有細節，甚至要弄清楚“所有細節”到底包括哪些細節都非常困難。正因為如此，很多最初不常用的功能在后來的實現中很少會被支持，而有些最初實現了的功能，卻又很少被使用。
隨著時間推移，這些當初看似被邊緣化的功能逐漸被用上，客戶端和服務器的互用性（interoperability）問題就被暴露了出來。HTTP管線化（HTTP Pipelining）就是一個非常好的例子。
## 2.3. 未能被充分利用的TCP
HTTP 1.1很難榨干TCP協議所能提供的所有性能。HTTP客戶端和瀏覽器必須要另辟蹊徑的去找到新的解決方案來降低頁面載入時間。
與此同時，人們也嘗試去用新的協議來替代TCP，但結果證明這也非常困難。無奈之下，我們只能嘗試同時改進TCP協議本身和基于TCP的上層協議。
簡言之，我們也能通過更好的利用TCP來減少傳輸過程中的暫停，并充分挖掘利用那些本可以用于發送/接受更多數據的時間。下面幾段將會著重討論這些問題。
## 2.4. 傳輸大小和資源數量
如果仔細觀察打開那些最流行的網站首頁所需要下載的資源的話，會發現一個非常明顯的趨勢。 近年來加載網站首頁需要的下載的數據量在逐漸增加，并已經超過了1.9MB。但在這里我們更需要關注的是：顯示每個頁面所需下載的平均資源數也超過了100個。
正如下圖所示，這種趨勢已經持續了很長一段時間，并卻沒有減緩的跡象。該圖表中綠色直線展示了傳輸數據大小的增長，紅色直線展示了平均請求資源數量的增長。
## 2.5 惱人的延遲
HTTP 1.1對網絡延遲非常敏感。部分原因是HTTP Pipelining還有很多問題，所以對大部分用戶來說是默認關閉的。
雖然近幾年來網絡帶寬增長非常快，但是與此相對的是，我們并沒有看到網絡延遲有對應程度的降低。在高延遲的網絡上（比如移動設備），即使擁有高連接速率，也很難獲得優質快速的網絡體驗。
另外一個需要低延遲的場景是某些視頻服務，如視頻會議、游戲和一些類似無法預生成待發送數據流的服務。
## 2.6 線頭阻塞（Head of line blocking）
HTTP Pipelining是這樣一種技術：在等待上一個請求響應的同時，發送下一個請求。(譯者注：作者這個解釋并不完全正確，HTTP Pipelining其實是把多個HTTP請求放到一個TCP連接中一一發送，而在發送過程中不需要等待服務器對前一個請求的響應；只不過，客戶端還是要按照發送請求的順序來接收響應。)但就像在超市收銀臺或者銀行柜臺排隊時一樣，你并不知道前面的顧客是干脆利索的還是會跟收銀員/柜員磨蹭到世界末日（譯者注：不管怎么說，服務器（即收銀員/柜員）是要**按照順序**處理請求的，如果前一個請求非常耗時（顧客磨蹭），那么后續請求都會受到影響），這就是所謂的線頭阻塞（Head of line blocking）。
當然，你可以在選擇隊伍時候就做好功課，去排一個你認為最快的隊伍，或者甚至另起一個新的隊伍（譯者注：即新建一個TCP連接）。但不管怎么樣，你總歸得先選擇一個隊伍，而且一旦選定之后，就不能更換隊伍。
但是，另起新隊伍會導致資源耗費和性能損失（譯者注：新建 TCP 連接的開銷非常大）。這種另起新隊伍的方式只在新隊伍數量很少的情況下有作用，因此它并不具備可擴展性。（譯者注：這段話意思是說，靠大量新建連接是不能有效解決延遲問題的，即HTTP Pipelining并不能徹底解決Head of line blocking問題。）所以針對此問題并沒有完美的解決方案。
即使在2015年的今天，大部分桌面瀏覽器也默認關閉了HTTP pipelining功能。
關于這個問題的更多細節，可以參閱Firefox的 [bugzilla #264354](https://bugzilla.mozilla.org/show_bug.cgi?id=264354)。
