http基礎課（36張圖學HTTP穩了呀）

2023-09-11 12:19:17 1

當您網上衝浪時，HTTP 協議無處不在。當您瀏覽網頁、獲取一張圖片、一段視頻時，HTTP 協議就正在發生。

本篇將儘可能用簡短的例子和必要的說明來讓您了解基礎的 HTTP 知識。

目錄：

網際網路是有關 web 客戶端和 web 伺服器之間的通信。

HTTP（HyperText Transfer Protocol）又叫超文本傳輸協議。本質上就是一個協定好雙方如何進行交流溝通的約定。

這就好比我在一起玩遊戲的朋友群裡發送一條 「1？」 的消息，朋友們就立即知道是在詢問今晚是不是要一起遊戲的意思。

但是如果我給其他人發送 「1？」 就可能出現問題：他們不知道我在說什麼。

調皮地給我媽發了一下試試...

本質上，這就是 HTTP 協議所代表的含義。我們已經同意，如果我們以特定的方式發送消息，則伺服器就會理解消息的意圖並作出回應。

1989 年 3 月，網際網路還只屬於少數人。在這一網際網路的黎明期，HTTP 誕生了。

來源：《圖解HTTP》

1989年，當時還在歐洲核子研究組織（CERN）工作的蒂姆·伯納斯·李（Tim Berners-Lee）提出了一種能讓遠隔兩地的研究者們共享知識的設想。

蒂姆·伯納斯·李 來源：wiki

最開始稱為 Mesh，後來在 1990 年實施期間將其重命名為 World Wide Web（全球資訊網）。它基於現有的 TCP/IP 協議構建，包括 4 個部分：

這四部分在 1990 年底完成。雖然此時 Web 頁面只能顯示單純的文本內容，瀏覽器也只能顯示呆板的文字信息，不過這已經基本滿足了建立 Web 站點的初衷，實現了信息資源共享。

1991 年創建的第一個網頁

以下就是 HTTP/0.9 的請求內容：

GET /page.html

用唯一可用的 GET 方法向目標伺服器獲取指定的文檔。（一旦連接到伺服器，協議、伺服器、埠號這些都不是必須的）

響應也極其簡單：只包含文檔本身。

網頁的內容

這意味著 HTTP/0.9 只能夠傳輸 HTML 文件。一旦出現問題，一個特殊的包含問題描述信息的 HTML 文件將被發回，供人們查看。

由於 HTTP/0.9 協議的應用十分有限，加之 HTTP 使用量和 HTML 的高速發展，瀏覽器和伺服器迅速擴展其內容使其用途更廣：

----------HTTP/0.9請求----------GET /page.html----------HTTP/1.0請求----------GET /page.html HTTP/1.0 -> 新增協議版本

----------HTTP/0.9響應----------....----------HTTP/1.0響應----------200 OK -> 新增狀態碼....

HTTP/0.9 規範大約只有一頁，而 HTTP/1.0 在 RFC-1945 中定義的規範則足足有 60 頁。這說明 HTTP 已經成長為一個重要的工具。

儘管 HTTP/1.0 從 HTTP/0.9 有了很大的飛躍，但仍然存在許多必須解決的已知缺陷。例如與 TCP 協議交互不良、沒有充分考慮緩存等問題。

拿與 TCP 協議交互不良舉例。由於 HTTP 是基於 TCP 建立的，所以通訊之前需要建立連接，通訊結束之後需要斷開連接。

HTTP/1.0 每一次的通訊都需要建立並斷開連接，這無疑增加了無謂的通信開銷。

文檔 RFC 1945 定義了 HTTP/1.0，但它是狹義的，並不是官方標準。所以實際運用起來非常地混亂。所以實際上自 1995 年開始，即 HTTP/1.0 文檔發布的下一年，就開始修訂 HTTP 的第一個標準化版本。

HTTP/1.1 在 1997 年 1 月以 RFC 2068 文件發布。HTTP/1.1 消除了大量歧義內容並引入了多項改進：

一個典型的請求流程， 所有請求都通過一個連接實現，看起來就像這樣：

由於 HTTP 的可擴展性——創建新的頭部和方法是很容易的——HTTP 協議穩定使用了超過 15 年。期間不斷對 HTTP/1.1 協議進行修訂（RFC 2616、RFC 7230、RFC 7235），為 HTTP/2.0 作了十足的鋪墊。

這些年來，網頁愈漸變得複雜，甚至演變成了獨有的應用，可見媒體的播放量，增進交互的腳本大小也增加了許多：更多的數據通過 HTTP 請求被傳輸。

在 2010 年到 2015 年，谷歌通過實踐證明了實驗性的 SPDY 協議的可行性，這成為了後來 HTTP/2 協議的基礎。

來源：HTTPS://www.keycdn.com/support/spdy-protocol

HTTP/2 在 HTTP/1.1 有幾處基本的不同：

