摘要：作者楊志曉的版本建立在協(xié)議之上。網(wǎng)絡(luò)上的大多數(shù)網(wǎng)站都是基于協(xié)議，而可以支持多線程的連接請(qǐng)求，通過這個(gè)操作可以減少載入網(wǎng)頁的時(shí)間。它可以防止重放攻擊，并確認(rèn)初始數(shù)據(jù)交換的完整性。

作者：楊志曉

a.HTTP建立在TCP協(xié)議之上。

b.HTTP/0.9 于1991年發(fā)布。

c.HTTP/1.0 于1996年發(fā)布。

d.HTTP/1.1 于1999年發(fā)布。

e.HTTP/2 于2015年發(fā)布。

a.工作原理如圖：
2_1.jpg

b.每次與服務(wù)器交互，都需要新開一個(gè)連接！

2_2.jpg

c.抓包分析：

demo：4張圖片+html總共5個(gè)請(qǐng)求

2_3.jpg

2_4.jpg

每一條tcp鏈接都會(huì)直接返回connection close

試想一下：請(qǐng)求一張圖片，新開一個(gè)連接，請(qǐng)求一個(gè)CSS文件，新開一個(gè)連接，請(qǐng)求一個(gè)JS文件，新開一個(gè)連接。HTTP協(xié)議是基于TCP的，TCP每次都要經(jīng)過三次握手，四次揮手，慢啟動(dòng)...這都需要去消耗我們非常多的資源的！

a.相對(duì)于持久化連接還有另外比較重要的改動(dòng)：

HTTP 1.1增加host字段

HTTP 1.1中引入了Chunked transfer-coding，范圍請(qǐng)求，實(shí)現(xiàn)斷點(diǎn)續(xù)傳(實(shí)際上就是利用HTTP消息頭使用分塊傳輸編碼，將實(shí)體主體分塊傳輸)

HTTP 1.1管線化(pipelining)理論，客戶端可以同時(shí)發(fā)出多個(gè)HTTP請(qǐng)求，而不用一個(gè)個(gè)等待響應(yīng)之后再請(qǐng)求

注意：這個(gè)pipelining僅僅是限于理論場(chǎng)景下，大部分桌面瀏覽器仍然會(huì)選擇默認(rèn)關(guān)閉HTTP pipelining！

所以現(xiàn)在使用HTTP1.1協(xié)議的應(yīng)用，都是有可能會(huì)開多個(gè)TCP連接的！

b.工作原理如圖：

只建立一條tcp鏈接，但是每個(gè)請(qǐng)求都是串行的，如下圖所示

2_5.jpg

c.對(duì)上面同一個(gè)demo 在開啟keep-alive后進(jìn)行抓包分析：(4張圖片+html總共5個(gè)請(qǐng)求)

2_6.jpg

5個(gè)請(qǐng)求發(fā)起一條tcp連接

2_7.jpg

d.圖片增加后抓包如下（開啟keep-alive）：

2_8.jpg

e.通過增加圖片個(gè)數(shù)抓包后發(fā)現(xiàn)，瀏覽器同時(shí)建立了6條tcp連接，觀察瀏覽器網(wǎng)絡(luò)請(qǐng)求加載圖如下：
2_9.jpg

f.http1.1 支持pipelining（流水線） 條件是：sever端需要支持，同時(shí)瀏覽器也要開啟，工作原理如下圖：

2_10.jpg

HTTP Pipelining其實(shí)是把多個(gè)HTTP請(qǐng)求放到一個(gè)TCP連接中一一發(fā)送，而在發(fā)送過程中不需要等待服務(wù)器對(duì)前一個(gè)請(qǐng)求的響應(yīng)；只不過，客戶端還是要按照發(fā)送請(qǐng)求的順序來接收響應(yīng)！

g.查詢了 火狐瀏覽器開啟pipelining方法：

在搜索欄輸入 network.http.pipelining ，查詢一下，如果沒有，請(qǐng)右擊鼠標(biāo)，選擇“新建”——布爾，然后輸入 network.http.pipelining ,賦值true，然后點(diǎn)擊確定。

解釋：激活這個(gè)鍵值之后，Pipelining同時(shí)發(fā)出成倍數(shù)的連接請(qǐng)求，從而達(dá)到提升連接速度的效果。網(wǎng)絡(luò)上的大多數(shù)網(wǎng)站都是基于HTTP協(xié)議，而HTTP1.1可以支持多線程的連接請(qǐng)求，通過這個(gè)操作可以減少Firefox載入網(wǎng)頁的時(shí)間。

h.總結(jié)：http1.x問題：

在HTTP1.0中，發(fā)送一次請(qǐng)求時(shí)，需要等待服務(wù)端響應(yīng)了才可以繼續(xù)發(fā)送請(qǐng)求。

在HTTP1.1中，發(fā)送一次請(qǐng)求時(shí)，不需要等待服務(wù)端響應(yīng)了就可以發(fā)送請(qǐng)求了，但是回送數(shù)據(jù)給客戶端的時(shí)候，客戶端還是需要按照響應(yīng)的順序來一一接收

