HTTP 長連接和短連接

轉(zhuǎn)載:http://www.cnblogs.com/0201zcr/p/4694945.html


1. HTTP協(xié)議與TCP/IP協(xié)議的關(guān)系

HTTP的長連接和短連接本質(zhì)上是TCP長連接和短連接肥惭。HTTP屬于應用層協(xié)議茂蚓,在傳輸層使用TCP協(xié)議补疑,在網(wǎng)絡(luò)層使用IP協(xié)議翘狱。IP協(xié)議主要解決網(wǎng)絡(luò)路由和尋址問題狠毯,TCP協(xié)議主要解決如何在IP層之上可靠的傳遞數(shù)據(jù)包,使在網(wǎng)絡(luò)上的另一端收到發(fā)端發(fā)出的所有包,并且順序與發(fā)出順序一致。TCP有可靠丢间,面向連接的特點。

2. 如何理解HTTP協(xié)議是無狀態(tài)的

HTTP協(xié)議是無狀態(tài)的驹针,指的是協(xié)議對于事務(wù)處理沒有記憶能力烘挫,服務(wù)器不知道客戶端是什么狀態(tài)。也就是說柬甥,打開一個服務(wù)器上的網(wǎng)頁和你之前打開這個服務(wù)器上的網(wǎng)頁之間沒有任何聯(lián)系饮六。HTTP是一個無狀態(tài)的面向連接的協(xié)議,無狀態(tài)不代表HTTP不能保持TCP連接苛蒲,更不能代表HTTP使用的是UDP協(xié)議(無連接)喜滨。

3. 什么是長連接、短連接撤防?

在HTTP/1.0中,默認使用的是短連接棒口。也就是說寄月,瀏覽器和服務(wù)器每進行一次HTTP操作,就建立一次連接无牵,但任務(wù)結(jié)束就中斷連接漾肮。如果客戶端瀏覽器訪問的某個HTML或其他類型的 Web頁中包含有其他的Web資源,如JavaScript文件茎毁、圖像文件克懊、CSS文件等;當瀏覽器每遇到這樣一個Web資源七蜘,就會建立一個HTTP會話谭溉。

但從 HTTP/1.1起,默認使用長連接橡卤,用以保持連接特性扮念。使用長連接的HTTP協(xié)議,會在響應頭有加入這行代碼:

Connection : keep-alive

在使用長連接的情況下碧库,當一個網(wǎng)頁打開完成后柜与,客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的 TCP連接不會關(guān)閉巧勤,如果客戶端再次訪問這個服務(wù)器上的網(wǎng)頁,會繼續(xù)使用這一條已經(jīng)建立的連接弄匕。Keep-Alive不會永久保持連接颅悉,它有一個保持時間,可以在不同的服務(wù)器軟件(如Apache)中設(shè)定這個時間迁匠。實現(xiàn)長連接要客戶端和服務(wù)端都支持長連接剩瓶。

HTTP協(xié)議的長連接和短連接,實質(zhì)上是TCP協(xié)議的長連接和短連接柒瓣。

3.1 TCP連接

當網(wǎng)絡(luò)通信時采用TCP協(xié)議時儒搭,在真正的讀寫操作之前,server與client之間必須建立一個連接芙贫,當讀寫操作完成后搂鲫,雙方不再需要這個連接 時它們可以釋放這個連接,連接的建立是需要三次握手的磺平,而釋放則需要4次握手魂仍,所以說每個連接的建立都是需要資源消耗和時間消耗的

經(jīng)典的三次握手示意圖:


經(jīng)典的三次握手

經(jīng)典的四次揮手關(guān)閉圖:


經(jīng)典的四次揮手

3.2 TCP短連接

我們模擬一下TCP短連接的情況,client向server發(fā)起連接請求拣挪,server接到請求擦酌,然后雙方建立連接。client向server 發(fā)送消息菠劝,server回應client赊舶,然后一次讀寫就完成了,這時候雙方任何一個都可以發(fā)起close操作赶诊,不過一般都是client先發(fā)起 close操作笼平。為什么呢,一般的server不會回復完client后立即關(guān)閉連接的舔痪,當然不排除有特殊的情況寓调。從上面的描述看,短連接一般只會在 client/server間傳遞一次讀寫操作

短連接的優(yōu)點是:管理起來比較簡單锄码,存在的連接都是有用的連接夺英,不需要額外的控制手段

3.3 TCP長連接

