[e2e] Number of persistent connections per HTTP server?
touch at ISI.EDU
Thu Oct 10 22:02:24 PDT 2002
Greg Minshall wrote:
>>Besides, how is the client to know what a short request is vs. a long
>>one? Sometimes even the server doesn't know (when the reply is sent in
> i remember that Van Jacoboson's observation on all this once upon a time was
> *something like* the server should be in charge of what bits of what URL get
> sent when since only the server really knows the details (such as, i suppose,
> sizes, etc.).
Perhaps. However, that would mean the server decides on which connection
to send a reply, i.e., that the request and reply could come on
That certainly argues for a more FTP-like approach to using connections;
it would have been useful had the original designers of HTTP not decided
on their own protocol, specifically because (paraphrased) 'most
connections will only be for one page'.
Further, as others have observed, sometimes even the server doesn't know
the sizes (esp. at the time it starts replying). FWIW, these are all
good reasons to find a way to use multiple connections to let IP do the
muxing it was intended, and let TCP do the flow control among a group of
connections rather than per-connection (e.g., RFC2140 ;-)
More information about the end2end-interest