共計 1194 個字符，預計需要花費 3 分鐘才能閱讀完成。

這篇文章給大家介紹 http 請求如何確定邊界，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

S3 上傳有兩種 method 方式 PUT 請求：這個上傳請求上傳對象協議明確攜帶 Content-length 的；POST 請求：這個不要求知名 Content-length，而是通過一種流式的數據傳輸，但是總歸還是要知道邊界在哪里？有以下幾種方式讓服務端知道數據的邊界；     HTTP 數據怎么確定邊界？

S3 是基于 HTTP 的協議，HTTP 是基于 TCP 協議的應用層協議，而 TCP 是面向數據流的協議，是沒有邊界的。HTTP 作為應用層協議需要自己明確定義數據邊界。

HTTP 邊界判定由于 http1.1 協議之后，http 可以是一個 keep-alive 的，可以是一個流式協議。那么我們需要有辦法去標識 body 邊界，有三種方式：

http 包頭部顯式設置 Content-Lengthhttp 傳輸編碼方式用 Transfer-Encoding: chunked 短連接（連接斷開）（第 3 種情況，一般作為異常場景看待。所以下面我們就討論前兩種情況）

這兩種情況都取決于客戶端的協議是否遵守。正常情況，如果傳輸了 Content-Length，就要和 body 一致。如果頭部沒有這個字段，那么也可以客戶端采用 Transfer-Encoding：chunked 的編碼方式傳輸 body，也能讓服務器正確的識別 body 的邊界。

      分四種情況討論

情況一：如果只設置了 Content-Length，但是 body 不準，怎么辦？

Content-Length 比 body 大？服務器一般實現會設置一個超時。服務端主動斷開連接，報告超時。這個當前線上系統由 nginx 完成，1 分鐘超時。客戶端自己  ctrl+c，客戶端主動斷開連接服務一般是卡主，服務器等待讀完客戶端聲明的數據。解決方法兩種：Content-Length 比 body 小？請求成功，數據截斷

情況二：如果沒有 Content-Length，設置了 Transfer-Encoding：Chunked？

這個時候能正確識別到邊界，以 Chunked 模式為準。有無 Content-Length 沒區別。就算設置了 Content-Length，也不會依賴用這個值，不準也沒關系。只要是按照 chunked 的模式，以實際取到的 body 為準。

情況三：Content-Length 和 Transfer-Encoding 都設置？

以 chunked 傳輸為準。

情況四：Content-Length 和 Transfer-Encoding 都沒設置？

這種情況和 Content-Length= 0 是一樣處理的。

      截圖示例      Chunked 的包

     Content-Length 的包

關于 http 請求如何確定邊界就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。