接下來我們再模擬一下長連接的情況,client向server發(fā)起連接滋捶,server接受client連接痛悯,雙方建立連接。Client與server完成一次讀寫之后炬太,它們之間的連接并不會主動關(guān)閉灸蟆,后續(xù)的讀寫操作會繼續(xù)使用這個連接。

首先說一下TCP/IP詳解上講到的TCP保活功能炒考,笨筛浚活功能主要為服務(wù)器應用提供,服務(wù)器應用希望知道客戶主機是否崩潰斋枢,從而可以代表客戶使用資源帘靡。如果客戶已經(jīng)消失,使得服務(wù)器上保留一個半開放的連接瓤帚,而服務(wù)器又在等待來自客戶端的數(shù)據(jù)描姚,則服務(wù)器將應遠等待客戶端的數(shù)據(jù),备甏危活功能就是試圖在服務(wù) 器端檢測到這種半開放的連接轩勘。

如果一個給定的連接在兩小時內(nèi)沒有任何的動作,則服務(wù)器就向客戶發(fā)一個探測報文段怯邪,客戶主機必須處于以下4個狀態(tài)之一:

  1. 客戶主機依然正常運行绊寻,并從服務(wù)器可達⌒客戶的TCP響應正常澄步,而服務(wù)器也知道對方是正常的,服務(wù)器在兩小時后將焙兔冢活定時器復位村缸。

  2. 客戶主機已經(jīng)崩潰,并且關(guān)閉或者正在重新啟動武氓。在任何一種情況下梯皿,客戶的TCP都沒有響應。服務(wù)端將不能收到對探測的響應县恕,并在75秒后超時索烹。服務(wù)器總共發(fā)送10個這樣的探測 ,每個間隔75秒弱睦。如果服務(wù)器沒有收到一個響應,它就認為客戶主機已經(jīng)關(guān)閉并終止連接渊额。

  3. 客戶主機崩潰并已經(jīng)重新啟動况木。服務(wù)器將收到一個對其保活探測的響應旬迹,這個響應是一個復位火惊,使得服務(wù)器終止這個連接。

  4. 客戶機正常運行奔垦,但是服務(wù)器不可達屹耐,這種情況與2類似,TCP能發(fā)現(xiàn)的就是沒有收到探查的響應椿猎。

3.4 長連接短連接操作過程

短連接的操作步驟是:

  • 建立連接——數(shù)據(jù)傳輸——關(guān)閉連接…建立連接——數(shù)據(jù)傳輸——關(guān)閉連接

長連接的操作步驟是:

  • 建立連接——數(shù)據(jù)傳輸…(保持連接)…數(shù)據(jù)傳輸——關(guān)閉連接

4. 長連接和短連接的優(yōu)點和缺點

  • 由上可以看出惶岭,長連接可以省去較多的TCP建立和關(guān)閉的操作寿弱,減少浪費,節(jié)約時間按灶。對于頻繁請求資源的客戶來說症革,較適用長連接。不過這里存在一個問題鸯旁,存活功能的探測周期太長噪矛,還有就是它只是探測TCP連接的存活,屬于比較斯文的做法铺罢,遇到惡意的連接時艇挨,保活功能就不夠使了韭赘。在長連接的應用場景下缩滨,client端一般不會主動關(guān)閉它們之間的連接,Client與server之間的連接如果一直不關(guān)閉的話辞居,會存在一個問題楷怒,隨著客戶端連接越來越多,server早晚有扛不住的時候瓦灶,這時候server端需要采取一些策略鸠删,如關(guān)閉一些長時間沒有讀寫事件發(fā)生的連接,這樣可 以避免一些惡意連接導致server端服務(wù)受損贼陶;如果條件再允許就可以以客戶端機器為顆粒度刃泡,限制每個客戶端的最大長連接數(shù),這樣可以完全避免某個蛋疼的客戶端連累后端服務(wù)碉怔。

  • 短連接對于服務(wù)器來說管理較為簡單烘贴,存在的連接都是有用的連接,不需要額外的控制手段撮胧。但如果客戶請求頻繁桨踪,將在TCP的建立和關(guān)閉操作上浪費時間和帶寬犹芹。

  • 長連接和短連接的產(chǎn)生在于client和server采取的關(guān)閉策略顷帖,具體的應用場景采用具體的策略,沒有十全十美的選擇槽棍,只有合適的選擇墓怀。

