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.

Received on Tuesday, 20 December 1994 16:25:13 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:13 UTC