從 HTTP/1 到 HTTP/2，以及即將到來的 HTTP/3

現在的生活中已經離不開互聯網，智能家居、在線支付、網上購物都須要互聯網的支持。互聯網切切實實地給生活帶來了諸多便利。有了互聯網，咱們能夠呆在空調房裏，一邊刷着微博，一邊等透心涼的西瓜送到手上，安安靜靜地作一個吃瓜羣衆。

互聯網的創建打破了地域限制，用戶直接上網就能夠瀏覽到各類信息。用戶上網的過程，即瀏覽器向服務端發送請求，而後將服務端主機上的內容顯示到本地。而瀏覽器與服務器之間，走的就是 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 快上加快的？