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

張龍豪發表於2017-05-05

序言

最近剛到公司不到一個月,正處於熟悉專案和原始碼的階段,因此最近經常會看一些原始碼。在研究一個專案的時候,原始碼裡面用到了HTTP的長輪詢。由於之前沒太接觸過,因此LZ便趁著這個機會,好好了解了一下HTTP的長長短短。

瞭解的方式主要都是LZ在網路上獲取的,這裡只是談一下LZ對於這四種叫法最直觀的理解。如果你之前不懂的話,可以幫你普及一下,如果你之前就懂得話,可以互相對照一下。

以前的誤解

很久之前LZ就聽說過長連線的說法,而且還知道HTTP1.0協議不支援長連線,從HTTP1.1協議以後,連線預設都是長連線。但LZ終究覺得對於長連線一直懵懵懂懂的,有種抓不到關鍵點的感覺。

今天LZ通過一番研究,終於明白了這其中的奧祕。而之前,LZ也看過長連線相關的內容,但一直都是雲裡霧裡的。這次之所以能在這麼短的時間裡搞清楚,和LZ自己技術的沉澱密不可分。因此,這裡LZ藉著這個機會,再次強調一下,千萬不要試圖去研究你研究了很久都整不明白的東西,或許是你的層次不到,也或許是你從未在實際的應用場景接觸過,這種情況下你去研究,只會事倍功半,徒勞一番罷了。

回到正題,既然說是誤解,那麼LZ的誤解到底是什麼?

那就是LZ一直認為,HTTP連線分為長連線和短連線,而我們現在常用的都是HTTP1.1,因此我們用的都是長連線。

這句話其實只對了一半,我們現如今的HTTP協議,大部分都是1.1的,因此我們平時用的基本上都是長連線。但是前半句是不對的,HTTP協議根本沒有長短連線這一說,也正因為誤解了這個,導致LZ對於長連線一直不明不白,始終不得其要領,具體下面一段會說到。

網路上很多文章都是誤人子弟,根本沒有說明白這個概念。這裡LZ要強調一下,HTTP協議是基於請求/響應模式的,因此只要服務端給了響應,本次HTTP連線就結束了,或者更準確的說,是本次HTTP請求就結束了,根本沒有長連線這一說。那麼自然也就沒有短連線這一說了。

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

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

一個形象的例子就是,拿你在網上購物來說,HTTP協議是指的那個快遞單,你寄件的時候填的單子就像是發了一個HTTP請求,等貨物運到地方了,快遞員會根據你發的請求把貨物送給相應的收貨人。而TCP協議就是中間運貨的那個大貨車,也可能是火車或者飛機,但不管是什麼,它是負責運輸的,因此必須要有路,不管是地上還是天上。那麼這個路就是所謂的TCP連線,也就是一個雙向的資料通道。

因此,LZ現在甚至覺得,“HTTP連線”這個詞就不應該出現,它只是一個應用層的協議,根本就沒有所謂的連線這一說,就像FTP也是應用層的協議,但是你有聽說過FTP連線嗎?(恩,好像是聽過,-_-,但你現在知道了,其實所謂的FTP連線,嚴格來說,依舊是TCP連線)

實際上,說HTTP請求和HTTP響應會更準確一些,而HTTP請求和HTTP響應,都是通過TCP連線這個通道來回傳輸的。

不管怎麼說,一定要務必記住,長連線是指的TCP連線,而不是HTTP連線。

一個疑問

之前LZ一直對一件事有些模糊不清,首先是怎麼樣就算是把HTTP變成長連線了,是不是隻要設定Connection為keep-alive就算是了?

如果是的話,那都說HTTP1.1預設是長連線,而觀察我們平時開發的Web應用的HTTP頭部,Connection也確實是keep-alive,那就是說我們大部分都是用的長連線,但是長連線不是一般用於互動比較頻繁的應用嗎?像我們這種普通的Web應用,比如部落格園這種,或者我的個人部落格這種,長連線有什麼用?

如果有用那用處到底是什麼,我們又不是客戶端與伺服器互動頻繁的那種應用(畢竟你開啟網頁肯定要半天才開啟另外一個吧),如果沒用的話,那到底應不應該把Connection為keep-alive這個header值給改掉,從而改成短連線?

這個疑問,在LZ明白了長連線其實是指的TCP連線之後,基本上就明白了。而這個疑問,也正是LZ在“以前的誤解”那一段所提到的,那個因為誤解導致LZ一直搞不明白的問題。

為什麼解決了上面那個誤解之後,前面所說的這些疑問LZ都明白了?

