Re: [hybi] An alternative design for the web socket handshake

[Jamie Lokier <[e-mail]>]

Roberto Peon wrote:
> 
>    On Sun, May 16, 2010 at 5:16 PM, Maciej Stachowiak <[1][e-mail]>
>    wrote:
> 
>    On May 16, 2010, at 12:38 PM, Jamie Lokier wrote:
>    >
>    > WebSocket would be almost unique, as a TLS user, in seeming to use
>    > 10-50 connections per individual user by design (the current one,
>    > where browsers can't share connections between WebSocket objects).
>    > TLS itself isn't designed with that kind of usage in mind.
> 
>      People keep saying this, but do we have any evidence there would be
>      10-50 connections per user to the same server?

I did explain in an earlier mail where that figure comes from.  In my
estimate, it isn't 10-50 per server, but 10-50 per user among all
servers they are connected to.  But when upstream proxies near the
client get involved (and mobile operators in particular might wish to
do so deliberately), then they are all to the same proxy.

It's interesting that Roberto points out that figure applies even to a
single server, although I expect only the most high profile servers
would see that.

That adds up to a *lot* of keepalive traffic when you consider, say,
an organisation with 100 users behind a 24Mbit/s-down 2Mbit/s-up link.
(When working it out, remember to include packet headers...)

One of the traffic pattern differences from HTTP that we've largely
not talked about is this:

WebSockets remain active when the user has a page open but it is
inactive, in the background, or even as an iconified/minimised window.
>From what I've seen, most pages are kept in that state nearly all the
time.  That is, they're left open in a browser that isn't being used
most of the time.

There is little or no HTTP traffic, but any WebSocket connections will
be relatively active, because they need to continuously transmit
"idle" keepalives, even if there are no data messages.  That's so they
will receive server-initiated messages when those happen.

In other words, there's a real chance that keepalives will be a large
fraction of traffic, or even dominant in some applications.  Moreover,
they are steady, so the traffic from multiple users doesn't
statistically multiplex as nicely as their bursty HTTP access.

I have seen that pattern in some non-web applications using a
publish-subscribe update model, which is one of the use-cases for
WebSocket in web pages.

>    Yes, and that is *without* the hanging gets.
>    Just try out the Alexa top XXX, and see for yourself!

That's useful, thank you.

(Btw, Imho we could really do with collecting the most useful
pointers, stats and so on together, out of the the many discussion
emails.  Anyone volunteer to help?)

>      For web apps using the "hanging get" approach, do you get 10-50
>      connections per user? If not, why would you expect it for
>      WebSocket? None of the typical "hanging get" techniques have a
>      built-in way to do connection sharing. Why do we expect things to
>      be different with WebSocket?
> 
>    It seems that more and more sites are using collaborative
>    and/or/notification-based features.

It's the notification-based features - or more generally,
server-initiated client updates - which I'm thinking about when I think
of WebSocket usage.

>    It seems natural that the number of requested concurrent streams
>    will increase as a result. The assumption that # concurrent
>    streams == # TCP connections does assume that we don't build in
>    multiplexing (or don't leave ourselves the possibility open for
>    the future). With multiplexing, the number of connections can go
>    down to the number of hosts involved. I sure hope for the sake of
>    the poor bottleneck (aka servers) that we do multiplexing right.

If there was more of a consensus in the direction of doing
multiplexing, or of an extension subprotocol that multiplexes, I'd be
happy to help make sure it is done well.  At the moment, the balance
of views expressed seems to be against multiplexing, and in favour of
one TCP connection per WebSocket object, but only just.

Within a single page, WebSocket browser apps can multiplex now - but
with faults.

It is done at the application layer by an app needing to dispatch
messages to different parts of the page.  The main issues I see in
multiplexing at the browser Javascript level, at present, are:

  - Separate open tabs/windows will have no choice but to use separate
    WebSockets.

  - Parts of a page authored using different frameworks, will
    inevitably use their own WebSocket objects.  (This is where the
    prediction that active ads will tend to add their own per-page
    WebSockets comes from.)

  - Without per-"channel" flow control (without considerable effort),
    if one independent part of the page, such as an iframe or WebWorker
    or whatever is unable to keep up with incoming updates, either the
    rest of the page stops receiving updates (a kind of head of line
    blocking), or the browser must use ever-increasing memory,
    queueing events faster than they are processed, to allow messages
    for the rest of the page to get through.

-- Jamie