- From: Henrik Nordstrom <henrik@henriknordstrom.net>
- Date: Tue, 24 Jul 2007 15:59:36 +0200
- To: "Roy T. Fielding" <fielding@gbiv.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-Id: <1185285576.25507.24.camel@henriknordstrom.net>
On mån, 2007-07-23 at 16:57 -0700, Roy T. Fielding wrote: > If the connections are used infrequently and are susceptible to > timeouts occurring while the next request is in transit, then the > data sent across the network far exceeds any average > *congestion-control* benefit obtained by avoiding the separate > connections. Indeed. And also causes a fair bit of other headaches. There is also the related case of a server forgetting to do a graceful close when it needs to close the connection after a response, and this causing even already sent responses in the TCP pipe to get flushed. > A new connection will be required anyway and the > request message is sent twice (though whether that message hit > the network or not seems to depend on the TCP implementation). And timing details.. > That should be testable to find the actual trade-off point where > a client should close the connection, but I have no experimental > evidence and no time to set up an experiment. It's very dependent on the connection timeout used by the server, and there is no standard or even recommendations on what timeouts to use. It's one of those shortcomings of TCP, missing an advisory close operation allowing either endpoint to gracefully ask if it's ok to close the connection. > In any case, > pipelining is still worthwhile for many reasons, particularly > when we have control over both sides of the connection, so we need > it defined in HTTP regardless of any single client's request profile. Yes. > BTW, do you know of any good (experiment-quality) evaluations > of HTTP over SCTP? Saw some when I looked into this. But unfortunately I don't have references.. The conclusions from what I can remember was that it currently performs rather poorly in comparision to pipelined HTTP over TCP, part due to the inability to batch fragments from different messages in the same IP packet to utilize the MTU fully, part from SCTP implementations not performing as well as they could. But also that SCTP is fairly young and implementations likely to improve over time likely making it perform noticeably better. I don't think there is any question that HTTP over SCTP has a great potential in reducing the average perceived latency of viewing complex pages. Regards Henrik
Received on Tuesday, 24 July 2007 14:00:16 UTC