undefined

在之前總結 WebSocket 的時候就已經提到過短長輪詢了~~今天看公眾號文章，又把長短連接引進來一起分析。感覺這種總結很棒，那么我們一起看看唄

長短連接

聽說長短連接的話，應該都是這一句吧:HTTP1.0 協議不支持連接，從 HTTP1.1 協議以后，連接默認是長連接。

HTTP 協議是基于請求/響應模式的，因此只要服務端給了響應，本次 HTTP 連接就結束了，或者更準確的說，是本次 HTTP 請求就結束了，根本沒有長連接這一說。那么自然也就沒有短連接這一說了。

之所以網絡上說 HTTP 分為長連接和短連接，其實本質上是說的 TCP 連接。TCP 連接是一個雙向的通道，它是可以保持一段時間不關閉的，因此 TCP 連接才有真正的長連接和短連接這一說。

其實知道了以后，會覺得這很好理解。HTTP 協議說到底是應用層的協議，而 TCP 才是真正的傳輸層協議，只有負責傳輸的這一層才需要建立連接。

于是，我們就知道了，長連接指的是 TCP 連接，不是 HTTP 連接。理解了這一點之后，我們再來看，把所有的請求都默認為長連接有什么作用。

因為長連接意味著連接被復用，那么這里復用的是 TCP 通道。于是，一個網站上的多個 HTTP 請求可以復用同一個 TCP 連接，這也就是節(jié)省了很多 TCP 連接建立和斷開的消耗。于是，我們就懂了，為啥 HTTP1.1 要默認長連接，因為短連接幾乎沒有好處啊~

那么第二個問題：怎么設置長連接呢？

很簡單，只要設置 Connection 為 keep-alive。當然是的，但要服務器和客戶端(HTTP1.1 默認)都設置。

另外，最后關于長連接還要多提一句，那就是，長連接并不是永久連接的。如果一段時間內(具體的時間長短，是可以在 header 當中進行設置的，也就是所謂的超時時間)，這個連接沒有 HTTP 請求發(fā)出的話，那么這個長連接就會被斷掉。

這一點其實很容易理解，否則的話，TCP 連接將會越來越多，直到把服務器的 TCP 連接數量撐爆到上限為止。現在想想，對于服務器來說，服務器里的這些個長連接其實很有數據庫連接池的味道，大家都是為了節(jié)省連接重復利用嘛，對不對？

長輪詢短輪詢

這里在我學習 websocket 的時候已經詳細說過了~~這里稍微再補充一下自己的理解吧。

輪詢：輪-> 循環(huán)； 詢: 查詢；

也就是長短輪詢，就是周期短或者周期長的循環(huán)查詢服務器信息。那么周期怎么算呢？客戶端發(fā)起的信息那一刻到服務器應答，就算一個周期。

于是長短輪詢就能很快區(qū)別開來了，長輪詢，不停地問服務器拿信息，但是服務器很久才回答你(信息有更新再回答)。短輪詢，不停地問服務器拿信息，服務器會馬上告訴你情況。

長短輪詢和長短連接的區(qū)別決定的方式；一個 TCP 連接是否為長連接，通過設置 HTTPde Connection Header 來決定的，而且是要客戶端和服務器都設置；輪詢的決定權是在于服務器的處理方式，客戶端沒辦法解決

實現方式，連接的長短由協議來規(guī)定和實現。而輪詢是依賴編程方式手動掛起請求實現的。

這里是來自別人的思路分享文章，因為沒有別人的思路歷程直接 copy 也是不太好。哪里看不明白，建議直接跳轉。

總結

以上是生活随笔為你收集整理的tcp协议中的长连接和短连接服务器,谈谈HTTP协议中的短轮询、长轮询、长连接和短链接...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。