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

Zhong Yu <zhong.j.yu@gmail.com> Wed, 22 May 2013 22:02 UTC

Return-Path: <zhong.j.yu@gmail.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9C511E814C for <hybi@ietfa.amsl.com>; Wed, 22 May 2013 15:02:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HyNZrzxwXw5i for <hybi@ietfa.amsl.com>; Wed, 22 May 2013 15:02:14 -0700 (PDT)
Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id BB25211E814B for <hybi@ietf.org>; Wed, 22 May 2013 15:02:14 -0700 (PDT)
Received: by mail-ob0-f176.google.com with SMTP id wp18so3080013obc.21 for <hybi@ietf.org>; Wed, 22 May 2013 15:02:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=16QBlhjjoxzTjlviujpEs6cVs2T4Bc8k2UQ2LWXiyMQ=; b=U2ITR7CehNeO8cqVqclgX0vKhmFl/c7iguddXTScnMzrzLexWVpsMiiPFObDRvojwl bIvgDKxZBz+fucLUaP5LCvx8yKWrcIN2jHM3e2E9RZv51uhBTVHQGY9YmDg1F+zROhIz g2pd1hiGgEbSFtQTzWbRLulMVjI/ucHBdKFnWAzajQNQarG3BvkOhhpJ4wIyO7M9K2OA omITBvJZRFw5FHZx3EpdxT510CVckEG/QU1jQDdxO/7KB71FP0D8vwn/8VEPCvZZQZys WcmyLH4TV1gC9Sz3CLCOVvtYRdkIkTXaRrTxQiNc5l4Tizp/wHEWO5yPZFKLv24xmgKC svXg==
MIME-Version: 1.0
X-Received: by 10.60.47.200 with SMTP id f8mr2949372oen.33.1369260134316; Wed, 22 May 2013 15:02:14 -0700 (PDT)
Received: by 10.76.98.227 with HTTP; Wed, 22 May 2013 15:02:14 -0700 (PDT)
In-Reply-To: <CAFWmRJ3-04eUqsme1mS-KTUir-KJagXnTDg7QWFzW6jquYuzmQ@mail.gmail.com>
References: <CAH9hSJZxr+aG7GZa4f-dUOTGj4bnJ+3XxivUX4jei5CMyqN4LQ@mail.gmail.com> <CAH9hSJZUG1f+3Uk=t2=A5i4O9=wPvAisspM=pgmGEH9emTL9-Q@mail.gmail.com> <CAH9hSJZai_UuxW4O6mZcEJT2DJoURtLo16XNci1qkYVWv4HVdg@mail.gmail.com> <007501ce56f0$67f74080$37e5c180$@noemax.com> <519CD6A1.7080708@ericsson.com> <519CE075.4000106@tavendo.de> <CAM5k6X9WmO80hiQZ6_GqK66PAd3of=2ZRi9=VrWj52apA1+=5g@mail.gmail.com> <519D02E7.6040009@tavendo.de> <CAM5k6X8Z-JxrgTy3NAc-wC7zK_AfsWAhqzNKaEY_yZzmz=pZcQ@mail.gmail.com> <CACuKZqHYmF+-zECFrGsHqt0i91jHAzk9Az72=tva_kn=ra2pKA@mail.gmail.com> <519D1D0E.5000905@callenish.com> <CAFWmRJ3-04eUqsme1mS-KTUir-KJagXnTDg7QWFzW6jquYuzmQ@mail.gmail.com>
Date: Wed, 22 May 2013 17:02:14 -0500
Message-ID: <CACuKZqEO7b4bgKV9pVktDhyuF=shrZqp8nrTy=KBQCOHFXZ+sw@mail.gmail.com>
From: Zhong Yu <zhong.j.yu@gmail.com>
To: Simone Bordet <sbordet@intalio.com>
Content-Type: multipart/alternative; boundary=001a11c2d682e944b804dd55b714
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] Call for interest: multiplexing dedicated for WebSocket
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 May 2013 22:02:16 -0000

On Wed, May 22, 2013 at 3:41 PM, Simone Bordet <sbordet@intalio.com> wrote:

> Hi,
>
> >>> On Wed, May 22, 2013 at 1:32 PM, John A. Tamplin <jat@jaet.org> 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 <bruce@callenish.com>
> 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.
>