HTTP協議中的短輪詢長輪詢長連線和短連線

http1.0協議不支援長連線，但都是基於tcp連線來說的

http1.1協議預設是長連線，但都是基於tcp連線來說的，http頭部，connection是keep-alive，但要伺服器和客戶端都設定，則可長連線。

http協議是基於請求/響應模式的，因此只要服務端給了響應，本次http連線就結束了，根本沒有長連線這一說。

網路上說http分為長連線和短連線，其實本質上是說的tcp連線。tcp連線是乙個雙向的通道，它是可以保持一段時間不關閉的，因此tcp連線才有真正的長連線和短連線這一說。

http協議說到底是應用層的協議

tcp才是真正的傳輸層協議，只有負責傳輸的這一層才需要建立連線。

http連線」這個詞就不應該出現，它只是乙個應用層的協議，實際上，說http請求和http響應會更準確一些，而http請求和http響應，都是通過tcp連線這個通道來回傳輸的。

不管怎麼說，一定要務必記住，長連線是指的tcp連線，而不是http連線。

長連線意味著連線會被復用，畢竟一直保持著連線不就是為了重複使用嘛。

長連線的好處：

長連線是為了復用，那既然長連線是指的tcp連線，也就是說復用的是tcp連線。那這就很好解釋了，也就是說，長連線情況下，多個http請求可以復用同乙個tcp連線，這就節省了很多tcp連線建立和斷開的消耗。

比如你請求了的乙個網頁，這個網頁裡肯定還包含了css、js等等一系列資源，如果你是短連線（也就是每次都要重新建立tcp連線）的話，那你每開啟乙個網頁，基本要建立幾個甚至幾十個tcp連線，這浪費了多少資源就不用lz去說了吧。

但如果是長連線的話，那麼這麼多次http請求（這些請求包括請求網頁內容，css檔案，js檔案，等等），其實使用的都是乙個tcp連線，很顯然是可以節省很多消耗的。

另外，最後關於長連線還要多提一句，那就是，長連線並不是永久連線的。如果一段時間內（具體的時間長短，是可以在header當中進行設定的，也就是所謂的超時時間），這個連線沒有http請求發出的話，那麼這個長連線就會被斷掉。

這一點其實很容易理解，否則的話，tcp連線將會越來越多，直到把伺服器的tcp連線數量撐爆到上限為止。現在想想，對於伺服器來說，伺服器裡的這些個長連線其實很有資料庫連線池的味道，大家都是為了節省連線重複利用嘛，對不對？

對於客戶端來說，不管是長輪詢還是短輪詢，客戶端的動作都是一樣的，就是不停的去請求，不同的是服務端，短輪詢情況下服務端每次請求不管有沒有變化都會立即返回結果，而長輪詢情況下，如果有變化才會立即返回結果，而沒有變化的話，則不會再立即給客戶端返回結果，直到超時為止。

但是長輪詢也是有壞處的，因為把請求掛起同樣會導致資源的浪費，假設還是1000個人停留在某個商品詳情頁面，那就很有可能伺服器這邊掛著1000個執行緒，在不停檢測庫存量，這依然是有問題的。

因此，從這裡可以看出，不管是長輪詢還是短輪詢，都不太適用於客戶端數量太多的情況，因為每個伺服器所能承載的tcp連線數是有上限的，這種輪詢很容易把連線數頂滿。

這裡簡單說一下它們的區別，lz這裡只說最根本的區別。

第乙個區別是決定的方式，乙個tcp連線是否為長連線，是通過設定http的connection header來決定的，而且是需要兩邊都設定才有效。而一種輪詢方式是否為長輪詢，是根據服務端的處理方式來決定的，與客戶端沒有關係。

第二個區別就是實現的方式，連線的長短是通過協議來規定和實現的。而輪詢的長短，是伺服器通過程式設計的方式手動掛起請求來實現的。

HTTP協議中的短輪詢 長輪詢 長連線和短連線