[hybi] Websocket success rates and TLS extension.

Greg Wilkins <gregw@webtide.com> Tue, 06 April 2010 08:11 UTC

Return-Path: <gregw@webtide.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 3FD7C3A6855 for <hybi@core3.amsl.com>; Tue, 6 Apr 2010 01:11:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id h3U1RP4oDxny for <hybi@core3.amsl.com>; Tue, 6 Apr 2010 01:11:49 -0700 (PDT)
Received: from fg-out-1718.google.com (fg-out-1718.google.com []) by core3.amsl.com (Postfix) with ESMTP id DC9313A694F for <hybi@ietf.org>; Tue, 6 Apr 2010 01:11:47 -0700 (PDT)
Received: by fg-out-1718.google.com with SMTP id l26so827623fgb.13 for <hybi@ietf.org>; Tue, 06 Apr 2010 01:11:42 -0700 (PDT)
Received: by with SMTP id n34mr3527031muh.31.1270541501768; Tue, 06 Apr 2010 01:11:41 -0700 (PDT)
Received: from [] (host116-234-static.43-88-b.business.telecomitalia.it []) by mx.google.com with ESMTPS id 23sm233068mun.7.2010. (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 06 Apr 2010 01:11:40 -0700 (PDT)
Message-ID: <4BBAECB7.2030009@webtide.com>
Date: Tue, 06 Apr 2010 10:11:35 +0200
From: Greg Wilkins <gregw@webtide.com>
User-Agent: Thunderbird (X11/20100317)
MIME-Version: 1.0
To: "hybi@ietf.org" <hybi@ietf.org>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: [hybi] Websocket success rates and TLS extension.
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Tue, 06 Apr 2010 08:11:50 -0000

At the IETF meeting the week before last Mike Belshe of the
google SPDY team  pointed me towards an interesting experiment
done by the google chrome websocket team - the results are
discussed here:


This compares success rates of making websocket connections
via port 80, a high port 61985 and TLS over 443.

The sample was from a self selected subset of chrome users,
so it's probably not very representative of average users -
but it's better than nothing.

Overall success rates were:

  port 80    - 63%
  port 61985 - 86%
  port 443   - 95%

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).

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.

Having a fallback to TLS over 443 will also be vital to
initial deployments.

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.

Because TLS negotiations represent round trips, they
don't want extra round trips for framing negotiations.
Hence they have proposed a TLS extension to allow
protocol negotiation during TLS handshake.


This would allow a TLS connection to be negotiated
with an application protocol and further round trips

I know supporting SPDY transport is probably outside of
the hybi charter - but I think it would not harm us
to consider their requirements when designing our