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

Simone Bordet <> Wed, 22 May 2013 20:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 11F9721F961B for <>; Wed, 22 May 2013 13:41:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XbLNELK8vHPh for <>; Wed, 22 May 2013 13:41:34 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c01::22b]) by (Postfix) with ESMTP id 0FF9821F8CE9 for <>; Wed, 22 May 2013 13:41:33 -0700 (PDT)
Received: by with SMTP id ma3so2106943pbc.2 for <>; Wed, 22 May 2013 13:41:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=dUSXo1P2AwKj17gKzwAtxd3x1dD+nPUoJerk6Jup1HU=; b=yKrPtfRhrgbl5kKdlOb97tqw5bRSfwuIAPCOq7oybOSarwuak94s3VfCyKhEyDzwNW 41UxtnvfFje2DEGZjoF7W+1JvtozCCVlqdpXCHNy/eBCIOAQXCQ3rsYJq5KaSJUrNXIg 0gakz8ApLffIMfukUZEborwNbaYGsWoYUAGUkIq0JPLu9t/nSAPnazlUdLvr6lBDGWjD 2rXDXnhe3HQb+CeILMnYA3ZcTgA4Z/biQ9Gk1Gr5+GAkGobPa8djMdHpwSApSgW08Uvu 55MmpXvO5nD8L/Yhr86LtCI3h8hrIV++NVGM1HWh8iT7SHHBBz9kgYD8T//mvJKAlSbb 73lA==
MIME-Version: 1.0
X-Received: by with SMTP id yw9mr10200531pab.25.1369255288965; Wed, 22 May 2013 13:41:28 -0700 (PDT)
Received: by with HTTP; Wed, 22 May 2013 13:41:28 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <007501ce56f0$67f74080$37e5c180$> <> <> <> <> <> <> <>
Date: Wed, 22 May 2013 22:41:28 +0200
X-Google-Sender-Auth: 0PismNcTlzNM2n3UEYOSyoD1PiQ
Message-ID: <>
From: Simone Bordet <>
To: Bruce Atherton <>
Content-Type: text/plain; charset=UTF-8
Cc: "" <>
Subject: Re: [hybi] Call for interest: multiplexing dedicated for WebSocket
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 May 2013 20:41:35 -0000


>>> On Wed, May 22, 2013 at 1:32 PM, John A. Tamplin <> 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 <> 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

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.

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
Developer advice, training, services and support
from the Jetty & CometD experts.
Intalio, the modern way to build business applications.