最近初涉網(wǎng)絡(luò)編程，分析了下HTTP協(xié)議，下面為第一篇關(guān)于HTTP連接控制方面的學(xué)習日志，主要參考RFC2616，肯定有疏漏之處，還望指出。
HTTP協(xié)議是位于傳輸層之上的應(yīng)用層協(xié)議，其網(wǎng)絡(luò)層基礎(chǔ)通常是TCP協(xié)議。TCP協(xié)議是面向連接和流的，因此連接的狀態(tài)和控制對于HTTP協(xié)議而言相當重要。同時，HTTP是基于報文的，因此如何確定報文長度也是協(xié)議中比較重要的一點。
Persistent Connections持久連接
目的
    在使用持久連接前，HTTP協(xié)議規(guī)定為獲取每個URL資源都需要使用單獨的一個TCP連接，這增加了HTTP服務(wù)端的負載，引起互聯(lián)網(wǎng)擁塞。例如內(nèi)嵌圖片以及其他類似數(shù)據(jù)的使用要求一個客戶端在很短時間內(nèi)向同一個服務(wù)端發(fā)起多個請求。
使用持久連接的優(yōu)點:
減少TCP連接數(shù)量
在一個連接上實現(xiàn)HTTP請求和應(yīng)答的流水，即允許客戶端發(fā)出多個請求，而不必在接收到前一請求的應(yīng)答后才發(fā)出下一請求，極大減少時間消耗
后續(xù)請求延遲減少，無需再在TCP握手上耗時
可以更加優(yōu)雅地實現(xiàn)HTTP協(xié)議，由于持續(xù)連接的存在無需報告錯誤后無需關(guān)閉連接，因此客戶端可使用最新的協(xié)議特性發(fā)出請求，如果接收到表示錯誤的應(yīng)答，則換用更舊的語義。

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

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

    所有接收實體的HTTP/1.1應(yīng)用程序必須接受"chunked"傳輸編碼, 這樣允許當報文長度無法預(yù)先確定時可以運用此機制獲取報文長度.
    報文不能同時包含Content-Length頭域和非"identity" Transfer-Encoding.如果出現(xiàn)了, Content-Length域必須被忽略.
    當Content-Length域在允許報文體的報文中存在時, 其域值必須嚴格等于消息體中的8比特字節(jié).HTTP/1.1 user agent 必須在接收并檢測到一個錯誤的長度時提醒用戶.
    以上方法中，最常見的還是使用Content-Length域表示報文體長度，Transfer-Encoding需要按格式解碼才能還原出發(fā)送編碼前的報文。

流水
    支持持久連接的客戶端可以流水發(fā)送請求，服務(wù)端必須按發(fā)送的順序發(fā)送應(yīng)答。
    假定持久連接和連接后即可流水的客戶端應(yīng)當做好在第一次流水失敗后重新嘗試此連接。在這樣的嘗試中，在確定連接是持久的之前，客戶端不能再流水。
    客戶端同樣必須準備好在服務(wù)端送回所有相關(guān)應(yīng)答前就關(guān)閉連接時重發(fā)請求。
    不應(yīng)流水non-idempotent方法

Proxy Servers
    對于代理服務(wù)端而言，正確實現(xiàn)Connection頭域指定的屬性尤為重要。
    代理服務(wù)端必須分立通告它的客戶端和連接的原始服務(wù)端持久連接的屬性，每個持久連接設(shè)置僅針對一個傳輸連接。
   
實踐考量
    超時值，服務(wù)端通常會為每個連接維護一個定時器，一旦某個連接不活躍超過一定時間值，服務(wù)端會關(guān)閉此連接。考慮到一個客戶端可能通過代理服務(wù)端發(fā)出更多連接，代理服務(wù)端通常會將超時值設(shè)置得更高。
    還有一些關(guān)于從異步關(guān)閉中恢復(fù)的討論。

報文傳輸要求
    使用TCP流控制來解決服務(wù)端臨時負載過高問題，而不是簡單的依賴客戶端重連而關(guān)閉連接。
    監(jiān)視連接情況以獲取錯誤狀態(tài)消息
    關(guān)于使用100(繼續(xù))狀態(tài)碼
    100狀態(tài)碼用于客戶端發(fā)送請求體之前測試是否可以發(fā)送該請求，對于Proxy，有以下要求：
1.如果代理服務(wù)端接收到包含Expect頭域值為"100-continue"的請求, 而不明確知道下一跳服務(wù)不支持HTTP/1.1以上版本, 則它必須轉(zhuǎn)發(fā)這個請求, 包括Expect頭域.
2.如果代理知道下一跳服務(wù)端為HTTP/1.0或者更低版本, 則它不能轉(zhuǎn)發(fā)此請求, 且必須以407應(yīng)答客戶端.
3.如果明確知道發(fā)出請求的客戶端版本為HTTP/1.0或者更低，則代理服務(wù)端絕不能轉(zhuǎn)發(fā)100應(yīng)答,這條規(guī)則凌駕于轉(zhuǎn)發(fā)1xx應(yīng)答的一般準則.

Connection頭域說明
BNF文法：
    Connection = "Connection" ":" 1#(connection-token)
    connection-token  = token
    Connection頭域中的token用于指定對于特定連接有意義的選項，因此proxy在轉(zhuǎn)發(fā)前要掃描此域，從頭中去除和token同名的域。例如Connection:Range,則要去掉Range域。
    HTTP/1.1定義了close這個token，發(fā)送者用此token表示在完成這個報文所屬請求/應(yīng)答的收發(fā)后連接將關(guān)閉。