HTTP 簡史 | Linux 中國

譯註：本文來源於 2013 年出版的《High Performance Browser Networking[1]》的第九章，因此有些資訊略有過時。事實上，現在 HTTP/2 已經有相當的不是，而新的 HTTP/3 也在設計和標準制定當中。

介紹

超文字傳輸協議Hypertext Transfer Protocol（HTTP）是網際網路上最普遍和廣泛採用的應用程式協議之一。它是客戶端和伺服器之間的通用語言，支援現代 Web。從最初作為單個的關鍵字和檔案路徑開始，它已成為不僅僅是瀏覽器的首選協議，而且幾乎是所有連線網際網路硬體和軟體應用程式的首選協議。

在本文中，我們將簡要回顧 HTTP 協議的發展歷史。對 HTTP 不同語意的完整討論超出了本文的範圍，但理解 HTTP 的關鍵設計變更以及每個變更背後的動機將為我們討論 HTTP 效能提供必要的背景，特別是在 HTTP/2 中即將進行的許多改進。

HTTP 0.9: 單行協議

蒂姆·伯納斯·李Tim Berners-Lee 最初的 HTTP 提案在設計時考慮到了簡單性，以幫助他採用他的另一個新想法：全球資訊網World Wide Web。這個策略看起來奏效了：註意，他是一個有抱負的協議設計者。

1991 年，伯納斯·李概述了這個新協議的動機，併列出了幾個高階設計標的：檔案傳輸功能、請求超檔案存檔索引搜尋的能力，格式協商以及將客戶端取用到另一個伺服器的能力。為了證明該理論的實際應用，構建了一個簡單原型，它實現了所提議功能的一小部分。

這些聽起來就挺複雜，而實際情況比這複雜得多。這些規則支援的是一種非常簡單的，對 Telnet 友好的協議，一些 Web 伺服器至今仍然支援這種協議：

1. $> telnet google.com 80
3. Connected to 74.125.xxx.xxx
5. GET /about/
7. (hypertext response)
8. (connection closed)

請求包含這樣一行：GET 方法和請求檔案的路徑。響應是一個超文字檔案，沒有標題或任何其他元資料，只有 HTML。真的是再簡單不過了。此外，由於之前的互動是預期協議的子集，因此它獲得了一個非官方的 HTTP 0.9 標簽。其餘的，就像他們所說的，都是歷史。

從 1991 年這些不起眼的開始，HTTP 就有了自己的生命，併在接下來幾年裡迅速發展。讓我們快速回顧一下 HTTP 0.9 的特性：

流行的 Web 伺服器，如 Apache 和 Nginx，仍然支援 HTTP 0.9 協議，部分原因是因為它沒有太多功能！如果你感興趣，開啟 Telnet 會話並嘗試透過 HTTP 0.9 訪問 google.com 或你最喜歡的網站，並檢查早期協議的行為和限制。

HTTP/1.0: 快速增長和 Informational RFC

1991 年至 1995 年期間，HTML 規範和一種稱為 “web 瀏覽器”的新型軟體快速發展，面向消費者的公共網際網路基礎設施也開始出現並快速增長。

完美風暴：1990 年代初的網際網路熱潮

基於蒂姆·伯納斯·李最初的瀏覽器原型，美國國家超級計算機應用中心（NCSA）的一個團隊決定實現他們自己的版本。就這樣，第一個流行的瀏覽器誕生了：NCSA Mosaic。1994 年 10 月，NCSA 團隊的一名程式員 Marc Andreessen 與 Jim Clark 合作建立了 Mosaic Communications，該公司後來改名為 Netscape（網景），並於 1994 年 12 月釋出了 Netscape Navigator 1.0。從這一點來說，已經很清楚了，全球資訊網已經不僅僅是學術上的好奇心了。

