Re: [hybi] Experiment comparing Upgrade and CONNECT

[Michael Platov <[e-mail]>]

> On 27.11.2010 00:48, Adam Barth wrote:
>> David Huang, Eric Chen, Eric Rescorla, Collin Jackson, and I have been
>> experimenting with the security of the Upgrade-based and CONNECT-based
>> WebSocket handshakes.  Please find a paper detailing our findings at
>> this location:
>> 
>> http://www.adambarth.com/experimental/websocket.pdf
>> ...
> 
> Very interesting stuff.
> 
> How about:
> 
> 1) Installing a permanent test service which would allow people to check 
> whether they have broken intermediaries in the path, and then

We did just that two month ago to troubleshot the problems our users were having with WebSocket-enabled browsers. We've being using websockets  (as an additional option, when they are available in a browser and work for the end user) and to help troubleshooting various problems we created a test service:
http://websocketstest.com/

The test consists of connecting to a websocket-enabled server and sending some data back and forth. Same procedure is repeated for 3 different ports. A client is considered to have a working websocket connection if data exchange succeed at least for one of the websocket ports. For comparison, similar test is also run using Comet as a transport.

Quick summary after running the test for 2 month (more than 4000 browsers tested):
WebSocket browser support: 30%
WebSocket success rate: 72%

More detailed information on the experiment can be found here:
http://websocketstest.com/ws/stats

Our experience so far showed that there are two biggest obstacles for Websockets in the wild:
1. Proxy servers (or other intermediaries). We're trying to detect proxies by HTTP headers, but it seems that many proxies don't set them. Judging by ones who set them (~4% of all failed connections), we can say that some of the incompatible proxies include various version of Squid and Microsoft ISA Server (there are others, but it's hard to identify them by their headers). We also have seen some problems with squid in transparent proxying setup.

2. Antivirus software installed on the PCs of the end users. We found that some antiviruses are blocking websocket connections. For some of the them, adding a simple exception helps to resolve the issue. Most of the users aren't going or not able to update their antivirus rules anyway, so hopefully antivirus vendors will address this issue once the usage of the websockets increases.


> 
> 2) Re-run the experiment again at a later point.
> 

We'll probably do that once the new version of the protocol we'll be supported by the browsers of our end users.

> Also:
> 
> 3) Stop shipping implementations of the so-called "76" protocol; we 
> know, that the current version performs better because of the framing, 
> right?

Even in its present form, websockets are useful as a backup option to workaround rare issue with Comet that are present in some environments. However, a version of a WebScoket protocol with better compatibility with existing HTTP-infrastructure (e.g. more HTTP-compatible handshake that works with already deployed HTTP proxies) is very anticipated.

> 
> Best regards, Julian


Best regards,
Michael