#科學燃計劃#

前端圈技術的爆發式增長隨之而來的開發人員學不動的疲憊感、焦慮感和不想跳出舒適圈的拖延懶惰。

jQuery華麗謝幕，React v16已經普及、Angular9和Vue3即將釋出。三大框架越來越貼近WebComponents標準。 TypeScript遍地開花，小程式日益火爆，快應用/PWA緊隨其後……

站在浪潮之巔的我們最需要的是停下來思考，轟轟烈烈的技術本質是什麼？

其實，轟轟烈烈的技術本質，是基礎知識和核心概念。

看你這篇題目的文章，是要講HTTP咯？HTTP那麼簡單，我們大家每天都用，有什麼好講的？

在停下來思考技術本質的同時，我們也要不斷的提高自己的認識層次，你所謂的簡單是因為你沒有聽到“遙遠的哭聲”。

(shout out to 男神黃執中)

有請我們今天的主角登場：HTTP

我將帶你從HTTP的歷史發展到各版本迭代主要特性來從全域性的角度重新認識HTTP。

HTTP的世界觀

先來明確一下時間線，回到30年前的那個春天。

一切的一切都始於1989年的3月，全球資訊網之父蒂姆·伯納斯·李(Tim Berners-Lee)的一篇論文，創造了全球資訊網，創造了HTTP。

1991年HTTP/0.9釋出 （沒有RFC，版本號是後加上去的）1996年5月HTTP/1.0在RFC1945釋出1997年1月HTTP/1.1釋出 RFC2616是當前最新版本2014年HTTP/1.1再次修訂，將大文件拆分為六份較小的文件， RFC7230-72352015年HTTP/2釋出 RFC7540 (基於谷歌的SPDY協議)2018年，網際網路標準化組織IETF提議將HTTP over QUIC更名為HTTP/3

如果希望全面的瞭解HTTP/3，推薦 Daniel Stenberg（CURL 作者）的HTTP/3詳解

縱觀HTTP的歷史發展長河，究其原因，是技術和需求一直在推動著它的發展。

HTTP是什麼？

HTTP是一個在計算機世界裡專門在兩點之間傳輸文字、圖片、音訊、影片等超文字資料的約定和規範。

HTTP通常跑在TCP/IP協議棧之上，依靠IP協議實現定址和路由、TCP協議實現可靠資料傳輸、DNS協議實現域名查詢、SSL/TLS協議實現安全通訊。當然，WebSocket、HTTPDNS依賴於HTTP。

HTTP/0.9

GET/index.html

HTTP/0.9當時是為了學術交流，基於請求和響應的模式，在網路中傳輸HTML超文字的內容。

如上所示，只有一個請求行，沒有HTTP請求頭和請求體。同樣，伺服器也沒有響應頭資訊，只是返回了資料。

因為都是HTML格式的檔案，決定了返回的檔案內容透過ASCII字元流進行傳輸。

HTTP/1.0

1994年底開啟撥號上網，網景也在同年推出了第一款瀏覽器，人們對全球資訊網的需求不再僅侷限於學術交流。

W3C和HTTP工作組HTTP-WG也在這個時代建立。為了滿足人們對瀏覽器的需求(不光是HTML，還有CSS、JS、圖片、音影片等)，檔案格式不再侷限於ASCII編碼。

HTTP/1.0的解決辦法是引入了請求頭和響應頭。

accept: text/htmlaccept-encoding: gzip, deflate, braccept-Charset: ISO-8859-1,utf-8accept-language: zh-CN,zh

同時也引入了狀態碼，為了減輕伺服器的壓力，提供了Cache機制。伺服器需要統計客戶端的基礎資訊(Windows 和 macOS)，加入了使用者代理欄位。

HTTP/1.1改進持久連線

一個TCP連線上可以傳輸多個HTTP請求，只要瀏覽器或者伺服器沒有斷開連線，該TCP會一直保持。

持久連線是預設開啟的，如果想要關閉，在請求頭中加上Connection:close即可關閉。

目前瀏覽器中對於同一個域名，預設允許同時建立6個TCP持久連線。

不成熟的HTTP管線化

