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

[Tobias Oberstein <[e-mail]>]

Am 15.05.2013 13:45, schrieb Takeshi Yoshino:> Hi all,
> 
> (Note: This is not WG's official process)
> 
> I'd like to survey how many people are interested in standardization and 
> implementation of multiplexing dedicated for WebSocket again at this point.

+1 for having WS mux and not depend on HTTP 2.0 / SPDY.

> 
> * Multiplexing is still important for WebSocket
> 
> HyBi WG has been working on the WebSocket multiplexing spec 
> (http://tools.ietf.org/html/draft-ietf-hybi-websocket-multiplexing-10). 
> Multiplexing functionality is really important to make WebSocket 
> scalable enough to be used for large scale production services. It's 
> still true.

Could you eloborate a bit on this? I'd like to better understand "the problem". As far as I can see, the current RFC text contains the following motivation for multiplexing:

"""
The WebSocket Protocol [RFC6455] requires a new transport connection
for every WebSocket connection.  This presents a scalability problem
when many clients connect to the same server, and is made worse by
having multiple clients running in different tabs of the same user
agent.
"""

What exactly is the scalability problem? Is it: scalability of a single server box is limited by the number of concurrently active TCP connections the server can handle? I.e. one is be able to handle 200k TCPs on a single box, but not 20Mio ..

If so, is the thinking that a) one needs some kind of "network concentrator" front-end servers that aggregate the many TCPs onto a few, and b) for doing that kind of concentration, WS multiplexing is one option?

However, concentration could also be done at the application level, e.g. stateless frontend server speaking WS with some app defined WS subprotocol to clients, and native database protocol to backend servers, multiplexing requests contained in the WS-based app protocol to requests on the few database protocol connections to backend servers.

That can also solve the scalability problem without requiring multiplexing at the WS level. So why do we need it at the WS level?

Sure, multiplexing at the WS level would allow to create generic concentrators, but a generic concentrator could not map incoming connections to backend boxes based on app data like UserID etc for sharding etc.

Another aspect is client-server transport efficiency.

Most efficient: exactly 1 TCP connection between given client device and server for any communication between the two.

The use of only 1 TCP connection between a given client device and a given server allows mechanisms like TCP slow start etc work efficiently.

A browser with multiple tabs opened to the same origin might be a common situation which could be handled by multiplexing in the networking code inside the browser.

Yet another option with browser could be a shared web worker opening 1 WS to the server, and have all tabs communicate only via that web worker.

However, when running _different_ apps on the same device connecting to the same origin, the multiplexing needed to happen cross-app, and hence the multiplexing needed to happen in kernel space or in a user space library used by all apps on the client device platform.

==

So my current thinking is:

- the "1 TCP for efficiency" problem can not be solved at the app layer, but needs multiplexing at WS (or within SPDY), which then solves the problem - but only partially (not across different apps, at least not without kernel-space implementation). The problem can be solved however with browsers and shared web workers also.

- the scalability problem can be solved both at the app layer or the WS/SPDY layer.

> 
> * Rapid adoption of HTTP/2.0
> 
> While our work is delayed and delayed again, httpbis folks started 
> seriously working on next generation HTTP. Now it's actively 
> standardized as HTTP/2.0 based on Google's SPDY experiments and input 
> from httpbis members. Gradually but several web service providers 
> already started adopting HTTP/2.0.
> 
> * WebSocket/SPDY experiment
> 
> Chrome WebSocket team has been working on both WebSocket/SPDY and 
> dedicated multiplexing in parallel. You can find the WebSocket/SPDY 
> proposal incorporated into Roberto's unofficial draft (section 4) at 
> https://github.com/grmocg/SPDY-Specification/blob/gh-pages/draft-mbelshe-spdy-00.txt. 
> Its framing is not so efficient as the dedicated one, but can coexist 
> with HTTP traffic in one TCP connection and developers just need to 
> understand and implement HTTP/2.0 framing.

"""
4.2.1. Frame mapping

   One WebSocket frame is mapped into one proceeding SPDY HEADERS frame
   and following plural SPDY data frames. The SPDY HEADERS frame must
   contain WebSocket frame fields and following SPDY data frames contain
   payload data. These data frames are free to be reframed.

   This plan doesn't care about overheads.
"""

This seems somehow straightforward, but introduces inefficiencies: the overhead per WS message is significantly increased and an additional framing layer that allows reframing costs CPU cycles.

Btw: assuming SPDY runs over TLS exclusively, is there any need for WS frame masking anymore?

> 
> * Concentrate on the best one
> 
> Developing and maintaining two different multiplexing code will be 
> burden for vendors. It seems that we should stop and think which 
> approach we should focus on.

Yes, but WS over SPDY is not ready today. WS is widely implemented and works today.

As an app developer, the only thing I care about is having a message-based, reliable, ordered, full-duplex communication with browsers that is both efficient and widely implemented.

Personally I don't care a lot about improving HTTP, since with single-page web apps (and manifests), app assets would be in browser cache anyway. So I care about pure WS solutions.

Stacking framing onto framing layers or WS on SPDY in general does not seem to improve efficiency or implementation availability in browsers. It's a step backward from my POV.

So yes, I do care about WS multiplexing.

> 
> Thanks