專案中，發現乙個問題，有的文字顯示不全，顯示一半就結束了，然後，我看響應頭，發現狀態碼為200的響應頭有transfer-encoding：chunked。
顯示不全的請求中，沒有這個header，所以我懷疑是不是這個問題導致的。
因為瀏覽器可以通過 content-length 的長度資訊，判斷出響應實體已結束。那如果 content-length 和實體實際長度不一致會怎樣？通常如果 content-length 比實際長度短，會造成內容被截斷；如果比實體內容長，會造成 pending。
針對http長連線和短連線，還是要回歸到它們的本質tcp連線上，因為http執行在tcp連線之上。
瀏覽器重用已經開啟的空閒持久連線，可以避開緩慢的三次握手，還可以避免遇上tcp慢啟動的擁塞適應階段。
當乙個網頁完成後，客戶端和伺服器之間用於傳輸http資料的tcp連線不會關閉，客戶端再次訪問伺服器時，會繼續使用這一條已經建立好的連線。
client向server發起連線，server接受client連線，雙方建立連線，client與server完成一次請求後，它們之間的連線並不會主動關閉，後續的讀寫操作會繼續使用這個連線。
client向server發起連線請求，server接到請求，然後雙方建立連線。client向server傳送訊息，server回應client，然後一次請求就完成了，客戶端自己會斷開連線。短連線一般只會在 client/server間傳遞一次請求操作。
對於頻繁請求資源的客戶端適合使用長連線。擼啊擼
例如資料庫使用的就是長連線。如果使用短連線，頻繁的通訊有可能導致socket錯誤，並且頻繁的建立socket對資源極大的浪費。
再者，資料庫本身就追求速度，使用短連線再慢慢的握握手，效率可想而知。
web**的http服務使用短連線，因為可能存在上億的客戶端，如果全部保持長連線，伺服器可能吃不消。
每個客戶端不會頻繁操作，就使用短連線，但是也不一定，如果老闆有錢，全部長連線也ojk。
我就去看看了csdn是什麼連線，發現有的是長連線，有的是短連線。然後我看到了csdn中存放在阿里雲上。
通過connection:keep-alive來實現長連線。
為了盡可能的提高http效能，1.1規定所有連線必須是持久的，已經不需要在頭部加上connection：keep-alive了。
想要短連線可以，connection:close但一般沒人會主動去使用。仔細觀察一下你的請求，有時候你可以在響應頭上看到這個引數。
content-encoding（內容編碼）
對實體內容進行壓縮編碼，優化傳輸。例如用zip壓縮檔案，減小內容體積。
內容編碼通常是選擇性的，例如jpg/png這類檔案一般不開啟，因為格式已經是高度壓縮過的，再壓一遍沒什麼效果，還吃資源。
transfer-encoding(傳輸編碼)
改變報文格式，不但不會減少實體內容傳輸大小，甚至還會使傳輸變大。
更深處說，就很細了，身為開發，就不深究了。
注意：content-encoding和transfer-encoding二者是相輔相成的，對於乙個http報文，有可能同時進行了內容編碼和傳輸編碼。
Http短輪詢 Http長輪詢 短連線和長連線
http短輪詢指前端使用ajax定時請求後端伺服器介面，後端伺服器接收到請求後馬上響應給前端 無論是否有結果 http長輪詢指前端使用ajax請求後段伺服器介面，後端伺服器在有資料更新時 或到達超時時間 才響應給前端，否則就掛起當前請求，前端在拿到響應結果後馬上再次向服務端發起請求 短連線指的是tc...
HTTP協議中的短輪詢 長輪詢 長連線和短連線
http1.0協議不支援長連線，從http1.1協議以後，連線預設都是長連線 http協議是基於請求 響應模式的，因此只要服務端給了響應，本次http連線就結束了 之所以網路上說http分為長連線和短連線，其實本質上是說的tcp連線。tcp連線是乙個雙向的通道，它是可以保持一段時間不關閉的，因此tc...
HTTP協議中的短輪詢 長輪詢 長連線和短連線
http1.0協議不支援長連線，但都是基於tcp連線來說的 http1.1協議預設是長連線，但都是基於tcp連線來說的，http頭部，connection是keep alive，但要伺服器和客戶端都設定，則可長連線。http協議是基於請求 響應模式的，因此只要服務端給了響應，本次http連線就結束了...