1.以前的誤解

很久之前就聽說過長連接的說法，而且還知道HTTP1.0協(xié)議不支持長連接，從HTTP1.1協(xié)議以后，連接默認都是長連接。

一直認為，HTTP連接分為長連接和短連接，而我們現(xiàn)在常用的都是HTTP1.1，因此我們用的都是長連接。

這句話其實只對了一半，我們現(xiàn)如今的HTTP協(xié)議，大部分都是1.1的，因此我們平時用的基本上都是長連接。但是前半句是不對的，HTTP協(xié)議根本沒有長短連接這一說，也正因為誤解了這個，導(dǎo)致對于長連接一直不明不白，始終不得其要領(lǐng)，具體下面一段會說到。

網(wǎng)絡(luò)上很多文章都是誤人子弟。強調(diào)一下，HTTP協(xié)議是基于請求/響應(yīng)模式的，因此只要服務(wù)端給了響應(yīng)，本次HTTP連接就結(jié)束了，或者更準確的說，是本次HTTP請求就結(jié)束了，根本沒有長短連接一說。

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

HTTP協(xié)議說到底是應(yīng)用層的協(xié)議，而TCP才是真正的傳輸層協(xié)議，只有負責(zé)傳輸?shù)倪@一層才需要建立連接。

一個形象的例子就是，拿你在網(wǎng)上購物來說，HTTP協(xié)議是指的那個快遞單，你寄件的時候填的單子就像是發(fā)了一個HTTP請求，等貨物運到地方了，快遞員會根據(jù)你發(fā)的請求把貨物送給相應(yīng)的收貨人。而TCP協(xié)議就是中間運貨的那個大貨車，也可能是火車或者飛機，但不管是什么，它是負責(zé)運輸?shù)?，因此必須要有路，不管是地上還是天上。那么這個路就是所謂的TCP連接，也就是一個雙向的數(shù)據(jù)通道。

因此，LZ現(xiàn)在甚至覺得，“HTTP連接”這個詞就不應(yīng)該出現(xiàn)，它只是一個應(yīng)用層的協(xié)議，根本就沒有所謂的連接這一說，就像FTP也是應(yīng)用層的協(xié)議，但是你有聽說過FTP連接嗎？

實際上，說HTTP請求和HTTP響應(yīng)會更準確一些，而HTTP請求和HTTP響應(yīng)，都是通過TCP連接這個通道來回傳輸?shù)摹?/p>

不管怎么說，一定要務(wù)必記住，長連接是指的TCP連接，而不是HTTP連接。

2、關(guān)于長連接

之前LZ一直對一件事有些模糊不清，首先是怎么樣就算是把HTTP變成長連接了，是不是只要設(shè)置Connection為keep-alive就算是了？

如果是的話，那都說HTTP1.1默認是長連接，而觀察我們平時開發(fā)的Web應(yīng)用的HTTP頭部，Connection也確實是keep-alive，那就是說我們大部分都是用的長連接，但是長連接不是一般用于交互比較頻繁的應(yīng)用嗎？像我們這種普通的Web應(yīng)用，比如博客園這種，或者我的個人博客這種，長連接有什么用？

如果有用那用處到底是什么，我們又不是客戶端與服務(wù)器交互頻繁的那種應(yīng)用（畢竟你打開網(wǎng)頁肯定要半天才打開另外一個吧），如果沒用的話，那到底應(yīng)不應(yīng)該把Connection為keep-alive這個header值給改掉，從而改成短連接？

第一個問題是，是不是只要設(shè)置Connection為keep-alive就算是長連接了？

當然是的，但要服務(wù)器和客戶端都設(shè)置。

第二個問題是，我們平時用的是不是長連接？

是的。（現(xiàn)在用的基本上都是HTTP1.1協(xié)議，你觀察一下就會發(fā)現(xiàn)，基本上Connection都是keep-alive。而且HTTP協(xié)議文檔上也提到了，HTTP1.1默認是長連接，也就是默認Connection的值就是keep-alive），一個網(wǎng)頁 各種js、圖片等文件，所以一次TCP連接需要發(fā)多個HTTP 請求。

