Re: p1-message-07 S 7.1.4

tis 2009-07-21 klockan 13:28 +0100 skrev Jamie Lokier:
> However, I'd say the really worthwhile change that's long in coming is
> to fix pipelining so that it can be actually deployed, and so that
> it's actually efficient and reliable when used.

pipelining works quite well to trusted/verified HTTP/1.1 servers
supporting persistent connections, provided you don't mix long haul
requests having a lot of delay in server processing with short ones
(head of line blocking issue).

the main problems with pipelining are

* Keeping the connection persistently open is a server decision, and the
client has no means of predicting if the server will accept to process
the the pipelined requests or not until it sees the response to the
previous request.

* The head of line blocking issue where the processing time (and/or
size) of one response delays all following responses, which can
introduce significant latency.

* Chunked encoding is quite fragile as message framing method. There is
quite some breakage in that area out on the net, some of which is very
hard to work around when pipelining is enabled.

Switching to SCTP as transport is a very interesting alternative for
fixing all this, but not by any means a short-term change for general
access.

> Usable pipelining is likely to be kinder to the network than many
> connections, and it's also likely to perform better, even over fast
> networks.

Very much so, at least as long as all requests are fast to process by
the server without too much processing latency. This has already been
proven several times more than a decade ago and one of the main reasons
why HTTP/1.1 has support for chunked encoding.

> I'm not sure how to achieve widely-compatible pipelining,
> but I have the impression it's not been seriously attempted.

I guess Opera is the ones best positioned to answer this as they to my
best knowledge is the only major browser which has actively ventured
into the land of enabling pipelining on the masses..

> That's a good one.  But I think there's a lot of scope for improving
> HTTP over TCP too, in very similar ways to the way HTTP over SCTP
> works.  Particularly in the area of non-blocking multiplexed multiple
> requests and responses, which SCTP does naturally and could be done in
> several ways over HTTP.  Perhaps they could share some design.

Probably not very feasible to do within HTTP/1.x, but maybe.. Chunked
encoding could be introduced in 1.1, so maybe something can be done in
1.2 at least for responses. But given the fact that chunked encoding is
as fragile as it is I am not too optimistic about introducing even more
complex message framing methods for HTTP/1.x over TCP..

Regards
Henrik

Received on Tuesday, 21 July 2009 15:30:38 UTC