Ian Hickson wrote: > On Sat, 31 Oct 2009, Mike Dierken wrote: > > > > I had one small question about "[..] the latency involved in having to > > establish new TCP connections for each HTTP message is non-existent in > > WebSocket". I know that you know that persistent HTTP 1.1 connections > > reduce the number of times an open/close of a connection would occur, so > > I was curious what's actually happening that connections are created for > > each request. (Not that I think the answer will or should change > > anything to do with WebSockets, just a curiousity sort of thing). > > Non-idempotent messages have to be sent using POST, which cannot be > pipelined in practice. There are several problems with HTTP pipelining, which make it unusable for POST and other non-idempotent request. They are design faults in HTTP pipelining, due to the way TCP behaves when a socket is closed; they are not intrinsic problems. Even re-using a _persistent_ connection for POST is fraught because the server might close the connection, and the client cannot detect whether it should re-send the request. There is something else quite non-obvious. Sending a POST request _followed_ by pipelining a second (idempotent) request can cause the POST's response to be lost or truncated. That's because the server may close the socket after the POST response. After that, the second request being in flight can cause the server TCP to send RST packets which can cause the client to drop what it has already received. (Apache has a workaround for this; look up "lingering close", but it's not described in the HTTP RFCs). Ironically in these cases, TCP makes a connection less reliable :-) As far as I can tell, WebSocket seems to have the same problem, which is unfortunate as pipelining small requests over WebSocket seems like a very natural thing to do. Applications can work around it in various ways (e.g. using unique request ids to detect+drop duplicates, and/or using orderly close markers), but this is probably unfamiliar territory for most web application writers. Most authors will be familiar with AJAX/HTTP, avoids these issues for POST requests by just not using pipelining. -- Jamie
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.