計算機網絡協議(四)——HTTP、HTTPS、P2P協議

概述

---

這個專欄的計算機網絡協議，我是在極客時間上學習 已經有三萬多人購買的劉超老師的趣談網絡協議專欄，講的特別好，像看小說一樣學習到了平時很枯燥的知識點，計算機網絡的書籍太枯燥，感興趣的同學可以去付費購買，絕對物超所值，本文就是對自己學習專欄的總結,評論區可以留下你的問題，咱們一起討論！

上一篇文章中介紹了常見的傳輸層的協議，接下來開始講應用層的協議。本文將分爲三個協議給大家進行介紹：

• HTTP協議：看個新聞原來這麼麻煩；
• HTTPS協議：點外賣的過程原來這麼複雜；
• P2P協議：我下小電影，99%急死你；

---

一、HTTP協議

http://www.taobao.com 是個URL，叫作統一資源定位符;

HTTP請求的準備
系統會將http://www.taobao.com 提交給DNS服務器解析爲IP地址；

目前使用的HTTP協議大部分都是1.1，默認開啓Keep-Alive，建立起的TCP連接可以在多次請求中複用；

---

HTTP請求的構建
建立連接之後，瀏覽器發送HTTP的請求，請求格式如下：

HTTP分爲三部分：請求行、首部、正文實體；

---

1.1、HTTP 1.1

---

第一部分：請求行
在請求行中，URL就是 http://www.taobao.com ，版本爲HTTP 1.1,方法有幾種類型：

• GET
  GET就是去服務器獲取一些資源，可以返回的是一個網頁，也有許多別的格式，比如說返回一個JSON字符串；

• POST
  需要主動告訴服務端一些信息，一般會放在正文裏面。正文可以有各種各樣的格式。常見的格式也是JSON；

• PUT
  向指定資源位置上傳最新內容，POST往往是用來創建一個資源的，而PUT往往是用來修改一個資源；

• DELETE，刪除資源，例如刪除雲主機；

---

第二部分：首部字段

首部是key value，通過冒號分隔，往往保存了一些非常重要的字段。例如，Accept-Charset，表示客戶端可以接受的字符集，防止傳過來的另外字符集導致亂碼；

或者是Content-Type是指正文的格式，進行POST的請求，如果正文是JSON，那麼我們就應該將這個值設置爲JSON；

在HTTP頭裏面，Cache-control是用來控制緩存的。當客戶端發送的請求中包含max-age指令時，如果判定緩存層中，資源的緩存時間數值比指定時間的數值小，那麼客戶端可以接受緩存的資源；當指定max-age值爲0，那麼緩存層通常需要將請求轉發給應用集羣。

If-Modified-Since也是一個關於緩存的，如果服務器在某段時間更新了就會下載最新資源，反之就會返回一個“304 Not Modifed”的響應；

---

HTTP請求的發送
HTTP協議是基於TCP，面向連接，通過stream二進制流的方式傳給對方；

每發送一個報文，都需要對方有一個迴應ACK,保證報文可靠傳到了對方；
TCP層每發送一個報文，就會在IP頭加上源地址和目標地址，交給IP層進行傳輸；

IP層和目標地址在一個局域網，就發送ARP協議來請求這個目標地址對應的MAC地址，然後將源MAC和目標MAC放入MAC頭，發送出去即可；不在同一個局域網，就需
要發送到網關，還要需要發送ARP協議，來獲取網關的MAC地址，然後將源MAC和網關MAC放入MAC頭，發送出去；

網關收到包發現MAC符合，取出目標IP地址，根據路由協議找到下一跳的路由器，獲取下一跳路由器的MAC地址，將包發給下一跳路由器。路由器一跳一跳終於到達目標的局域網後，找到目標機器的MAC地址進行匹配；；發現IP地址符合，根據IP頭中協議項，知道自己上一層是TCP協議，於是解析TCP的頭，裏面有序列號，需要看一看這個序列包是不是我要的，如果是就放入緩存中然後返回一個ACK，如果不是就丟棄。

HTTP的服務器正在監聽TCP的端口號，目標機器返回對應的包發送給HTTP服務器，最終就將想要看到的網頁傳到客戶端；

