如今的生活中已經離不開網際網路，智慧家居、線上支付、網上購物都需要網際網路的支援。網際網路切切實實地給生活帶來了諸多便利。有了網際網路，我們可以呆在空調房裡，一邊刷著微博，一邊等透心涼的西瓜送到手上，安安靜靜地做一個吃瓜群眾。

網際網路的建立打破了地域限制，使用者直接上網就可以瀏覽到各種資訊。使用者上網的過程，即瀏覽器向服務端傳送請求，然後將服務端主機上的內容顯示到本地。而瀏覽器與伺服器之間，走的就是 HTTP 協議。HTTP（Hypertext Transfer Protocol），超文字傳輸協議，它是應用層協議。由於其簡捷、快速的方式，適用於分散式和合作式超媒體資訊系統。自 1990 年起，HTTP 就已經被應用於全球資訊網（WWW）全球資訊服務系統。

HTTP 協議發展至今已經更新迭代了多個版本，下面我們來看看 HTTP 的發展史。

最原始的 HTTP/0.9

已過時的 HTTP/0.9 是 HTTP 協議的第一個版本，誕生於 1989 年。它的組成極其簡單，只允許客戶端傳送 GET 這一種請求，而且不支援請求頭。由於沒有協議頭，所以 HTTP/0.9 只能支援一種內容——純文字。伺服器只能迴應 HTML 格式的字串，不能迴應別的格式。伺服器傳送完畢後，就會關閉 TCP 連線。

HTTP/0.9 具有典型的無狀態性，每個訪問都獨立處理，處理完成後就會斷開連線。如果請求的頁面不存在，也不會返回任何錯誤碼。

進化後的 HTTP/1

HTTP/1 是 HTTP 1.0 和 HTTP 1.1 的統稱，分別指 HTTP 協議的版本是 1.0 和 1.1。

HTTP 1.0 是 HTTP 協議的第二個版本，至今仍被廣泛採用。它在 HTTP/0.9 的基礎上做了大量的擴充和改進，包括：

• 可以傳送更多格式的內容，如影象、視訊、二進位制檔案，不僅僅侷限於文字了
• 在 GET 的基礎上，增加了 HEAD 和 POST 請求方法
• 改變了 HTTP 請求和迴應的格式。除了資料部分，每次通訊都必須包括頭資訊（HTTP Header），用來描述一些元資料，即增加了請求頭資訊
• 新增了響應狀態碼（status code）、多字符集支援、許可權（authorization）、快取（cache）、內容編碼（content encoding）等功能
• 雖然還是無狀態協議，不過在請求（request）中增加 了“Connection: keep-alive”Header 頭後就能支援長連線

更新後的 HTTP 1.0 相比之前變化尤其大，支援的功能也很豐富，但仍有諸多缺點。

HTTP 1.0 預設不支援長連線，這樣就增加了 TCP 連線次數，造成開銷浪費。HTTP 1.0 所保持的 TCP 每次只能處理一個請求，雖然能一次性接收多個請求，但是還是得按順序一次處理一個請求，這樣在後續請求等待前序請求完成時，很容易造成阻塞。同時，它還不支援斷點續傳。

這時，HTTP 1.1 登場了。它也是目前主流的 HTTP 協議版本，相比於 HTTP 1.0，它有了明顯的優勢：

加強和優化長連線

HTTP 1.1 支援長連線和請求的流水線處理，在一個 TCP 連線上可以傳送多個 HTTP 請求和響應，減少了建立和關閉連線的消耗和延遲。在 HTTP 1.1 中預設開啟 “Connection: keep-alive”，一定程度上彌補了 HTTP 1.0 每次請求都要建立連線的缺點。

快取支援

所有 HTTP 1.1 請求裡的響應頭都包含了“Date：”標頭，因此每個 Response 都為快取添加了時間戳。

請求頭引入了 range 頭域

它允許只請求資源的某個部分，即返回狀態碼是 206（Partial Content），這樣就方便了開發者自由的選擇，以便於充分的利用頻寬和連線。

採用分塊傳輸編碼

對於一些很耗時的動態操作，伺服器需要等到所有操作完成後才能傳送資料，顯然這樣的效率不高。更好的處理方法是，產生一塊資料，就傳送一塊，採用流模式來取代快取模式。

新增了多個請求方法和錯誤狀態碼

包括 PUT、PATCH、HEAD、OPTIONS、DELETE。另外，客戶端請求的頭資訊中新增了 Host 欄位，用來指定伺服器的域名。同時新增了 24 個錯誤狀態碼。

