圖解http筆記-2

持久鏈接

http的初始版本中，沒進行一次http通訊就要斷開鏈接。
之前傳輸的內容都是很小的，可是如今，當一個瀏覽器請求一個有很圖片的html網頁時，要請求html文檔，也要請求圖片等資源，就要進行不少次TCP的斷開和鏈接，增長通訊的開銷。
因此就有了HTTP keep-alive的方法：
只要一端沒有明確提出斷開鏈接，就保持TCP的鏈接。

'Connection': 'keep-alive'

---

http報文內的http信息：

對於http報文來講，分爲：

• 請求報文 (請求端/客戶端)
• 響應報文 (響應端/服務端)

報文的結構：

首部內容有如下部分組成：

• 請求行：包含請求的方法，請求URI和HTTP版本
• 狀態行：包含代表響應結果的狀態碼，緣由短語和HTTP版本
• 首部字段：包含請求和響應的各類條件和屬性的各種首部，通常分爲:
  • 通用首部
  • 請求首部
  • 響應首部
  • 實體首部
• 其餘：其餘的HTTP的RFC內未包含的首部（cookie等）

---

傳輸中的編碼

報文主體和實體主體的差別

HTTP報文的主體用於傳輸請求或者響應的實體主體。
一般，他們是同樣的，可是當傳輸過程當中進行編碼操做時，致使實體主體的內容發生變化，就會和報文主體產生差別。

壓縮傳輸內容的編碼

好比發送郵件附件時，能夠使用編碼使郵件的容量變小。
經常使用的內容編碼有：

• gzip （GNU zip）
• compress （UNIX系統的標準壓縮）
• deflate (zlib)
• identity (不進行編碼)

這些信息會寫在HTTP報文的首部裏，例如這裏是我截取下來的請求某個網站時的頭部：

'Accept': 'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8'
'Accept-Encoding': 'gzip, deflate, br'
'Accept-Language': 'zh-CN,zh;q=0.9'

該內容的解碼是由客戶端負責壓縮

分塊傳輸編碼

請求的編碼的實體還未傳輸完以前，瀏覽器沒法顯示請求的頁面。對於較大的數據，經過把數據分割爲不少塊，能讓瀏覽器逐步顯示頁面。
分塊傳輸編碼會將實體分紅不少部分，每一個部分都會用16進制來標記數據的大小，最後一塊會使用"0(CR+LF)"來標記

多部分對象集合

當咱們發送郵件時，可能會包含圖片，文件，視頻等，採用MIME（多用途因特網擴展）機制。而在MIME中 採用了多部分對象集合的方法
當在HTTP報文中使用多部分對象集合時，回來首部字段中添加content-type,例：

'Content-Type': 'application/x-www-form-urlencoded'

---

獲取部份內容的範圍請求

範圍請求：指定範圍發送的請求
用於傳輸一個很大的文件的斷開後繼續傳輸。例如10000字節的資源，能夠只請求5001~10000字節內的資源
若是服務器沒法響應範圍請求，則返回狀態碼200 OK和完整的實體內容

內容協商返回最合適的內容

包含在請求報文中的某些首部字段就是判斷的基準：

Accpet:
Accept-Charset:
Accept-Encoding:
Accept-Language:
Content-Language:

內容協商的技術有：

• 服務器驅動協商（以請求的首部字段做參考，服務器端自動處理）
• 客戶端驅動協商 （用戶從瀏覽器顯示的可選列表中手動選擇）
• 透明協商 （以上兩種方法的結合）