HTTP協議篇(一)：多路複用、數據流

管道機制、多路複用

管道機制(Pipelining)

---

 HTTP 1.1 引入了管道機制（Pipelining），即客戶端可經過同一個TCP鏈接同時發送多個請求。若是客戶端須要請求兩個資源，之前的作法是在同一個TCP鏈接裏面，先發送A請求，而後等待服務器作出迴應，收到後再發出B請求；而管道機制則容許瀏覽器同時發出A請求和B請求，可是服務器仍是按照順序，先回應A請求，完成後再回應B請求。

 

多路複用(Multiplexing)

---

雖然 HTTP 1.1 默認啓用長TCP鏈接，但全部的請求-響應都是按序進行的(這裏的長鏈接可理解成半雙工協議。即使是HTTP 1.1引入了管道機制，也是如此)。複用同一個TCP鏈接期間，即使是經過管道同時發送了多個請求，服務端也是按請求的順序依次給出響應的；而客戶端在未收到以前所發出全部請求的響應以前，將會阻塞後面的請求(排隊等待)，這稱爲"隊頭堵塞"（Head-of-line blocking）。

HTTP/2複用TCP鏈接則不一樣，雖然依然遵循請求-響應模式，但客戶端發送多個請求和服務端給出多個響應的順序不受限制，這樣既避免了"隊頭堵塞"，又能更快獲取響應。在複用同一個TCP鏈接時，服務器同時(或前後)收到了A、B兩個請求，先回應A請求，但因爲處理過程很是耗時，因而就發送A請求已經處理好的部分， 接着迴應B請求，完成後，再發送A請求剩下的部分。HTTP/2長鏈接能夠理解成全雙工的協議。

 

Content-Length

---

Content-length 聲明本次響應的數據長度。keep-alive 鏈接能夠前後傳送多個響應，所以用Content-length來區分數據包是屬於哪個響應。在HTTP 1.0 中，Content-Length字段不是必需的，由於瀏覽器與服務器通訊使用的是短鏈接，服務端發送完數據關閉TCP鏈接，就代表收到的數據包已經全了。

 

分塊傳輸(Chunked)、數據流

分塊傳輸(Chunked)

---

使用Content-Length字段的前提條件是，服務器發送響應以前，必須知道響應的數據長度。 對於一些很耗時的動態操做來講，這意味着，服務器要等到全部操做完成，才能發送數據，顯然這樣的效率不高。更好的處理方法是，產生一塊數據，就發送一塊，採用"流模式"（Stream）取代"緩存模式"（Buffer）。所以，HTTP 1.1 規定能夠不使用Content-Length字段，而使用"分塊傳輸編碼"（Chunked Transfer Encoding）。只要請求或響應的頭信息有Transfer-Encoding: chunked字段，就代表body將可能由數量未定的多個數據塊組成。

每一個數據塊以前會有一行包含一個16進制數值，表示這個塊的長度；最後一個大小爲0的塊，就表示本次響應的數據發送完了。

HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked

25
This is the data in the first chunk

1C
and this is the second one

3
con

8
sequence

0

 

數據流

---

HTTP/2 長鏈接中的數據包是不按請求-響應順序發送的，一個完整的請求或響應(稱一個數據流stream，每一個數據流都有一個獨一無二的編號)可能會分紅非連續屢次發送。數據包發送的時候，都必須標記所屬的數據流ID，用來區分它屬於哪一個數據流。另外還規定，客戶端發出的數據流，ID一概爲奇數，服務器發出的，ID爲偶數。數據流發送到一半的時候，客戶端和服務器均可以發送信號（RST_STREAM幀）取消這個數據流。HTTP 1.1 取消數據流的惟一方法，就是關閉TCP鏈接；HTTP/2 取消某一次請求，同時保證TCP鏈接還打開着，能夠被其餘請求使用。客戶端還能夠指定數據流的優先級，優先級越高，服務器就會越早響應。