---

HTTP返回的構建
HTTP的返回報文也是有一定格式的，基於HTTP 1.1；

• 狀態碼會反應HTTP請求的結果，1XX 信息，2XX 成功，3XX 重定向，4XX 客戶端錯誤，5XX 服務器錯誤；
• Retry-After表示告訴客戶端應該在多長時間以後再次嘗試一下；
• Content-Type，表示返回的是HTML，還是JSON；

構造好了返回的HTTP報文，接下來就是把這個報文發送出去。還是交給Socket去發送，還是交給TCP層，讓TCP層將返回的HTML，也分成一個個小的段，並且保證每個段都可靠到達。

這些段加上TCP頭後會交給IP層，然後把剛纔的發送過程反向走一遍。雖然兩次不一定走相同的路徑，但是邏輯過程是一樣的，一直到達客戶端。客戶端發現MAC地址符合、IP地址符合，於是就會交給TCP層。根據序列號看是不是自己要的報文段，

如果是，則會根據TCP頭中的端口號，發給相應的進程。這個進程就是瀏覽器，瀏覽器作爲客戶端也在監聽某個端口。

當瀏覽器拿到了HTTP的報文。發現返回“200”，一切正常，於是就從正文中將HTML拿出來。HTML是一個標準的網頁格式。瀏覽器只要根據這個格式，展示出一個絢麗多彩的網頁。

---

1.2、HTTP 2.0

HTTP/1.x 缺陷
HTTP/1.x 實現簡單是以犧牲性能爲代價的：

客戶端需要使用多個連接才能實現併發和縮短延遲；
不會壓縮請求和響應首部，從而導致不必要的網絡流量；
不支持有效的資源優先級，致使底層 TCP 連接的利用率低下

---

HTTP 2.0會對HTTP的頭進行一定的壓縮，將原來每次都要攜帶的大量key value在
兩端建立一個索引表，對相同的頭只發送索引表中的索引;

---

HTTP 2.0協議將一個TCP的連接中，切分成多個流，每個流都有自己的ID，而且流可以是客戶端發往服務端，也可以是服務端發往客戶端。它其實只是一個虛擬的通道。流是有優先級的。

---

HTTP 2.0還將所有的傳輸信息分割爲更小的消息和幀，並對它們採用二進制格式編碼。
Header幀用於傳輸Header內容，並且會開啓一個新的流；
Data幀用來傳輸正文實體，多個Data幀屬於同一個流；

通過這兩種機制，HTTP 2.0的客戶端可以將多個請求分到不同的流中，然後將請求內容拆成幀，進行二進制傳輸。這些幀可以打散亂序發送， 然後根據每個幀首部的流標識符重新組裝，並且可以根據優先級，決定優先處理哪個流的數據；

HTTP 2.0成功解決了HTTP 1.1的隊首阻塞問題，同時，也不需要通過HTTP 1.x的pipeline機制用多，條TCP連接來實現並行請求與響應；減少了TCP連接數對服務器性能的影響，同時將頁面的多個數據css、js、 jpg等通過一個數據鏈接進行傳輸，能夠加快頁面組件的傳輸速度。

---

1.3 QUIC協議

• 自定義連接機制：UDP是無連接，是以一個64位的隨機數作爲ID來標識，當IP或者端口變化的時候，只要ID不變，就不需要重新建立連接。
• 自定義重傳機制：QUIC中的序列號也是遞增的，任何一個序列號的包只發送一次，下次就要加一，假設發送包的序號是100，再次發送的序號是101，如果返回的ACK是101就是對第二個包的響應，RTT計算相對準確；
• 無阻塞的多路複用：QUIC基於UDP,一個連接上的stream沒有依賴，假如stream2丟失了一個包，後面跟着的stream3的UDP包無需等待，直接發送給用戶；
• 自定義流量控制：QUIC的流量控制是通過window_update，來告訴對端它可以
  接受的字節數。但是其窗口是適應自己的多路複用機制的，不但在一個連接上控制窗口，還在一個連接中的每個stream控制窗口。

---

總結

