一個月沒寫，自己定的目標沒有實現，不想寫太水的內容。但這一篇可能又是水

我在排查httpclient問題時，發現了這個請求頭，但不知道是做什麼用的,於是百度一下

一、Transfer-Encoding: chunked
Transfer-Encoding頭欄位可以用在請求頭或響應頭中。該頭欄位有兩個值chunked和identity
作用:
Transfer-Encoding值為chunked時，代表要把請求的資料或響應的資料切割成一系列的塊資料傳輸。
Transfer-Encoding值為identity時，代表不做任何處理。
好了，現在我們瞭解到設定chunked的作用就是分塊傳輸資料。那分塊傳輸的目的又是為了什麼呢？
要注意: 分塊傳輸不會減少請求的內容的大小，因為要調整請求報文格式，可能還會導致傳輸內容變大.與Content-Encoding欄位作用不同

二、分塊目的
先丟擲:
分塊傳輸的目的是為了實現長連線, 有了長連線後就可以實現連線池.
長連線和連線池的作用是可以提高http請求的效能。

三、http長連如何實現?
1.什麼是短連線?
連線->傳輸資料->關閉連線

2.什麼是長連線?
連線->傳輸資料->保持連線 -> 傳輸資料-> 。。。 ->關閉連線。

3.長連線為什麼可以提效能？
HTTP執行在TCP連線之上，自然也有著跟TCP一樣的三次握手、四次揮手、慢啟動等特性。使用長連線可以減少三次握手、還可以避免遇上TCP慢啟動的擁塞適應階段等時間，自然可以提高效能。

4.如何設定http短連為長連？
答案: Connection: keep-alive (關於這個頭部欄位詳細看參考)

5.那問題又來了，配置完keep-alive後，http連線如何來確定請求或響應的實體邊界，即我們怎麼知道某一次的請求內容或響應內容已傳送完成?

兩個方案:
1、是判斷傳輸資料是否達到了Content-Length指示的大小。具體方法:計算實體長度，並通過頭部告訴對方
2、設定Transfer-Encoding:chunked，進行分塊傳輸。
方案1的問題在於某些情況下實體長度並沒那麼好獲得(如網路響應大檔案，獲取長度比較耗時，客戶端需要等待較長時間),於是有了方案2.


下面說一下方案2 
設定Transfer-Encoding:chunked後，代表報文采用了分塊編碼，報文改為一系列分塊來傳輸。
報文格式要求如下:
每個分塊包含十六進位制的長度值和資料，長度值獨佔一行，長度不包括它結尾的 CRLF（\r\n），也不包括分塊資料結尾的 CRLF。最後一個分塊長度值必須為 0，對應的分塊資料沒有內容，表示實體結束.
例如(紅色為對報文的註釋說明,非報文內容一部分):

b\r\n /*此處的b是16進位制，代表了10進位制的10,即說下一行內容長度為*/
 
01234567890\r\n
5\r\n
12345\r\n'
0\r\n' /*0代表下一行沒有內容，傳輸結束*/
\r\n'

四、問題
1、短連如何確認一次請求完成?
伺服器通常在傳送回所請求的資料之後就關閉連線。這樣客戶端讀資料時會返回EOF（-1），就知道資料已經接收完全了

五、

這個文章相對來講水一些，只是自己東拼西湊整理的一些。如有錯誤，還請留言指正.

下一篇會整理些BigDecimal相關資訊，之後會寫一些MySQL InnoDB相關的資訊,全部參考《MySQL技術內幕 InnoDB儲存引擎（第二版）》

參考:
http://www.cnblogs.com/skynet/archive/2010/12/11/1903347.html
https://blog.csdn.net/hellochenlu/article/details/56841896
https://www.cnblogs.com/zhanjindong/p/httpclient-connection-pool.html
https://imququ.com/post/transfer-encoding-header-in-http.html
https://www.zhoulujun.cn/html/webfront/SGML/web/2015_1016_317.html