Re: [hybi] Call for interest: multiplexing dedicated for WebSocket

[Zhong Yu <[e-mail]>]

On Wed, May 22, 2013 at 3:41 PM, Simone Bordet <[e-mail]> wrote:

> Hi,
>
> >>> On Wed, May 22, 2013 at 1:32 PM, John A. Tamplin <[e-mail]> wrote:
> >>> Servers don't handle tons of long-lived connections very well
> >>
> >> On 22/05/2013 12:00 PM, Zhong Yu wrote:
> >> Is that still true today? Recent server implementations all boast they
> can handle tons of connections.
> >
> >On Wed, May 22, 2013 at 9:31 PM, Bruce Atherton <[e-mail]>
> wrote:
> > Tons of short, HTTP Request/Response type connections. John is talking
> about long-lived WebSockets connections, the kind that might hang around
> for days, weeks, even months. It is a different problem.
>
> Well I am not sure.
> I have seen the TCP Linux stack collapsing due to usage of HTTP 1.0 by
> a proxy. Opening and closing connections at a high rate it's a killer.
> Long lived connections, on the other hand, not so problematic, at
> least in my experience, so Zhong Yu's question still stand for me.
>
> Another point not addressed by the article linked by Tobias is the
> type of usage of the protocol.
> The HTTP protocol has a typical 1 request followed by 10-200 requests
> in a burst, that can be performed concurrently.
> In a non-mux protocol (like HTTP/1.1) browsers open 6 connections, so
> to serve the burst you need multiple "passes" at using those 6
> connections, which leads to the well known ziggurat profile: 6 out,
> pause, 6 out, pause, etc.
> In SPDY, which is muxed, the 100 requests go out at once, with a flat
> profile.
> Roberto Peon and us (Jetty) have showed demos where this effect is
> *eye visible*. SPDY is faster than HTTP just because of mux
> (http://webtide.intalio.com/2012/10/spdy-push-demo-from-javaone-2012/).
>
> Now, HTTP has a semantic which benefits clearly from multiplexing.
> Does this hold true for WebSocket, which does not have semantic, but
> just framing ? I think it depends.
> If you use WebSocket to transport HTTP (i.e. the opposite that
> HTTP/2.0 is working on) then perhaps mux would be very important.
> But if you use WebSocket for chat messaging, perhaps that's not that
> important to have mux.
> The difference here is between a request/response model versus a
> messaging model.
> The model changes the need for mux.
>

I think the main difference is that, a WebSocket channel is a meaningful
identity that cannot be reduced, so there must be an overhead associated
with each live channel; mux cannot change that fact. On the other hand,
HTTP messages have no logical relationship to HTTP connections, it doesn't
matter which connection a message is delivered on, therefore it's possible
to reduce HTTP connections to remove overhead.

Zhong Yu


>
> Since WebSocket does not define a model (just framing), perhaps mux is
> less important.
> Application protocols may implement mux if they need to.
>
> > Think of it this way. Say your server can handle 10K simultaneous
> connections to serve web pages and it takes about 330ms to serve them.
> > If every one of those opens a websocket connection, you'll need 30K
> WebSocket connections just to handle a single second of traffic.
> > If on average the page is kept open for only an hour, that is 108M
> connections.
>
> That's under the assumption that WebSocket connections are closed
> after a "request", which is wrong.
> WebSocket connections are persistent.
> If you want to serve HTTP resources via WebSocket, you better open 1
> connection per client (like SPDY does), and your server will only be
> able to handle 10k clients at any time.
> But then you'll need mux, or you go back to HTTP/1.1, just with a
> different framing (WebSocket).
>
> --
> Simone Bordet
> ----
> http://cometd.org
> http://webtide.com
> http://intalio.com
> Developer advice, training, services and support
> from the Jetty & CometD experts.
> Intalio, the modern way to build business applications.
>