HTTP協議中的Transfer-Encoding
瀏覽器和服務器端支持持久連接
持久連接（Persist Connection）
HTTP1.0默認不是持久連接的
HTTP1.1默認是持久連接的
在HTTP請求和響應中加入Connection:KEEP-alive這個告訴對方當前tcp連接時持久連接的，
進行持久連接，可以減少客戶端的等待時間，因為不使用持久連接，要盡心TCP的三次握手過程。
如果不想使用TCP的持久連接可以在HTTP頭部加入connection：close，來告訴對方當前連接在客戶端獲取響應后，關閉TCP連接。
transfer-encoding：則是用來改變報文格式。
content-encoding:是HTTP實體內容進行編碼，目的是優化傳輸，例如服務器端用gzip對響應實體盡心壓縮，
並不是服務器端所有的信息都需要壓縮處理，例如圖片，已經是高度壓縮過得了，就不用壓縮了。壓縮會浪費消耗CPU資源。
HTTP持久連接和非持久連接的區別：
①如果是HTTP是持久連接，如果服務器端返回數據沒有實體內容的長度即（Content-length）則瀏覽器一直處於pending狀態，
即一直等待狀態。如果是非持久連接的話，不會出現這種情況。
這是因為，對於非持久連接，瀏覽器可以通知連接是否關閉來界定請求或者響應實體的邊界；而對於持久連接，
這種方法顯然不奏效。需要在響應中加入Content-length告訴瀏覽器當前響應結束。
由於Content-Length字段必須真實反映實體長度，但實際應用中，有些時候實體長度並沒有那么好獲得，例如實體
來自於網絡文件，或者有動態語言生成。這時候要想獲取長度，只能開一個足夠打的buffer，等內容全部生成好再
計算。但這樣做一方面需要更大的內容開銷，另一方面也會讓客戶端等待更久。
我們在做web性能優化時，有一個重要的指標叫TTFB(TIME TO FIRST Byte)，它代表的是從客戶端發出請求到收到響應
的第一個字節所花費的時間。大部分；瀏覽器自帶的network面板都可以看到這個指標，越短的TTFB意味着用戶可以
越早看到頁面內容，用戶體驗好。
可想而知，服務器端為了計算響應實體長度而緩存所有內容，跟更短的TTFB理念不一樣。
但在HTTP報文中，實體一定要在頭部之后，順序不能顛倒，為此我們需要一個新的機制：不依賴頭部的長度信息，
也能知道實體的邊界。
Transfer-Encoding：chunked，利用分塊傳輸
分跨傳輸相當簡單，只需要在HTTP響應頭中加入Transfer-Encoding：chunked，就代表這個報文采用了分塊編碼。
Keep-Alive: timeout=5, max=100（代表當前TCP連接可以保持5秒，這個TCP連接最多接受100個HTTP請求，超過100個就斷開）