什么是Content-Length？
Content-Length是HTTP消息長度，用十進制數字表示的八位字節的數字，是Headers中常見的一個字段。Content-Length應該是精確的，否則就會導致異常 ( HTTP1.0中這個字段可有可無)。
Content-Length字段指出報文中實體主體的字節大小。這個大小是包含了所有內容編碼的。比如, 對文本文件進行了gzip壓縮的話，Content-Length首部指的就是壓縮后的大小而不是原始大小。
Content-Length是如何工作的
Content-Length使用十進制的數字表示了消息的長度，服務端/客戶端通過它來得知后續要讀取消息的長度。
如果這個長度不正確, 會發生如下情況：
Content-Length > 實際長度
如果Content-Length比實際的長度大，服務端/客戶端讀取到消息結尾后，會等待下一個字節，自然會無響應直到超時。
同樣地，在響應消息中Content-Length超過實際長度也是一樣的效果：
Content-Length < 實際長度
如果這個長度小於實際長度，首次請求的消息會被截取，比如參數為param=piaoruiqing，Content-Length為10，那么這次請求的消息會被截取為: param=piao，如圖所示：
但，僅僅是如此嗎，當然不，我們再來看看第二次請求會發生什么讓人意外的事情，如圖：
連續的兩次請求，第一次消息被截斷，而第二次沒有發生預期的截斷，而是服務端拋出了異常: Request method 'ruiqingPOST' not supported。刺不刺激？
那 ruiqingPOST是個什么神仙方法??? 此時，憑着多年開發(DEBUG)經驗練就的敏感度，我們大致可以猜出，上一次請求被截取剩下的消息，在這次請求出現了。掏出wireshark來驗證一下，如圖：
導致這種情況的原因就是開啟了Connection:keep-alive，如果使用Connection:close，所產生的現象就是每一次的請求都被截斷，但不會產生解析混亂(如將上一次剩下的消息拼接到后續的請求消息中)。
不確定Content-Length的值怎么辦？
Content-Length首部指示出報文中實體主體的字節大小。但如在請求處理完成前無法獲取消息長度，我們就無法明確指定Content-Length，此時應該使用Transfer-Encoding: chunked
什么是Transfer-Encoding: chunked
數據以一系列分塊的形式進行發送。Content-Length 頭部在這種情況下不會被設置發送。在每一個分塊的開頭需要添加當前分塊的長度，以十六進制的形式表示，后面緊跟着 \r\n，之后是分塊本身，后面也是\r\n。終止塊是一個常規的分塊，不同之處在於其長度為0。
Transfer-Encoding: chunked是如何工作的
接下來我們用一個下載文件的例子，來探討Transfer-Encoding: chunked是如何工作的。服務端代碼如下：
使用postman發起請求，wireshark抓包查看，如圖：
在wireshark中可以很清晰地看到chunked的數據，其結構大致是：返回的消息被分為多個數據塊，每個數據塊有兩部分，長度 + 數據，這兩部分都以CRLF(即\r\n)結尾。而終止塊是一個特殊的數據塊，其長度為0，如圖：
如此，即完成了分塊編碼。其主要應用於如下場景，即要傳輸大量的數據，但是在請求在沒有被處理完之前響應的長度是無法獲得的。例如，當需要用從數據庫中查詢獲得的數據生成一個大的HTML表格、需要傳輸大量的圖片等。
PS:
Content-Length如果需要存在且生效，那么他的值必須是正確的，否則會發生異常。(大於實際值會超時，小於實際值會截斷並可能導致后續的數據解析混亂)
如果報文中包含Transfer-Encoding: chunked首部, 那么Content-Length將被忽略。