摘要：作者楊志曉的版本建立在協(xié)議之上。網(wǎng)絡(luò)上的大多數(shù)網(wǎng)站都是基于協(xié)議，而可以支持多線程的連接請求，通過這個操作可以減少載入網(wǎng)頁的時間。它可以防止重放攻擊，并確認(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ù)器交互，都需要新開一個連接！

2_2.jpg

c.抓包分析：

demo：4張圖片+html總共5個請求

2_3.jpg

2_4.jpg

每一條tcp鏈接都會直接返回connection close

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

a.相對于持久化連接還有另外比較重要的改動：

HTTP 1.1增加host字段

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

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

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

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

b.工作原理如圖：

只建立一條tcp鏈接，但是每個請求都是串行的，如下圖所示

2_5.jpg

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

2_6.jpg

5個請求發(fā)起一條tcp連接

2_7.jpg

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

2_8.jpg

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

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

2_10.jpg

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

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

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

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

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

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

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

所以說，無論是HTTP1.0還是HTTP1.1提出了Pipelining理論，還是會出現(xiàn)阻塞的情況。從專業(yè)的名詞上說這種情況，叫做線頭阻塞（Head of line blocking）簡稱：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 在實現(xiàn)上分為 記錄層 和 握手層 兩層，其中握手層又含四個子協(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: 一個 32 字節(jié)數(shù)據(jù)，28 字節(jié)是隨機生成的 (圖中的 Random Bytes)；剩余的 4 字節(jié)包含額外的信息，與客戶端時鐘有關(guān) (圖中使用的是 GMT Unix Time)。在握手時，客戶端和服務(wù)器都會提供隨機數(shù)，客戶端的暫記作 random_C (用于后續(xù)的密鑰的生成)。這種隨機性對每次握手都是獨一無二的，在身份驗證中起著舉足輕重的作用。它可以防止 重放攻擊，并確認(rèn)初始數(shù)據(jù)交換的完整性。

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

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

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

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

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

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

如圖所示：
2_14.jpg

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

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

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

方法：body上加上length解決

Headers Frame: 幀頭
2_17.jpg

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

抓包分析：
2_18.jpg

2_19.jpg

2_20.png

分了三個包分別為：8192+8192+5281

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

展示圖如下：
2_21.jpg

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

tcp會保證包有序，并且保證了不會丟包

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

j.抓包分析請求：
2_22.jpg

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

附課堂板書：

2_24.jpg