HTTP發展史（HTTP1.1，HTTPS，SPDY，HTTP2.0，QUIC，HTTP3.0）

本文將從HTTP不斷髮展的時間線來說解與其相關的知識點，其中包括HTTP1.1，HTTPS，SPDY，HTTP2.0，QUIC，HTTP3.0等，文章中內容涉及面較廣，屬於掃盲級別，不會特別深刻某個知識點來延伸，但願各位讀者都能有所收穫。

1. WEB始祖HTTP

HTTP的全稱是：超文本傳輸協議(HyperText Transfer Protocol) 。 伴隨着計算機網絡和瀏覽器的誕生，HTTP1.0也隨之而來，處於計算機網絡中的應用層，HTTP是創建在TCP協議之上，因此HTTP協議的瓶頸及其優化技巧都是基於TCP協議自己的特性，例如TCP創建鏈接的3次握手和斷開鏈接的4次揮手以及每次創建鏈接帶來的RTT延遲時間。

2. HTTP與現代化瀏覽器

早在HTTP創建之初，主要就是爲了將超文本標記語言(HTML)文檔從WEB服務器傳送到客戶端的瀏覽器。也是說對於前端來講，咱們所寫的HTML頁面將要放在咱們的WEB服務器上，用戶端經過瀏覽器訪問URL地址來獲取網頁的顯示內容，可是到了WEB2.0以來，咱們的頁面變得複雜，不只僅單純的是一些簡單的文字和圖片，同時咱們的HTML頁面有了CSS，JavaScript，來豐富咱們的頁面展現，當ajax的出現，咱們又多了一種向服務器端獲取數據的方法，這些其實都是基於HTTP協議的。一樣到了移動互聯網時代，咱們頁面能夠跑在手機端瀏覽器裏面，可是和PC相比，手機端的網絡狀況更加複雜，這使得咱們開始了不起不對HTTP進行深刻理解並不斷優化過程當中。

3.HTTP的基本優化

• 帶寬：

若是說咱們還停留在撥號上網的階段，帶寬可能會成爲一個比較嚴重影響請求的問題，可是如今網絡基礎建設已經使得帶寬獲得極大的提高，咱們再也不會擔憂由帶寬而影響網速，那麼就只剩下延遲了。

• 延遲：

1. 瀏覽器阻塞（HOL blocking）： 瀏覽器會由於一些緣由阻塞請求。瀏覽器對於同一個域名，同時只能有 4 個鏈接（這個根據瀏覽器內核不一樣可能會有所差別），超過瀏覽器最大鏈接數限制，後續請求就會被阻塞。
2. DNS 查詢（DNS Lookup）： 瀏覽器須要知道目標服務器的 IP 才能創建鏈接。將域名解析爲 IP 的這個系統就是 DNS。這個一般能夠利用DNS緩存結果來達到減小這個時間的目的。
3. 創建鏈接（Initial connection）： HTTP 是基於 TCP 協議的，瀏覽器最快也要在第三次握手時才能捎帶 HTTP 請求報文，達到真正的創建鏈接，可是這些鏈接沒法複用會致使每次請求都經歷三次握手和慢啓動。三次握手在高延遲的場景下影響較明顯，慢啓動則對文件類大請求影響較大。下圖爲三次握手流程圖：

   

4.HTTP1.0和HTTP1.1的一些區別

HTTP1.0最先在網頁中使用是在1996年，那個時候只是使用一些較爲簡單的網頁上和網絡請求上，而HTTP1.1則在1999年纔開始普遍應用於如今的各大瀏覽器網絡請求中，同時HTTP1.1也是當前使用最爲普遍的HTTP協議。

主要區別主要體如今：

