转---谈谈HTTP协议中的短轮询、长轮询、长连接和短连接
作者：伯樂在線專欄作者 - 左瀟龍
http://web.jobbole.com/85541/
如有好文章投稿，請點擊 → 這里了解詳情
?
引言
?
最近剛到公司不到一個月，正處于熟悉項目和源碼的階段，因此最近經(jīng)常會看一些源碼。在研究一個項目的時候，源碼里面用到了HTTP的長輪詢。由于之前沒太接觸過，因此LZ便趁著這個機會，好好了解了一下HTTP的長長短短。
?
了解的方式主要都是LZ在網(wǎng)絡上獲取的，這里只是談一下LZ對于這四種叫法最直觀的理解。如果你之前不懂的話，可以幫你普及一下，如果你之前就懂得話，可以互相對照一下。
?
以前的誤解
?
很久之前LZ就聽說過長連接的說法，而且還知道HTTP1.0協(xié)議不支持長連接，從HTTP1.1協(xié)議以后，連接默認都是長連接。但LZ終究覺得對于長連接一直懵懵懂懂的，有種抓不到關鍵點的感覺。
?
今天LZ通過一番研究，終于明白了這其中的奧秘。而之前，LZ也看過長連接相關的內容，但一直都是云里霧里的。這次之所以能在這么短的時間里搞清楚，和LZ自己技術的沉淀密不可分。因此，這里LZ借著這個機會，再次強調一下，千萬不要試圖去研究你研究了很久都整不明白的東西，或許是你的層次不到，也或許是你從未在實際的應用場景接觸過，這種情況下你去研究，只會事倍功半，徒勞一番罷了。
?
回到正題，既然說是誤解，那么LZ的誤解到底是什么？
?
那就是LZ一直認為，HTTP連接分為長連接和短連接，而我們現(xiàn)在常用的都是HTTP1.1，因此我們用的都是長連接。
?
這句話其實只對了一半，我們現(xiàn)如今的HTTP協(xié)議，大部分都是1.1的，因此我們平時用的基本上都是長連接。但是前半句是不對的，HTTP協(xié)議根本沒有長短連接這一說，也正因為誤解了這個，導致LZ對于長連接一直不明不白，始終不得其要領，具體下面一段會說到。
?
網(wǎng)絡上很多文章都是誤人子弟，根本沒有說明白這個概念。這里LZ要強調一下，HTTP協(xié)議是基于請求/響應模式的，因此只要服務端給了響應，本次HTTP連接就結束了，或者更準確的說，是本次HTTP請求就結束了，根本沒有長連接這一說。那么自然也就沒有短連接這一說了。
?
之所以網(wǎng)絡上說HTTP分為長連接和短連接，其實本質上是說的TCP連接。TCP連接是一個雙向的通道，它是可以保持一段時間不關閉的，因此TCP連接才有真正的長連接和短連接這一說。
?
其實知道了以后，會覺得這很好理解。HTTP協(xié)議說到底是應用層的協(xié)議，而TCP才是真正的傳輸層協(xié)議，只有負責傳輸?shù)倪@一層才需要建立連接。
?
一個形象的例子就是，拿你在網(wǎng)上購物來說，HTTP協(xié)議是指的那個快遞單，你寄件的時候填的單子就像是發(fā)了一個HTTP請求，等貨物運到地方了，快遞員會根據(jù)你發(fā)的請求把貨物送給相應的收貨人。而TCP協(xié)議就是中間運貨的那個大貨車，也可能是火車或者飛機，但不管是什么，它是負責運輸?shù)?#xff0c;因此必須要有路，不管是地上還是天上。那么這個路就是所謂的TCP連接，也就是一個雙向的數(shù)據(jù)通道。
?
因此，LZ現(xiàn)在甚至覺得，“HTTP連接”這個詞就不應該出現(xiàn)，它只是一個應用層的協(xié)議，根本就沒有所謂的連接這一說，就像FTP也是應用層的協(xié)議，但是你有聽說過FTP連接嗎？（恩，好像是聽過，-_-，但你現(xiàn)在知道了，其實所謂的FTP連接，嚴格來說，依舊是TCP連接）
?
實際上，說HTTP請求和HTTP響應會更準確一些，而HTTP請求和HTTP響應，都是通過TCP連接這個通道來回傳輸?shù)摹?/p>
?
不管怎么說，一定要務必記住，長連接是指的TCP連接，而不是HTTP連接。
?
一個疑問
?
之前LZ一直對一件事有些模糊不清，首先是怎么樣就算是把HTTP變成長連接了，是不是只要設置Connection為keep-alive就算是了？
?
如果是的話，那都說HTTP1.1默認是長連接，而觀察我們平時開發(fā)的Web應用的HTTP頭部，Connection也確實是keep-alive，那就是說我們大部分都是用的長連接，但是長連接不是一般用于交互比較頻繁的應用嗎？像我們這種普通的Web應用，比如博客園這種，或者我的個人博客這種，長連接有什么用？
?
如果有用那用處到底是什么，我們又不是客戶端與服務器交互頻繁的那種應用（畢竟你打開網(wǎng)頁肯定要半天才打開另外一個吧），如果沒用的話，那到底應不應該把Connection為keep-alive這個header值給改掉，從而改成短連接？
?
這個疑問，在LZ明白了長連接其實是指的TCP連接之后，基本上就明白了。而這個疑問，也正是LZ在“以前的誤解”那一段所提到的，那個因為誤解導致LZ一直搞不明白的問題。
?
為什么解決了上面那個誤解之后，前面所說的這些疑問LZ都明白了？
?
因為長連接意味著連接會被復用，畢竟一直保持著連接不就是為了重復使用嘛。但如果長連接是指的HTTP的話，那就是說HTTP連接可以被重復利用，這個話聽起來就感覺很別扭。之所以覺得別扭，其實就是LZ的一種直覺，沒什么理論依據(jù)。而這種別扭的根源就在于，之前一直沒有融會貫通的感覺，所以總感覺缺少點什么。不過這點疑惑，并沒有影響LZ的工作，因此也就沒深究過。
?
但現(xiàn)在好了，明白了長連接實際上是指的TCP連接，LZ瞬間自己就想明白了上面的那些問題。
?
第一個問題是，是不是只要設置Connection為keep-alive就算是長連接了？
?
當然是的，但要服務器和客戶端都設置。
?
第二個問題是，我們平時用的是不是長連接？
?
這個也毫無疑問，當然是的。（現(xiàn)在用的基本上都是HTTP1.1協(xié)議，你觀察一下就會發(fā)現(xiàn)，基本上Connection都是keep-alive。而且HTTP協(xié)議文檔上也提到了，HTTP1.1默認是長連接，也就是默認Connection的值就是keep-alive）
?
第三個問題，也是LZ之前最想不明白的問題，那就是我們這種普通的Web應用（比如博客園，我的個人博客這種）用長連接有啥好處？需不需要關掉長連接而使用短連接？
?
這個問題LZ現(xiàn)在終于明白了，問題的答案是好處還是有的。
?
好處是什么？
?
首先，剛才已經(jīng)說了，長連接是為了復用，這個在之前LZ就明白。那既然長連接是指的TCP連接，也就是說復用的是TCP連接。那這就很好解釋了，也就是說，長連接情況下，多個HTTP請求可以復用同一個TCP連接，這就節(jié)省了很多TCP連接建立和斷開的消耗。
?
比如你請求了博客園的一個網(wǎng)頁，這個網(wǎng)頁里肯定還包含了CSS、JS等等一系列資源，如果你是短連接（也就是每次都要重新建立TCP連接）的話，那你每打開一個網(wǎng)頁，基本要建立幾個甚至幾十個TCP連接，這浪費了多少資源就不用LZ去說了吧。
?
但如果是長連接的話，那么這么多次HTTP請求（這些請求包括請求網(wǎng)頁內容，CSS文件，JS文件，圖片等等），其實使用的都是一個TCP連接，很顯然是可以節(jié)省很多消耗的。
?
這樣一解釋，就很明白了，不知道大家看了這些解釋感覺如何，反正LZ在自己想明白以后，有種豁然開朗的感覺。
?
另外，最后關于長連接還要多提一句，那就是，長連接并不是永久連接的。如果一段時間內（具體的時間長短，是可以在header當中進行設置的，也就是所謂的超時時間），這個連接沒有HTTP請求發(fā)出的話，那么這個長連接就會被斷掉。
?
這一點其實很容易理解，否則的話，TCP連接將會越來越多，直到把服務器的TCP連接數(shù)量撐爆到上限為止?，F(xiàn)在想想，對于服務器來說，服務器里的這些個長連接其實很有數(shù)據(jù)庫連接池的味道，大家都是為了節(jié)省連接重復利用嘛，對不對？
?
長輪詢和短輪詢
?
前面基本上LZ已經(jīng)把長短連接說的差不多了，接下來說說長短輪詢，今天也正是為了研究長短輪詢，LZ才順便研究了下長短連接這回事。
?
短輪詢相信大家都不難理解，比如你現(xiàn)在要做一個電商中商品詳情的頁面，這個詳情界面中有一個字段是庫存量（相信這個大家都不陌生，隨便打開淘寶或者京東都能找到這種頁面）。而這個庫存量需要實時的變化，保持和服務器里實際的庫存一致。
?
這個時候，你會怎么做？
?
最簡單的一種方式，就是你用JS寫個死循環(huán)，不停的去請求服務器中的庫存量是多少，然后刷新到這個頁面當中，這其實就是所謂的短輪詢。
?
這種方式有明顯的壞處，那就是你很浪費服務器和客戶端的資源?？蛻舳诉€好點，現(xiàn)在PC機配置高了，你不停的請求還不至于把用戶的電腦整死，但是服務器就很蛋疼了。如果有1000個人停留在某個商品詳情頁面，那就是說會有1000個客戶端不停的去請求服務器獲取庫存量，這顯然是不合理的。
?
那怎么辦呢？
?
長輪詢這個時候就出現(xiàn)了，其實長輪詢和短輪詢最大的區(qū)別是，短輪詢去服務端查詢的時候，不管庫存量有沒有變化，服務器就立即返回結果了。而長輪詢則不是，在長輪詢中，服務器如果檢測到庫存量沒有變化的話，將會把當前請求掛起一段時間（這個時間也叫作超時時間，一般是幾十秒）。在這個時間里，服務器會去檢測庫存量有沒有變化，檢測到變化就立即返回，否則就一直等到超時為止。
?
而對于客戶端來說，不管是長輪詢還是短輪詢，客戶端的動作都是一樣的，就是不停的去請求，不同的是服務端，短輪詢情況下服務端每次請求不管有沒有變化都會立即返回結果，而長輪詢情況下，如果有變化才會立即返回結果，而沒有變化的話，則不會再立即給客戶端返回結果，直到超時為止。
?
這樣一來，客戶端的請求次數(shù)將會大量減少（這也就意味著節(jié)省了網(wǎng)絡流量，畢竟每次發(fā)請求，都會占用客戶端的上傳流量和服務端的下載流量），而且也解決了服務端一直疲于接受請求的窘境。
?
但是長輪詢也是有壞處的，因為把請求掛起同樣會導致資源的浪費，假設還是1000個人停留在某個商品詳情頁面，那就很有可能服務器這邊掛著1000個線程，在不停檢測庫存量，這依然是有問題的。
?
因此，從這里可以看出，不管是長輪詢還是短輪詢，都不太適用于客戶端數(shù)量太多的情況，因為每個服務器所能承載的TCP連接數(shù)是有上限的，這種輪詢很容易把連接數(shù)頂滿。之所以舉這個例子，只是因為大家肯定都會網(wǎng)購，所以這個例子比較通俗一點。
?
哪怕輪詢解決不了獲取庫存這個問題，但只要大家明白了長短輪詢的區(qū)別，這就足夠了。實際上，據(jù)LZ自己平日里購物的觀察，那個庫存量應該是不會變的，這個例子純屬LZ個人的意淫，-_-。
?
長短輪詢和長短連接的區(qū)別
?
這里簡單說一下它們的區(qū)別，LZ這里只說最根本的區(qū)別。
?
第一個區(qū)別是決定的方式，一個TCP連接是否為長連接，是通過設置HTTP的Connection Header來決定的，而且是需要兩邊都設置才有效。而一種輪詢方式是否為長輪詢，是根據(jù)服務端的處理方式來決定的，與客戶端沒有關系。
?
第二個區(qū)別就是實現(xiàn)的方式，連接的長短是通過協(xié)議來規(guī)定和實現(xiàn)的。而輪詢的長短，是服務器通過編程的方式手動掛起請求來實現(xiàn)的。
?
結語
?
好了，本文就到此為止吧。LZ寫這篇文章，主要也是為了避免自己遺忘。說實話，寫到最后了，LZ感覺對于它們的理解又進了一步，這就是寫博客的好處吧。
轉載于:https://www.cnblogs.com/AlexBlogs/p/6501735.html
總結
以上是生活随笔為你收集整理的转---谈谈HTTP协议中的短轮询、长轮询、长连接和短连接的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 「服务端」node服务的监控预警系统架构
- 下一篇： js函数中参数的传递