柚子快報(bào)激活碼778899分享：HTTP與HTTPS詳解

http://yzkb.51969.com/

一、HTTP的概念

HTTP是超文本傳輸協(xié)議，是一種應(yīng)用層協(xié)議，是基于為瀏覽器/服務(wù)器間提供統(tǒng)一的信息交換格式而出現(xiàn)的，其發(fā)展歷程為HTTP/1.0、HTTP/1.1、HTTP/2、HTTP/3。

1. HTTP版本區(qū)別

HTTP/1.0：HTTP/1.0為短連接，即客戶端單次請(qǐng)求后就關(guān)閉TCP連接。這樣效率顯然是很低的HTTP/1.1：HTTP/1.1默認(rèn)為長(zhǎng)連接，提升了連接的利用率，可用報(bào)文中Connecton字段控制的，取值Keep-Alive 為長(zhǎng)連接（默認(rèn)），取值Close 表示關(guān)閉長(zhǎng)連接。并且引入了管道化技術(shù)，發(fā)送請(qǐng)求后不必等待響應(yīng)就可以繼續(xù)發(fā)送下一個(gè)請(qǐng)求，但是由于性能原因很少被支持。HTTP/2：HTTP/1為半雙工，只能由客戶端向服務(wù)端發(fā)送請(qǐng)求，服務(wù)端再響應(yīng)請(qǐng)求。并且HTTP/1.1存在應(yīng)用層隊(duì)頭阻塞和報(bào)文頭部信息重復(fù)傳輸?shù)膯?wèn)題。HTTP/2引入了全雙工，服務(wù)端也可主動(dòng)發(fā)送數(shù)據(jù)。并且HTTP/2通過(guò)將報(bào)文分幀傳輸?shù)姆绞?，?shí)現(xiàn)了連接的多路復(fù)用，解決了應(yīng)用層面的隊(duì)頭阻塞問(wèn)題。此外，HTTP/2通過(guò)HPACK算法對(duì)HTTP報(bào)文頭部進(jìn)行了壓縮，提升了傳輸效率HTTP/3：在HTTP/3之前，HTTP都是基于TCP傳輸?shù)?。HTTP/3基于UDP傳輸

2. HTTP2 vs HTTP1.1

HTTP1.1存在的問(wèn)題，HTTP1.1引入了長(zhǎng)連接，但仍存在一些問(wèn)題：

應(yīng)用層隊(duì)頭阻塞：在一條連接中，客戶端必須等待獲取完一個(gè)請(qǐng)求的全部響應(yīng)報(bào)文才能獲取下一個(gè)請(qǐng)求的響應(yīng)報(bào)文。如果說(shuō)前一個(gè)請(qǐng)求需要的響應(yīng)時(shí)間特別久比如說(shuō)是一個(gè)大文件，后面的請(qǐng)求響應(yīng)只能被阻塞。報(bào)文頭部信息重復(fù)傳輸：由于HTTP本身是無(wú)狀態(tài)協(xié)議，每次請(qǐng)求響應(yīng)都需要帶上全部的頭部信息，并且這些頭部信息中很多都是重復(fù)不變的，比如UserAgent，或者每個(gè)字段的名稱。這些頭部信息的重復(fù)傳輸就造成了資源的浪費(fèi)。 半雙工：不支持服務(wù)器推送消息， 因此當(dāng)客戶端需要獲取通知時(shí)，只能通過(guò)定時(shí)器不斷地拉取消息，這無(wú)疑浪費(fèi)大量了帶寬和服務(wù)器資源。

為了應(yīng)對(duì)這些問(wèn)題常見(jiàn)的優(yōu)化方案如下：

減少請(qǐng)求數(shù)量：將請(qǐng)求的資源文件內(nèi)聯(lián)合并為一個(gè)請(qǐng)求響應(yīng)。增加連接個(gè)數(shù)：可以開(kāi)多個(gè)TCP連接去分別進(jìn)行請(qǐng)求，但是瀏覽器對(duì)一個(gè)域名的并發(fā)TCP連接數(shù)限制為6個(gè)，因此還有一些解決方案就是不同資源類型放到不同的二級(jí)域名下面，比如像圖片這種消耗比較大的資源單獨(dú)放到一個(gè)域名下，這樣就可以增加并發(fā)的TCP連接數(shù)。但是大量的TCP連接的創(chuàng)建與銷毀肯定是存在性能問(wèn)題的，單個(gè)TCP連接的利用率還是沒(méi)有提上去。前面提到的兩個(gè)問(wèn)題還是沒(méi)有完全解決。