1. 緩存處理： 在HTTP1.0中主要使用header裏的If-Modified-Since,Expires來作爲緩存判斷的標準，HTTP1.1則引入了更多的緩存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存策略。
2. 帶寬優化及網絡鏈接的使用： HTTP1.0中，存在一些浪費帶寬的現象，例如客戶端只是須要某個對象的一部分，而服務器卻將整個對象送過來了，而且不支持斷點續傳功能，HTTP1.1則在請求頭引入了range頭域，它容許只請求資源的某個部分，即返回碼是206（Partial Content），這樣就方便了開發者自由的選擇以便於充分利用帶寬和鏈接。
3. 錯誤通知的管理： 在HTTP1.1中新增了24個錯誤狀態響應碼，如409（Conflict）表示請求的資源與資源的當前狀態發生衝突；410（Gone）表示服務器上的某個資源被永久性的刪除。
4. Host頭處理： 在HTTP1.0中認爲每臺服務器都綁定一個惟一的IP地址，所以，請求消息中的URL並無傳遞主機名（hostname）。但隨着虛擬主機技術的發展，在一臺物理服務器上能夠存在多個虛擬主機（Multi-homed Web Servers），而且它們共享一個IP地址。HTTP1.1的請求消息和響應消息都應支持Host頭域，且請求消息中若是沒有Host頭域會報告一個錯誤（400 Bad Request）。
5. 長鏈接： HTTP 1.1支持長鏈接（PersistentConnection）和請求的流水線（Pipelining）處理，在一個TCP鏈接上能夠傳送多個HTTP請求和響應，減小了創建和關閉鏈接的消耗和延遲，其中長鏈接也就是對應在HTTP1.1中的Connection： keep-alive，必定程度上彌補了HTTP1.0每次請求都要建立鏈接的缺點。

下圖是常見的HTTP1.1的請求和響應在瀏覽器中的截圖：

5.HTTP1.0和1.1現存的一些問題

1. HTTP1.0和HTTP1.1能夠稱作HTTP1.x，正如上面提到過的，HTTP1.x在傳輸數據時，每次都須要從新創建鏈接，無疑增長了大量的延遲時間，特別是在移動端更爲突出。
2. HTTP1.x在傳輸數據時，全部傳輸的內容都是明文，客戶端和服務器端都沒法驗證對方的身份，這在必定程度上沒法保證數據的安全性。
3. HTTP1.x在使用時，header裏攜帶的內容過大，在必定程度上增長了傳輸的成本，而且每次請求header基本不怎麼變化，尤爲在移動端會增長用戶流量。
4. 雖然HTTP1.1支持了keep-alive，來彌補屢次建立鏈接產生的延遲，可是keep-alive使用多了一樣會給服務端帶來大量的性能壓力，而且對於單個文件被不斷請求的服務(例如圖片存放網站)，keep-alive可能會極大的影響性能，由於它在文件被請求以後還保持了沒必要要的鏈接很長時間。一樣keep-alive也沒法解決線頭阻塞（Head-of-line blocking, HOL）問題。

6.HTTPS來了

爲了解決上面的一些問題，網景在1994年建立了HTTPS，並應用在網景導航者瀏覽器中。 最初，HTTPS是與SSL一塊兒使用的，在SSL逐漸演變到TLS時（其實兩個是一個東西，只是名字不一樣而已），最新的HTTPS也由在2000年五月公佈的RFC 2818正式肯定下來。簡單來講，HTTPS就是安全版的HTTP，而且因爲當今時代對安全性要求更高，Chrome和Firefox都大力支持網站使用HTTPS，蘋果也在iOS 10系統中強制APP使用HTTPS來傳輸數據，因而可知HTTPS勢在必行。

7.HTTPS與HTTP的一些區別

1. HTTPS協議須要到CA申請證書，通常免費證書不多，須要交費。
2. HTTP是超文本傳輸協議，信息是明文傳輸，HTTPS則是具備安全性的TLS加密傳輸協議。
3. HTTP和HTTPS使用的是徹底不一樣的鏈接方式，用的默認端口也不同，前者是80，後者是443。
4. HTTPS的鏈接很簡單，HTTPS協議是由TLS+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比HTTP協議安全。

