因为这段时间都是在弄网络方面的东西，协议如果不熟就说不过去了。于是就恶补HTTP/1.1的协议内容。HTTP/1.1的协议连接在一个稳定的tcp连接上，并且默认的方式是持续性连接的，除非报头出现了close的connection头，keep-alives 就没什么很大用了。那么，如果client 事实上 shutdown了 而连接未释放，怎么办？象任何其他协议一样，HTTP/1.1 都有 practical condition 的。否则就玩不转了。HTTP 连接的问题而言，Time Out的选择是不被量化 但是是默认的。Proxy server 而言 time Out的时间应该略为比 一般的server再长一点。
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.
Fielding, et al. Standards Track [Page 46]
RFC 2616 HTTP/1.1 June 1999
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.
