[譯] HTTP簡史

• 原文地址：Brief History of HTTP
• 原文做者：Ilya Grigorik
• 譯文出自：掘金翻譯計劃
• 本文永久連接：github.com/xitu/gold-m…
• 譯者：jerryOnlyZRJ
• 校對者：Fengziyin1234, Park-ma

簡介

超文本傳輸協議（HTTP）是 Internet 上最廣泛和普遍採用的應用程序協議之一：它是客戶端和服務器之間的通用語言，支持現代 Web。從簡單的單一關鍵字和文檔路徑開始，它已再也不是瀏覽器的專屬，並且適用於幾乎全部鏈接互聯網的軟件和硬件應用程序的協議。

在本章中，咱們將簡要介紹 HTTP 協議的演變。對不一樣 HTTP 語義的完整討論超出了本書的範圍，可是理解 HTTP 的關鍵設計變動以及每一個變動背後的動機將爲咱們討論 HTTP 性能提供必要的背景知識，特別是本文中說起的 HTTP/2 即將進行的許多改進。

HTTP 0.9：單線協議

Tim Berners-Lee 最初的 HTTP 提案在設計時考慮到了 簡單性，以幫助他支撐他的另外一個新生想法：萬維網。該策略彷佛有效：有抱負的協議設計者，請注意

1991 年，Berners-Lee 概述了新協議產生的動機並列出了幾個高級設計目標：文件傳輸功能、請求索引搜索超文本存檔的能力、格式協商以及將客戶端引用到另外一個服務器的能力。爲了證實該理論的實際應用，他構建了一個簡單的原型，它實現了所提議功能的一小部分：

• 客戶端請求是單個 ASCII 字符串。
• 客戶請求由回車（CRLF）終止。
• 服務器響應是 ASCII 字符流。
• 服務器響應是一種超文本標記語言（HTML）。
• 文檔傳輸完成後終止鏈接。

其實並無那麼複雜，這些規則啓用的是一個一些 Web 服務器當前依然支持的、很是簡單的而且 Telnet 友好的協議：

$> telnet google.com 80

Connected to 74.125.xxx.xxx

GET /about/

(hypertext response)
(connection closed)
複製代碼

請求由單行：GET 方法和所請求文檔的路徑組成。響應是單個超文本文檔 — 沒有頭部或任何其餘元數據，只有 HTML，它真的不能再簡單了。此外，因爲先前的交互是預期協議的子集，所以它私下裏也被叫作 HTTP/0.9。其他的，正如他們所說，是歷史。

從1991年這些不起眼的開始，HTTP 開始了本身的生命，並在將來幾年迅速發展。讓咱們快速回顧一下 HTTP/0.9 的功能：

• 客戶端 - 服務器，請求 - 響應協議。
• ASCII 協議，運行在 TCP / IP 連接之上。
• 旨在傳輸超文本文檔（HTML）。
• 每次請求後，服務器和客戶端之間的鏈接都將關閉。

小提示：現階段流行的 Web 服務器，如 Apache 和 Nginx，仍然有一部分支持 HTTP/0.9 協議，由於它真的特別簡單！若是您感到好奇，請打開 Telnet 會話並嘗試經過 HTTP/0.9 訪問 google.com 或您本身喜歡的網站，並檢查此早期協議的行爲和限制。

HTTP/1.0: 協議的快速發展和信息 RFC

1991年至1995年期間是 HTML 規範的快速發展的階段，瀏覽器誕生，面向消費者的公共互聯網基礎設施出現並快速增加。

完美風暴：20 世紀 90 年代初的互聯網熱潮

在 Tim Berner-Lee 最初的瀏覽器原型的基礎上，國家超級計算應用中心（NCSA）的一個團隊決定實現他們本身的版本。這標誌着，第一個流行的瀏覽器誕生了：NCSA Mosaic。1994 年 10 月，NCSA 團隊的一名程序員 Marc Andreessen 與 Jim Clark 合做建立了 Mosaic Communications。該公司後來更名爲 Netscape（網景），並於 1994 年 12 月發佈了 Netscape Navigator 1.0。從那時開始，一切已經很明朗了，萬維網不只僅是一個學術熱點，它必將引發 更多的 關注。

實際上，同年第一次萬維網會議在瑞士日內瓦舉辦，以幫助指導 HTML 的發展爲目的的萬維網聯盟（W3C）也由此誕生。在同一時期，在 IETF 內部同期創建了 HTTP 工做組（HTTP-WG），專一於改進 HTTP 協議。直到今天，他們依舊是互聯網的重要團隊，繼續推進互聯網的進化。

最後，爲了創造完美的風暴，CompuServe 、AOL 和 Prodigy 在1994-1995年開始向公衆提供撥號上網服務。憑藉這股互聯網浪潮，Netscape 在1995年8月9日以很是成功的 IPO 創造了歷史 — 互聯網熱潮已經到來，每一個人都想要分得一瓢羹！

