HTTP 演變

HTTP（超文字傳輸協議）是全球資訊網的基礎協議。 HTTP 由蒂姆·伯納斯·李及其團隊在 1989 年至 1991 年間開發，它經歷了許多變化，這些變化有助於保持其簡單性，同時塑造其靈活性。繼續閱讀以瞭解 HTTP 如何從一個旨在在一個半信任的實驗室環境中交換檔案的協議發展成為一個現代的網際網路迷宮，它以高解析度和 3D 傳輸影像和影片。

全球資訊網的發明

1989 年，蒂姆·伯納斯·李在歐洲核子研究組織工作期間，提出了在網際網路上構建超文本系統的建議。它最初被稱為Mesh，後來在 1990 年的實施過程中更名為全球資訊網。它構建在現有的 TCP 和 IP 協議之上，由 4 個構建塊組成

  • 一種用於表示超文字文件的文字格式，即超文字標記語言（HTML）。
  • 一種用於交換這些文件的簡單協議，即超文字傳輸協議（HTTP）。
  • 一個用於顯示（和編輯）這些文件的客戶端，第一個名為WorldWideWeb 的網頁瀏覽器。
  • 一個用於訪問文件的伺服器，httpd 的早期版本。

這四個構建塊在 1990 年底完成，第一個伺服器在 1991 年初執行在歐洲核子研究組織之外。1991 年 8 月 6 日，蒂姆·伯納斯·李釋出在公開的alt.hypertext 新聞組上。這現在被認為是全球資訊網作為公共專案的正式開始。

在那些早期階段使用的 HTTP 協議非常簡單。它後來被稱為 HTTP/0.9，有時也被稱為單行協議。

HTTP/0.9 - 單行協議

HTTP 的初始版本沒有版本號；後來被稱為 0.9 以將其與以後的版本區分開來。HTTP/0.9 非常簡單：請求由一行組成，並以唯一可能的方法GET 開頭，後跟資源的路徑。完整的 URL 沒有包含在內，因為一旦連線到伺服器，協議、伺服器和埠就不再需要了。

http
GET /mypage.html

響應也非常簡單：它只包含檔案本身。

html
<html>
  A very simple HTML page
</html>

與隨後的演變不同，沒有 HTTP 標頭。這意味著只能傳輸 HTML 檔案。沒有狀態程式碼或錯誤程式碼。如果有問題，會生成一個特定的 HTML 檔案，其中包含供人類理解的故障描述。

HTTP/1.0 - 構建可擴充套件性

HTTP/0.9 非常有限，但瀏覽器和伺服器很快就使其變得更加通用

  • 版本資訊在每個請求中傳送（HTTP/1.0 附加到 GET 行）。
  • 響應的開頭也會發送一個狀態碼行。這使得瀏覽器本身能夠識別請求的成功或失敗並相應地調整其行為。例如，以特定方式更新或使用其本地快取。
  • 為請求和響應引入了 HTTP 標頭的概念。元資料可以傳輸，協議變得非常靈活和可擴充套件。
  • 除了純 HTML 檔案之外，其他文件也可以透過Content-Type 標頭傳輸。

在那個時候，一個典型的請求和響應看起來像這樣

http
GET /mypage.html HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)

HTTP/1.0 200 OK
Date: Tue, 15 Nov 1994 08:12:31 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/html
<HTML>
A page with an image
  <IMG SRC="/myimage.gif">
</HTML>

後面跟著第二個連線，以及獲取影像的請求（以及相應的響應）

http
GET /myimage.gif HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)

HTTP/1.0 200 OK
Date: Tue, 15 Nov 1994 08:12:32 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/gif
(image content)

在 1991 年至 1995 年之間，這些都是透過嘗試和檢視的方式引入的。伺服器和瀏覽器會新增一個功能，然後看看它是否會流行起來。互操作性問題很常見。為了解決這些問題，一份描述常見做法的資訊文件於 1996 年 11 月釋出。這被稱為RFC 1945，並定義了 HTTP/1.0。

HTTP/1.1 - 標準化協議

與此同時，正式標準化正在進行中。這與 HTTP/1.0 的各種實現同時進行。HTTP 的第一個標準化版本 HTTP/1.1 於 1997 年初發布，僅比 HTTP/1.0 晚幾個月。

HTTP/1.1 澄清了歧義並引入了許多改進

  • 連線可以重複使用，這節省了時間。它不再需要多次開啟來顯示嵌入在單個原始文件中的資源。
  • 添加了流水線處理。這允許在第一個請求的答案完全傳輸之前傳送第二個請求。這降低了通訊的延遲。
  • 還支援分塊響應。
  • 引入了額外的快取控制機制。
  • 引入了內容協商，包括語言、編碼和型別。客戶端和伺服器現在可以就交換哪些內容達成一致。
  • 由於Host 標頭，從同一 IP 地址託管不同域的能力允許伺服器並置。