HTTP2做了如下改進(jìn)：

報(bào)文分幀傳輸：在應(yīng)用層將一個(gè)報(bào)文視為一個(gè)stream流，將報(bào)文拆分為多個(gè)有序的幀，每個(gè)幀的stream流id相同，幀id不同。那么在接收方就可以通過(guò)流id區(qū)分一個(gè)報(bào)文，并通過(guò)幀id將報(bào)文按序組裝起來(lái)。因此在一個(gè)連接中就可以同時(shí)傳輸多個(gè)請(qǐng)求或者響應(yīng)，就是多個(gè)報(bào)文的幀混合傳輸，接收端根據(jù)id在應(yīng)用層進(jìn)行組裝，這樣實(shí)現(xiàn)了連接的多路復(fù)用，有效提升了TCP連接的利用率。報(bào)文頭部壓縮算法：使用HPACK算法對(duì)報(bào)文頭部進(jìn)行壓縮。使用靜態(tài)表存儲(chǔ)常見(jiàn)的HTTP字段和值，用動(dòng)態(tài)表存儲(chǔ)請(qǐng)求過(guò)程中動(dòng)態(tài)的字段和值，并且使用哈夫曼編碼壓縮字符串值。那么在傳輸過(guò)程中只需要用對(duì)應(yīng)的表索引來(lái)替代實(shí)際的值，這樣就大大減少了報(bào)文頭部的大小。支持全雙工：服務(wù)器支持主動(dòng)推送資源，大大提升了消息的傳輸性能，服務(wù)器推送資源時(shí)，會(huì)先發(fā)送 PUSH_PROMISE 幀，告訴客戶端接下來(lái)在哪個(gè) Stream 發(fā)送資源，然后用偶數(shù)號(hào) Stream 發(fā)送資源給客戶端。

參考：

https://www.bilibili.com/video/BV1vv4y1U77yhttps://www.bilibili.com/video/BV1Jz4y1B7sthttps://zhuanlan.zhihu.com/p/330300133

2. HTTP3 vs HTTP2

HTTP2是基于TCP進(jìn)行傳輸?shù)?，但是基于TCP具有以下局限性：

TCP隊(duì)頭阻塞：TCP要保證數(shù)據(jù)包按序到達(dá)給到應(yīng)用層，因此可能會(huì)出現(xiàn)一個(gè)報(bào)文stream的幀都到達(dá)了，要是等待前面丟失的重傳，沒(méi)辦法給到應(yīng)用層讀取。連接握手延遲與連接遷移： HTTPS 請(qǐng)求前需要經(jīng)過(guò) TCP 三次握手和 TLS 四次握手（TLS 1.2）建立連接，并且用戶IP地址變動(dòng)時(shí)又要重新建立連接，比如手機(jī)在4G網(wǎng)絡(luò)和WiFi之間切換時(shí)。慢啟動(dòng)：發(fā)送速率先要有個(gè)慢啟動(dòng)的過(guò)程。

HTTP3基于QUIC協(xié)議，其傳輸層為UDP：

無(wú)隊(duì)頭阻塞：UDP不關(guān)心數(shù)據(jù)包順序，一個(gè)報(bào)文的幀都到達(dá)后由QUIC協(xié)議組裝給應(yīng)用層，丟失了由QUIC協(xié)議控制重傳。更快的連接握手與連接遷移：QUIC 協(xié)議握手，這個(gè)握手過(guò)程只需要 1 RTT，握手的目的是為確認(rèn)雙方的「連接 ID」。QUIC 協(xié)議的通信雙方連接關(guān)系就是基于這個(gè)連接 ID確定的，而不是IP端口四元組，因此在用戶網(wǎng)絡(luò)發(fā)生變化時(shí)仍然可以基于連接 ID 繼續(xù)通信，無(wú)需重新建立連接。

二、HTTP報(bào)文格式

作為一種應(yīng)用層協(xié)議，其規(guī)定的信息交換格式如下：

1. 請(qǐng)求報(bào)文

請(qǐng)求報(bào)文為主動(dòng)發(fā)送一個(gè)http請(qǐng)求的報(bào)文，格式說(shuō)明:

