HTTP 1.1 Connction 前序部分譯文

文章目錄

• 8.1.1 Purpose
• 8.1.2 Overall Operation
• 8.1.3 Proxy Servers
• 8.1.4 Practical Considerations

8 Connections

8 串連

8.1 Persistent Connections8.1持久串連8.1.1 Purpose8.1.1目的

Prior to persistent connections, a separate TCP connection was established to fetch each URL, increasing the load on
HTTP servers and causing congestion on the Internet. The use of inline images and other associated data often
require a client to make multiple requests of the same server in a short amount of time. Analysis of these
performance problems and results from a prototype implementation are available [26] [30]. Implementation
experience and measurements of actual HTTP/1.1 (RFC 2068) implementations show good results [39]. Alternatives

have also been explored, for example, T/TCP [27].

之所以設計了持久性連結，是為了消除每個URL資源會建立獨立的TCP串連所帶來的對Http伺服器的負載和網路阻塞。內聯圖片和其他相關資料通常使得

用戶端需要段時間內向同一個伺服器發起多次請求。關於具體效能問題的分析和具體協議的實現請參見引用[26][30].

實現經驗和Http/1.1 （RFC 2068）的真實實現細節能說明問題。還有一些可選的資料去查看，例如T/TCP 引用[27]。

Persistent HTTP connections have a number of advantages:
• By opening and closing fewer TCP connections, CPU time is saved in routers and hosts (clients, servers,
   proxies, gateways, tunnels, or caches), and memory used for TCP protocol control blocks can be saved in
  hosts.
• HTTP requests and responses can be pipelined on a connection. Pipelining allows a client to make multiple
   requests without waiting for each response, allowing a single TCP connection to be used much more
  efficiently, with much lower elapsed time.
Fielding, et al
Standards Track
[Page 29]
RFC 2616
•
HTTP/1.1
June, 1999
Network congestion is reduced by reducing the number of packets caused by TCP opens, and by allowing
TCP sufficient time to determine the congestion state of the network.
•
Latency on subsequent requests is reduced since there is no time spent in TCP’s connection opening
handshake.
• HTTP can evolve more gracefully, since errors can be reported without the penalty of closing the TCP
connection. Clients using future versions of HTTP might optimistically try a new feature, but if
communicating with an older server, retry with old semantics after an error is reported.

HTTP implementations SHOULD implement persistent connections.

持久性HTTP串連有如下優點：

a 、通過開啟更少的TCP串連，路由器和主機（用戶端，伺服器，代理，網關，隧道或者緩衝）上的CPU時間被節省了，

並且主機上用於TCP 協議控制塊的記憶體也能節省。

b、無需等到上個請求響應，可以流水線般發出多個請求。

c、網路擁堵減輕，通過兩種方式：一是減少開啟TCP 串連所發的包數量，二是允許TCP有足夠的時間來決定網路擁堵的狀況。

d、連續的請求延時減輕了，因為不需要花很多時間來進行TCP串連開啟階段的握手。

e、HTTP實現更加優雅。即使出現錯誤，也無需關閉TCP串連。當用戶端嘗試用新的HTTP特性向舊特徵伺服器發出請求報錯時，

會自動retry舊特徵的請求。

8.1.2 Overall Operation總體描述

A significant difference between HTTP/1.1 and earlier versions of HTTP is that persistent connections are the
default behavior of any HTTP connection. That is, unless otherwise indicated, the client SHOULD assume that the
server will maintain a persistent connection, even after error responses from the server.
Persistent connections provide a mechanism by which a client and a server can signal the close of a TCP connection.
This signaling takes place using the Connection header field (section 14.10). Once a close has been signaled, the

client MUST NOT send any more requests on that connection.

HTTP1.1與之前的HTTP版本不同的是，持久化串連是預設的。即，除非特殊聲明，用戶端應當假定伺服器會維護一個持久化

串連，即使在伺服器放回錯誤之後的每次請求。

持久串連對關閉TCP串連的行為提供訊號量機制支援。這個訊號量是在HTTP頭中的Connection網域設定，注意Client向Proxy發出請求時該域可能被Proxy-Connection域替換。一旦close訊號被表明，用戶端絕不能再通過該串連發送更多的請求。

8.1.2.1 Negotiation 協商

An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to maintain a persistent connection unless a
Connection header including the connection-token “close” was sent in the request. If the server chooses to
close the connection immediately after sending the response, it SHOULD send a Connection header including the
connection-token close.
An HTTP/1.1 client MAY expect a connection to remain open, but would decide to keep it open based on whether
the response from a server contains a Connection header with the connection-token close. In case the client
does not want to maintain a connection for more than that request, it SHOULD send a Connection header
including the connection-token close.
If either the client or the server sends the close token in the Connection header, that request becomes the last
one for the connection.
Clients and servers SHOULD NOT assume that a persistent connection is maintained for HTTP versions less than
1.1 unless it is explicitly signaled. See section 19.6.2 for more information on backward compatibility with
HTTP/1.0 clients.
In order to remain persistent, all messages on the connection MUST have a self-defined message length (i.e., one not

defined by closure of the connection), as described in section 4.4.