*註：這裡 HTTP/2 並不是合併成一個包，而是分成多個 Stream 發送，這裡只是為了繪畫方便。

大家可以通過點擊這裡直觀感受到 HTTP/2 比 HTTP/1.1 快了多少。

詳細的 HTTP/2 優秀的地方可以參看下 4 連結

在 2015 年 5 月正式標準化後，HTTP/2 取得了極大的成功，在 2016 年 7 月前，8.7% 的站點已經在使用它。高流量的站點最迅速普及，在數據傳輸上節省了可觀的成本和支出。

這種迅速的普及率很可能是因為 HTTP2 不需要站點和應用做出改變：使用 HTTP/1.1 和 HTTP/2 對他們來說是透明的。

擁有一個最新的伺服器和新點的瀏覽器進行交互就足夠了。只有一小部分群體需要做出改變，而且隨著陳舊的瀏覽器和伺服器的更新，而不需 Web 開發者做什麼，用的人自然就增加了。

隨著 HTTP/2 的發布，就像先前的 HTTP/1.x 一樣，HTTP 沒有停止進化。HTTP 的擴展性依然被用來添加新的功能。

HTTP 的進化證實了它良好的擴展性和簡易性，釋放了很多應用程式的創造力並且情願使用這個協議。

HTTP/3 是即將到來的第三個主要版本的 HTTP 協議。與前任協議不同，在 HTTP/3 中，將棄用 TCP 協議，改為使用 UDP 協議和 QUIC 協議實現。

此變化主要為了解決 HTTP/2 中存在的隊頭阻塞問題。由於 HTTP/2 在單個 TCP 連接上使用了多路復用，受到 TCP 擁塞控制的影響，少量的丟包就可能導致整個 TCP 連接上的所有流被阻塞。

截至 2021 年 1 月，HTTP/3 仍然是草案狀態。

HTTP 協議在設計之初就沒有充分考慮安全性的問題。所以基於 HTTP 的這些應用都承擔著如下的幾個風險：

HTTPS（HTTP over SSL）採取嵌套新一層安全套接字層（Secure Socket Layer,SSL）來解決網絡傳輸的安全性問題。

加密是很容易聯想到的解決方法。但如何保證傳輸加密方法的過程不被竊聽呢？

這時候非對稱加密的出現解決了這一大難題。它把密碼革命性地分成公鑰和私鑰，由於兩個秘鑰並不相同，所以稱為非對稱加密。

舉個例子，假設我們現在需要加密的字符是 520，我們加密的方法是把這個數乘以 91，並把結果的最後三位公布出來：

註：這裡的 91 相當於公鑰，任何人都可以知道。

解密我們當然不能通過除以 91 來完成，而是通過 x11，取出結果後三位來還原：

註：這裡的 x11 相當於私鑰，只有解密方才知道。

這是因為 91*11=1001，任何一個三位數乘以 1001 顯然後三位是不會變的。這大概就是非對稱加密的原理了，基於這個原理我們通信的雙方就可以各自生成自己的公鑰私鑰並進行相對安全的通信了。

非對稱加密通信演示

上面的過程看似無懈可擊，但在 TCP/IP 的端到端的通信裡，路途遙遠，夜長夢多。

如果在第二步的時候，信息被黑客截取，在嚴刑拷打之下知道了這是傳輸公鑰的信息。那麼完全可以自己生成一對密鑰和公鑰，冒充是彼此來傳輸自己的秘鑰。

加密危機之後，又產生了信任危機。我們需要一個有公信力的組織來證明身份，這個問題就得到了解決。

這個可信的組織就是頒發 HTTPS 證書的組織 CA（Certificate Authority）。每次有客戶端或者服務端想要公開自己的公鑰時，都需要向 CA 做出申請，通過後 CA 會頒發一個與公開公鑰綁定的數字證書。(了解更多證書)

進行 HTTPS 通信時，伺服器會把證書發送給客戶端，客戶端取得其中的公開密鑰之後，先進行驗證，如果驗證通過，就可以開始通信。

在之前介紹比特幣原理的時候，我們提到過一種哈希算法。它的作用是能把任意長度的輸入編程固定長度的二進位輸出。

註：為了簡化右邊為 16 進位數

在 HTTPS 中，有一種新的摘要算法，可以簡單理解為是對於內容的一種壓縮。所以但凡內容變化一丁點，哪怕是一個標點符號，壓縮之後的數字哈希也不對。

客戶端在發送明文之前會通過摘要算法算出明文的 「指紋」，發送的時候把 「指紋 明文」 一同加密成密文後，發送給伺服器。

伺服器解密後，用相同的摘要算法算出發送過來的明文，通過比較客戶端攜帶的 「指紋」 和當前算出的 「指紋」 做比較，若 「指紋」 相同，說明數據是完整的。

儘管聽上去 HTTPS 就是更安全的 HTTP，但也有許多細節方面的不同：

來源：我沒有三顆心臟

作者：我沒有三顆心臟