Keep-Alive模式
我們都知道HTTP是基於TCP的，每一個HTTP請求都需要進行三步握手。如果一個頁面對某一個域名有多個請求，就會進行頻繁的建立連接和斷開連接。所以HTTP 1.0中出現了Connection: keep-alive，用於建立長連接，即我們所說的Keep-Alive模式。下圖是普通模式和長連接模式的請求對比：
HTTP/1.0中默認使用Connection: close。在HTTP/1.1中已經默認使用Connection: keep-alive。
通過對比可以看出，Keep-Alive模式更加高效，因為避免了連接建立和釋放的開銷。但是，如果一個連接是不會斷開的，那么多個請求之間如何進行區分呢？也就是說瀏覽器是如何知道當前請求已經完成了呢？為了解決這個問題，HTTP對header中又添加了一個Content-Length字段。
Content-Length
Content-Length表示實體內容的長度。瀏覽器通過這個字段來判斷當前請求的數據是否已經全部接收。
所以，當瀏覽器請求的是一個靜態資源時，即服務器能明確知道返回內容的長度時，可以設置Content-Length來控制請求的結束。但當服務器並不知道請求結果的長度時，如一個動態的頁面或者數據，Content-Length就無法解決上面的問題，這個時候就需要用到Transfer-Encoding字段。
Transfer-Encoding
Transfer-Encoding是指傳輸編碼，還有一個類似的字段叫做：Content-Encoding。兩者的區別是Content-Encoding用於對實體內容的壓縮編碼，比如Content-Encoding: gzip；Transfer-Encoding則改變了報文的格式，比如上面的問題中，當服務端無法知道實體內容的長度時，就可以通過指定Transfer-Encoding: chunked來告知瀏覽器當前的編碼是將數據分成一塊一塊傳遞的。當然, 還可以指定Transfer-Encoding: gzip, chunked表明實體內容不僅是gzip壓縮的，還是分塊傳遞的。最后，當瀏覽器接收到一個長度為0的chunked時， 知道當前請求內容已全部接收。