一個典型的請求流，全部透過一個單一連線，看起來像這樣

http
GET /en-US/docs/Glossary/CORS-safelisted_request_header HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://mdn.club.tw/en-US/docs/Glossary/CORS-safelisted_request_header

HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Wed, 20 Jul 2016 10:55:30 GMT
Etag: "547fa7e369ef56031dd3bff2ace9fc0832eb251a"
Keep-Alive: timeout=5, max=1000
Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT
Server: Apache
Transfer-Encoding: chunked
Vary: Cookie, Accept-Encoding

(content)

GET /static/img/header-background.png HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://mdn.club.tw/en-US/docs/Glossary/CORS-safelisted_request_header

HTTP/1.1 200 OK
Age: 9578461
Cache-Control: public, max-age=315360000
Connection: keep-alive
Content-Length: 3077
Content-Type: image/png
Date: Thu, 31 Mar 2016 13:34:46 GMT
Last-Modified: Wed, 21 Oct 2015 18:27:50 GMT
Server: Apache

(image content of 3077 bytes)

HTTP/1.1 最初作為RFC 2068 於 1997 年 1 月釋出。

二十多年的發展

HTTP 的可擴充套件性使得建立新的標頭和方法變得容易。即使 HTTP/1.1 協議在兩次修訂中得到了完善，RFC 2616 於 1999 年 6 月釋出，RFC 7230-RFC 7235 於 2014 年 6 月釋出，在 HTTP/2 釋出之前，它在 15 年以上的時間裡非常穩定。HTTP/1.1 於 2022 年再次更新，更新為RFC 9110。不僅更新了 HTTP/1.1，而且所有 HTTP 都進行了修訂，現在被拆分為以下文件：語義 (RFC 9110)、快取 (RFC 9111) 應用於所有 HTTP 版本，以及 HTTP/1.1 (RFC 9112)、HTTP/2 (RFC 9113) 和 HTTP/3 (RFC 9114)。此外，該規範最終獲得了網際網路標準 (STD 97) 的地位，而在此之前它一直是提議的/草案標準。

使用 HTTP 進行安全傳輸

HTTP 最大的變化發生在 1994 年底。網路服務公司 Netscape Communications 沒有將 HTTP 傳送到基本的 TCP/IP 堆疊上，而是在其之上建立了一個額外的加密傳輸層：SSL。SSL 1.0 從未公開發布，但 SSL 2.0 及其後繼者 SSL 3.0 允許建立電子商務網站。為此，它們對伺服器和客戶端之間交換的訊息進行了加密並保證了其真實性。SSL 最終被標準化併成為 TLS。

在同一時期，很明顯需要一個加密的傳輸層。網路不再是一個主要由學術界使用的網路，而是變成了一個廣告商、隨機個人和罪犯爭奪儘可能多的私人資料的叢林。隨著建立在 HTTP 之上的應用程式變得更加強大，並且需要訪問地址簿、電子郵件和使用者位置等私人資訊，TLS 在電子商務用例之外變得必不可少。

將 HTTP 用於複雜應用程式

蒂姆·伯納斯·李最初並沒有將 HTTP 設想為一個只讀介質。他想建立一個網路，人們可以在其中遠端新增和移動文件——一種分散式檔案系統。大約在 1996 年，HTTP 擴充套件到允許創作，並建立了一個名為 WebDAV 的標準。它發展到包括特定應用程式，例如用於處理地址簿條目的 CardDAV 和用於處理日曆的 CalDAV。但所有這些 *DAV 擴充套件都存在一個缺陷：它們只有在伺服器實施時才能使用。

在 2000 年，設計了一種使用 HTTP 的新模式：具象狀態傳輸（或 REST）。API 並非基於新的 HTTP 方法，而是依賴於使用基本 HTTP/1.1 方法訪問特定的 URI。這允許任何 Web 應用程式讓 API 檢索和修改其資料，而無需更新瀏覽器或伺服器。所有必要的資訊都嵌入到網站透過標準 HTTP/1.1 提供的檔案中。REST 模型的缺點是每個網站都定義了自己的非標準 RESTful API，並且對它擁有完全控制權。這不同於 *DAV 擴充套件，在 *DAV 擴充套件中，客戶端和伺服器是互操作的。RESTful API 在 2010 年代變得非常普遍。