愈來愈多的公共網站上的使用案例代表大衆對於新興網絡的功能需求在不斷增長，這很快暴露了 HTTP/0.9 的許多根本限制：咱們須要的協議不只能夠提供超文本文檔，還能夠提供有關請求和響應的更豐富的元數據、啓用內容協商等。對此，新興的 Web 開發人員社區的迴應方式是，經過「實現，部署，並看是否有人開始採用它」這一專門的過程，來製做大批實驗性質的 HTTP 服務器和客戶端。

從這段快速的實驗期開始，一系列最佳的實踐和常見的模式開始出現，1996 年 5 月，HTTP 工做組（HTTP-WG）發佈了 RFC 1945，它記錄了許多 HTTP/1.0 不規範但卻「常見」的實現方法。請注意，這只是一個信息 RFC：HTTP/1.0 ，由於咱們知道它不是正式規範或 Internet 標準！

話雖如此，但 HTTP/1.0 請求實例看起來卻很是熟悉：

$> telnet website.org 80

Connected to xxx.xxx.xxx.xxx

GET /rfc/rfc1945.txt HTTP/1.0 1⃣️
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
Accept: */*

HTTP/1.0 200 OK 2⃣️
Content-Type: text/plain
Content-Length: 137582
Expires: Thu, 01 Dec 1997 16:00:00 GMT
Last-Modified: Wed, 1 May 1996 12:45:26 GMT
Server: Apache 0.84

(plain-text response)
(connection closed)
複製代碼

1⃣️ 具備HTTP版本號的請求行，後接請求頭

2⃣️具備響應狀態碼，後接響應頭

前面的變化儘管不僅是 HTTP/1.0 功能的詳盡列表，但它確實說明了一些關鍵的協議更改：

• 請求可能包含多個換行符分隔的頭部字段。
• 響應對象以響應狀態行爲前綴。
• 響應對象有本身的一組換行符分隔的頭部字段。
• 響應對象不限於超文本。
• 每次請求後，服務器和客戶端之間的鏈接都將關閉。

請求和響應頭都應保證是 ASCII 編碼，但響應對象自己能夠是任何類型：HTML 文件、純文本文件、圖像或任何其餘內容類型。所以，HTTP 的「超文本傳輸​​」部分在新特性引入後不久就變得不那麼恰當了。實際上，HTTP已經迅速發展成爲 超媒體 傳輸，但原始名稱仍然存在。

除了媒體類型協商以外，RFC 還記錄了許多其餘經常使用功能：內容編碼，字符集支持，多部分類型，受權，緩存，代理行爲，日期格式等。

小提示：現在，Web 上的幾乎全部服務器均可以而且仍將使用 HTTP/1.0。除此以外，到如今爲止，你應該更爲了解了吧！每一個請求須要新的 TCP 鏈接會對 HTTP/1.0 形成嚴重的性能損失。參考：三次握手，以及慢啓動。

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 標準解決了早期版本中發現的許多協議歧義，並引入了許多關鍵性能優化：keep-alive 鏈接，分塊編碼傳輸，字節範圍請求，附加緩存機制，傳輸編碼和管道式請求。

有了這些能力，咱們如今能夠檢查由任何現代 HTTP 瀏覽器和客戶端執行的典型 HTTP/1.1 會話：

$> telnet website.org 80
Connected to xxx.xxx.xxx.xxx

GET /index.html HTTP/1.1 1⃣️

Host: website.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4)... (snip)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: __qca=P0-800083390... (snip)

HTTP/1.1 200 OK 2⃣️

Server: nginx/1.0.11
Connection: keep-alive
Content-Type: text/html; charset=utf-8
Via: HTTP/1.1 GWA
Date: Wed, 25 Jul 2012 20:23:35 GMT
Expires: Wed, 25 Jul 2012 20:23:35 GMT
Cache-Control: max-age=0, no-cache
Transfer-Encoding: chunked

100 3⃣️

<!doctype html>
(snip)

100
(snip)

0 4⃣️

GET /favicon.ico HTTP/1.1 5⃣️

Host: www.website.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4)... (snip)
Accept: */*
Referer: http://website.org/
Connection: close 6⃣️

Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: __qca=P0-800083390... (snip)

HTTP/1.1 200 OK 7⃣️

Server: nginx/1.0.11
Content-Type: image/x-icon
Content-Length: 3638
Connection: close
Last-Modified: Thu, 19 Jul 2012 17:51:44 GMT
Cache-Control: max-age=315360000
Accept-Ranges: bytes
Via: HTTP/1.1 GWA
Date: Sat, 21 Jul 2012 21:35:22 GMT
Expires: Thu, 31 Dec 2037 23:55:55 GMT
Etag: W/PSA-GAu26oXbDi

(icon data)
(connection closed)
複製代碼

1⃣️ 請求 HTML 文件，包含編碼，字符集和 cookie 元數據

2⃣️ 原始 HTML 請求的分塊響應

3⃣️ 塊中的八位字節數表示爲 ASCII 十六進制數（256 字節）

4⃣️ 分塊流響應結束

5⃣️ 請求在同一 TCP 鏈接上建立的圖標文件

6⃣️ 通知服務器不會重用鏈接

