作者：楊志曉

http的版本：

a.HTTP建立在TCP協議之上。

b.HTTP/0.9 於1991年發佈。

c.HTTP/1.0 於1996年發佈。

d.HTTP/1.1 於1999年發佈。

e.HTTP/2 於2015年發佈。

http 1.0 no keep-alive（默認短鏈接）

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

b.每次與服務器交互，都需要新開一個連接！

2_2.jpg

c.抓包分析：

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

2_3.jpg

2_4.jpg

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

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

http 1.1 默認有 keep-alive

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

HTTP 1.1增加host字段
HTTP 1.1中引入了Chunked transfer-coding，範圍請求，實現斷點續傳(實際上就是利用HTTP消息頭使用分塊傳輸編碼，將實體主體分塊傳輸)
HTTP 1.1管線化(pipelining)理論，客戶端可以同時發出多個HTTP請求，而不用一個個等待響應之後再請求
- 注意：這個pipelining僅僅是限於理論場景下，大部分桌面瀏覽器仍然會選擇默認關閉HTTP pipelining！
- 所以現在使用HTTP1.1協議的應用，都是有可能會開多個TCP連接的！

b.工作原理如圖：

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

2_5.jpg

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

2_6.jpg

5個請求發起一條tcp連接

2_7.jpg

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

2_8.jpg

e.通過增加圖片個數抓包後發現，瀏覽器同時建立了6條tcp連接，觀察瀏覽器網絡請求加載圖如下：
2_9.jpg

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

2_10.jpg

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

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

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

解釋：激活這個鍵值之後，Pipelining同時發出成倍數的連接請求，從而達到提升連接速度的效果。網絡上的大多數網站都是基於HTTP協議，而HTTP1.1可以支持多線程的連接請求，通過這個操作可以減少Firefox載入網頁的時間。

h.總結：http1.x問題：

在HTTP1.0中，發送一次請求時，需要等待服務端響應了纔可以繼續發送請求。

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

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

http2.0（建立在https基礎上）

a.SSL(Secure Sockets Layer) 安全套接層，是一種安全協議，經歷了 SSL 1.0、2.0、3.0 版本後發展成了標準安全協議 - TLS(Transport Layer Security) 傳輸層安全性協議。TLS 有 1.0 (RFC 2246)、1.1(RFC 4346)、1.2(RFC 5246)、1.3(RFC 8446) 版本。

TLS 在實現上分爲 記錄層 和 握手層 兩層，其中握手層又含四個子協議: 握手協議 (handshake protocol)、更改加密規範協議 (change cipher spec protocol)、應用數據協議 (application data protocol) 和警告協議 (alert protocol)

2_11.jpg

HTTPS = HTTP over TLS.

b.抓包分析：

ClientHello
2_12.jpg

Version: 協議版本（protocol version）指示客戶端支持的最佳協議版本
Random: 一個 32 字節數據，28 字節是隨機生成的 (圖中的 Random Bytes)；剩餘的 4 字節包含額外的信息，與客戶端時鐘有關 (圖中使用的是 GMT Unix Time)。在握手時，客戶端和服務器都會提供隨機數，客戶端的暫記作 random_C (用於後續的密鑰的生成)。這種隨機性對每次握手都是獨一無二的，在身份驗證中起着舉足輕重的作用。它可以防止重放攻擊，並確認初始數據交換的完整性。
Session ID: 在第一次連接時，會話 ID（session ID）字段是空的，這表示客戶端並不希望恢復某個已存在的會話。典型的會話 ID 包含 32 字節隨機生成的數據，一般由服務端生成通過 ServerHello 返回給客戶端。
Cipher Suites: 密碼套件（cipher suite）塊是由客戶端支持的所有密碼套件組成的列表，該列表是按優先級順序排列的
Compression: 客戶端可以提交一個或多個支持壓縮的方法。默認的壓縮方法是 null，代表沒有壓縮
Extensions: 擴展（extension）塊由任意數量的擴展組成。這些擴展會攜帶額外數據

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