HTTP長鏈接、短鏈接到底是什麼？

1. HTTP協議與TCP/IP協議的關係

HTTP的長鏈接和短鏈接本質上是TCP長鏈接和短鏈接。HTTP屬於應用層協議，在傳輸層使用TCP協議，在網絡層使用IP協議。 IP協議主要解決網絡路由和尋址問題，TCP協議主要解決如何在IP層之上可靠地傳遞數據包，使得網絡上接收端收到發送端所發出的全部包，而且順序與發送順序一致。TCP協議是可靠的、面向鏈接的。

2. 如何理解HTTP協議是無狀態的

HTTP協議是無狀態的，指的是協議對於事務處理沒有記憶能力，服務器不知道客戶端是什麼狀態。也就是說，打開一個服務器上的網頁和上一次打開這個服務器上的網頁之間沒有任何聯繫。HTTP是一個無狀態的面向鏈接的協議，無狀態不表明HTTP不能保持TCP鏈接，更不能表明HTTP使用的是UDP協議（無鏈接）。

3. 什麼是長鏈接、短鏈接？

在HTTP/1.0中默認使用短鏈接。也就是說，客戶端和服務器每進行一次HTTP操做，就創建一次鏈接，任務結束就中斷鏈接。當客戶端瀏覽器訪問的某個HTML或其餘類型的Web頁中包含有其餘的Web資源（如JavaScript文件、圖像文件、CSS文件等），每遇到這樣一個Web資源，瀏覽器就會從新創建一個HTTP會話。

而從HTTP/1.1起，默認使用長鏈接，用以保持鏈接特性。使用長鏈接的HTTP協議，會在響應頭加入這行代碼：

Connection:keep-alive 

在使用長鏈接的狀況下，當一個網頁打開完成後，客戶端和服務器之間用於傳輸HTTP數據的TCP鏈接不會關閉，客戶端再次訪問這個服務器時，會繼續使用這一條已經創建的鏈接。Keep-Alive不會永久保持鏈接，它有一個保持時間，能夠在不一樣的服務器軟件（如Apache）中設定這個時間。實現長鏈接須要客戶端和服務端都支持長鏈接。

HTTP協議的長鏈接和短鏈接，實質上是TCP協議的長鏈接和短鏈接。

3.1. TCP鏈接

當網絡通訊時採用TCP協議時，在真正的讀寫操做以前，客戶端與服務器端之間必須創建一個鏈接，當讀寫操做完成後，雙方再也不須要這個鏈接時能夠釋放這個鏈接。鏈接的創建依靠「三次握手」，而釋放則須要「四次握手」，因此每一個鏈接的創建都是須要資源消耗和時間消耗的。

經典的三次握手創建鏈接示意圖：

經典的四次握手關閉鏈接示意圖：

3.2. TCP短鏈接

模擬一下TCP短鏈接的狀況：client向server發起鏈接請求，server接到請求，而後雙方創建鏈接。client向server發送消息，server迴應client，而後一次請求就完成了。這時候雙方任意均可以發起close操做，不過通常都是client先發起close操做。上述可知，短鏈接通常只會在 client/server間傳遞一次請求操做。

短鏈接的優勢是：管理起來比較簡單，存在的鏈接都是有用的鏈接，不須要額外的控制手段。

3.3. TCP長鏈接

咱們再模擬一下長鏈接的狀況：client向server發起鏈接，server接受client鏈接，雙方創建鏈接，client與server完成一次請求後，它們之間的鏈接並不會主動關閉，後續的讀寫操做會繼續使用這個鏈接。

TCP的保活功能主要爲服務器應用提供。若是客戶端已經消失而鏈接未斷開，則會使得服務器上保留一個半開放的鏈接，而服務器又在等待來自客戶端的數據，此時服務器將永遠等待客戶端的數據。保活功能就是試圖在服務端器端檢測到這種半開放的鏈接。

若是一個給定的鏈接在兩小時內沒有任何動做，服務器就向客戶發送一個探測報文段，根據客戶端主機響應探測4個客戶端狀態：

• 客戶主機依然正常運行，且服務器可達。此時客戶的TCP響應正常，服務器將保活定時器復位。
• 客戶主機已經崩潰，而且關閉或者正在從新啓動。上述狀況下客戶端都不能響應TCP。服務端將沒法收到客戶端對探測的響應。服務器總共發送10個這樣的探測，每一個間隔75秒。若服務器沒有收到任何一個響應，它就認爲客戶端已經關閉並終止鏈接。
• 客戶端崩潰並已經從新啓動。服務器將收到一個對其保活探測的響應，這個響應是一個復位，使得服務器終止這個鏈接。
• 客戶機正常運行，可是服務器不可達。這種狀況與第二種狀態相似。