HTTP/1.1 中試圖透過管線化的技術來解決隊頭阻塞的問題。但是因為各種原因，被各大廠商放棄治療了。

增加對虛擬主機的支援

HTTP/1.0中每個域名都只繫結唯一的IP地址，因此一個伺服器只能支援一個域名。

但是隨著虛擬主機技術的發展，一臺物理主機上繫結多個虛擬主機的需求大大提升，每個虛擬主機都有自己單獨的域名，這些單獨的域名都公用同一個IP地址。

因此，請求頭中也增加了Host欄位，表示當前的域名地址，伺服器可根據不同的Host值做不同的處理。

增加對動態生產內容的支援

HTTP/1.0需要在響應頭中設定完整的資料大小Content-Length：900，這樣，瀏覽器就可以根據設定的資料大小來接收資料。

由於伺服器端技術發展，頁面都是動態生成的，傳輸資料之前並不知道最終資料大小， 導致瀏覽器不知道何時會接受完所有的檔案資料。

HTTP/1.1透過引入Chunk transfer機制來解決問題，伺服器將資料分割成若干個任意大小的資料塊，每個資料塊傳送時會附上上一個資料塊的長度，最後使用一個長度為0的塊作為傳送資料完成的標誌。

客戶端Cookie、安全機制

HTTP1.1引入了客戶端Cookie機制和安全機制。

HTTP/2HTTP/1.1的缺陷對頻寬的利用率不理想三個問題導致TCP 的慢啟動同時開啟了多條 TCP 連線，那麼這些連線會競爭固定的頻寬HTTP/1.1 隊頭阻塞的問題HTTP/2多路複用

HTTP/2使用多路複用機制解決了上述問題。

一個域名只使用一個 TCP 長連線和消除隊頭阻塞問題。透過引入二進位制分幀層，實現了 HTTP 的多路複用技術。

HTTP/2伺服器推送

伺服器可以提前將資料推送到瀏覽器，瀏覽器有權選擇是否接受。瀏覽器傳送RST_STREAM幀可以選擇拒收。

HTTP/2頭部壓縮

頭部的壓縮大大的提升了傳輸效率。HTTP/2開發了“HPACK”演算法，在客戶端和伺服器建立“字典”，用索引號表示重複的字串，還採用哈夫曼編碼來壓縮整數和字串。

HTTP/2可以設定請求的優先順序

可以設定讓某些重要的資料優先被伺服器處理並返回。

HTTP/3HTTP/2的缺陷TCP的隊頭阻塞

在 TCP 傳輸過程中，由於單個數據包的丟失而造成的阻塞稱為 TCP 上的隊頭阻塞。 HTTP/2只解決了應用層面的隊頭阻塞，隊頭阻塞的問題還存在於TCP協議本身。

TCP建立連線的延時

TCP以及TCP+TLS建立連線的所產生的延時也是影響傳輸效率的一個主要因素。

TCP協議僵化中介軟體僵化

我們把在網際網路的各處搭建的裝置叫做中間裝置(中介軟體)，比如路由器、NAT、防火牆、交換機等，它們通常依賴一些很少升級的軟體，這些軟體使用了大量的 TCP 特性，設定之後便很少進行更新。這就對我們我們更新TCP的時候造成了很大的困難， 新協議的資料包經過這些中介軟體時，它們不會去理解包的內容從而丟棄掉這些資料包。

作業系統

因為 TCP 協議都是透過作業系統核心來實現的，應用程式只能使用不能修改。通常作業系統的更新都滯後於軟體的更新，所以想要更新作業系統核心中的TCP協議也是非常困難的。

QUIC協議

HTTP/3 選擇了一個折衷的方法——UDP 協議，基於 UDP 實現了類似於 TCP 的多路資料流、傳輸可靠性等功能，我們把這套功能稱為QUIC 協議。

實現了類似 TCP 的流量控制、傳輸可靠性的功能集成了 TLS 加密功能實現了 HTTP/2 中的多路複用功能實現了快速握手功能

關於HTTP/3更多詳細的內容，請移步我翻譯成中文版的HTTP/3詳解。

站在巨人的肩膀上：

《瀏覽器工作原理與實踐》

《透視HTTP協議》

《趣談網路協議》

《Web協議詳解與抓包實戰》