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