Q&A: Are WebSockets ready for commercial use?

By On September 7, 2011 · 5 Comments

I’m not answering this question directly in the post. I’d like people to ask questions and raise concerns in the comments and I’ll then do my best to answer the questions and alleviate any concerns.

I believe that WebSockets are ready for commercial use and I’ll justify this stance in answering any questions.

Look forward to hearing your questions and thoughts.

View Q&A/Comments

Related posts:

  1. What came before WebSockets?
  2. Recent article in .net magazine: WebSockets – Code a real-time survey
Tagged with: •
 
Facebook Twitter Delicious Mixx StumbleUpon Digg
  • http://twitter.com/richiehindle Richie Hindle

    Hi Phil – thanks for the opportunity to pick your brain!

    A little bit of context: I work in the corporate world, shipping software that runs on corporate intranets and extranets. Here, networks are often complex, using a variety of proxies, firewalls and so on.  And the client machines are often either ancient (think XP and IE6) or locked down (no plugins) or both.I have two main concerns: proxies, and browser support.Regarding proxies, Wikipedia says “If unencrypted WebSocket traffic flows through an explicit or a
    transparent proxy server on its way to the WebSocket server, then,
    whether or not the proxy server behaves as it should, the connection is
    almost certainly bound to fail today (as WebSocket become more
    mainstream, proxy servers may become WebSocket aware). Therefore,
    unencrypted WebSocket connections should be used only in the simplest
    topologies.”

    As for browser support: until very recently WebSockets were disabled in Firefox because of a security flaw in the spec (and many people will still be using those versions of Firefox in which it was disabled).  Plus IE only supports them via Flash or Silverlight (even in the latest version, let alone ancient ones).

    For an internet-facing service, either one of those problems will exclude a tiny percentage of potential users, and that’s probably considered acceptable.  But for me, they look like killers.

    • http://www.leggetter.co.uk Phil Leggetter

      Hey Richie,

      Good question and thanks for asking. It does need answered and addressed.

      Corporate networks like the ones you seem to be working with have been a real problem for a long time and unfortunately there is no silver bullet.

      * Proxies

      The fact is that proxies are still going to get in the way. But the key word here is “still”. For the past 10 years they’ve been a pain for realtime web technologies and that’s not going to change too quickly. HTTP Streaming and HTTP Long-Polling are also impacted by proxies even though they use port 80 and should simply “tunnel” through the infrastructure. My experience tells me that this isn’t always the case. WebSockets experience the same problems as these older solutions and in most cases the solution is SSL.

      > Unencrypted connections are a requirement in my field, where many organisations don’t have the internal certificate infrastructure needed for SSL.

      This is surprising. I’m not going to pretend to be an expert in this field but as far as I’m aware adding SSL support to a web server is generally as simple as installing the certificate (the process differs on each server) and allowing port 443 connections on the network. I’d be very surprised if even a corporate network had this port locked down. The technology I used to work on was used by many large corporations in the financial world and, although there were occasionally problems, SSL tended to be *the* solution. And it’s most probably going to have to be the solution for WebSockets within corporate networks too.

      The main point here is that all realtime technologies are impacted by firewalls and proxies. I think that it’s highly unlikely that WebSockets won’t work but HTTP Streaming will. Realtime web solutions will either work or not.

      * Browser support

      ** Security

      The security concern you raise is an interesting one. Martyn Loughran, the CTO of Pusher, sums this up pretty well in his post “It’s not WebSockets, it’s your broken proxy” (http://blog.pusher.com/2010/12/9/it-s-not-websockets-it-s-your-broken-proxy)

      > The thing is though, that it is not a WebSocket issue per se. It is a problem with the caching proxies, that can be exploited by a client machine. The tests were done with Java and Flash clients, and it is therefore something that has presumably been an issue for many years. The arrival of WebSockets has exposed the problem, as more scrutiny has been applied to the mechanism.

      Full details of the problem can be found here: http://www.adambarth.com/papers/2011/huang-chen-barth-rescorla-jackson.pdf

      This security concern has been addressed in later versions of the WebSocket protocol.

      ** Browser support

      If your clients are stuck with IE6 and are not allowed plugins then your only solution is HTTP Streaming, HTTP Long-Polling or, heaven forbid, standard HTTP polling. The first two solutions may be impacted by the proxy issues already covered. Standard polling is just crazily inefficient but, depending on the frequency of updates and your required polling interval, might do.

      The normal solution to browser support is of course fallback. First try WebSockets. If WebSockets aren’t supported try the next best thing. This is normally a WebSocket connection via a plugin such as Flash. If that’s not going to work then try HTTP Streaming. If that fails try HTTP Long-Polling. As a last resort go to standard HTTP Polling. These checks and attempts should be done in an intelligent way too. For example, if the browser is IE6 and Flash isn’t installed it should straight away try HTTP Streaming. Many realtime web technologies will do this sort of thing for you so it’s not something you’ll actually need to worry about.

      Based on your scenario, a *heavily* locked down corporate network, I think you’d need a good realtime web technology stack that handled this fallback for you. I would suggest that your scenario is becoming less and less common. I certainly hope that’s the case.

      WebSocket support is growing at a very fast rate and I’m very hopeful that IE10 will have WebSocket support. Until then the Flash fallback (which still uses WebSockets), according to Adobe’s stats, covers 99% of all web browsers. Silverlight fallback is an extra.

      So, I’d argue that 99% browser support most definitely means that WebSockets are ready for commercial use. There will always be edge cases but there are also edge cases for the alternatives.

      This really just justifies your concerns but hopefully it gives you a bit more food for thought when it comes to choosing your realtime web technologies.

      If I’ve missed anything or you’d like anything cleared up then please let me know.

      Cheers,

      Phil

      • http://twitter.com/richiehindle Richie Hindle

        Hi Phil, thanks for the detailed response!

        It’s bad news that proxies are likely to have a bad effect on *all* such technologies.  Hopefully a good fallback library will cope?

        Re. SSL, the problem is that internal servers need certificates that are recognised by the browsers.  That means either buying certificates from commercial authorities for all your servers, or using your own root CA and installing its certificate in all your users’ browsers.  Either way it’s a hassle, and on a trusted intranet there’s no perceived need to jump through those hoops – SSL “isn’t needed” because the whole network is secure. Remember, this isn’t about internet-facing servers.

        • http://www.leggetter.co.uk Phil Leggetter

          > Hopefully a good fallback library will cope?

          If the proxies are being a real pain and SSL isn’t an option then things would probably fallback to standard HTTP Polling. If it’s just an Intranet then I’m guessing there won’t be too many users – unless it’s a global Intranet? If the user base is small then normal polling won’t be too big an issue as scaling isn’t such a problem. That said, your users miss out on a true realtime experience.

          A wildcard SSL certificate (*.yourdomain.com) can be purchased from GoDaddy for £127.99 a year. But I understand it’s still a bit of a hassle.

          If rich user experiences are really required within a web app in a corporate network then it’s getting to the stage that the corporation needs to start upgrading their infrastructure. Whether that’s by encouraging users to install the Google Chrome frame (http://code.google.com/chrome/chromeframe/ – which doesn’t require admin privileges), changing the the users default browser, upgrading their OS, allowing Flash to be installed or changing the configuration of their proxies or firewalls to be a bit more realistic.

          The simple fact is that IE6, which shipped over 10 years ago, doesn’t cut it any more. New technologies and JavaScript libraries aren’t being developed with it in mind. How many of their servers and desktop PCs from 10 years ago are still in operation…. ok, I don’t want to know ;)

          • http://twitter.com/richiehindle Richie Hindle

            Thanks for the information, Phil – all very useful!

Set your Twitter account name in your settings to use the TwitterBar Section.