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

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

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

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

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

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

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

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