什麼是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表示在完成這個報文所屬請求/應答的收發後連線將關閉。