請(qǐng)求行(request line)：包括請(qǐng)求方法，資源的URL，以及HTTP協(xié)議版本。請(qǐng)求頭(header)：包括請(qǐng)求服務(wù)器所需要的附加信息?？招?CRLF)：請(qǐng)求頭部后面必須是空行,即使請(qǐng)求數(shù)據(jù)為空,也要有空行。請(qǐng)求數(shù)據(jù)(body)：也稱為請(qǐng)求體，可以添加任意類型的數(shù)據(jù)，通過(guò)請(qǐng)求頭中的Content-Length字段確定請(qǐng)求數(shù)據(jù)的長(zhǎng)度。

（1）GET請(qǐng)求報(bào)文

根據(jù)RFC規(guī)范，GET 的語(yǔ)義是從服務(wù)器獲取指定的資源。GET請(qǐng)求一般不攜帶請(qǐng)求體，如果有請(qǐng)求參數(shù)則放在URL后面，一個(gè)GET請(qǐng)求報(bào)文的樣例如下:

GET /video1?p=2 HTTP/1.1 # 請(qǐng)求行：GET請(qǐng)求方式 請(qǐng)求資源路徑 HTTP協(xié)議版本

Host: www.bilibili.com # 服務(wù)器的主機(jī)地址和端口號(hào),默認(rèn)是80

Connection: keep-alive # 和服務(wù)端保持長(zhǎng)連接

Upgrade-Insecure-Requests: 1 # 讓瀏覽器升級(jí)不安全請(qǐng)求，使用https請(qǐng)求

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36 # 用戶代理，也就是客戶端的名稱

Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8 # 可接受的數(shù)據(jù)類型

Accept-Encoding: gzip, deflate # 可接受的壓縮格式

Accept-Language: zh-CN,zh;q=0.9 #可接受的語(yǔ)言

Cookie: pgv_pvi=1246921728; # 登錄用戶的身份標(biāo)識(shí)

---- 空行 ----

（2）POST請(qǐng)求報(bào)文

根據(jù) RFC 規(guī)范，POST 的語(yǔ)義是根據(jù)請(qǐng)求體（報(bào)文body）對(duì)指定的資源請(qǐng)求做出處理。一般提交表單時(shí)就會(huì)使用POST請(qǐng)求，例如登錄，一個(gè)POST請(qǐng)求報(bào)文的樣例如下:

POST /login HTTP/1.1 # 請(qǐng)求行：POST請(qǐng)求方式 請(qǐng)求資源路徑 HTTP協(xié)議版本

Host: www.bilibili.com # 服務(wù)器的主機(jī)地址和端口號(hào),默認(rèn)是80

Connection: keep-alive # 和服務(wù)端保持長(zhǎng)連接

Content-Type: application/json;charset=utf-8 # 請(qǐng)求體的數(shù)據(jù)類型

Content-Length：32 # 請(qǐng)求體的數(shù)據(jù)長(zhǎng)度

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36 # 客戶端的名稱

---- 空行 ----

{username:hello,pass:123456} # 請(qǐng)求體

2. 響應(yīng)報(bào)文

響應(yīng)報(bào)文為響應(yīng)一個(gè)http請(qǐng)求的報(bào)文，格式說(shuō)明：

狀態(tài)行(status line): 包括HTTP協(xié)議版本，狀態(tài)碼和狀態(tài)消息消息報(bào)頭(header): 包括返回客戶端的一些附加信息空行(CRLF): 必須有空行響應(yīng)正文(body): 服務(wù)器返回給客戶端的數(shù)據(jù),可以是任意類型的數(shù)據(jù) 響應(yīng)報(bào)文樣例：

HTTP常見(jiàn)響應(yīng)狀態(tài)碼

狀態(tài)碼301和302的區(qū)別 301是永久重定向，瀏覽器會(huì)緩存請(qǐng)求，之后再請(qǐng)求都是直接到重定向后的地址 302是臨時(shí)重定向，例如想訪問(wèn)某個(gè)資源，但是服務(wù)器檢測(cè)到還未登錄，于是302重定向到登錄頁(yè)面

參考：http協(xié)議詳解 HTTP 請(qǐng)求報(bào)文

三、HTTP 與 HTTPS的區(qū)別

HTTP是明文傳輸，HTTPS比HTTP多一層SSL/TLS 安全協(xié)議，在TCP的三次握手之后，還需進(jìn)行TLS握手，握手成功后通過(guò)秘鑰對(duì)整個(gè)HTTP報(bào)文通過(guò)對(duì)稱加密進(jìn)行密文傳輸通信。HTTP 默認(rèn)端口號(hào)是 80，HTTPS 默認(rèn)端口號(hào)是 443。

SSL/TLS 協(xié)議基本流程：