• HTTP協議雖然很常用，也很複雜，重點記住GET、POST、 PUT、DELETE這幾個方法，以及重要的首部字段；
• HTTP 2.0通過頭壓縮、分幀、二進制編碼、多路複用等技術提升性能；
• QUIC協議通過基於UDP自定義的類似TCP的連接、重試、多路複用、流量控制技術，進一步提升性能。

---

二、HTTPS協議

用HTTP協議看個新聞倒是沒啥問題，但是假如你要是在網頁中下單購物，黑客截獲了你的支付請求，就可以騙取你的銀行卡和密碼；

一般能想到的思路就是加密

加密分爲：

• 對稱加密；
• 非對稱加密；

---

對稱加密：

對稱密鑰加密（Symmetric-Key Encryption），加密和解密使用同一密鑰。

• 優點：運算速度快；

• 缺點：無法安全地將密鑰傳輸給通信方

比如：你和淘寶之間各自約定一個密鑰，採用密鑰加密傳輸，淘寶採用這個密鑰解密，黑客截獲你的請求，也破解不了；

存在的問題就是 你如何同淘寶之間約定同一個密鑰，如果這個密鑰在網絡中傳輸，會被黑客截獲的，總不能像諜戰劇一樣線下傳輸，約定同一個密鑰，這對於大型互聯網公司是不可能的；

常見的對稱加密算法：

• DES算法：DES 加密算法是一種 分組密碼，以 64 位爲 分組對數據 加密，它的 密鑰長度 是 56 位，加密解密 用 同一算法,破譯 DES 加密算法實際上就是 搜索密鑰的編碼,窮舉法的運算次數爲 2 ^ 56 次；
• 3DES算法：基於 DES 的 對稱算法，對 一塊數據 用 三個不同的密鑰 進行 三次加密，強度更高；
• AES算法：AES 加密算法是密碼學中的 高級加密標準，該加密算法採用 對稱分組密碼體制，密鑰長度的最少支持爲 128 位、 192 位、256 位，分組長度 128 位；

---

非對稱加密

非對稱密鑰加密，又稱公開密鑰加密（Public-Key Encryption）；加密和解密使用不同的密鑰。

公開密鑰所有人都可以獲得，通信發送方獲得接收方的公開密鑰之後，就可以使用公開密鑰進行加密，接收方收到通信內容後使用私有密鑰解密。

• 如果使用 公鑰 對數據 進行加密，只有用對應的 私鑰 才能 進行解密。
• 如果使用 私鑰 對數據 進行加密，只有用對應的 公鑰 才能 進行解密。

非對稱密鑰除了用來加密，還可以用來進行簽名。因爲私有密鑰無法被其他人獲取，因此通信發送方使用其私有密鑰進行簽名，通信接收方使用發送方的公開密鑰對簽名進行解密，就能判斷這個簽名是否正確。
常見的非對稱加密算法

• RSA算法：RSA 是第一個能同時用於 加密 和 數字簽名 的算法，RSA 加密算法 基於一個十分簡單的數論事實：將兩個大 素數 相乘十分容易，但想要對其乘積進行 因式分解 卻極其困難，因此可以將 乘積 公開作爲 加密密鑰。
• ECC算法：在某些情況下，它比其他的方法使用 更小的密鑰，比如 RSA 加密算法，提供 相當的或更高等級 的安全級別。

---

數字證書

不對稱加密一般通過放在公網地址上讓對方下載，另一種就是在建立連接的時候，傳給對方；

例如：通過以下命令創建一個私鑰

openssl genrsa -out cliu8siteprivate.key 1024

再根據這個私鑰，創建對應的公鑰：

openssl rsa -in cliu8siteprivate.key -pubout -outcliu8sitepublic.pem

這個時候就需要權威部門的介入，就像你的戶口本上只要公安局蓋章之後，才能證明是你，由權威部門頒發的稱爲證書（Certificate）；

證書（Certificate）中包含公鑰、證書的所有者、證書的發佈機構和證書的有效期；

證書的生成需要權威機構去認證，就是CA（ Certificate Authority）；

採用以下命令

openssl req -key cliu8siteprivate.key -new -out cliu8sitecertifcate.req