5. 什么時候用長連接汽纠,短連接?

  • 長連接多用于操作頻繁傀履,點對點的通訊虱朵,而且連接數(shù)不能太多情況,。每個TCP連接都需要三步握手碴犬,這需要時間絮宁,如果每個操作都是先連接,再操作的話那么處理速度會降低很多翅敌,所以每個操作完后都不斷開羞福,次處理時直接發(fā)送數(shù)據(jù)包就OK了,不用建立TCP連接蚯涮。例如:數(shù)據(jù)庫的連接用長連接治专, 如果用短連接頻繁的通信會造成socket錯誤,而且頻繁的socket 創(chuàng)建也是對資源的浪費遭顶。

  • 而像WEB網(wǎng)站的http服務(wù)一般都用短鏈接张峰,因為長連接對于服務(wù)端來說會耗費一定的資源,而像WEB網(wǎng)站這么頻繁的成千上萬甚至上億客戶端的連接用短連接會更省一些資源棒旗,如果用長連接喘批,而且同時有成千上萬的用戶,如果每個用戶都占用一個連接的話铣揉,那可想而知吧饶深。所以并發(fā)量大,但每個用戶無需頻繁操作情況下需用短連好逛拱。

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末敌厘,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子朽合,更是在濱河造成了極大的恐慌俱两,老刑警劉巖,帶你破解...
    沈念sama閱讀 218,682評論 6 507
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件曹步,死亡現(xiàn)場離奇詭異宪彩,居然都是意外死亡,警方通過查閱死者的電腦和手機讲婚,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 93,277評論 3 395
  • 文/潘曉璐 我一進店門尿孔,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人筹麸,你說我怎么就攤上這事纳猫。” “怎么了竹捉?”我有些...
    開封第一講書人閱讀 165,083評論 0 355
  • 文/不壞的土叔 我叫張陵,是天一觀的道長尚骄。 經(jīng)常有香客問我块差,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 58,763評論 1 295
  • 正文 為了忘掉前任憨闰,我火速辦了婚禮状蜗,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘鹉动。我一直安慰自己轧坎,他們只是感情好,可當我...
    茶點故事閱讀 67,785評論 6 392
  • 文/花漫 我一把揭開白布泽示。 她就那樣靜靜地躺著缸血,像睡著了一般。 火紅的嫁衣襯著肌膚如雪械筛。 梳的紋絲不亂的頭發(fā)上捎泻,一...
    開封第一講書人閱讀 51,624評論 1 305
  • 那天,我揣著相機與錄音埋哟,去河邊找鬼笆豁。 笑死,一個胖子當著我的面吹牛赤赊,可吹牛的內(nèi)容都是我干的闯狱。 我是一名探鬼主播,決...
    沈念sama閱讀 40,358評論 3 418
  • 文/蒼蘭香墨 我猛地睜開眼抛计,長吁一口氣:“原來是場噩夢啊……” “哼哄孤!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起爷辱,我...
    開封第一講書人閱讀 39,261評論 0 276
  • 序言:老撾萬榮一對情侶失蹤录豺,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后饭弓,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體双饥,經(jīng)...
    沈念sama閱讀 45,722評論 1 315
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 37,900評論 3 336
  • 正文 我和宋清朗相戀三年弟断,在試婚紗的時候發(fā)現(xiàn)自己被綠了咏花。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 40,030評論 1 350
  • 序言:一個原本活蹦亂跳的男人離奇死亡阀趴,死狀恐怖昏翰,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情刘急,我是刑警寧澤棚菊,帶...
    沈念sama閱讀 35,737評論 5 346
  • 正文 年R本政府宣布,位于F島的核電站叔汁,受9級特大地震影響统求,放射性物質(zhì)發(fā)生泄漏检碗。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 41,360評論 3 330
  • 文/蒙蒙 一码邻、第九天 我趴在偏房一處隱蔽的房頂上張望折剃。 院中可真熱鬧,春花似錦像屋、人聲如沸怕犁。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,941評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽奏甫。三九已至,卻和暖如春篇恒,著一層夾襖步出監(jiān)牢的瞬間扶檐,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 33,057評論 1 270
  • 我被黑心中介騙來泰國打工胁艰, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留款筑,地道東北人。 一個月前我還...
    沈念sama閱讀 48,237評論 3 371
  • 正文 我出身青樓腾么,卻偏偏與公主長得像奈梳,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子解虱,可洞房花燭夜當晚...
    茶點故事閱讀 44,976評論 2 355

推薦閱讀更多精彩內(nèi)容