實際上，同年在瑞士日內瓦組織了第一次全球資訊網會議，這導致全球資訊網聯盟World Wide Web Consortium（W3C）的成立，以幫助指導 HTML 的發展。同樣，在 IETF 內部建立了一個並行的HTTP 工作組HTTP Working Group（HTTP-WG），專註於改進 HTTP 協議。後來這兩個團體一直對 Web 的發展起著重要作用。

最後，完美風暴來臨，CompuServe，AOL 和 Prodigy 在 1994-1995 年的同一時間開始向公眾提供撥號上網服務。憑藉這股迅速的浪潮，Netscape 在 1995 年 8 月 9 日憑藉其成功的 IPO 創造了歷史。這預示著網際網路熱潮已經到來，人人都想分一杯羹！

不斷增長的新 Web 所需功能及其在公共網站上的應用場景很快暴露了 HTTP 0.9 的許多基礎限制：我們需要一種能夠提供超文字檔案、提供關於請求和響應的更豐富的元資料，支援內容協商等等的協議。相應地，新興的 Web 開發人員社群透過一個特殊的過程生成了大量實驗性的 HTTP 伺服器和客戶端實現來回應：實現，部署，並檢視其他人是否採用它。

從這些急速增長的實驗開始，一系列最佳實踐和常見樣式開始出現。1996 年 5 月，HTTP 工作組HTTP Working Group（HTTP-WG）釋出了 RFC 1945，它記錄了許多被廣泛使用的 HTTP/1.0 實現的“常見用法”。請註意，這隻是一個資訊性 RFC：HTTP/1.0，如你所知的，它不是一個正式規範或 Internet 標準！

話雖如此，HTTP/1.0 請求看起來應該是：

1. $> telnet website.org 80
3. Connected to xxx.xxx.xxx.xxx
5. GET /rfc/rfc1945.txt HTTP/1.0 ❶
6. User-Agent: CERN-LineMode/2.15 libwww/2.17b3
7. Accept: */*
9. HTTP/1.0 200 OK ❷
10. Content-Type: text/plain
11. Content-Length: 137582
12. Expires: Thu, 01 Dec 1997 16:00:00 GMT
13. Last-Modified: Wed, 1 May 1996 12:45:26 GMT
14. Server: Apache 0.84
16. (plain-text response)
17. (connection closed)

前面的互動並不是 HTTP/1.0 功能的詳盡串列，但它確實說明瞭一些關鍵的協議更改：

請求頭和響應頭都保留為 ASCII 編碼，但響應物件本身可以是任何型別：HTML 檔案、純文字檔案、影象或任何其他內容型別。因此，HTTP 的“超文字傳輸”部分在引入後不久就變成了用詞不當。實際上，HTTP 已經迅速發展成為一種超媒體傳輸，但最初的名稱沒有改變。

除了媒體型別協商之外，RFC 還記錄了許多其他常用功能：內容編碼、字符集支援、多部分型別、授權、快取、代理行為、日期格式等。

今天，幾乎所有 Web 上的伺服器都可以並且仍將使用 HTTP/1.0。不過，現在你應該更加清楚了！每個請求都需要一個新的 TCP 連線，這會對 HTTP/1.0 造成嚴重的效能損失。參見三次握手[2]，接著會慢啟動[3]。

HTTP/1.1: Internet 標準

將 HTTP 轉變為官方 IETF 網際網路標準的工作與圍繞 HTTP/1.0 的檔案工作並行進行，並計劃從 1995 年至 1999 年完成。事實上，第一個正式的 HTTP/1.1 標準定義於 RFC 2068，它在 HTTP/1.0 釋出大約六個月後，即 1997 年 1 月正式釋出。兩年半後，即 1999 年 6 月，一些新的改進和更新被納入標準，並作為 RFC 2616 釋出。

HTTP/1.1 標準解決了早期版本中發現的許多協議歧義，並引入了一些關鍵的效能最佳化：保持連線，分塊編碼傳輸，位元組範圍請求，附加快取機制，傳輸編碼和請求管道。

有了這些功能，我們現在可以審視一下由任何現代 HTTP 瀏覽器和客戶端執行的典型 HTTP/1.1 會話：

1. $> telnet website.org 80
2. Connected to xxx.xxx.xxx.xxx
4. GET /index.html HTTP/1.1 ❶
5. Host: website.org
6. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4)... (snip)
7. Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
8. Accept-Encoding: gzip,deflate,sdch
9. Accept-Language: en-US,en;q=0.8
10. Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
11. Cookie: __qca=P0-800083390... (snip)
13. HTTP/1.1 200 OK ❷
14. Server: nginx/1.0.11
15. Connection: keep-alive
16. Content-Type: text/html; charset=utf-8
17. Via: HTTP/1.1 GWA
18. Date: Wed, 25 Jul 2012 20:23:35 GMT
19. Expires: Wed, 25 Jul 2012 20:23:35 GMT
20. Cache-Control: max-age=0, no-cache
21. Transfer-Encoding: chunked
23. 100 ❸
24. tml>

25. (snip)
27. 100
28. (snip)
30. 0 ❹
32. GET /favicon.ico HTTP/1.1 ❺
33. Host: www.website.org
34. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4)... (snip)
35. Accept: */*
36. Referer: http://website.org/
37. Connection: close ❻
38. Accept-Encoding: gzip,deflate,sdch
39. Accept-Language: en-US,en;q=0.8
40. Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
41. Cookie: __qca=P0-800083390... (snip)
43. HTTP/1.1 200 OK ❼
44. Server: nginx/1.0.11
45. Content-Type: image/x-icon
46. Content-Length: 3638
47. Connection: close
48. Last-Modified: Thu, 19 Jul 2012 17:51:44 GMT
49. Cache-Control: max-age=315360000
50. Accept-Ranges: bytes
51. Via: HTTP/1.1 GWA
52. Date: Sat, 21 Jul 2012 21:35:22 GMT
53. Expires: Thu, 31 Dec 2037 23:55:55 GMT
54. Etag: W/PSA-GAu26oXbDi
56. (icon data)
57. (connection closed)