8.HTTPS改造

若是一個網站要全站由HTTP替換成HTTPS，可能須要關注如下幾點：

1. 安裝CA證書： 通常的證書都是須要收費的，這邊推薦一個比較好的購買證書網站： 1)Let’s Encrypt： 免費，快捷，支持多域名（不是通配符），三條命令就能夠簽署+導出證書。缺點是暫時只有三個月有效期，到期需續簽。 2)Comodo PositiveSSL： 收費，可是比較穩定。
2. 配置WEB服務器： 在購買證書以後，在證書提供的網站上配置本身的域名，將證書下載下來以後，配置本身的WEB服務器，同時進行代碼改造。
3. HTTPS會下降用戶訪問速度： TLS須要握手，HTTPS對速度會有必定程度的下降，可是隻要通過合理優化和部署，HTTPS 對速度的影響徹底能夠接受。在不少場景下，HTTPS 速度徹底不遜於 HTTP，若是使用SPDY，HTTPS的速度甚至還要比 HTTP 快。相對於HTTPS下降訪問速度，其實更須要關心的是服務器端的CPU壓力，HTTPS中大量的密鑰算法計算，會消耗大量的CPU資源，只有足夠的優化，HTTPS 的機器成本纔不會明顯增長。

推薦一則淘寶網改造HTTPS的文章。

9.使用SPDY提速你的網站

2012年Google一聲驚雷提出了SPDY (發音爲"speedy") 的方案，你們纔開始從正面看待和解決老版本HTTP協議自己的問題，SPDY能夠說是綜合了HTTPS和HTTP二者優勢於一體的傳輸協議，主要解決：

1. 下降延遲： 針對HTTP高延遲的問題，SPDY優雅的採起了多路複用（Multiplexing）。多路複用經過多個請求stream共享一個TCP鏈接的方式，下降了建立多個TCP的延遲同時提升了帶寬的利用率。
2. 請求優先級（Request Prioritization）： 多路複用帶來一個新的問題是，在鏈接共享的基礎之上有可能會致使關鍵請求被阻塞。SPDY容許給每一個request設置優先級，這樣重要的請求就會優先獲得響應。好比瀏覽器加載首頁，首頁的html內容應該優先展現，以後纔是各類靜態資源文件，腳本文件等加載，這樣能夠保證用戶能第一時間看到網頁內容。
3. header壓縮： 前面提到HTTP1.x的header不少時候都是重複多餘的，而有些header的內容在不壓縮的狀況下則比較「龐大」（例如cookie和user-agent等）。選擇合適的壓縮算法能夠減少包的大小和數量，不只能夠節省資源，還能夠縮短數據傳遞的延遲。
4. 基於HTTPS的加密協議傳輸： 保留了HTTPS的TLS加密特性，大大提升了傳輸數據的可靠性。
5. 服務端推送（Server Push）： 採用了SPDY的網頁，例如個人網頁有一個sytle.css的請求，在客戶端收到sytle.css數據的同時，服務端會將index.js的文件推送給客戶端，當客戶端再次嘗試獲取index.js時就能夠直接從緩存中獲取到，不用再發請求了。

SPDY構成圖：

SPDY位於HTTP之下，TCP和SSL之上，這樣能夠輕鬆兼容老版本的HTTP協議(將HTTP1.x的內容封裝成一種新的frame格式)，同時可使用已有的SSL功能。 因爲SPDY並非一個標準協議，後來SPDY也未能單獨成爲正式標準，不過SPDY開發組的成員全程參與了HTTP2.0的制定過程。SPDY也有本身的兼容性問題，在HTTP2.0出來以後，大部分瀏覽器將不在支持。兼容性以下圖：

10. HTTP2.0的前世此生