數字證書認證機構（CA，Certificate Authority）是客戶端與服務器雙方都可信賴的第三方機構；要想驗證證書，需要CA的公鑰，，CA的公鑰也需要更牛的CA給它簽名，然後形成CA的證書。就像你不相信區公安局，可以打電話問市公安局，讓市公安局確認區公安局的合法性。這樣層層上去，直到全球皆知的幾個著名大CA，稱爲rootCA，做最後的背書。通過這種層層授信背書的方式，從而保證了非對稱加密模式的正常運轉。

服務器的運營人員向 CA 提出公鑰的申請，CA 在判明提出申請者的身份之後，會對已申請的公開密鑰做數字簽名，然後分配這個已簽名的公開密鑰，並將該公開密鑰放入公開密鑰證書後綁定在一起。

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

---

HTTPS的工作模式

當你登錄一個外賣網站的時候，由於是HTTPS，客戶端會發送Client Hello消息到服務器，以明文傳輸TLS版本信息、加密套件候選列表、壓縮算法候選列表等信息。另外，還會有一個隨機數，在協商對稱密鑰的時候使用。

類似於，“您好，我要訂外賣，但你要加密我要吃的飯，再給你一個隨機數留着”

外賣網站返回一個回Server Hello消息, 告訴客戶端，服務器選擇使用的協議版本、加密套件、壓縮算法等，也會有一個隨機數，用於後續的密鑰協商。

類似於，“您好，保密沒問題，你的加密套路還挺多，咱們就按套路2來吧，我這裏也有個隨機數，你也留着。”

然後外賣網站會給你一個證書，如果你不信任這個證書就拿自己信任的CA庫中的CA證書的公鑰去解密外賣網站的證書，成功即爲可信的CA，反之不斷地回溯CA,直到找到一個授信地CA即可；

證書驗證完畢之後，覺得這個外賣網站可信，於是客戶端計算產生隨機數字Pre-master，發送Client Key Exchange，用證書中的公鑰加密，再發送給服務器，服務器可以通過私鑰解密出來。

目前爲止，無論是客戶端還是服務器，都有了三個隨機數，分別是：自己的、對端的，以及剛生成的Pre-Master隨機數。通過這三個隨機數，可以在客戶端和服務器產生相同的對稱密鑰。

有了對稱密鑰，後面就可以協商通信密鑰和加密算法進行加密通信了。

---

總結

• 加密分對稱加密和非對稱加密。對稱加密效率高，但是解決不了密鑰傳輸問題；非對稱加密可以解決這個問題，但是效率不高；
• 非對稱加密需要通過證書和權威機構來驗證公鑰的合法性。
• HTTPS是綜合了對稱加密和非對稱加密算法的HTTP協議。既保證傳輸安全，也保證傳輸效率。

---

三、P2P協議

最簡單就是通過過HTTP進行下載，文件一大，速度就很慢；

還可以通過FTP，也即文件傳輸協議，FTP有兩種工作模式，分別爲主動模式(PORT)和被動模式(PASV)

無論是HTTP的方式，還是FTP的方式,都難以解決單一服務器的帶寬壓力，因爲它們都是採用的傳統的客戶端服務器的方式；

P2P就是peer-to-peer，資源開始並不集中地存儲在某些設備上，而是分散地存儲在多臺設備上。這些設備我們姑且稱爲peer。

想要下載一個文件的時候，你只要得到那些已經存在了文件的peer，並和這些peer之間，建立點對點的連接，而不需要到中心服務器上，就可以就近下載文件。一旦下載了文件，你也就成爲peer中的一員，你旁邊的那些機器，也可能會選擇從你這裏下載文件，所以當你使用P2P軟件的時候，例如BitTorrent ，往往能夠看到，既有下載流量，也有上傳的流量，也即你自己也加入了這個P2P的網絡，自己從別人那裏下載，同時也提供給其他人下載。可以想象，這種方式，參與的人越多，下載速度越快，一切完美。

---

種子（.torrent）文件
.torrent文件由兩部分組成，分別是：announce（tracker URL）和文件信息。

文件信息包含以下內容：