客戶端向服務(wù)器索要并驗(yàn)證服務(wù)器的公鑰。雙方協(xié)商生產(chǎn)「會(huì)話秘鑰」。雙方采用「會(huì)話秘鑰」進(jìn)行加密通信。

前兩步就是 TLS 握手階段，握手過(guò)程中的密鑰交換算法有兩種：RSA 算法 和 ECDHE 算法。

1. 基于RSA的TLS握手機(jī)制

（1）第一次握手：客戶端首先會(huì)發(fā)一個(gè)「Client Hello」消息，其中包括客戶端使用的 TLS 版本號(hào)、支持的密碼套件列表、以及生成的第一個(gè)隨機(jī)數(shù)（Client Random）。

（2）第二次握手：當(dāng)服務(wù)端收到客戶端的「Client Hello」消息后，會(huì)確認(rèn) TLS 版本號(hào)是否支持，和從密碼套件列表中選擇一個(gè)密碼套件，以及生成第二個(gè)隨機(jī)數(shù)（Server Random）。接著返回「Server Hello」消息，其中包括確認(rèn) 的TLS 版本號(hào)、選擇的密碼套件、Server Random。然后，服務(wù)端為了證明自己的身份，會(huì)發(fā)送「Server Certificate」給客戶端，這個(gè)消息里含有數(shù)字證書(shū)。隨后，服務(wù)端發(fā)了「Server Hello Done」消息，目的是告訴客戶端，我已經(jīng)把該給你的東西都給你了，第二次握手完畢。

密碼套件基本的形式是「密鑰交換算法 + 簽名算法 + 對(duì)稱加密算法 + 摘要算法」

（3）第三次握手：客戶端首先對(duì)證書(shū)進(jìn)行驗(yàn)證，認(rèn)為可信則繼續(xù)往下走。接著客戶端就會(huì)生成第三個(gè)隨機(jī)數(shù) (pre-master)，用服務(wù)器公鑰加密后傳給服務(wù)端。然后客戶端用這三個(gè)隨機(jī)數(shù)生成一個(gè)會(huì)話秘鑰，用于后續(xù)通信的對(duì)稱加密。生成完「會(huì)話密鑰」后，然后客戶端發(fā)一個(gè)「Change Cipher Spec」，告訴服務(wù)端開(kāi)始使用加密方式發(fā)送消息。然后，客戶端再發(fā)一個(gè)「Encrypted Handshake Message（Finished）」消息，把之前所有發(fā)送的數(shù)據(jù)做個(gè)摘要，再用會(huì)話密鑰（master secret）加密一下，讓服務(wù)器做個(gè)驗(yàn)證，驗(yàn)證加密通信「是否可用」和「之前握手信息是否有被中途篡改過(guò)」。

數(shù)字證書(shū)的簽發(fā)與驗(yàn)證：

（4）第四次握手：服務(wù)端收到加密后的第三個(gè)隨機(jī)數(shù) (pre-master)后，用服務(wù)端私鑰進(jìn)行解密，然后進(jìn)行與客戶端同樣的操作：用這三個(gè)隨機(jī)數(shù)生成同樣的會(huì)話秘鑰、發(fā)送「Change Cipher Spec」、發(fā)送會(huì)話秘鑰加密后的摘要信息「Encrypted Handshake Message（Finished）」。驗(yàn)證過(guò)摘要信息之后客戶端和服務(wù)端就可以開(kāi)始用會(huì)話秘鑰加密通信了。

2. 基于ECDHE的TLS握手機(jī)制

使用 RSA 密鑰協(xié)商算法的最大問(wèn)題是不支持前向保密。

因?yàn)榭蛻舳藗鬟f隨機(jī)數(shù)（用于生成對(duì)稱加密密鑰的條件之一）給服務(wù)端時(shí)使用的是公鑰加密的，服務(wù)端收到后，會(huì)用私鑰解密得到隨機(jī)數(shù)。所以一旦服務(wù)端的私鑰泄漏了，過(guò)去被第三方截獲的所有 TLS 通訊密文都會(huì)被破解。

為了解決這個(gè)問(wèn)題，后面就出現(xiàn)了 ECDHE 密鑰協(xié)商算法，我們現(xiàn)在大多數(shù)網(wǎng)站使用的正是 ECDHE 密鑰協(xié)商算法。

參考：

https://xiaolincoding.com/network/https到底把什么加密了?

柚子快報(bào)激活碼778899分享：HTTP與HTTPS詳解

http://yzkb.51969.com/

精彩鏈接