因爲這段時間都是在弄網絡方面的東西，協議如果不熟就說不過去了。於是就惡補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.