有了HTTP1.x，那麼HTTP2.0也就瓜熟蒂落的出現了。HTTP2.0能夠說是SPDY的升級版（其實本來也是基於SPDY設計的）。可是，HTTP2.0跟SPDY 仍有不一樣的地方，主要是如下兩點：

1. HTTP2.0消息頭的壓縮算法採用HPACK算法，而非SPDY採用的DEFLATE算法。
2. HTTP2.0設計初期支持明文HTTP傳輸，而SPDY強制使用HTTPS，到後期二者都須要使用HTTPS。

2015年9月，Google 宣佈了計劃，移除對SPDY的支持，擁抱 HTTP2.0，並將在Chrome 51中生效。

11. HTTP2.0新特性

HTTP2.0的特性大部分和SPDY相似，主要有如下4個：

1. 新的二進制格式（Binary Format）： HTTP1.x的解析是基於文本。基於文本協議的格式解析存在自然缺陷，文本的表現形式有多樣性，要作到健壯性考慮的場景必然不少，二進制則不一樣，只認0和1的組合。基於這種考慮HTTP2.0的協議解析決定採用二進制格式，實現方便且健壯。

2. 多路複用（MultiPlexing）： 即鏈接共享，即每個request都是是用做鏈接共享機制的。一個request對應一個id，這樣一個鏈接上能夠有多個request，每一個鏈接的request能夠隨機的混雜在一塊兒，接收方能夠根據request的 id將request再歸屬到各自不一樣的服務端請求裏面。多路複用原理和keep alive區別以下圖：

   

3. header壓縮： 如上文中所言，對前面提到過HTTP1.x的header帶有大量信息，並且每次都要重複發送，HTTP2.0使用encoder來減小須要傳輸的header大小，通信雙方各自cache一份header fields表，既避免了重複header的傳輸，又減少了須要傳輸的大小。

4. 服務端推送（Server Push）： 同SPDY同樣，HTTP2.0也具備Server Push功能。

目前，有大多數網站已經啓用HTTP2.0，例如YouTuBe，淘寶網等網站，利用Chrome控制檯能夠查看是否啓用Server Push，以下圖：

關於HTTP2.0和HTTP1.x中多路複用的區別，能夠形象的用下圖表示：

12. HTTP2.0的升級改造

對比HTTPS的升級改造，HTTP2.0獲取會稍微簡單一些，你可能須要關注如下問題：

1. 前文說了HTTP2.0須要基於HTTPS的，而且如今主流的瀏覽器像Chrome，Firefox表示仍是隻支持基於TLS部署的HTTP2.0協議，因此要想升級成HTTP2.0仍是先升級HTTPS爲好。
2. 當你的網站已經升級HTTPS以後，那麼升級HTTP2.0就簡單不少，你須要作的就是將服務器進行升級，若是你使用Nginx，須要在配置文件中啓動相應的協議就能夠了，能夠參考《NGINX白皮書》，《NGINX配置HTTP2.0官方指南》。
3. 使用了HTTP2.0那麼，本來的HTTP1.x怎麼辦，這個問題其實不用擔憂，HTTP2.0徹底兼容HTTP1.x的語義，對於不支持HTTP2.0的瀏覽器，Nginx會自動向下兼容的。 在Chrome控制檯中的Network面板，能夠看到請求採用的HTTP2.0協議，以下圖：

   

13. HTTP3.0是什麼？

HTTP3.0，也稱做HTTP over QUIC。HTTP3.0的核心是QUIC(讀音quick)協議，由Google在2015年提出的SPDY v3演化而來的新協議，傳統的HTTP協議是基於傳輸層TCP的協議，而QUIC是基於傳輸層UDP上的協議，能夠定義成：HTTP3.0基於UDP的安全可靠的HTTP2.0協議。

QUIC協議針對基於TCP和TLS的HTTP2.0協議解決了下面的問題：