4. 長鏈接和短鏈接的優勢和缺點

由上能夠看出，長鏈接能夠省去較多的TCP創建和關閉的操做，減小浪費，節約時間。對於頻繁請求資源的客戶端適合使用長鏈接。在長鏈接的應用場景下，client端通常不會主動關閉鏈接，當client與server之間的鏈接一直不關閉，隨着客戶端鏈接愈來愈多，server會保持過多鏈接。這時候server端須要採起一些策略，如關閉一些長時間沒有請求發生的鏈接，這樣能夠避免一些惡意鏈接致使server端服務受損；若是條件容許則能夠限制每一個客戶端的最大長鏈接數，這樣能夠徹底避免惡意的客戶端拖垮總體後端服務。

短鏈接對於服務器來講管理較爲簡單，存在的鏈接都是有用的鏈接，不須要額外的控制手段。但若是客戶請求頻繁，將在TCP的創建和關閉操做上浪費較多時間和帶寬。

長鏈接和短鏈接的產生在於client和server採起的關閉策略。不一樣的應用場景適合採用不一樣的策略。

由上能夠看出，長鏈接能夠省去較多的TCP創建和關閉的操做，減小浪費，節約時間。對於頻繁請求資源的客戶來講，較適用長鏈接。不過這裏存在一個問題，存活功能的探測週期太長，還有就是它只是探測TCP鏈接的存活，屬於比較斯文的作法，遇到惡意的鏈接時，保活功能就不夠使了。在長鏈接的應用場景下，client端通常不會主動關閉它們之間的鏈接，Client與server之間的鏈接若是一直不關閉的話，會存在一個問題，隨着客戶端鏈接愈來愈多，server遲早有扛不住的時候，這時候server端須要採起一些策略，如關閉一些長時間沒有讀寫事件發生的鏈接，這樣可 以免一些惡意鏈接致使server端服務受損；若是條件再容許就能夠以客戶端機器爲顆粒度，限制每一個客戶端的最大長鏈接數，這樣能夠徹底避免某個蛋疼的客戶端連累後端服務。

短鏈接對於服務器來講管理較爲簡單，存在的鏈接都是有用的鏈接，不須要額外的控制手段。但若是客戶請求頻繁，將在TCP的創建和關閉操做上浪費時間和帶寬。

長鏈接和短鏈接的產生在於client和server採起的關閉策略，具體的應用場景採用具體的策略，沒有十全十美的選擇，只有合適的選擇。

長鏈接短鏈接操做過程

短鏈接的操做步驟是：

創建鏈接——數據傳輸——關閉鏈接...創建鏈接——數據傳輸——關閉鏈接

長鏈接的操做步驟是：

創建鏈接——數據傳輸...（保持鏈接）...數據傳輸——關閉鏈接

何時用長鏈接，短鏈接？  　　

長鏈接多用於操做頻繁，點對點的通信，並且鏈接數不能太多狀況，。每一個TCP鏈接都須要三步握手，這須要時間，若是每一個操做都是先鏈接，再操做的話那麼處理速度會下降不少，因此每一個操做完後都不斷開，次處理時直接發送數據包就OK了，不用創建TCP鏈接。例如：數據庫的鏈接用長鏈接， 若是用短鏈接頻繁的通訊會形成socket錯誤，並且頻繁的socket 建立也是對資源的浪費。 
  
　　而像WEB網站的http服務通常都用短連接，由於長鏈接對於服務端來講會耗費必定的資源，而像WEB網站這麼頻繁的成千上萬甚至上億客戶端的鏈接用短鏈接會更省一些資源，若是用長鏈接，並且同時有成千上萬的用戶，若是每一個用戶都佔用一個鏈接的話，那可想而知吧。因此併發量大，但每一個用戶無需頻繁操做狀況下需用短連好。

 

http和socket之長鏈接和短鏈接區別

http://www.jianshu.com/p/b68d2b26f5f4

 

HTTP 的長鏈接和短鏈接

http://blog.jobbole.com/104108/

 

HTTP持久鏈接

https://zh.wikipedia.org/wiki/HTTP%E6%8C%81%E4%B9%85%E8%BF%9E%E6%8E%A5

 

長鏈接

http://baike.baidu.com/view/2831907.htm