【筆記整理】http協議淺析（二）

做者：楊志曉

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

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

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

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

如圖所示：
2_14.jpg

e.HTTP2全部性能加強的核心在於新的二進制分幀層(再也不以文本格式來傳輸了)，它定義瞭如何封裝http消息並在客戶端與服務器之間傳輸。
2_15.jpg

f.看上去協議的格式和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，怎麼肯定完結？

抓包分析：
2_18.jpg

2_19.jpg

2_20.png

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

當前看到的是分包後，最大的包大小是 8192

展現圖以下：
2_21.jpg

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

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

HTTP2全部性能加強的核心在於新的二進制分幀層(再也不以文本格式來傳輸了)，它定義瞭如何封裝http消息並在客戶端與服務器之間傳輸。

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

觀察http2的瀏覽器網絡請求加載圖以下：
2_23.jpg

附課堂板書：

2_24.jpg