1. 減小了TCP三次握手及TLS握手時間： 無論是HTTP1.0/1.1仍是 HTTPS，HTTP2.0，都使用了TCP進行傳輸。HTTPS和HTTP2還須要使用TLS協議來進行安全傳輸。這就出現了兩個握手延遲，而基於UDP協議的QUIC，由於UDP 自己沒有鏈接的概念，鏈接創建時只須要一次交互，半個握手的時間。區別以下圖：

   

2. 多路複用丟包時的線頭阻塞問題： QUIC保留了HTTP2.0多路複用的特性，可是即便在多路複用過程當中，同一個TCP鏈接上有多個stream，假如其中一個stream丟包，在重傳先後續的stream都會受到影響，而QUIC中一個鏈接上的多個stream之間沒有依賴。因此當發生丟包時，只會影響當前的stream，也就避免了線頭阻塞問題。
3. 優化重傳策略： 以往的TCP丟包重傳策略是：在發送端爲每個封包標記一個編號 (sequence number)，接收端在收到封包時，就會回傳一個帶有對應編號的ACK封包給發送端，告知發送端封包已經確實收到。當發送端在超過必定時間以後尚未收到回傳的 ACK，就會認爲封包已經丟失，啓動從新傳送的機制，複用與原來相同的編號從新發送一次封包，確保在接收端這邊沒有任何封包漏接。 這樣的機制就會帶來一些問題，假設發送端總共對同一個封包發送了兩次 (初始 + 重傳)，使用的都是同一個sequence number：編號N。以後發送端在拿到編號N封包的回傳ACK 時，將沒法判斷這個帶有編號N的ACK，是接收端在收到初始封包後回傳的ACK。這就會加大後續的重傳計算的耗時。QUIC爲了不這個問題，發送端在傳送封包時，初始與重傳的每個封包都改用一個新的編號，unique packet number，每個編號都惟一併且嚴格遞增，這樣每次在收到ACK時，就能夠依據編號明確的判斷這個ACK是來自初始封包或者是重傳封包。
4. 流量控制： 經過流量控制能夠限制客戶端傳輸資料量的大小，有了流量控制後，接收端就能夠只保留相對應大小的接收 buffer，優化記憶體被佔用的空間。可是若是存在一個流量極慢的stream ，光一個stream就有可能佔用掉接收端全部的資源。QUIC爲了不這個潛在的HOL Blocking，採用了連線層 (connection flow control) 和 Stream 層的 (stream flow control) 流量控制，限制單一 Stream 能夠佔用的最大buffer size。
5. 鏈接遷移： TCP鏈接基於四元組（源 IP、源端口、目的 IP、目的端口），切換網絡時至少會有一個因素髮生變化，致使鏈接發生變化。當鏈接發生變化時，若是還使用原來的 TCP 鏈接，則會致使鏈接失敗，就得等原來的鏈接超時後從新創建鏈接，因此咱們有時候發現切換到一個新網絡時，即便新網絡情況良好，但內容仍是須要加載好久。若是實現得好，當檢測到網絡變化時馬上創建新的 TCP 鏈接，即便這樣，創建新的鏈接仍是須要幾百毫秒的時間。 QUIC 的鏈接不受四元組的影響，當這四個元素髮生變化時，原鏈接依然維持。QUIC 鏈接不以四元組做爲標識，而是使用一個 64 位的隨機數，這個隨機數被稱爲 Connection ID，對應每一個stream，即便 IP 或者端口發生變化，只要 Connection ID 沒有變化，那麼鏈接依然能夠維持。

技術老是在不斷髮展，留給咱們每一個開發者就是在學習的道路上不斷的折騰，在HTTP協議發展的20多年來，每次標準的更新都會帶來一大批的服務器和瀏覽器廠商升級以及業務的提高。對於一名合格的開發者而言，只有不斷的摸索和跟進這些新技術，才能作到不被趨勢所淘汰。祝君好運，將來可期。

歡迎關注課程： 《從0到1 實戰朋友圈移動Web App開發》 《移動Web App開發之實戰美團外賣》