什么是Http長連接

長連接定義：
client方與server方先建立連接，連接建立后不斷開，然后再進行報文發送和接收。這種方式下由于通訊連接一直存在。此種方式常用于P2P點對點的通信。

長連接的操作步驟是：建立連接——數據傳輸...（保持連接）...數據傳輸——關閉連接
長連接適用場景：
監控系統：后臺硬件熱插拔、LED、溫度、電壓發生變化；
即時通信系統：其它用戶登錄、發送信息；
即時報價系統：后臺數據庫內容發生變化；
像以上這些連接，如果每次操作都要建立連接然后再操作的話處理速度會降低。所以操作時第一次連接上以后，以后每次直接發送數據就可以了，不用再建立TCP連接。
再比如：數據庫的連接用長連接，如果用短連接頻繁的通信會造成socket錯誤，頻繁的socket創建也是對資源的浪費。
Comet
以前的http的長連接技術不成熟，目前有新技術名叫Comet：基于 HTTP 長連接的“服務器推”技術。
案例：基于 AJAX 的長輪詢（long-polling）方式
AJAX 的出現使得 JavaScript 可以調用 XMLHttpRequest 對象發出 HTTP 請求，JavaScript 響應處理函數根據服務器返回的信息對 HTML 頁面的顯示進行更新。使用 AJAX 實現“服務器推”與傳統的 AJAX 應用不同之處在于執行順序及內容：
1.服務器端會阻塞請求直到有數據傳遞或超時才返回。
2.客戶端 JavaScript 響應處理函數會在處理完服務器返回的信息后，再次發出請求，重新建立連接。
3.當客戶端處理接收的數據、重新建立連接時，服務器端可能有新的數據到達；這些信息會被服務器端保存直到客戶端重新建立連接，客戶端會一次把當前服務器端所有的信息取回。

具體方案及案例可以參考IBM官網：http://www.ibm.com/developerworks/cn/web/wa-lo-comet/

什么是Http短連接

短連接定義
Client方與server每進行一次報文收發交易時才進行通訊連接，交易完畢后立即斷開連接。此方式常用于一點對多點通訊。

短連接的操作步驟是：建立連接——數據傳輸——關閉連接...建立連接——數據傳輸——關閉連接

短連接的適用場景：
短連接多用于操作頻繁，點對點的通訊，而且連接數不能太多的情況。每個TCP連接的建立都需要三次握手，每個TCP連接的斷開要四次握手。
web網站的http服務一般都用短連接。因為長連接對于服務器來說要耗費一定的資源。像web網站這么頻繁的成千上萬甚至上億客戶端的連接用短連接更省一些資源。
試想如果都用長連接，而且同時用成千上萬的用戶，每個用戶都占有一個連接的話，可想而知服務器的壓力有多大。所以并發量大，但是每個用戶又不需頻繁操作的情況下需要短連接。總之：長連接和短連接的選擇要視需求而定。
什么是Http持久連接
HTTP協議是位于傳輸層之上的應用層協議，其網絡層基礎通常是TCP協議。TCP協議是面向連接和流的，因此連接的狀態和控制對于HTTP協議而言相當重要。同時，HTTP是基于報文的，因此如何確定報文長度也是協議中比較重要的一點。?

Persistent Connections持久連接?

????在使用持久連接前，HTTP協議規定為獲取每個URL資源都需要使用單獨的一個TCP連接，這增加了HTTP服務端的負載，引起互聯網擁塞。例如內嵌圖片以及其他類似數據的使用要求一個客戶端在很短時間內向同一個服務端發起多個請求。?
使用持久連接的優點:?
減少TCP連接數量?
在一個連接上實現HTTP請求和應答的流水，即允許客戶端發出多個請求，而不必在接收到前一請求的應答后才發出下一請求，極大減少時間消耗?
后續請求延遲減少，無需再在TCP握手上耗時?
可以更加優雅地實現HTTP協議，由于持續連接的存在無需報告錯誤后無需關閉連接，因此客戶端可使用最新的協議特性發出請求，如果接收到表示錯誤的應答，則換用更舊的語義。?

總體描述?
HTTP/1.1和之前版本的顯著區別是HTTP/1.1默認使用持久連接。即，除非服務端在應答中明確指出，客戶端應當假定服務端會維持一個持久連接，即使從服務端收到的應答是報告錯誤。?
持久連接對關閉TCP連接的行為提供信號量機制支持。這個信號量是在HTTP頭中的Connection域設置，注意Client向Proxy發出請求時該域可能被Proxy-Connection域替換。一旦close信號被表明，客戶端絕不能再通過該連接發送更多的請求。?

