用了這麼久HTTP, 你是否瞭解Content-Length和Transfer-Encoding ?

由Content-Length致使的問題引起的一系列思考: 前段時間開發API網關, 使用postman調試時出現了超時的狀況, 經排查肯定是請求數據被處理後Content-Length與實際不一致致使的問題, 故有此文.

文章地址: blog.piaoruiqing.com/blog/2019/0…

前言

Content-Length, HTTP消息長度, 用十進制數字表示的八位字節的數目. 通常狀況下, 不少工做都被框架完成, 咱們不多去關注這部份內容, 但少數狀況下發生了Content-Length與實際消息長度不一致, 程序可能會發生比較奇怪的異常, 如:

• 無響應直到超時.
• 請求被截斷, 並且下一個請求解析出現錯亂.

什麼是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, 所產生的現象就是每一次的請求都被截斷, 但不會產生解析混亂(如將上一次剩下的消息拼接到後續的請求消息中).

[版權聲明]
本文發佈於 樸瑞卿的博客, 容許非商業用途轉載, 但轉載必須保留原做者 樸瑞卿 及連接: blog.piaoruiqing.com. 若有受權方面的協商或合做, 請聯繫郵箱: piaoruiqing@gmail.com.

不肯定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表格、須要傳輸大量的圖片等.

結語

• Content-Length若是存在且生效, 必須是正確的, 不然會發生異常.(大於實際值會超時, 小於實際值會截斷並可能致使後續的數據解析混亂)
• 若是報文中包含Transfer-Encoding: chunked首部, 那麼Content-Length將被忽略.

若是這篇文章對您有幫助，請點個贊吧 (￣▽￣)"

參考文獻

• developer.mozilla.org
• 《HTTP權威指南》

推薦閱讀:

• 秒殺場景實踐之搶紅包
• Redis分佈式鎖

歡迎關注公衆號(代碼如詩):

[版權聲明]
本文發佈於 樸瑞卿的博客, 容許非商業用途轉載, 但轉載必須保留原做者 樸瑞卿 及連接: blog.piaoruiqing.com. 若有受權方面的協商或合做, 請聯繫郵箱: piaoruiqing@gmail.com.