哇，這裡發生了很多事情！第一個也是最明顯的區別是我們有兩個物件請求，一個用於 HTML 頁面，另一個用於影象，它們都透過一個連線完成。這就是保持連線的實際應用，它允許我們重用現有的 TCP 連線到同一個主機的多個請求，提供一個更快的終端使用者體驗。參見TCP 最佳化[4]。

要終止持久連線，註意第二個客戶端請求透過 Connection 請求頭向伺服器傳送顯示的 close。類似地，一旦傳輸響應，伺服器就可以通知客戶端關閉當前 TCP 連線。從技術上講，任何一方都可以在沒有此類訊號的情況下終止 TCP 連線，但客戶端和伺服器應盡可能提供此類訊號，以便雙方都啟用更好的連線重用策略。

HTTP/1.1 改變了 HTTP 協議的語意，預設情況下使用保持連線。這意味著，除非另有說明（透過 Connection:close 頭），否則伺服器應預設保持連線開啟。

但是，同樣的功能也被反向移植到 HTTP/1.0 上，透過 Connection:keep-Alive 頭啟用。因此，如果你使用 HTTP/1.1，從技術上講，你不需要 Connection:keep-Alive頭，但許多客戶端仍然選擇提供它。

此外，HTTP/1.1 協議還添加了內容、編碼、字符集，甚至語言協商、傳輸編碼、快取指令、客戶端 cookie，以及可以針對每個請求協商的十幾個其他功能。

我們不打算詳細討論每個 HTTP/1.1 特性的語意。這個主題可以寫一本專門的書了，已經有了很多很棒的書。相反，前面的示例很好地說明瞭 HTTP 的快速進展和演變，以及每個客戶端-伺服器交換的錯綜複雜的過程，裡面發生了很多事情！

要瞭解 HTTP 協議所有內部工作原理，參考 David Gourley 和 Brian Totty 共同撰寫的權威指南： The Definitive Guide。（這裡翻譯的不準確）

