Http Connection有兩種連接方式：短連接和長連接；短連接即一次請求對應一次TCP連接的建立和銷毀過程，而長連接是多個請求共用同一個連接這樣可以節省大量連接建立時間提高通信效率。目前主流瀏覽器都會在請求頭里面包含Connection:keep-alive字段，該字段的作用就是告訴HTTP服務器響應結束后不要關閉連接，瀏覽器會將建立的連接緩存起來，當在有限時效內有再次對相同服務器發送請求時則直接從緩存中取出連接進行通信。當然被緩存的連接如果空閑時間超過了設定值（如firefox為115s，IE為60s）則會關閉連接。
當使用短連接的時候Recipient可以通過服務器端對Connection的關閉來正確獲得消息體的結束位置；但長連接的時候Recipient怎么正確得知相鄰兩次請求的響應內容的分界位置呢？主要是采用設置響應頭Content-Length或者Transfer-Encoding:chunked的方法來解決這一問題。
Chunked transfer encoding是一種數據傳輸機制,將消息體分成若干塊從Server傳輸到Recipient(接收者);目前采用chunked傳輸方式比較多，為什么要采用chunked下面會說；如果不采用chunked傳輸方式則必須設置Content-Length字段，以便使Recipient能夠正確獲知消息體的結束位置，而為什么采用chunked不用設置Content-Length字段呢？因為chunked傳輸方式特定的格式可以使Recipient正確獲知消息體的結束。
Chunked傳輸即分塊傳輸：將響應主體分成若干塊，並在每一塊前面加上該塊數據的長度以及回車換行，這樣Recipient（如瀏覽器）就可以根據這個長度值正確接收每一塊數據，最后以一個0長度的分塊作為消息體的結束標志。采用該傳輸方式Sender在開始傳輸響應內容到Recipient前不需要知道內容的長度。
Chunked消息體格式如下：
hex的分塊長度+<CR>回車+<LF>換行
chunked data
結束塊的分塊長度為0
如要發送的內容(消息體)為：123456789那么消息體的格式為：
9<CR><LF>
123456789<CR><LF>
0<CR><LF>
采用分塊傳輸方式的好處：
（1）由於在服務器發送數據到Recipient前不需要知道數據的字節長度，所以可以動態產生響應內容而不用先將所有數據進行緩存；由於當消息體結束的時候有明確的信號標識（0<CR><LF>），因此后面對同一HTTP服務器的請求可以復用本次連接。
（2）允許服務器在消息體后面發送額外的響應頭字段，這個非常重要當一個字段的值要等到響應內容全部產生后才能確定的情況下，如響應內容的數字簽名，如果不使用分塊傳輸服務器為了計算響應內容的算數字簽名則必須先緩存所有內容直到內容產生完成。（如果不采用Chunked分塊傳輸則在消息體后面發送的響應頭不能被Recipient正確獲取）
（3）HTTP服務器有時使用compression(gzip或者deflate)方法優化傳輸即對被傳輸的字節進行壓縮，chunked和gzip編碼相互之間作用在HTTP編碼的兩個階段；第一階段響應內容字節流采用gzip進行壓縮編碼,壓縮完成后產生的字節流采用chunked的方式進行傳輸編碼，這意味着chunked和compression可以同時使用，只是作用於不同的階段。