HTTP 1.1 雖然增加了很多功能，但是它自身仍然有很多不足。由於各個請求到達伺服器的速度不同，如果先發的請求先到達可能會發生阻塞，剩下所有的請求都會被阻塞在那次請求應答之後，這樣就降低了頻寬。

增強後的 HTTP/2

隨著 Web 技術的飛速發展，HTTP 1.1 已經無法滿足使用者對效能的要求，此後 Google 推出協議 SPDY，意在解決 HTTP 1.1 中廣為人知的效能問題。HTTP/2 因此應運而生，它是 HTTP 協議自 1999 年 HTTP 1.1 釋出後的首個更新，主要基於 SPDY 協議。

那 HTTP/2 到底有哪些具體變化呢？

• 多路複用：HTTP/2 使用多路複用技術，使用一個 TCP 連線併發處理多個請求，不但節約了開銷而且可處理請求的數量也比 HTTP 1.1 大了很多
• 資料傳輸：HTTP/2 採用二進位制格式傳輸資料，而非 HTTP 1.x 的文字格式，二進位制協議解析起來更高效
• 頭部壓縮：HTTP 1.1 不支援 Header 資料壓縮，HTTP/2 使用 HPACK 演算法對 Header 的資料進行壓縮，使得資料傳輸更快
• 伺服器推送（Server Push）：當對支援 HTTP/2 的伺服器請求資料的時候，伺服器會順便把一些客戶端需要的資源一起推送到伺服器，這種方式適用於載入靜態資源，節約頻寬

> 小廣告時間：
又拍雲 CDN 當前已全平臺支援 HTTP/2，並已預設開啟。又因 HTTP/2 是在 HTTPS 協議的基礎上實現的，所以只要使用又拍雲 HTTPS 加速服務的域名，都可免費享受 HTTP/2 服務，無需做任何特殊配置。而開啟 HTTPS，只需完成證書申請與管理，無須繁雜流程，輕鬆實現網站與 Web 應用的 HTTPS 加密部署。

即將到來的 HTTP/3

就像 HTTP/1 到 HTTP/2 一樣，HTTP/3 到來同樣有著它的重要任務。

由於 HTTP/2 是基於 HTTP/1 的升級，因此第一個版本中發現的許多核心問題都會向前延伸。其中就包括 TCP 協議在整個網際網路上實施的方式所帶來的問題：HTTP/2 使用了多路複用，一般來說同一個地址只需要使用一個 TCP 連線；單連線最終會成為網路質量較差的環境中的資料瓶頸 - 網路質量下降更容易出現丟包，導致在重傳期間不能傳輸其他資料，勢必會降低整個請求的處理速度。

修改 TCP 協議顯然是不可能的，因此 HTTP/3 引用了基於 UDP 的 QUIC 協議，並有望成為 HTTP 協議的第三個正式版本。HTTP/3 曾用名 HTTP-over-QUIC，QUIC 代表“快速 UDP 網際網路連線”，本身就是 Google 試圖將 TCP 協議重寫進而改進出來的一種技術，它結合了 HTTP/2，TCP，UDP 和 TLS（用於加密）等等。

針對 HTTP/2 的軟肋，HTTP/3 和 QUIC 彌補了前者的不足。QUIC 使用 UDP 協議，它在兩個端點間建立連線，且支援多路複用連線。QUIC 能夠提供等同於 SSL/TLS 層級的網路安全保護，減少資料傳輸及建立連線時的延遲時間，雙向控制頻寬，以避免網路擁塞。Google 希望使用這個協議來取代 TCP 協議，使網頁傳輸速度更快。

展望未來

有些人認為，目前 HTTP/2 的標準尚未完全採用，推出 HTTP/3 可能還為時尚早。這確實是一個有效的觀點，但是正如我們所看到的，這個協議已經得到了世界大規模的測試和實現。谷歌早在 2015 年就已經開始測試，並且在 2017 年 Facebook 也進行了測試。

從概念上講，HTTP/3 是一個出色的協議。但是，在當前的應用程式中實現，仍然需要進行大量的迭代更新。雖然 QUIC 和 UDP 的結合為 Google 提供了出色的使用示例，但 IETF（網際網路工程任務組）標準認為仍未達到目標。網站管理者應該根據自身實際情況進行權衡，來確定哪個協議適合自己的網站，這樣才是正確的做法。

未來如何，我們拭目以待！

推薦閱讀：

一文讀懂 HTTP/2 特性

夜空中最靚的二狗子是如何讓 HTTPS 快上加快的