HTTP/2: 提高傳輸效能

RFC 2616 自釋出以來，已經成為網際網路空前增長的基礎：數十億各種形狀和大小的裝置，從臺式電腦到我們口袋裡的小型網路裝置，每天都在使用 HTTP 來傳送新聞，影片，在我們生活中的數百萬的其他網路應用程式都在依靠它。

一開始是一個簡單的，用於檢索超文字的簡單協議，很快演變成了一種通用的超媒體傳輸，現在十年過去了，它幾乎可以為你所能想象到的任何用例提供支援。可以使用協議的伺服器無處不在，客戶端也可以使用協議，這意味著現在許多應用程式都是專門在 HTTP 之上設計和部署的。

需要一個協議來控制你的咖啡壺？RFC 2324 已經涵蓋了超文字咖啡壺控制協議（HTCPCP/1.0）- 它原本是 IETF 在愚人節開的一個玩笑，但在我們這個超連結的新世界中，它不僅僅意味著一個玩笑。

超文字傳輸協議（HTTP）是一個應用程式級的協議，用於分散式、協作、超媒體資訊系統。它是一種通用的、無狀態的協議，可以透過擴充套件請求方法、錯誤碼和頭，用於超出超文字之外的許多工，比如名稱伺服器和分散式物件管理系統。HTTP 的一個特性是資料表示的型別和協商，允許獨立於傳輸的資料構建系統。

RFC 2616: HTTP/1.1, June 1999

HTTP 協議的簡單性是它最初被採用和快速增長的原因。事實上，現在使用 HTTP 作為主要控制和資料協議的嵌入式裝置（感測器，執行器和咖啡壺）並不罕見。但在其自身成功的重壓下，隨著我們越來越多地繼續將日常互動轉移到網路 —— 社交、電子郵件、新聞和影片，以及越來越多的個人和工作空間，它也開始顯示出壓力的跡象。使用者和 Web 開發人員現在都要求 HTTP/1.1 提供近乎實時的響應能力和協議 效能，如果不進行一些修改，就無法滿足這些要求。

為了應對這些新挑戰，HTTP 必須繼續發展，因此 HTTPbis 工作組在 2012 年初宣佈了一項針對 HTTP/2 的新計劃：

已經有一個協議中出現了新的實現經驗和興趣，該協議保留了 HTTP 的語意，但是沒有保留 HTTP/1.x 的訊息框架和語法，這些問題已經被確定為妨礙效能和鼓勵濫用底層傳輸。

工作組將使用有序的雙向流中生成 HTTP 當前語意的新運算式的規範。與 HTTP/1.x 一樣，主要傳輸標的是 TCP，但是應該可以使用其他方式傳輸。

HTTP/2 charter, January 2012

HTTP/2 的主要重點是提高傳輸效能並支援更低的延遲和更高的吞吐量。主要的版本增量聽起來像是一個很大的步驟，但就效能而言，它將是一個重大的步驟，但重要的是要註意，沒有任何高階協議語意收到影響：所有的 HTTP 頭，值和用例是相同的。

任何現有的網站或應用程式都可以並且將透過 HTTP/2 傳送而無需修改。你無需修改應用程式標記來利用 HTTP/2。HTTP 伺服器將來一定會使用 HTTP/2，但這對大多數使用者來說應該是透明的升級。如果工作組實現標的，唯一的區別應該是我們的應用程式以更低的延遲和更好的網路連線利用率來傳送資料。

話雖如此，但我們不要走的太遠了。在討論新的 HTTP/2 協議功能之前，有必要回顧一下我們現有的 HTTP/1.1 部署和效能最佳實踐。HTTP/2 工作組正在新規範上取得快速的進展，但即使最終標準已經完成並準備就緒，在可預見的未來，我們仍然必須支援舊的 HTTP/1.1 客戶端，實際上，這得十年或更長時間。