HTTP 1.1 Connction 报头部分译文

8 Connections

8 连接

8.1 Persistent Connections

8.1持久连接

8.1.1 Purpose

8.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表示在完成这个报文所属请求/应答的收发后连接将关闭。