關(guān)于 HTTP 后端人員需要了解的 20+ 圖片！
前言
當(dāng)您網(wǎng)上沖浪時，HTTP 協(xié)議無處不在。當(dāng)您瀏覽網(wǎng)頁、獲取一張圖片、一段視頻時，HTTP 協(xié)議就正在發(fā)生。
本篇將盡可能用簡短的例子和必要的說明來讓您了解基礎(chǔ)的 HTTP 知識。
目錄：
什么是 HTTP？ HTTP 簡史； HTTP 與 HTTPS；
Part 1. 什么是 HTTP？
互聯(lián)網(wǎng)是有關(guān) web 客戶端和 web 服務(wù)器之間的通信。
HTTP（HyperText Transfer Protocol）又叫超文本傳輸協(xié)議。本質(zhì)上就是一個協(xié)定好雙方如何進行交流溝通的約定。
這就好比我在一起玩游戲的朋友群里發(fā)送一條 「1？」 的消息，朋友們就立即知道是在詢問今晚是不是要一起游戲的意思。
但是如果我給其他人發(fā)送 「1？」 就可能出現(xiàn)問題：他們不知道我在說什么。
本質(zhì)上，這就是 HTTP 協(xié)議所代表的含義。我們已經(jīng)同意，如果我們以特定的方式發(fā)送消息，則服務(wù)器就會理解消息的意圖并作出回應(yīng)。
Part 2. HTTP 簡史
1989 年 3 月，互聯(lián)網(wǎng)還只屬于少數(shù)人。在這一互聯(lián)網(wǎng)的黎明期，HTTP 誕生了。
HTTP / 0.9 - 單行協(xié)議
1989年，當(dāng)時還在歐洲核子研究組織（CERN）工作的蒂姆·伯納斯·李（Tim Berners-Lee）提出了一種能讓遠隔兩地的研究者們共享知識的設(shè)想。
最開始稱為 Mesh，后來在 1990 年實施期間將其重命名為 World Wide Web（萬維網(wǎng)）。它基于現(xiàn)有的 TCP/IP 協(xié)議構(gòu)建，包括 4 個部分：
一種表示超文本文檔的文本格式，即超文本標記語言（HTML）； 一種用于交換這些文檔的簡單協(xié)議，即 HyperText 傳輸協(xié)議（HTTP）； 一個客戶端可以顯示這些文檔，第一個 Web 瀏覽器稱為 WorldWideWeb。 一個可以訪問文檔的服務(wù)器；
這四部分在 1990 年底完成。雖然此時 Web 頁面只能顯示單純的文本內(nèi)容，瀏覽器也只能顯示呆板的文字信息，不過這已經(jīng)基本滿足了建立 Web 站點的初衷，實現(xiàn)了信息資源共享。
以下就是 HTTP/0.9 的請求內(nèi)容：
GET /page.html
用唯一可用的 GET 方法向目標服務(wù)器獲取指定的文檔。（一旦連接到服務(wù)器，協(xié)議、服務(wù)器、端口號這些都不是必須的）
響應(yīng)也極其簡單：只包含文檔本身。
<HTML>
網(wǎng)頁的內(nèi)容
</HTML>
這意味著 HTTP/0.9 只能夠傳輸 HTML 文件。一旦出現(xiàn)問題，一個特殊的包含問題描述信息的 HTML 文件將被發(fā)回，供人們查看。
HTTP/1.0 - 構(gòu)建可擴展性
由于 HTTP/0.9 協(xié)議的應(yīng)用十分有限，加之 HTTP 使用量和 HTML 的高速發(fā)展，瀏覽器和服務(wù)器迅速擴展其內(nèi)容使其用途更廣：
協(xié)議版本信息會隨著每一次請求發(fā)送；
----------HTTP/0.9請求----------
GET /page.html
----------HTTP/1.0請求----------
GET /page.html HTTP/1.0 -> 新增協(xié)議版本
服務(wù)器在響應(yīng)時回復(fù)狀態(tài)碼，使瀏覽器能了解請求執(zhí)行成功或失敗，并相應(yīng)調(diào)整行為（如更新或失?。?；
----------HTTP/0.9響應(yīng)----------
<HTML>
....
</HTML>
----------HTTP/1.0響應(yīng)----------
200 OK -> 新增狀態(tài)碼
<HTML>
....
</HTML>
引入了 HTTP 頭的概念，無論是請求還是響應(yīng)，允許傳輸其他信息，使協(xié)議更靈活以及更具擴展性；
在 HTTP 頭的幫助下，具備了除傳輸純文本的 HTML 文件以外，還可以傳輸其他類型文檔的能力（歸功于 Content-Type頭）；
HTTP/0.9 規(guī)范大約只有一頁，而 HTTP/1.0 在 RFC-1945 中定義的規(guī)范則足足有 60 頁。這說明 HTTP 已經(jīng)成長為一個重要的工具。
盡管 HTTP/1.0 從 HTTP/0.9 有了很大的飛躍，但仍然存在許多必須解決的已知缺陷。例如與 TCP 協(xié)議交互不良、沒有充分考慮緩存等問題。
拿與 TCP 協(xié)議交互不良舉例。由于 HTTP 是基于 TCP 建立的，所以通訊之前需要建立連接，通訊結(jié)束之后需要斷開連接。
HTTP/1.0 每一次的通訊都需要建立并斷開連接，這無疑增加了無謂的通信開銷。
HTTP/1.1 - 標準化的協(xié)議
文檔 RFC 1945 定義了 HTTP/1.0，但它是狹義的，并不是官方標準。所以實際運用起來非常地混亂。所以實際上自 1995 年開始，即 HTTP/1.0 文檔發(fā)布的下一年，就開始修訂 HTTP 的第一個標準化版本。
HTTP/1.1 在 1997 年 1 月以 RFC 2068 文件發(fā)布。HTTP/1.1 消除了大量歧義內(nèi)容并引入了多項改進：
連接可以復(fù)用，節(jié)省了多次打開 TCP 連接加載網(wǎng)頁文檔資源的時間；
增加管線化技術(shù)，允許在第一個應(yīng)答被完全發(fā)送之前就發(fā)送第二個請求，以降低通信延遲；
支持響應(yīng)分塊；
引入額外的緩存控制機制，在 HTTP
Cache-Control標頭中引入了很多可以選擇的選項；引入內(nèi)容協(xié)商機制，包括語言，編碼，類型等，并允許客戶端和服務(wù)器之間約定以最合適的內(nèi)容進行交換；
能夠使不同域名配置在同一個 IP 地址的服務(wù)器上。
一個典型的請求流程， 所有請求都通過一個連接實現(xiàn)，看起來就像這樣：
超過 15 年的擴展
由于 HTTP 的可擴展性——創(chuàng)建新的頭部和方法是很容易的——HTTP 協(xié)議穩(wěn)定使用了超過 15 年。期間不斷對 HTTP/1.1 協(xié)議進行修訂（RFC 2616、RFC 7230、RFC 7235），為 HTTP/2.0 作了十足的鋪墊。
HTTP/2.0 - 為更優(yōu)異的表現(xiàn)
這些年來，網(wǎng)頁愈漸變得復(fù)雜，甚至演變成了獨有的應(yīng)用，可見媒體的播放量，增進交互的腳本大小也增加了許多：更多的數(shù)據(jù)通過 HTTP 請求被傳輸。
在 2010 年到 2015 年，谷歌通過實踐證明了實驗性的 SPDY 協(xié)議的可行性，這成為了后來 HTTP/2 協(xié)議的基礎(chǔ)。
HTTP/2 在 HTTP/1.1 有幾處基本的不同：
HTTP/2 是二進制協(xié)議而不是文本協(xié)議，不再可讀。頭信息和數(shù)據(jù)體都是二進制（體積更?。⑶医y(tǒng)稱為幀(frame)。
這是一個復(fù)用協(xié)議，可以多路復(fù)用。并行的請求能在同一個鏈接中處理，移除了 HTTP/1.x 中順序和阻塞的約束;
*注：這里 HTTP/2 并不是合并成一個包，而是分成多個 Stream 發(fā)送，這里只是為了繪畫方便。
大家可以通過點擊這里直觀感受到 HTTP/2 比 HTTP/1.1 快了多少。
壓縮了 Headers。因為 Headers 在一系列請求中常常是相似的，其移除了重復(fù)和傳輸重復(fù)數(shù)據(jù)的成本。實現(xiàn)這一功能的算法被稱為 HPACK 算法;
其允許服務(wù)器在客戶端緩存中填充數(shù)據(jù)，通過一個叫服務(wù)器推送的機制來提前請求；
詳細的 HTTP/2 優(yōu)秀的地方可以參看下 4 鏈接
在 2015 年 5 月正式標準化后，HTTP/2 取得了極大的成功，在 2016 年 7 月前，8.7% 的站點已經(jīng)在使用它。高流量的站點最迅速普及，在數(shù)據(jù)傳輸上節(jié)省了可觀的成本和支出。
這種迅速的普及率很可能是因為 HTTP2 不需要站點和應(yīng)用做出改變：使用 HTTP/1.1 和 HTTP/2 對他們來說是透明的。
擁有一個最新的服務(wù)器和新點的瀏覽器進行交互就足夠了。只有一小部分群體需要做出改變，而且隨著陳舊的瀏覽器和服務(wù)器的更新，而不需 Web 開發(fā)者做什么，用的人自然就增加了。
后 HTTP/2 進化
隨著 HTTP/2 的發(fā)布，就像先前的 HTTP/1.x 一樣，HTTP 沒有停止進化。HTTP 的擴展性依然被用來添加新的功能。
HTTP 的進化證實了它良好的擴展性和簡易性，釋放了很多應(yīng)用程序的創(chuàng)造力并且情愿使用這個協(xié)議。
HTTP/3 - 更好的未來
HTTP/3 是即將到來的第三個主要版本的 HTTP 協(xié)議。與前任協(xié)議不同，在 HTTP/3 中，將棄用 TCP 協(xié)議，改為使用 UDP 協(xié)議和 QUIC 協(xié)議實現(xiàn)。
此變化主要為了解決 HTTP/2 中存在的隊頭阻塞問題。由于 HTTP/2 在單個 TCP 連接上使用了多路復(fù)用，受到 TCP 擁塞控制的影響，少量的丟包就可能導(dǎo)致整個 TCP 連接上的所有流被阻塞。
截至 2021 年 1 月，HTTP/3 仍然是草案狀態(tài)。
小結(jié)
HTTP/0.9 只能傳輸單一的 HTML 純文本，不夠靈活； HTTP/1.x 有連接無法復(fù)用、隊頭阻塞、協(xié)議開銷大和安全因素等多個缺陷； HTTP/2 通過多路復(fù)用、二進制流、Header 壓縮等等技術(shù)，極大地提高了性能，但是還是存在著問題的； QUIC 基于 UDP 實現(xiàn)，是 HTTP/3 中的底層支撐協(xié)議，該協(xié)議基于 UDP，又取了 TCP 中的精華，實現(xiàn)了即快又可靠的協(xié)議；
Part 3. HTTP 與 HTTPS
為什么需要 HTTPS
HTTP 協(xié)議在設(shè)計之初就沒有充分考慮安全性的問題。所以基于 HTTP 的這些應(yīng)用都承擔(dān)著如下的幾個風(fēng)險：
使用明文（不加密）進行通信，內(nèi)容可能會被竊聽； 不驗證通信方的身份，通信方的身份有可能是偽裝的； 無法驗證信息的完整性，也就是說信息可能是被篡改過的；
HTTPS（HTTP over SSL）采取嵌套新一層安全套接字層（Secure Socket Layer,SSL）來解決網(wǎng)絡(luò)傳輸?shù)陌踩詥栴}。
如何防止被竊聽？
加密是很容易聯(lián)想到的解決方法。但如何保證傳輸加密方法的過程不被竊聽呢？
這時候非對稱加密的出現(xiàn)解決了這一大難題。它把密碼革命性地分成公鑰和私鑰，由于兩個秘鑰并不相同，所以稱為非對稱加密。
舉個例子，假設(shè)我們現(xiàn)在需要加密的字符是 520，我們加密的方法是把這個數(shù)乘以 91，并把結(jié)果的最后三位公布出來：
注：這里的 91 相當(dāng)于公鑰，任何人都可以知道。
解密我們當(dāng)然不能通過除以 91 來完成，而是通過 x11，取出結(jié)果后三位來還原：
注：這里的 x11 相當(dāng)于私鑰，只有解密方才知道。
這是因為 91*11=1001，任何一個三位數(shù)乘以 1001 顯然后三位是不會變的。這大概就是非對稱加密的原理了，基于這個原理我們通信的雙方就可以各自生成自己的公鑰私鑰并進行相對安全的通信了。
如何驗證對方身份？
上面的過程看似無懈可擊，但在 TCP/IP 的端到端的通信里，路途遙遠，夜長夢多。
如果在第二步的時候，信息被黑客截取，在嚴刑拷打之下知道了這是傳輸公鑰的信息。那么完全可以自己生成一對密鑰和公鑰，冒充是彼此來傳輸自己的秘鑰。
加密危機之后，又產(chǎn)生了信任危機。我們需要一個有公信力的組織來證明身份，這個問題就得到了解決。
這個可信的組織就是頒發(fā) HTTPS 證書的組織 CA（Certificate Authority）。每次有客戶端或者服務(wù)端想要公開自己的公鑰時，都需要向 CA 做出申請，通過后 CA 會頒發(fā)一個與公開公鑰綁定的數(shù)字證書。(了解更多證書)
進行 HTTPS 通信時，服務(wù)器會把證書發(fā)送給客戶端，客戶端取得其中的公開密鑰之后，先進行驗證，如果驗證通過，就可以開始通信。
如何防止被篡改？
在之前介紹比特幣原理的時候，我們提到過一種哈希算法。它的作用是能把任意長度的輸入編程固定長度的二進制輸出。
注：為了簡化右邊為 16 進制數(shù)
在 HTTPS 中，有一種新的摘要算法，可以簡單理解為是對于內(nèi)容的一種壓縮。所以但凡內(nèi)容變化一丁點，哪怕是一個標點符號，壓縮之后的數(shù)字哈希也不對。
客戶端在發(fā)送明文之前會通過摘要算法算出明文的 「指紋」，發(fā)送的時候把 「指紋 + 明文」 一同加密成密文后，發(fā)送給服務(wù)器。
服務(wù)器解密后，用相同的摘要算法算出發(fā)送過來的明文，通過比較客戶端攜帶的 「指紋」 和當(dāng)前算出的 「指紋」 做比較，若 「指紋」 相同，說明數(shù)據(jù)是完整的。
HTTP 與 HTTPS 有什么不同？
盡管聽上去 HTTPS 就是更安全的 HTTP，但也有許多細節(jié)方面的不同：
HTTP 明文傳輸，存在安全風(fēng)險的問題。HTTPS 則解決 HTTP 不安全的缺陷，在 TCP 和 HTTP 網(wǎng)絡(luò)層之間加入了 SSL/TLS 安全協(xié)議，使得報文能夠加密傳輸； HTTP 連接建立相對簡單， TCP 三次握手之后便可進行 HTTP 的報文傳輸。而 HTTPS 在 TCP 三次握手之后，還需進行 SSL/TLS 的握手過程，才可進入加密報文傳輸; HTTP 的端口號是 80，HTTPS 的端口號是 443; HTTPS 協(xié)議需要向 CA（證書權(quán)威機構(gòu)）申請數(shù)字證書，來保證服務(wù)器的身份是可信的;
后記
HTTP 協(xié)議是紛繁復(fù)雜的網(wǎng)絡(luò)世界的基礎(chǔ)，它保證了各個應(yīng)用之間的"交流無阻礙"。本篇也盡可能使用動圖的形式清晰地表達，希望大家能用餐愉快。
至此，我們對 HTTP 協(xié)議已經(jīng)有了相當(dāng)?shù)牧私饬恕：罄m(xù)也會繼續(xù)跟大家一起學(xué)習(xí)計算機網(wǎng)絡(luò)的基礎(chǔ)知識，也會嘗試著跟著后端學(xué)習(xí)路線圖的腳步跟著大家一起學(xué)習(xí)進階。
參考資料
How HTTP Works and Why it's Important – Explained in Plain English - https://www.freecodecamp.org/news/how-the-internet-works/ Evolution of HTTP - https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP The Evolution of HTTP - https://www.oreilly.com/library/view/learning-http2/9781491962435/ch01.html xxxxHub 都用上了 HTTP/2 ，它牛逼在哪？| 小林Coding - https://mp.weixin.qq.com/s/TvGAmKKrKrcWlsV2cfC34g 一文讀懂 HTTP/2 及 HTTP/3 特性 - https://blog.fundebug.com/2019/03/07/understand-http2-and-http3/
（完）
- End -
Hi，這里是 我沒有三顆心臟，2021，與您在 Be Better 的路上共同成長！