• info區：指定種子中的文件數、文件大小、目錄結構等；
• Name字段：指定頂層目錄名字；
• 每個段的大小：：BitTorrent （簡稱BT）協議把一個文件分成很多個小段，然後分段下載；
• 段哈希值：將整個種子中，每個段的SHA-1哈希值拼在一起；

下載時，BT客戶端會先解析.torrent文件得到tracker地址，連接到tracker服務器；trakcer服務器迴應下載者的請求，並返回其它下載者的IP提供給下載者，根據.torrent文件交換雙方已有的塊，然後交換雙方沒有的數據；

每下載一個塊，需要算出下載塊的Hash驗證碼，並與.torrent文件中的對比；

這種方法的弊端是太依賴tracker服務器，一旦tracker服務器出現故障或者線路遭到屏蔽，BT工具就無法正常工作；

---

去中心化網絡（DHT）

DHT（Distributed Hash Table）

每個加入這個DHT網絡的人，都要負責存儲這個網絡裏的資源信息和其他成員的聯繫信息，相當於所有人一起構成了一個龐大的分佈式存儲數據庫。

DHT中有一個Kademlia協議

任何一個BitTorrent 啓動之後，都會充當兩個角色：

• peer,監聽TCP端口，用來上傳還是下載文件；
• DHT node，監聽一個UDP的端口，通過該節點加入DHT網絡；

每個DHT node都有一個ID，是通過文件哈希計算出的索引(來知道某些文件保存在哪些節點中)；

DHT算法：如果一個文件計算出一個哈希值，則和這個哈希值一樣的那個DHT node，就有責任知道從哪裏下載這個文件，即便它自己沒保存這個文件。除了一模一樣的那個DHT node應該知道，ID和這個哈希值非常接近的N個DHTnode也應該知道；

ID相似，在Kademlia網絡中，距離是通過異或（XOR）計算的；

在這種模式下，種子.torrent文件裏面就不再是tracker的地址了，而是一個list的node的地址，而所有這些node都是已經在DHT網絡裏面的。當然隨着時間的推移，很可能有退出的，有下線的，但是我們假設，不會所有的都聯繫不上，總有一個能聯繫上。

---

DHT中按照距離分層，就像你的朋友圈一樣 按照親疏程度遠近分層；

DHT網絡中通過Kademlia的查詢機制，二分查找，對於總節點數N，只需要查詢log2(N)次，如下所示：

Kademlia算法中，每個節點只有4個指令：

• PING：測試一個節點是否在線，還活着沒，相當於打個電話，看還能打通不；
• STORE：要求一個節點存儲一份數據，既然加入了組織，有義務保存一份數據；
• FIND_NODE：根據節點ID查找一個節點，就是給一個160位的ID，通過上面朋友圈的方式找到那個節點；
• FIND_VALUE：根據KEY查找一個數據，實則上跟FIND_NODE非常類似。KEY就是文件對應的160位的ID，就是要找到保存了文件的節點。

DHT網絡中網絡如何更新？

• 每個bucket裏的節點，都按最後一次接觸的時間倒序排列，相當於，朋友圈裏面最近聯繫過的人往往是最熟的；
• 每次執行四個指令中的任意一個都會觸發更新；
• 當一個節點與自己接觸時，檢查它是否已經在k-bucket中，也就是說是否已經在朋友圈。如果在，那麼將它挪到k-bucket列表的最底，也就是最新的位置，剛聯繫過，就置頂一下，方便以後多聯繫；如果不在，新的聯繫人要不要加到通訊錄裏面呢？假設通訊錄已滿的情況，PING一下列表最上面，也即最舊的一個節點。如果PING通了，將舊節點挪到列表最底，並丟棄新節點，老朋友還是留一下；如果PING不通，刪除舊節點，並將新節點加入列表，這人聯繫不上了，刪了吧。

---

總結

• 下載一個文件可以使用HTTP或FTP，這兩種都是集中下載的方式，而P2P則換了一種思路，採取非中心化下載的方式；
• P2P也是有兩種，一種是依賴於tracker的，也即元數據集中，文件數據分散；另一種是基於分佈式的 哈希算法，元數據和文件數據全部分散；