W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1994

Re: Connection Header

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Tue, 20 Dec 94 16:15:10 PST
Message-Id: <9412210015.AA25446@acetes.pa.dec.com>
To: John Franks <john@math.nwu.edu>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, mogul@pa.dec.com
    I have some some serious reservations about this.  Perhaps someone
    more knowledgeable about TCP/IP can alleviate them.  Won't this
    maintain the connection during the entire time that a client takes to
    download and layout and display a document containing containing
    mulitple images?  This could represent a substantial amount of time
    over a slow link.  For a heavily loaded server, say like HotWired,
    keeping the connection open during the entire time a user enters her
    password and multiple images in a document are downloaded over a 14.4
    link could add up to quite a bit of time.  I would think that the
    maximum number of allowed connections would be exceded quite often.
    There would probably be a large number of timeouts each one representing
    almost 10 seconds of unused connect time.
    
Other people have already responded, pointing out the basic
misunderstanding here about TCP connection state records.

I just wanted to address the "maximum number of connections" issue.
Even with persistent-connection HTTP, you never need to support
any more simultaneous connections than with vanilla HTTP.  However,
the more connections you have available, the better the performance.

One caveat: my simulations assumed that the request rate would
remain constant even if the UPP improved (because responses would
be received faster, using persistent connections).  This could
actually lead to a slightly higher request rate.  On the other hand,
I would assume it would cause a higher request rate from exactly
those clients that have open connections, so it would not actually
increase the number of processes needed to respond to those requests.

-Jeff
Received on Tuesday, 20 December 1994 16:25:13 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:10 EDT