[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 [127.0.0.1]) 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-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (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 [72.14.220.157]) 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 10.102.240.34 with SMTP id n34mr3527031muh.31.1270541501768; Tue, 06 Apr 2010 01:11:41 -0700 (PDT)
Received: from [192.168.0.100] (host116-234-static.43-88-b.business.telecomitalia.it [88.43.234.116]) by mx.google.com with ESMTPS id 23sm233068mun.7.2010.04.06.01.11.40 (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 2.0.0.24 (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: http://www.ietf.org/mail-archive/web/tls/current/msg05593.html 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. http://tools.ietf.org/html/draft-agl-tls-nextprotoneg-00 This would allow a TLS connection to be negotiated with an application protocol and further round trips avoided. 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 own. cheers
- [hybi] Websocket success rates and TLS extension. Greg Wilkins
- Re: [hybi] Websocket success rates and TLS extens… Justin Erenkrantz
- Re: [hybi] Websocket success rates and TLS extens… Mike Belshe
- Re: [hybi] Websocket success rates and TLS extens… Justin Erenkrantz
- Re: [hybi] Websocket success rates and TLS extens… Justin Erenkrantz
- Re: [hybi] Websocket success rates and TLS extens… Greg Wilkins
- Re: [hybi] Websocket success rates and TLS extens… Julian Reschke
- Re: [hybi] Websocket success rates and TLS extens… Greg Wilkins
- Re: [hybi] Websocket success rates and TLS extens… Jamie Lokier
- Re: [hybi] Websocket success rates and TLS extens… Mike Belshe
- Re: [hybi] Websocket success rates and TLS extens… Mike Belshe