Re: [hybi] Websocket success rates and TLS extension.

Mike Belshe <> Fri, 16 April 2010 08:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 43B3728C123 for <>; Fri, 16 Apr 2010 01:58:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.624
X-Spam-Status: No, score=0.624 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id t7YUopXOv3VL for <>; Fri, 16 Apr 2010 01:58:41 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 140DE3A69CD for <>; Fri, 16 Apr 2010 01:57:08 -0700 (PDT)
Received: by pzk31 with SMTP id 31so1088879pzk.31 for <>; Fri, 16 Apr 2010 01:56:58 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 16 Apr 2010 01:56:56 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Fri, 16 Apr 2010 01:56:56 -0700
Received: by with SMTP id e19mr687723wfg.186.1271408216754; Fri, 16 Apr 2010 01:56:56 -0700 (PDT)
Message-ID: <>
From: Mike Belshe <>
To: Justin Erenkrantz <>
Content-Type: multipart/alternative; boundary="000e0cd32f701fc96d048456cb27"
Cc: "" <>
Subject: Re: [hybi] Websocket success rates and TLS extension.
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 16 Apr 2010 08:58:43 -0000

On Thu, Apr 15, 2010 at 11:41 PM, Justin Erenkrantz

> On Tue, Apr 6, 2010 at 1:11 AM, Greg Wilkins <> wrote:
> > In conversation (not in the link above), Mike indicated that
> > most of the port 80 failures were after connection (hinting
> > at intermediary issues with websocket), while most of the
> > 61985 failures were failed connections (suggesting the port
> > was just blocked).
> That's a useful data point...
> > To me, this suggests that if websocket is going to
> > be workable over port 80, then we definitely need to
> > engage the intermediary vendors so that the 37% failure
> > rate can be improved.
> Yes.
> > Having a fallback to TLS over 443 will also be vital to
> > initial deployments.
> Indeed.
> > I also talked to Mike about the possibility of SPDY using
> > websocket as transport.   The issue for SPDY is that while
> > the framing of websocket is probably sufficient, they are
> > very sensitive to the time taken to initiate a connection.
> > Typically they want to use several connections to display
> > a page and every round trip establishing a connection
> > is latency on the critical path to render the page.
> Sorry for being dense - there are too many "they" in this paragraph
> for me to parse it properly.
> In particular, the sentence:
> > Typically they want to use several connections to display
> > a page and every round trip establishing a connection
> > is latency on the critical path to render the page.
> In this paragraph, I think "they" == "Web Socket" - as we have not had
> the channel/multiplex discussion yet and some have said that it should
> not be needed at all.  *If* there is multiplexing, then I think this
> round trip setup-time is minimized.

I think I know what Greg was referring to.

With SPDY, we've observed that the key to minimizing latency is removing
round-trips.  While bandwidth continues to go up (5Mbps, 10Mbps, more!),
RTTs are not going down.  The average RTT to Google today is over 100ms.
 Even in the US, where broadband is prevalent, ~90ms.

Today, each layer of the stack introduces a Round Trip:   DNS, TCP, HTTP
With WebSockets, as spec'd:  DNS, TCP, HTTP, WebSocket

So, any protocol which induces an extra RT (e.g. the websocket upgrade
handshake) faces a 90ms per connection on the critical path tax which
current HTTP does not have.  From our study of web pages, web pages
typically have about 2.5 connections to unique domains that are on the
critical path of the web page download.  This number can use more research,
but I believe it is roughly right. (e.g. loads subresources
from - so adding an extra handshake RT to the protocol means 2
extra RTs to load the page; the average site on the net today touches 8
domains).   It's very hard to overcome a 180-225ms handicap with a short
webpage download.

The multiplexing does amortize the cost, but doesn't win back the latency.
 Current protocols (HTTP) just open an ass-ton of connections in parallel to
achieve the multiplexing, and this mostly suffices.  So we can build a more
efficient protocol (websocket/spdy/something else), but if you induce a new
handshake, you can still end up slower.  This is the problem which SPDY is
currently researching most.

So back to Greg's note:  the current websocket handshake requires a RT, and
it will be difficult to use websocket for low-latency uses which it has
that.  We're pretty sure that a low-latency protocol needs to remove more
RTs.  But perhaps there is something genius yet to be discovered :-)


> But, I'm not quite clear if that's the intent of your statement.  -- justin
> _______________________________________________
> hybi mailing list