Of HTTP/1.1 persistent connections and TCP Keepalive timers

I'm curious about how HTTP/1.1 [RFC2616] persistent connections typically work 
with respect to the typical browsers out in the wild today (Netscape & 
Microsoft being the two I'm particularly interested in). If I cause a browser 
to send a GET request for a given URL (using HTTP/1.1) to a server, and the 
server doesn't encounter any errors in processing it and responding, and then 
I (say) don't touch the browser for hours, what *typically* happens to the 
established HTTP/1.1 (-over-TCP) connection?

I note that RFC2616 says (in part)..


                             :
8 Connections

8.1 Persistent Connections
                             :
   HTTP implementations SHOULD implement persistent connections.
                             :
   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.
                             :


As it is written, this effectively puts the responsibility for closing the 
HTTP/1.1-cum-TCP connection on the client.

In nosing around on this subject, I note that in [W.R.Stevens, TCP/IP 
Illustrated Vol 1, http://www.dqc.org/~chris/tcpip_ill/], in chapter 23 
Stevens says that..

1. "Keepalives are not part of the TCP specification. ... Nevertheless, many 
implementations provide the keep-alive timer."

2. "If there is no activity on a given connection for 2 hours, the server 
sends a probe segment to the client. ... A perpetual question by people 
discovering the keepalive option is whether the 2-hour idle time value can be 
changed. They normally want it much lower, on the order of minutes. As we show 
in Appendix E, the value can usually be changed, but in all the systems 
described in this appendix, the keepalive interval is a system-wide value, so 
changing it affects all users of the option. "

..and in appendix E he shows kernel configuration parameters for several 
Unix-based TCP implementations, most all of which have a default 2-hour 
timeout *before* a keepalive packet will be sent.

I also note that Microsoft shows a default value of 2 hour idletime for the 
keepalive timer in this doc:

  http://www.microsoft.com/technet/winnt/reskit/sur_tcp2.asp


Some questions (again, in the case of HTTP/1.1 persistent connections):

Q1. Do the popular browsers typically take the platform's OS's TCP defaults 
for
the keepalive (if such capability is provided by the TCP/IP stack, and if it 
is actually used by the browser), or do they typically set this value to 
something in particular?


Q2. What typical assumptions are made on the browsers' parts about an 
established connection to a web site in the absence of user actions? If a
browser opened a HTTP/1.1 connection and the server is behaving as-specified 
by RFC2616, then it is up to the browser to close the connection. What do 
browsers typically do? I looked through the documented configuration 
parameters for Netscape Communicator..

  http://docs.iplanet.com/docs/manuals/communicator/newprefs/newprefn.html

..and could not find a timeout setting that's applicable for this particular 
case. How long will browsers, that are speaking HTTP/1.1, let this connection 
sit in the ESTABLISHED state?


Q3. Are the popular browsers typically using HTTP/1.1, or HTTP/1.0? I didn't 
notice any config parameters that might have something to do with setting the 
default.

thanks,

JeffH

Received on Wednesday, 1 November 2000 23:59:34 UTC