因為長連線意味著連線會被複用,畢竟一直保持著連線不就是為了重複使用嘛。但如果長連線是指的HTTP的話,那就是說HTTP連線可以被重複利用,這個話聽起來就感覺很彆扭。之所以覺得彆扭,其實就是LZ的一種直覺,沒什麼理論依據。而這種彆扭的根源就在於,之前一直沒有融會貫通的感覺,所以總感覺缺少點什麼。不過這點疑惑,並沒有影響LZ的工作,因此也就沒深究過。

但現在好了,明白了長連線實際上是指的TCP連線,LZ瞬間自己就想明白了上面的那些問題。

第一個問題是,是不是隻要設定Connection為keep-alive就算是長連線了?

當然是的,但要伺服器和客戶端都設定。

第二個問題是,我們平時用的是不是長連線?

這個也毫無疑問,當然是的。(現在用的基本上都是HTTP1.1協議,你觀察一下就會發現,基本上Connection都是keep-alive。而且HTTP協議文件上也提到了,HTTP1.1預設是長連線,也就是預設Connection的值就是keep-alive)

第三個問題,也是LZ之前最想不明白的問題,那就是我們這種普通的Web應用(比如部落格園,我的個人部落格這種)用長連線有啥好處?需不需要關掉長連線而使用短連線?

這個問題LZ現在終於明白了,問題的答案是好處還是有的。

好處是什麼?

首先,剛才已經說了,長連線是為了複用,這個在之前LZ就明白。那既然長連線是指的TCP連線,也就是說複用的是TCP連線。那這就很好解釋了,也就是說,長連線情況下,多個HTTP請求可以複用同一個TCP連線,這就節省了很多TCP連線建立和斷開的消耗。

比如你請求了部落格園的一個網頁,這個網頁裡肯定還包含了CSS、JS等等一系列資源,如果你是短連線(也就是每次都要重新建立TCP連線)的話,那你每開啟一個網頁,基本要建立幾個甚至幾十個TCP連線,這浪費了多少資源就不用LZ去說了吧。

但如果是長連線的話,那麼這麼多次HTTP請求(這些請求包括請求網頁內容,CSS檔案,JS檔案,圖片等等),其實使用的都是一個TCP連線,很顯然是可以節省很多消耗的。

這樣一解釋,就很明白了,不知道大家看了這些解釋感覺如何,反正LZ在自己想明白以後,有種豁然開朗的感覺。

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

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

長輪詢和短輪詢

前面基本上LZ已經把長短連線說的差不多了,接下來說說長短輪詢,今天也正是為了研究長短輪詢,LZ才順便研究了下長短連線這回事。

短輪詢相信大家都不難理解,比如你現在要做一個電商中商品詳情的頁面,這個詳情介面中有一個欄位是庫存量(相信這個大家都不陌生,隨便開啟淘寶或者京東都能找到這種頁面)。而這個庫存量需要實時的變化,保持和伺服器裡實際的庫存一致。

這個時候,你會怎麼做?

最簡單的一種方式,就是你用JS寫個死迴圈,不停的去請求伺服器中的庫存量是多少,然後重新整理到這個頁面當中,這其實就是所謂的短輪詢。

這種方式有明顯的壞處,那就是你很浪費伺服器和客戶端的資源。客戶端還好點,現在PC機配置高了,你不停的請求還不至於把使用者的電腦整死,但是伺服器就很蛋疼了。如果有1000個人停留在某個商品詳情頁面,那就是說會有1000個客戶端不停的去請求伺服器獲取庫存量,這顯然是不合理的。

那怎麼辦呢?

長輪詢這個時候就出現了,其實長輪詢和短輪詢最大的區別是,短輪詢去服務端查詢的時候,不管庫存量有沒有變化,伺服器就立即返回結果了。而長輪詢則不是,在長輪詢中,伺服器如果檢測到庫存量沒有變化的話,將會把當前請求掛起一段時間(這個時間也叫作超時時間,一般是幾十秒)。在這個時間裡,伺服器會去檢測庫存量有沒有變化,檢測到變化就立即返回,否則就一直等到超時為止。

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

這樣一來,客戶端的請求次數將會大量減少(這也就意味著節省了網路流量,畢竟每次發請求,都會佔用客戶端的上傳流量和服務端的下載流量),而且也解決了服務端一直疲於接受請求的窘境。

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

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

哪怕輪詢解決不了獲取庫存這個問題,但只要大家明白了長短輪詢的區別,這就足夠了。實際上,據LZ自己平日裡購物的觀察,那個庫存量應該是不會變的,這個例子純屬LZ個人的意淫,-_-。、

長輪詢和長短連線的區別

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

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

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

結語

好了,本文就到此為止吧。LZ寫這篇文章,主要也是為了避免自己遺忘。說實話,寫到最後了,LZ感覺對於它們的理解又進了一步,這就是寫部落格的好處吧。

 

作者:左瀟龍

原文地址:http://www.cnblogs.com/zuoxiaolong/p/life49.html

相關文章