Re: [hybi] #1: HTTP Compliance

[Willy Tarreau <[e-mail]>]

On Thu, Jul 22, 2010 at 01:11:05AM +0100, Jamie Lokier wrote:
> Greg Wilkins wrote:
> >    I can visibly tell when establishing a
> >    chat room if I have the WS transport enabled in the client or not,
> >    because I can see the extra delays as WS is tried and fails.
> >    This will be a barrier to frameworks like cometd-2 including WS in
> >    their transport negotiations.
> 
> (Aside: I think Ian's past responses suggest the following resolution:
> When you're establishing a chat room connection, you *ought* to know
> if you're connecting to a WS-aware chat service, in the same way that
> you already must know in advance which WS subprotocol to request
> if you do get a WS connection.)
> 
> As noted some time ago, even when WS negotation *succeeds*, it can be
> slower than comet-style HTTP, both slower in sending the first
> messages, and slower in receiving the first responses.
> 
> That situation is ridiculous.
> 
> It means latency-optimised apps may open *two* connections in
> parallel: One comet-style HTTP, and one WebSocket.  They will
> communicate initial messages over the HTTP connection, and switch to
> the WebSocket connection when that is ready.  That's not kind on
> low bandwidth links, nor easy to program, so it's an ugly compromise.

And it's reliance on random numbers in userspace and MD5 to hash
minuscule messages does not help at all keeping latency low !

> We can greatly improve the situation by avoiding some delays in the
> negotiation sequence.
> 
> Unfortunately it seems each "waiting point" needs a different method
> of avoidance, so TLS negotation round trip delay is reduced only by
> using an ignorable TLS extension to carry initial messages; HTTP
> handshake round trip delay is reduced only by encoding initial
> messages in a HTTP-compatible manner, post-HTTP confirmation round
> trip delay is removed only by encoding initial messages in a way that
> is harmless to non-WS servers, and delays to messages originating
> between those stages are reduced only by rather fiddly inter-stage
> encodings.

Agreed. You're defining a well-stacked model where each layer informs
the upper one about some information that may be needed for its handshake
to complete without having to wait.

> (Ideally we'd avoid the TCP 3-way handshake round trip too by
> including some data in the SYN, finally outperforming HTTP :-), but I
> have the uncertain impression that's considered inadvisable.)

I think it was the principle of TTCP, but with TCP it's not possible
because you don't know how large the other side's buffers before you
receive the SYN-ACK which contains the MSS. However if you're interested,
I can explain to you a system-dependant way to save one ACK from the
client to the server by sending the data with the first ACK ;-)

> Fortunately there is a systematic approach possible, even though the
> details are annoyingly technical, and fortunately each step could be
> optionally implemented or not according to the implementer's
> preference.  Simple implementations could ignore them entirely.

That's what is nice with declarative protocols such as HTTP where
you announce what you're doing. At least we should find a clean way
to be able to decide whether we want an HTTP medium or just a TCP
medium. I thought that the port was a good thing, but maybe the
protocol scheme itself speaks better (ws/wss). After all, browsers
currently use http/https for this. We could even have variants such
as :

  - WS = plain TCP, no initial handshake
  - WSS = plain TLS, no initial handshake beyond TLS
  - WSTP = WS over HTTP = HTTP initial handshake

Just a few ideas, hoping they will help others find better ones.

Regards,
Willy