7⃣️ 圖標響應，而後關閉鏈接

哎呀，那裏有太多事情發生！第一個也是最明顯的區別是咱們有兩個對象請求，一個用於HTML頁面，另外一個用於圖像，二者都經過單個鏈接傳遞。這是鏈接 keep-alive 的實際應用，它容許咱們重用現有的 TCP 鏈接，以便對同一主機發出多個請求，並提供更快的最終用戶體驗。參閱 TCP 的優化。

要終止持久鏈接，請注意第二個客戶端請求 close 經過 Connection 請求頭向服務器發送顯式指令。相似地，一旦傳輸響應，服務器就能夠通知客戶端關閉當前 TCP 鏈接的意圖。從技術上講，任何一方均可以在沒有此類信號的狀況下終止 TCP 鏈接，但客戶端和服務器應儘量提供它以在雙方上實現更好的鏈接重用策略。

小提示：HTTP/1.1 下將 HTTP 協議的語法更改成默認狀況使用鏈接 keep-alive。這意味着，除非另有說明（經過 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 撰寫的 O'Reilly 出版的 HTTP：The Definitive Guide 。

HTTP/2: 提升運輸性能

自發布以來，RFC 2616 已經成爲互聯網空前增加的基礎：數十億臺各類形狀和大小的設備，從臺式電腦到咱們口袋裏的小型網絡設備，以及咱們生活中都已離不開的天天都會用 HTTP 來傳送新聞、視頻以及數以百萬計的其餘網絡應用程序。

最初用於檢索超文本的簡單單行協議最終演變爲通用的超媒體傳輸，或許十年以後甚至可用於爲您能想象的任何需求提供支持。無處不在的服務器以及協議在客戶端中的普遍可用性，意味着如今許多應用程序都是專門在 HTTP 之上設計和部署的。

須要一個協議來控制你的咖啡壺？RFC 2324 已經涵蓋了超文本咖啡壺控制協議（HTCPCP/1.0）—— 本來是 IETF 的愚人節玩笑，卻漸漸的在咱們新的超鏈接世界中再也不是「玩笑」。

超文本傳輸協議（HTTP）是用於分佈式協做超媒體信息系統的應用程序級協議。它是一種通用的無狀態協議，能夠經過擴展其請求方法，錯誤代碼和頭部，用於拓展其用於超文本以外的許多任務，例如名稱服務器和分佈式對象管理系統。HTTP 的一個特性是數據表示的輸入和協商，容許系統獨立於正在傳輸的數據而構建。

RFC 2616：HTTP/1.1，1999 年 6 月

HTTP 協議的簡捷性使其最初被普遍採用和快速發展成爲可能。事實上，如今發現使用 HTTP 做爲主要控制和數據協議的嵌入式設備（傳感器，執行器和咖啡壺）並不罕見。但在其自身成功的重壓下，隨着咱們愈來愈多地繼續將咱們的平常互動轉移到網絡 —— 社交、電子郵件、新聞、視頻以及愈來愈多的我的和工做空間 —— 它也開始顯示出有心無力的跡象。用戶和 Web 開發人員如今都要求 HTTP/1.1 提供近乎實時的響應和協議性能，若是不作出修改，它就沒法知足需求。

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

新的實現專一於在保留 HTTP 的語義的基礎上，摒棄 HTTP/1.x 消息框架和語法的遺留問題，這些問題已被肯定爲妨礙性能，並且極易形成底層傳輸的誤用。

工做組將基於 HTTP 當前的語義以及有序的全雙工模式中設計新的規範。與 HTTP/1.x 同樣，主要目標傳輸是 TCP，但應該可使用其餘傳輸。

HTTP/2 章程，2012 年 1 月

HTTP/2 的主要關注點是提升傳輸性能並實現更低的延遲和更高的吞吐量。主要的版本增幅聽起來是一個很大的步驟，就性能而言，它將是一個重要的步驟，但重要的是要注意，沒有任何高級協議語義受到影響：全部 HTTP 頭，值和用戶場景都是相同的。

任何現有的網站或應用程序均可以而且將經過 HTTP/2 傳送而無需作出任何修改：您無需變動您的應用程序以利用 HTTP/2。HTTP 服務器將廣泛使用 HTTP/2，但這應該成爲大多數用戶的透明升級。若是工做組實現其目標，惟一的區別應該是咱們的應用程序以更低的延遲和更好的網絡連接利用率交付！

話雖如此，讓咱們不要過於超前。在咱們開始使用新的 HTTP/2 協議功能以前，值得退一步並檢查咱們現有的 HTTP/1.1 部署和性能最佳實踐。HTTP/2 工做組正在新規範上取得快速進展，但即便最終標準已經完成並準備就緒，咱們仍然必須在可預見的將來支持舊的 HTTP/1.1 客戶端。實際上，有可能會是十年或更長時間。

若是發現譯文存在錯誤或其餘須要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可得到相應獎勵積分。文章開頭的 本文永久連接 即爲本文在 GitHub 上的 MarkDown 連接。

---

掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區，文章來源爲 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。