最近初涉網絡編程，分析了下HTTP協議，下面為第一篇關于HTTP連接控制方面的學習日志，主要參考RFC2616，肯定有疏漏之處，還望指出。
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表示在完成這個報文所屬請求/應答的收發后連接將關閉。