一個HTTP 1.1伺服器可以假定一個HTTP1.1用戶端會維護持久化串連，除非請求中包括標明‘close’欄位的Connection。

如果伺服器希望在發送網response後就關閉連結，應該在response中加上標明‘close’的Connection。

(因為TCP串連雙向，這個應答包北用戶端收到後，串連進入半關閉狀態)。

同樣的，HTTP/1.1用戶端可以期望串連是持久的，除非如前所述收到表示串連關閉的應答。當然，也可以主動發出一個包含Connection:close的請求以表明終止串連。 

不管是用戶端還是伺服器發出一個包含close的Connection域，已有的請求便是這個串連上的最後一個。

對於，之前的HTTP版本，持久化串連預設是關閉的。

為保證持久性，串連上的報文都必須有一個自訂的報文傳輸長度(否則必須通過串連的關閉表示報文結束，因為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需要按格式解碼才能還原出發送編碼前的報文。 

8.1.2.2 Pipelining

A client that supports persistent connections MAY “pipeline” its requests (i.e., send multiple requests without
waiting for each response). A server MUST send its responses to those requests in the same order that the requests
were received.
Clients which assume persistent connections and pipeline immediately after connection establishment SHOULD be
prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it MUST NOT
pipeline before it knows the connection is persistent. Clients MUST also be prepared to resend their requests if the
server closes the connection before sending all of the corresponding responses.
Clients SHOULD NOT pipeline requests using non-idempotent methods or non-idempotent sequences of methods
(see section 9.1.2). Otherwise, a premature termination of the transport connection could lead to indeterminate
results. A client wishing to send a non-idempotent request SHOULD wait to send that request until it has received
the response status for the previous request.
Fielding, et al
Standards Track
[Page 30]
RFC 2616
HTTP/1.1

June, 1999

支援持久串連的用戶端可以流水發送請求，服務端必須按發送的順序發送應答。 
    假定持久串連和串連後即可流水的用戶端應當做好在第一次流水失敗後重新嘗試此串連。在這樣的嘗試中，

在確定串連是持久的之前，用戶端不能再流水。 
    用戶端同樣必須準備好在服務端送回所有相關應答前就關閉串連時重發請求。 
    不應流水non-idempotent方法 

8.1.3 Proxy Servers

It is especially important that proxies correctly implement the properties of the Connection header field as
specified in section 14.10.
The proxy server MUST signal persistent connections separately with its clients and the origin servers (or other
proxy servers) that it connects to. Each persistent connection applies to only one transport link.
A proxy server MUST NOT establish a HTTP/1.1 persistent connection with an HTTP/1.0 client (but see RFC 2068
[33] for information and discussion of the problems with the Keep-Alive header implemented by many HTTP/1.0

clients).

 對於代理服務端而言，正確實現Connection頭域指定的屬性尤為重要。 
  代理服務端必須分立通告它的用戶端和串連的原始服務端持久串連的屬性，每個持久串連設定僅針

對一個傳輸串連。 

8.1.4 Practical Considerations

Servers will usually have some time-out value beyond which they will no longer maintain an inactive connection.
Proxy servers might make this a higher value since it is likely that the client will be making more connections
through the same server. The use of persistent connections places no requirements on the length (or existence) of this
time-out for either the client or the server.
When a client or server wishes to time-out it SHOULD issue a graceful close on the transport connection. Clients
and servers SHOULD both constantly watch for the other side of the transport close, and respond to it as appropriate.
If a client or server does not detect the other side’s close promptly it could cause unnecessary resource drain on the
network.
A client, server, or proxy MAY close the transport connection at any time. For example, a client might have started
to send a new request at the same time that the server has decided to close the “idle” connection. From the server’s
point of view, the connection is being closed while it was idle, but from the client’s point of view, a request is in
progress.
This means that clients, servers, and proxies MUST be able to recover from asynchronous close events. Client
software SHOULD reopen the transport connection and retransmit the aborted sequence of requests without user
interaction so long as the request sequence is idempotent (see section 9.1.2). Non-idempotent methods or sequences
MUST NOT be automatically retried, although user agents MAY offer a human operator the choice of retrying the
request(s). Confirmation by user-agent software with semantic understanding of the application MAY substitute for
user confirmation. The automatic retry SHOULD NOT be repeated if the second sequence of requests fails.
Servers SHOULD always respond to at least one request per connection, if at all possible. Servers SHOULD NOT
close a connection in the middle of transmitting a response, unless a network or client failure is suspected.
Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to
a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy. A
proxy SHOULD use up to 2*N connections to another server or proxy, where N is the number of simultaneously
active users. These guidelines are intended to improve HTTP response times and avoid congestion.
逾時值，服務端通常會為每個串連維護一個定時器，一旦某個串連不活躍超過一定時間值，服務端會關閉此串連。考慮到一個用戶端可能通過代理服務端發出更多串連，代理服務端通常會將逾時值設定得更高。 
    還有一些關於從非同步關閉中恢複的討論。 

報文傳輸要求 
    使用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表示在完成這個報文所屬請求/應答的收發後串連將關閉。