所以說，無論是HTTP1.0還是HTTP1.1提出了Pipelining理論，還是會(huì)出現(xiàn)阻塞的情況。從專業(yè)的名詞上說這種情況，叫做線頭阻塞（Head of line blocking）簡(jiǎn)稱：HOLB

a.SSL(Secure Sockets Layer) 安全套接層，是一種安全協(xié)議，經(jīng)歷了 SSL 1.0、2.0、3.0 版本后發(fā)展成了標(biāo)準(zhǔn)安全協(xié)議 - TLS(Transport Layer Security) 傳輸層安全性協(xié)議。TLS 有 1.0 (RFC 2246)、1.1(RFC 4346)、1.2(RFC 5246)、1.3(RFC 8446) 版本。

TLS 在實(shí)現(xiàn)上分為 記錄層 和 握手層 兩層，其中握手層又含四個(gè)子協(xié)議: 握手協(xié)議 (handshake protocol)、更改加密規(guī)范協(xié)議 (change cipher spec protocol)、應(yīng)用數(shù)據(jù)協(xié)議 (application data protocol) 和警告協(xié)議 (alert protocol)

2_11.jpg

HTTPS = HTTP over TLS.

b.抓包分析：

ClientHello
2_12.jpg

Version: 協(xié)議版本（protocol version）指示客戶端支持的最佳協(xié)議版本

Random: 一個(gè) 32 字節(jié)數(shù)據(jù)，28 字節(jié)是隨機(jī)生成的 (圖中的 Random Bytes)；剩余的 4 字節(jié)包含額外的信息，與客戶端時(shí)鐘有關(guān) (圖中使用的是 GMT Unix Time)。在握手時(shí)，客戶端和服務(wù)器都會(huì)提供隨機(jī)數(shù)，客戶端的暫記作 random_C (用于后續(xù)的密鑰的生成)。這種隨機(jī)性對(duì)每次握手都是獨(dú)一無二的，在身份驗(yàn)證中起著舉足輕重的作用。它可以防止 重放攻擊，并確認(rèn)初始數(shù)據(jù)交換的完整性。

Session ID: 在第一次連接時(shí)，會(huì)話 ID（session ID）字段是空的，這表示客戶端并不希望恢復(fù)某個(gè)已存在的會(huì)話。典型的會(huì)話 ID 包含 32 字節(jié)隨機(jī)生成的數(shù)據(jù)，一般由服務(wù)端生成通過 ServerHello 返回給客戶端。

Cipher Suites: 密碼套件（cipher suite）塊是由客戶端支持的所有密碼套件組成的列表，該列表是按優(yōu)先級(jí)順序排列的

Compression: 客戶端可以提交一個(gè)或多個(gè)支持壓縮的方法。默認(rèn)的壓縮方法是 null，代表沒有壓縮

Extensions: 擴(kuò)展（extension）塊由任意數(shù)量的擴(kuò)展組成。這些擴(kuò)展會(huì)攜帶額外數(shù)據(jù)

c.繪制流程圖如下：
2_13.jpg

d.HTTP2與HTTP1.1最重要的區(qū)別就是解決了線頭阻塞的問題！其中最重要的改動(dòng)是：多路復(fù)用 (Multiplexing)

如圖所示：
2_14.jpg

e.HTTP2所有性能增強(qiáng)的核心在于新的二進(jìn)制分幀層(不再以文本格式來傳輸了)，它定義了如何封裝http消息并在客戶端與服務(wù)器之間傳輸。
2_15.jpg

f.看上去協(xié)議的格式和HTTP1.x完全不同了，實(shí)際上HTTP2并沒有改變HTTP1.x的語義，只是把原來HTTP1.x的header和body部分用frame重新封裝了一層而已
2_16.jpg

g.問題：被封裝后，不用每次攜帶header，但是header里這個(gè)body的長(zhǎng)度，這怎么處理呢？

方法：body上加上length解決

Headers Frame: 幀頭
2_17.jpg

h.問題一：body分了許多個(gè)strem，怎么確定完結(jié)？

抓包分析：
2_18.jpg

2_19.jpg

2_20.png

分了三個(gè)包分別為：8192+8192+5281

當(dāng)前看到的是分包后，最大的包大小是 8192

展示圖如下：
2_21.jpg

i.問題二：怎么確定沒丟包，錯(cuò)沒錯(cuò)，秩序亂沒亂，怎么合包

tcp會(huì)保證包有序，并且保證了不會(huì)丟包

HTTP2所有性能增強(qiáng)的核心在于新的二進(jìn)制分幀層(不再以文本格式來傳輸了)，它定義了如何封裝http消息并在客戶端與服務(wù)器之間傳輸。

j.抓包分析請(qǐng)求：
2_22.jpg

觀察http2的瀏覽器網(wǎng)絡(luò)請(qǐng)求加載圖如下：
2_23.jpg

附課堂板書：

2_24.jpg