自 2005 年以來，更多 API 可用於網頁。其中一些 API 為特定目的建立了 HTTP 協議的擴充套件

  • 伺服器傳送事件，其中伺服器可以偶爾向瀏覽器推送訊息。
  • WebSocket，一種可以透過升級現有 HTTP 連線來設定的新協議。

放寬 Web 的安全模型

HTTP 與網路安全模型（即 同源策略）是相互獨立的。事實上，目前的網路安全模型是在 HTTP 誕生之後才開發出來的！多年來，在某些限制條件下，放鬆同源策略的某些限制被證明是有用的。伺服器透過一組新的 HTTP 頭部資訊，向客戶端傳輸放鬆這些限制的程度和時間。這些頭部資訊在 跨域資源共享 (CORS) 和 內容安全策略 (CSP) 等規範中定義。

除了這些大型擴充套件之外，還添加了許多其他頭部資訊，有時僅供實驗使用。值得注意的頭部資訊包括用於控制隱私的 "請勿跟蹤" (DNT) 頭部資訊、X-Frame-Options 和 Upgrade-Insecure-Requests，但還有很多其他的頭部資訊。

HTTP/2 - 更高效能的協議

多年來，網頁變得越來越複雜。其中一些甚至本身就是應用程式。顯示的視覺媒體也越來越多，增加互動性的指令碼的體積和大小也增加了。透過越來越多的 HTTP 請求傳輸的資料量和大小也增加了，這給 HTTP/1.1 連線帶來了更大的複雜性和開銷。為了解決這個問題，谷歌在 2010 年代初期實施了一個實驗性的協議 SPDY。這種在客戶端和伺服器之間交換資料的替代方式引起了瀏覽器和伺服器開發人員的興趣。SPDY 定義了響應能力的提升，並解決了重複資料傳輸的問題，為 HTTP/2 協議奠定了基礎。

HTTP/2 協議與 HTTP/1.1 在以下幾個方面有所不同。

  • 這是一個二進位制協議，而不是文字協議。它不能手動讀取和建立。儘管存在這個障礙，它允許實施改進的最佳化技術。
  • 這是一個多路複用協議。可以在同一連線上發出並行請求，從而消除 HTTP/1.x 協議的限制。
  • 它壓縮頭部資訊。由於這些資訊在多個請求中經常相似，這消除了傳輸資料的重複和開銷。
  • 它允許伺服器透過一種稱為伺服器推送的機制，將資料填充到客戶端快取中。

HTTP/2 協議於 2015 年 5 月正式標準化，其使用率在 2022 年 1 月達到頂峰，佔所有網站的 46.9%（請參閱 這些統計資料）。高流量網站為了節省資料傳輸開銷和後續預算，最先快速採用該協議。

這種快速採用可能是因為 HTTP/2 不需要對網站和應用程式進行更改。要使用它，只需要一個最新的與最新瀏覽器通訊的伺服器即可。只需要有限的幾個組來觸發採用，隨著舊版瀏覽器和伺服器版本的更新，使用率自然會提高，而無需網站開發人員進行大量的工作。

HTTP/2 之後的演變

HTTP 的可擴充套件性仍在用於新增新功能。值得注意的是，我們可以引用 2016 年出現的 HTTP 協議的新擴充套件。

  • 對 Alt-Svc 的支援允許將給定資源的標識和位置分離。這意味著可以實現更智慧的 CDN 快取機制。
  • 引入 客戶端提示 允許瀏覽器或客戶端主動向伺服器傳達有關其需求和硬體限制的資訊。
  • 在 Cookie 頭部資訊中引入與安全相關的字首有助於確保安全 Cookie 不會被篡改。

HTTP/3 - HTTP over QUIC

HTTP 的下一個主要版本 HTTP/3 具有與早期版本 HTTP 相同的語義，但使用 QUIC 而不是 TCP 作為傳輸層部分。截至 2022 年 10 月，26% 的網站都在使用 HTTP/3。

QUIC 旨在為 HTTP 連線提供更低的延遲。與 HTTP/2 一樣，它也是一個多路複用協議，但 HTTP/2 執行在單個 TCP 連線上，因此在 TCP 層處理的資料包丟失檢測和重傳可能會阻塞所有流。QUIC 在 UDP 上執行多個流，併為每個流獨立地實施資料包丟失檢測和重傳，因此，如果發生錯誤，只有包含該資料包資料的流會被阻塞。

根據 RFC 9114 的定義，HTTP/3 受大多數主流瀏覽器支援，包括 Chromium（及其變體，如 Chrome 和 Edge）和 Firefox。