Accept-Encoding、Content-Encoding、Transfer-Encoding

一、爲什麼要編碼（壓縮）

• 編碼的目的就是爲了壓縮報文實體內容的大小，而通過壓縮服務器響應報文傳輸的內容實體，在一定程度上就可以加快響應的速度。
• encode:If you encode a message or some information, you put it into a code or express it in a different form or system of language.
  Accept-Encoding:設置接受的編碼格式（對內容[body部分]壓縮方式）

二、Accept-encoding與Content-encoding壓縮過程

1. 瀏覽器發送Http request 給Web服務器, request 中有Accept-Encoding: gzip, deflate。 (告訴服務器， 瀏覽器支持gzip壓縮)

2. Web服務器接到request後， 生成原始的Response, 其中有原始的Content-Type和Content-Length。

3. Web服務器通過Gzip，來對Response進行編碼， 編碼後header中有Content-Type和Content-Length(壓縮後的大小)， 並且增加了Content-Encoding:gzip. 然後把Response發送給瀏覽器。

4. 瀏覽器接到Response後，根據Content-Encoding:gzip來對Response 進行解碼。 獲取到原始response後， 然後顯示出網頁。

（因爲客戶端Accept-Encoding有可能提供了多種解壓方式，所以服務端返回時，要指定是用哪種壓縮方式進行壓縮的）

三、二中爲什麼要加content-length

• 在http1.0時非持久連接，是用連接是否關閉來界定請求或響應實體的邊界；對於http1.1持久連接（瀏覽器可以重用已經打開的空閒持久連接，來避免三次握手，從而避免遇上TCP慢啓動的擁塞適應階段），顯然不奏效，因爲連接並沒有關閉，造成瀏覽器並不知道已經發送完畢（儘管服務端已經發送完所有數據），從而導致響應內容不會顯示在瀏覽器界面上。
• 要解決這個問題可以在響應頭上加content-length，瀏覽器用此字段判斷響應實體結束。
• 但是content-length有時並不容易獲取，需要開足夠大的buffer，等內容全部生成再計算，從而造成內存開銷大而且用戶等待時間長（這不利於用戶體驗），爲解決此問題，有了Transfer-Encoding。

四、傳輸編碼Transfer-Encoding解決的問題

• Transfer-Encoding會改變報文的格式和傳輸方式，使用它不會減少內容傳輸的大小，甚至會使傳輸變大，但是解決了content-length所帶來的問題。

五、Transfer-Encoding-Chunked格式

• 將報文中實體用分塊方式來傳輸。每個分塊包含16進制的長度值及數據，最後一個分塊長度值必須爲0，代表傳輸結束。
• Transfer-Encoding: chunked：數據以一系列分塊的形式進行發送。 Content-Length 首部在這種情況下不被髮送。

六、Content-Encoding和Transfer-Encoding結合使用

即先對內容壓縮，再對其分塊傳輸。

參考：https://blog.csdn.net/zhangzeguang88/article/details/51554097
https://www.cnblogs.com/plokmju/p/http_code.html