第三個問題，普通的Web應(yīng)用（比如博客園，我的個人博客這種）用長連接有啥好處？需不需要關(guān)掉長連接而使用短連接？

3、長連接好處是什么？

首先，長連接是為了復(fù)用TCP連接。多個HTTP請求可以復(fù)用同一個TCP連接，這就節(jié)省了很多TCP連接建立和斷開的消耗。

一個網(wǎng)頁，包含了CSS、JS等等一系列資源，如果是短連接（也就是每次都要重新建立TCP連接）的話，那你每打開一個網(wǎng)頁，每一個資源需要建立一次TCP連接，基本要建立幾個甚至幾十個TCP連接

但如果是長連接的話，那么這么多次HTTP請求（這些請求包括請求網(wǎng)頁內(nèi)容，CSS文件，JS文件，圖片等等），其實使用的都是一個TCP連接，很顯然是可以節(jié)省很多消耗的。

長連接并不是永久連接的

如果一段時間內(nèi)（具體的時間長短，是可以在header當中進行設(shè)置的，也就是所謂的超時時間），這個連接沒有HTTP請求發(fā)出的話，那么這個長連接就會被斷掉。

4、長輪詢和短輪詢

短輪詢（定時去服務(wù)器獲取新數(shù)據(jù)）

短輪詢相信大家都不難理解，比如你現(xiàn)在要做一個電商中商品詳情的頁面，這個詳情界面中有一個字段是庫存量，這個庫存量需要實時的變化，保持和服務(wù)器里實際的庫存一致。

這個時候，你會怎么做？

最簡單的一種方式，就是你用JS寫個死循環(huán)，不停的去請求服務(wù)器中的庫存量是多少，然后刷新到這個頁面當中，這其實就是所謂的短輪詢。

這種方式有明顯的壞處，那就是你很浪費服務(wù)器和客戶端的資源。如果有1000個人停留在某個商品詳情頁面，那就是說會有1000個客戶端不停的去請求服務(wù)器獲取庫存量，這顯然是不合理的。

那怎么辦呢？

長輪詢（數(shù)據(jù)沒變服務(wù)器會阻塞（掛起）客戶端的請求，直到數(shù)據(jù)有變化才回復(fù)客戶端請求）

長輪詢這個時候就出現(xiàn)了，其實長輪詢和短輪詢最大的區(qū)別是，短輪詢?nèi)シ?wù)端查詢的時候，不管庫存量有沒有變化，服務(wù)器就立即返回結(jié)果了。而長輪詢則不是，在長輪詢中，服務(wù)器如果檢測到庫存量沒有變化的話，將會把當前請求掛起一段時間（這個時間也叫作超時時間，一般是幾十秒）。在這個時間里，服務(wù)器會去檢測庫存量有沒有變化，檢測到變化就立即返回，否則就一直等到超時為止。

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

長輪詢壞處

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

因此，從這里可以看出，不管是長輪詢還是短輪詢，都不太適用于客戶端數(shù)量太多的情況，因為每個服務(wù)器所能承載的TCP連接數(shù)是有上限的，這種輪詢很容易把連接數(shù)頂滿。之所以舉這個例子，只是因為大家肯定都會網(wǎng)購，所以這個例子比較通俗一點。

5、長短輪詢和長短連接的區(qū)別

第一個區(qū)別是決定的方式，一個TCP連接是否為長連接，是通過設(shè)置HTTP的Connection Header來決定的，而且是需要兩邊都設(shè)置才有效。而一種輪詢方式是否為長輪詢，是根據(jù)服務(wù)端的處理方式來決定的，與客戶端沒有關(guān)系。

第二個區(qū)別就是實現(xiàn)的方式，連接的長短是通過協(xié)議來規(guī)定和實現(xiàn)的。而輪詢的長短，是服務(wù)器通過編程的方式手動掛起請求來實現(xiàn)的。

原文鏈接：http://www.itdecent.cn/p/3fc3646fad80