協商(Negotiation)?
HTTP/1.1 服務端可以假定HTTP/1.1客戶端會維持持久連接，除非請求中Connection域的值是"close".同樣的，如果服務端打算在送出應答后立即關閉連接，它應當在應答中包含同樣的Connection域。(TCP連接關閉是雙向的,此時TCP進入半關閉狀態)?
同樣的，HTTP/1.1客戶端可以期望連接是持久的，除非如前所述收到表示連接關閉的應答。當然，也可以主動發出一個包含Connection:close的請求以表明終止連接。?
無論客戶端還是服務端發出的報文包含Connection:close，則該請求均為連接上的最后一個請求(服務端發出此應答后關閉，因此不可能接收更多的請求)?
報文傳輸長度?
????為保證持久性，連接上的報文都必須有一個自定義的報文傳輸長度(否則必須通過連接的關閉表示報文結束，因為TCP連接是面向流的)，確定的規則按優先級由高到低排列如下：?
????報文傳輸長度指報文中出現的報文體的長度(即，不包括頭長度，因為報文頭的結束可通過連續兩個CRLF確定）?
1.任何絕不能包含報文體(如1xx,204,304)的應答消息總是以頭域后的第一個空行結束,無視頭中所有的entity類型域的設置，包括Content-Length域。?
2.Transfer-Encoding域出現，其值為除"identify"以外的其他值，則用"chunked"傳輸編碼方式確定傳輸長度，具體方式留待下篇分析。?
3.Content -Length域出現，且Transfer-Encoding域未出現(出現則忽略Content-Length域)。Content-Length域的值為十進制數的字節序，如Content-Length：1234，則1、2、3、4是分別作為一個octet傳輸的，因此需要atoi轉換成數值。?
4.如果報文使用了"multipart/byteranges"的媒體類型，且沒對傳輸長度做前面的指明，則這種自分割的媒體類型定義了傳輸長度。具體參見Range頭域的說明。?
5.服務端關閉連接(此方法不可用于客戶端發出的請求報文，因為客戶端關閉連接則使得服務端無法發送應答).?
????為保持和HTTP/1.0的兼容性, 包含報文體的HTTP/1.1請求必須包含合法的Content-Length頭域,除非明確知道服務端是HTTP/1.1兼容的.如果請求包含消息體, 而沒有Content-Length域,那么如果服務端無法確定消息長度時,它會返回400(無效請求),或者堅持獲取合法Content-Length 而返回411(要求包含長度).?

????所有接收實體的HTTP/1.1應用程序必須接受"chunked"傳輸編碼, 這樣允許當報文長度無法預先確定時可以運用此機制獲取報文長度.?
????報文不能同時包含Content-Length頭域和非"identity" Transfer-Encoding.如果出現了, Content-Length域必須被忽略.?
????當Content-Length域在允許報文體的報文中存在時, 其域值必須嚴格等于消息體中的8比特字節.HTTP/1.1 user agent 必須在接收并檢測到一個錯誤的長度時提醒用戶.?
????以上方法中，最常見的還是使用Content-Length域表示報文體長度，Transfer-Encoding需要按格式解碼才能還原出發送編碼前的報文。?
流水?
????支持持久連接的客戶端可以流水發送請求，服務端必須按發送的順序發送應答。?
????假定持久連接和連接后即可流水的客戶端應當做好在第一次流水失敗后重新嘗試此連接。在這樣的嘗試中，在確定連接是持久的之前，客戶端不能再流水。?
????客戶端同樣必須準備好在服務端送回所有相關應答前就關閉連接時重發請求。?
????不應流水non-idempotent方法?

Proxy Servers?
????對于代理服務端而言，正確實現Connection頭域指定的屬性尤為重要。?
????代理服務端必須分立通告它的客戶端和連接的原始服務端持久連接的屬性，每個持久連接設置僅針對一個傳輸連接。?
?????
實踐考量?
????超時值，服務端通常會為每個連接維護一個定時器，一旦某個連接不活躍超過一定時間值，服務端會關閉此連接。考慮到一個客戶端可能通過代理服務端發出更多連接，代理服務端通常會將超時值設置得更高。?
????還有一些關于從異步關閉中恢復的討論。?
報文傳輸要求?
????使用TCP流控制來解決服務端臨時負載過高問題，而不是簡單的依賴客戶端重連而關閉連接。?
????監視連接情況以獲取錯誤狀態消息?
????關于使用100(繼續)狀態碼?
????100狀態碼用于客戶端發送請求體之前測試是否可以發送該請求，對于Proxy，有以下要求：?
1.如果代理服務端接收到包含Expect頭域值為"100-continue"的請求, 而不明確知道下一跳服務不支持HTTP/1.1以上版本, 則它必須轉發這個請求, 包括Expect頭域.?
2.如果代理知道下一跳服務端為HTTP/1.0或者更低版本, 則它不能轉發此請求, 且必須以407應答客戶端.?
3.如果明確知道發出請求的客戶端版本為HTTP/1.0或者更低，則代理服務端絕不能轉發100應答,這條規則凌駕于轉發1xx應答的一般準則.?
Connection頭域說明?
BNF文法：?
????Connection = "Connection" ":" 1#(connection-token)?
????connection-token ?= token?
????Connection頭域中的token用于指定對于特定連接有意義的選項，因此proxy在轉發前要掃描此域，從頭中去除和token同名的域。例如Connection:Range,則要去掉Range域。?
????HTTP/1.1定義了close這個token，發送者用此token表示在完成這個報文所屬請求/應答的收發后連接將關閉。

總結

以上是生活随笔為你收集整理的HTTP长连接，短链接，持久连接的区别的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。