網絡優化系列專題，聊一聊面對復雜多變的移動網絡，我們需要掌握哪些網絡基礎知識，以及該如何做好網絡優化這項工作。
網絡優化系列專題
- 網絡優化背景知識（待完善）
《關于 5G，你應該知道的發展史》
《HTTP 發展的前世今生》
《網絡安全 — HTTPS》
《關于網絡優化，你需要了解什么？》
《HTTP 的第一次變革 — HTTP/2》
《展望更好 — HTTP/3》
-
如何優化網絡性能（待更）
...
如今，打開手機或電腦，只要你上網，不論是選擇哪個操作系統，不論是用瀏覽器還是 App，不論是看新聞、短視頻還是聽音樂...，總會有 HTTP 在后臺默默為你服務。
在享受如此便捷舒適的網絡生活時，你是否有想過，HTTP 協議是怎么來的？它最開始是什么樣子的？又是如何發展到今天，幾乎“統治”整個互聯網世界的呢？
今天我們就來聊一聊 HTTP 的發展歷程，了解下它的成長軌跡。
誕生
1989 年 3 月 12 日，任職于 CERN（歐洲核子研究中心）的 Tim Berners-Lee（蒂姆.伯納斯 - 李）提交了一篇名為《Information Management : a proposal》（關于信息化管理的建議）文章，提出了在互聯網上構建超鏈接文檔系統的構想，初步闡述了后來被稱為 World Wide Web（萬維網） 的信息管理概念，該篇文章中他確立了三項關鍵技術：
URI（Uniform Resource Identifier）：即統一資源標識符，作為互聯網上資源的唯一身份；
HTML（Hypertext Markup Language）：超文本標記語言，描述超文本文檔；
HTTP（Hypertext Transfer Protocol）：即超文本傳輸協議，用來傳輸超文本。
基于它們，就可以把超文本系統完美地運行在互聯網上，讓各地的人們能夠自由地共享信息，這也是我們現在所熟知的 Web。
所以在這一年，HTTP 誕生了，從此開始了它的光輝之路。由于該篇文章，1989 年也被認為是蒂姆.博納斯 - 李發明 World Wide Web 的年份。
HTTP/0.9
20 世紀 90 年代初期的互聯網世界非常簡陋，計算機處理能力弱，存儲容量小，網速很慢，還是一片“信息荒漠”。網絡上絕大多數的資源都是純文本，很多通信協議也都使用純文本，所以 HTTP 的設計也不可避免地受到了時代的限制。
這一時期的 HTTP 被定為 0.9 版本，結構比較簡單，為了便于服務器和客戶端處理，它也采用純文本格式。蒂姆.博納斯 - 李最初設想系統里的文檔都是只讀的，所以只允許用 “GET” 操作從服務器上獲取 HTML 文檔，并且在響應請求之后立即關閉連接，功能非常有限。
HTTP/0.9 雖然很簡單，但它作為一個“原型”，充分驗證了 Web 服務的可行性，而“簡單”也正式它的優點，因為這蘊含了后來進化和擴展的可能性：把簡單的系統變復雜，要比把復雜的系統變簡單容易得多。
第一個網站
1990 年 12 月 20 日，蒂姆.博納斯 - 李架設了人類歷史上第一個網站，域名為 Info.cern.ch，它被用于 CERN 內部；所使用的服務器則是他的個人 NeXT 電腦，直到今天，這臺 NeXT 電腦依然被作為人類首個網站的服務器，當然這個網站也被 CERN 保留了下來。
1991 年 8 月 6 日，蒂姆.博納斯 - 李又將與 World Wide Web 項目相關的總結文檔上傳至互聯網，這是第一個出現在互聯網上的 Web 網站，距離現在已經整整 28 周年了。
HTTP / 1.0
但是在當時，World Wide Web 并沒有迅速獲得世人的認可。盡管博納斯·李堅信自己的發明將會“統治世界”，但是到了 1992 年，他的論文還是被“超文本會議”拒絕了。
而這時，正在美國伊利諾大學 NCSA（美國國家超級計算應用中心） 學習（兼職）的馬克.安德森出現了，年僅 22 歲的他已經對互聯網頗為熟悉了；他覺得在 World Wide Web 加上圖形更有意思，就與人合作開發出第一個可以圖文混排的瀏覽器 Mosaic。該瀏覽器一經發布就受到了熱烈歡迎。但由于 Mosaic 是由大學的資金和設備開發的，所以它的所有權歸 NCSA 所有。
注意，Mosaic 并不是第一個圖形接口瀏覽器，比它更早的例如由蒂姆.博納斯 - 李本人開發的 WorldWideWeb（世界上第一個網頁瀏覽器，后更名為 Nexus）、鮮為人知的 Erwise 和 ViolaWWW。但是 Mosaic 卻是第一個可以在文字中嵌入圖片，而不是在單獨窗口中顯示圖片的瀏覽器。
同一時期，計算機多媒體技術也有了新的發展，1992 年 JPEG（聯合圖像專家小組） 圖像格式誕生，1995 年發明了 MP3（動態影像專家壓縮標準音頻層面3）音樂格式。
這些新軟件，新技術一經推出立刻就吸引了廣大網民的熱情，更多的人開始認識互聯網，開始使用互聯網，研究 HTTP 并提出改進意見，甚至實驗性地往協議里添加各種新特性，從用戶需求的角度促進了 HTTP 的發展。
于是在這些已有實踐的基礎上，經過一系列的草案，HTTP/1.0 版本在 1996 年正式發布，它在多方面增強了 0.9 版本，形式上已經和我們現在的 HTTP 差別不大了，例如：
- 增加了 HEAD、POST 等新方法；
- 增加了響應狀態碼，標記可能的錯誤原因；
- 引入協議版本號概念；
- 引入了 HTTP Header 的概念，讓 HTTP 處理請求和響應更加靈活；
- 傳輸數據不在僅限于文本。
但是 HTTP/1.0 并不是一個標準，只是記錄已有實踐和模式的一份參考文檔，不具有實際的約束力，就有點類似于備忘錄。
所以 HTTP 1.0 的發布，對于當時正在蓬勃發展的互聯網來說，并沒有太多的實際意義，各方“勢力”仍然按照自己的意圖繼續在市場上奮力“拼殺”。
HTTP / 1.1
前面我們有提到，第一個圖文混排的瀏覽器 Mosaic 由馬克.安德森與他人合作開發，但是它的所有權歸 NCSA 所有，而 NCSA 最后決定將 Mosaic 交給了 Spyglass （實際是 NCSA 的一個分支，旨在將 NCSA 技術商業化）用于商業用途和運營。
于是，1994 年馬克.安德森離開 NCSA，與人合作創辦了 Netscape，也就是網景公司（最初叫做 Mosaic 公司，為了規避與 NCSA 的法律糾葛，同年 11 月公司最終變更為 Netscape），專門用來開發用于商業運作的圖形瀏覽器，公司的產品也更名為網景瀏覽器。同年 12 月 15 日網景瀏覽器 1.0 正式發布，軟件改名為 NetScape Navigator（網景導航者）。
網景瀏覽器是第一個大獲成功的商業瀏覽器，它將蒂姆.博納斯 - 李發明的 World Wide Web 從實驗室帶到了公眾視野；正如博納斯 - 李預言的那樣，World Wide Web 開始了“統治世界”的進程。
隨著網景公司的日益強大，公司開始嘗試創做一種能夠讓用戶通過瀏覽器操作的網絡應用系統。這讓微軟感受到了威脅，擔心網景可能威脅到微軟的操作系統和應用程序市場。于是微軟于 1995 年研發了自己的 Internet Explorer，這一年開始了著名的瀏覽器大戰，網景的 NetScape Navigator 和微軟的 Internet Explorer 都希望在互聯網上占據主導地位。
雖然這場“戰爭”的結果你一定早就知道了，最終微軟的 IE 取得了決定性的勝利，而網景則“敗走麥城”（最后憑借 Mozilla Firefox 又扳回一局）。
具有諷刺意味的是，Internet Explorer 正是在馬克.安德森開發的 Mosaic 的基礎上發展而來的。當然，微軟獲得了伊利諾大學的許可。
不可否認，“瀏覽器大戰”再一次極大地推動了 Web 的發展，HTTP/1.0 也在這個過程中經受了實踐的檢驗。于是在 “大戰” 結束之后的 1999 年，HTTP/1.1 發布了 RFC（Request for Comments）文檔，編號為 2616，正式確立了延續十余年的傳奇。
從版本號我們就可以看出，HTTP/1.1 是對 HTTP/1.0 的小幅度修正。但一個重要的區別是：它是一個正式的標準，而不是一份可有可無的參考文檔。這意味著今后互聯網上所有的瀏覽器、服務器、網關和代理等等，只要用到 HTTP 協議，就必須嚴格遵守這個標準，相當于是互聯網世界的一個“立法”。
不過，說 HTTP/1.1 是小幅度“修正”也不太確切，它還是有很多實質性進步的。畢竟經過了多年的實戰檢驗，比起 0.9 和 1.0 更加接近用戶, 同時表述也更加嚴謹。HTTP/1.1 主要的變更有以下：
- 增加了 PUT、DELETE 等新方法；
- 增加了緩存管理和控制；
- 明確了連接管理，允許持久連接；
- 允許響應數據分塊（chunked），利于傳輸大文件；
- 強制要求 Host 頭，讓互聯網主機通關成為可能。
由此，互聯網在它的“保駕護航”下邁開了新的步伐，開啟了后續的 Web 1.0，Web 2.0 時代。現在許多知名企業都是在這個時間點左右創立的，例如 Google、新浪、搜狐、網易、騰訊等。
- 不過由于 HTTP/1.1 太過龐大和復雜，所以在 2014 年又做了一次修訂，原來一個大文檔被拆分成了六份較小的文檔，編號為 7230 ~ 7235，優化了一些細節，但此外沒有任何實質性的改動。
Google 開始領航
HTTP/1.1 發布之后，整個互聯網世界呈現出了爆發式的增長，度過了十多年的“快樂時光”，更涌現了 Facebook、Twitter、淘寶和京東等互聯網新貴。
然而，這期間也出現了一些對 HTTP 不滿的意見，主要是連接慢，無法跟上迅猛發展的互聯網，但 HTTP/1.1 標準一直“巋然不動”，無奈之下人們只好發明各式各樣的“小花招”來緩解這些問題，比如以前常見的切圖、JS 合并等網頁優化手段。
HTTP/2.0
終于有一天，搜索巨頭 Google 忍不住了，決定“揭竿起義”，那么它是怎么開始“造反”的呢？
Google 首先開發了自己的 Chrome 瀏覽器，然后推出了新的 SPDY 協議，并在 Chrome 里應用于自家的服務器，如同十多年前的網景和微軟一樣，從實際的用戶來“倒逼” HTTP 協議的變革，這也開啟了第二次“瀏覽器大戰”。
歷史再次重演，不過這次的勝利者是 Google，Chrome 目前在全球的占有率超過了 60%，“挾用戶以號令天下”，Google 借此順勢把 SPDY 推上了標準的寶座，互聯網標準化組織以 SPDY 為基礎開始制定新版本的 HTTP 協議，最終在 2015 年發布了 HTTP/2.0 RFC 編號 7540。
- SPDY 并不是首字母縮略字，僅僅是 speedy 的縮寫。Google 最早是在 Chromium 中提出 SPDY 協議，HTTP/2 的關鍵功能主要來自 SPDY 技術，換言之，SPDY 的成果被采納而最終演變為 HTTP/2。SPDY 協議通過壓縮、多路復用和優先級來縮短加載時間。
HTTP/2 的制定充分考慮了互聯網的現狀：帶寬、移動和不安全，在高度兼容 HTTP/1.1 的同時更注重性能方面的改進，主要的特點有：
- 二進制協議，不再是純文本；
- 可發起多個請求（多路復用），廢棄了 1.1 里的通道；
- 使用專用算法壓縮頭部，減少數據傳輸量；
- 允許服務器主動向客戶端推送數據；
- 增強了安全性，要求加密通信。
連接復用
網絡連接這個環節需要經過 TCP 三次握手、TLS 秘鑰協商，連接建立的代價是非常大的，這里優化思路是復用連接，這樣不用每次請求都重新建立連接。這里我們利用的是 HTTP 協議里的 keep-alive。而 HTTP/2.0 的多路復用則可以進一步的提升連接復用率。它復用的這條連接支持同時處理多條請求，所有請求都可以并發在這條連接上進行。
HTTP/3
HTTP/2 這么好，是不是已經完美了呢？答案是否定的，H2 的多路復用在本質上依然是同一條 TCP 連接，如果所有域名的請求都集中在某一條連接上，在網絡擁塞的時候容易出現 TCP 隊首阻塞的問題。
這一次還是 Google，而且它要“革自己的命”。在 HTTP/2 還處于草案之時，Google 又發明了一個新的協議 — QUIC（Quick UDP Internet Connection），而且還是相同的“套路”，繼續在 Chrome 和自家服務器里“試驗著玩”，依托它的龐大用戶量和數據量，持續地推動 QUIC 協議成為互聯網上的“既成事實”。
在連接復用中我們說過 HTTP/2 + TCP 會存在隊首阻塞的問題，基于 UDP 的 QUIC 才是終極解決方案。 QUIC 也確實因為自身素質過硬，在 2018 年，互聯網標準化組織 IETF 提議將 “HTTP over QUIC” 更名為 HTTP/3 并獲得成功，HTTP/3 正式進入了標準化制定階段，也許幾年以后就會正式發布，到時候我們說不定可以直接跳過 HTTP/2 直接進入 HTTP/3。
如下圖所示，可以把 QUIC 簡單理解為 HTTP/2.0 + TLS 1.3 + UDP。
目前 QUIC 還有很多坑還沒有踩完，發現的主要問題例如有創建連接成功率和運營商劫持等。
小結
2019 年 3 月 12 日，是 World Wide Web 誕生 30 周年的紀念日，當然也是 HTTP 協議的整個發展過程，這里再簡單總結下：
1. HTTP 協議始于三十年前蒂姆.博納斯 - 李的一篇論文；
2. HTTP/0.9 是個簡單的文本協議，只能獲取文本資源；
3. HTTP/1.0 確立了大部分現在使用的技術，但它不是正式標準；
4. HTTP/1.1 是目前互聯網上使用最廣泛的協議，功能也非常完善；
5. HTTP/2.0 基于 Google 的 SPDY 協議，注重性能改善，改善的目標是低延遲，但其普及率并不高。
6. HTTP/3 基于 Google 的 QUIC 協議，目前正在制定中，將是未來發展的方向。
最后
通過今天的介紹，相信你對 HTTP 有了一個初步但清晰的認識。另外大家對 HTTP 的發展還有哪些理解和認識？歡迎大家留言分享或指正。
文章如果對你有幫助，請留個贊吧。
彩蛋
早期的 HTTP/0.9 是沒有版本號的，0.9 這個版本號是后來才加上去的，用于區別之后的 1.0/1.1；
HTTP/1.0 的 RFC 編號是 1945，而 HTTP/0.9 則沒有 RFC；
一個有趣的事實：“World Wide Web” 是英語中極少數縮寫（WWW）比原文發音更長的詞。
擴展閱讀
UI 優化系列
- 關于 UI 渲染，你需要了解什么？
- Android 之如何優化 UI 渲染（上）
- Android 之如何優化 UI 渲染（下）
- Android 之 Choreographer 詳細分析
- LayoutAnimation 炫酷的布局動畫及原理分析
- Android 之你真的了解 View.post() 原理嗎？
存儲優化系列
