undefined

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

長短連接

聽說長短連接的話，應(yīng)該都是這一句吧:HTTP1.0 協(xié)議不支持連接，從 HTTP1.1 協(xié)議以后，連接默認(rèn)是長連接。

HTTP 協(xié)議是基于請求/響應(yīng)模式的，因此只要服務(wù)端給了響應(yīng)，本次 HTTP 連接就結(jié)束了，或者更準(zhǔn)確的說，是本次 HTTP 請求就結(jié)束了，根本沒有長連接這一說。那么自然也就沒有短連接這一說了。

之所以網(wǎng)絡(luò)上說 HTTP 分為長連接和短連接，其實本質(zhì)上是說的 TCP 連接。TCP 連接是一個雙向的通道，它是可以保持一段時間不關(guān)閉的，因此 TCP 連接才有真正的長連接和短連接這一說。

其實知道了以后，會覺得這很好理解。HTTP 協(xié)議說到底是應(yīng)用層的協(xié)議，而 TCP 才是真正的傳輸層協(xié)議，只有負(fù)責(zé)傳輸?shù)倪@一層才需要建立連接。

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

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

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

很簡單，只要設(shè)置 Connection 為 keep-alive。當(dāng)然是的，但要服務(wù)器和客戶端(HTTP1.1 默認(rèn))都設(shè)置。

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

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

長輪詢短輪詢

這里在我學(xué)習(xí) websocket 的時候已經(jīng)詳細(xì)說過了~~這里稍微再補(bǔ)充一下自己的理解吧。

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

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

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

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

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。