一篇文章徹底了解HTTP發展史

2019 年 10 月 7 日
筆記

閱讀文本大概需要 6 分鐘。

HTTP 協議可以算是在人們日常生活、工作用得比較多的協議。我們使用瀏覽器訪問網頁，就是通過 HTTP 來傳遞數據；客戶端跟伺服器交互，大部分會使用到 HTTP 協議。對於我們做數據採集的人來說，也是再正常不過。Requests 和 Scrapy 都是對 HTTP 進行封裝的支援自定義配置的庫。

互聯網工程任務組（IETF）在去年提議將 HTTP-over-QUIC 重命名為 HTTP/3。我們是做技術的，需要保持一定敏感度。一旦 HTTP/3 標準被定下來，各大產商會相繼支援，那會給我們帶來什麼影響？需要我們回顧下 HTTP 的發展史。

HTTP 0.9

我們把時間撥回到 1991年，萬維網協會（World Wide Web Consortium，W3C）和互聯網工程任務組（IETF）制定了 HTTP 0.9 標準。因為那個年代互聯網還在普及，加上網速頻寬低，所以 HTTP 0.9 只支援 GET 請求。

HTTP 1.0

時間來到1996 年 5 月，HTTP/1.0 版本發布，HTTP 協議新增很多內容。首先是請求方式的多樣化，從單一的 GET 請求，增加了 POST 命令和 HEAD 命令。除此之外，還支援發送任何格式的內容。這兩項新增內容，不僅使得互聯網不僅可以傳輸文字、傳輸影像、影片、二進位文件，還豐富了瀏覽器與伺服器的互動方式。這為互聯網的大發展奠定了基礎。

再次，HTTP請求和回應的格式也變了。除了數據部分，每次通訊都必須包括頭資訊（HTTP header），用來描述一些元數據。其他的新增功能還包括狀態碼（status code）、多字符集支援、多部分發送（multi-part type）、許可權（authorization）、快取（cache）、內容編碼（content encoding）等。

但 HTTP/1.0 還是存在缺點：

第一點是：連接無法復用。HTTP 1.0 規定瀏覽器與伺服器只保持短暫的連接，瀏覽器的每次請求都需要與伺服器建立一個TCP連接，伺服器完成請求處理後立即斷開TCP連接，伺服器不跟蹤每個客戶也不記錄過去的請求。如果還要請求其他資源，就必須再新建一個連接。
第二點是：Head-Of-Line Blocking（HOLB，隊頭阻塞）。HOLB 是指一系列包（package）因為第一個包被阻塞；當頁面中需要請求很多資源的時候，HOLB 會導致在達到最大請求數量時，剩餘的資源需要等待其它資源請求完成後才能發起請求。這會導致頻寬無法被充分利用，以及後續健康請求被阻塞。

HTTP 1.1

W3C 組織為了解決 HTTP 1.0 遺留的問題，在 1997 年 1 月，發布 HTTP/1.1 版本，只比 1.0 版本晚了半年。它進一步完善了 HTTP 協議，一直用到了20年後的今天，直到現在還是最流行的版本。具體優化點：

快取處理。在 HTTP 1.0 中主要使用 header 里的 If-Modified-Since,Expires 來做為快取判斷的標準，HTTP 1.1則引入了更多的快取控制策略例如 Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的快取頭來控制快取策略。
頻寬優化及網路連接的使用。針對網路開銷大的問題，HTTP 1.1 在請求頭引入了range頭域，它允許只請求資源的某個部分，即返回碼是206（Partial Content），這樣就方便了開發者自由的選擇以便於充分利用頻寬和連接。
錯誤通知的管理。在HTTP1.1中新增了24個錯誤狀態響應碼。 4 . 長鏈接。HTTP/1.1 加入 Connection：keep-alive 可以復用一部分連接，在一個TCP連接上可以傳送多個HTTP請求和響應，減少了建立和關閉連接的消耗和延遲。

隨著網路的發展，HTTP 1.1 還是暴露出一些局限性。

雖然加入 keep-alive 可以復用一部分連接，但域名分片等情況下仍然需要建立多個 connection，耗費資源，給伺服器帶來性能壓力。
pipeling 只部分解決了 HOLB。HTTP 1.1 嘗試使用 pipeling 來解決隊頭阻塞問題，即瀏覽器可以一次性發出多個請求（同個域名、同一條 TCP 鏈接）。但 pipeling 要求返回是按序的，那麼前一個請求如果很耗時（比如處理大圖片），那麼後面的請求即使伺服器已經處理完，仍會等待前面的請求處理完才開始按序返回。
協議開銷大。HTTP/1 在使用時，header 里攜帶的內容過大，在一定程度上增加了傳輸的成本，並且每次請求 header 基本不怎麼變化，尤其在移動端增加用戶流量。

HTTP 2.0

互聯網的發展還是受到網路速度的限制。有個調侃的話，永遠不要忽略一輛載滿磁帶的在高速公路上飛馳的卡車的頻寬。大概意思說數據量大到一定程度時，物理運輸無論是速度、安全性、便捷性都比網路傳輸好。

Google是業務首先提出雲計算的概念；加上Google的公司文化特點是自己內部資訊公開、透明，每個人都能了解到其他任何人當前的工作計劃、程式碼等。Google為了解決內部系統傳輸數據慢的問題，自行研發的 SPDY 協議，目的是以最小化網路延遲，提升網路速度，解決 HTTP/1.1 效率不高的問題。

SPDY 協議是在 TCP 協議之上。相比 HTTP/1 的文本格式，HTTP/2 採用二進位格式傳輸數據，解析起來更高效。同時，還支援對 Header 壓縮，減少頭部的包體積大小。

HTTP 2.0 還引入了多路復用技術。多路復用很好地解決了瀏覽器限制同一個域名下的請求數量的問題，同時也更容易實現全速傳輸，畢竟新開一個 TCP 連接都需要慢慢提升傳輸速度。

Google於2009 年公開了 SPDY 協議，W3C 組織協議不錯。於是乎，W3C 將 SPDY 協議引入到 HTTP 協議中，在 2012 年發布 HTTP 2.0。

HTTP 3.0

不得不說Google的技術確實牛逼，TCP 協議雖然能保證不丟包，但還是存在一些局限性。Google為了提高Web聯網的速度決定推倒重來，吸收 TCP 快速打開的技術，快取當前會話的上下文等優點，基於 UDP 協議研發一種名為QUIC （全稱是「快速UDP互聯網連接」）的實驗性網路協議，並且使用運用在 Chrome 瀏覽器上。

我們可以在 Chrome 瀏覽器地址欄上輸入 chrome://flags/ 來體驗 QUIC。

身兼 IETF 旗下 HTTP 工作組組長和 QUIC 工作組組長的馬克•諾丁漢（Mark Nottingham）提議，將 HTTP-over-QUIC 實驗性協議將被重命名為 HTTP/3，並有望成為 HTTP 協議的第三個正式版本。

—END—