WebSockets in Firefox

Here’s the pitch for WebSockets: a low-complexity, low-latency, bi-directional communication system that has a pretty simple API for web developers. Let’s break that down, and then talk about if and when we’re going to include it in Firefox:

Low-complexity

The WebSocket protocol, which is started via an HTTP-like handshake, has a relatively simple model for sending text packets back and forth. The complexity of the protocol is quite low. There’s no multiplexing, no support for binary data, and once the data connection is set up, the actual transport is quite cheap.

Note that there are people who feel – possibly correctly – that support for multiplexing and binary data should be added. That would obviously increase the complexity but in some cases might be worth the cost. But more on that later.

Bi-directional Communication

One of the key aspects of WebSocket is its support for simple bi-directional communication. Servers can easily send updates to clients and clients can send updates to servers. Many of the comet-style applications that people have built will be much simpler and faster with this model because the protocol and API support it directly.

While allowing for bi-directional communication it also is bound by the HTTP same-origin model. That is, it’s doesn’t give the browser the ability to connect to any site on any port it wants to.

So WebSocket is really TCP with the HTTP security model.

Low-latency

This is actually the primary value in WebSockets. The key thing is that the cost of sending a small amount of data is also very small. It’s possible to do bi-directional communication today with comet-style applications, but small amounts of data often require a huge amount of overhead to do so.

A second-hand story to give you a sense of scale: Google Wave, which tries to do real-time communication with keystrokes has a several-kilobyte overhead for just about every keystroke because of the TCP startup, teardown and HTTP message headers involved with what should be only a few bytes sent over the wire.

I haven’t tried, but I’m going to guess that if you built Quake on top of HTTP comet that the interactive experience would be poor. So this is where WebSockets really shine.

Simple API

The actual API that a developer sees for WebSocket is relatively simple. You can send messages, you can get messages, you get events when sockets open, close or there’s an error. Additional complexity, which I’m sure others will develop, will happen in JavaScript and backend libraries.

(While this might seem like punting on the issue of complexity, this is actually the model for success we’ve seen for other browser standards: build something relatively simple that others can experiment with. When we understand what’s slow or what’s preventing progress, iterate and improve.)

When will it be in Firefox?

We really really want to support WebSockets in the next version of Firefox. And a lot of other people want us to include support too.

The first set of test patches, written by the wonderful Wellington Fernando de Macedo (one of our most excellent contributors!) was first submitted in April of 2009. Since then we’ve been iterating both on the patches themselves and following the spec as it’s changed.

Unfortunately, the spec itself is still under revision. WebSockets did ship in Chrome with version 4 and I’m told by Chrome developers that it’s going to be included in Chrome 5, without changes. Unfortunately, the version that Google included in Chrome doesn’t reflect the current draft. The handshake for how to start a WebSocket connection has changed, largely to improve security on servers. There’s also a lot of ongoing discussion on the role of integrated compression, direct support for binary data (instead of encoding binary data as strings), whether or not the protocol should support multiplexing and a number of other issues.

Since WebSocket isn’t used widely yet, and that Chrome has an uptake rate that’s similar to Firefox, the hope is that once a more recent draft makes it through the process that both Chrome and Firefox can include a more recent version at around the same time.

So in short: we want to ship it because the promise of WebSockets is great, but we’ll have to see if it’s stable and safe enough to do so. Code isn’t the issue – we’ve had that for a while. It’s whether or not there’s consensus on if the protocol is “done enough” to ship it to a few hundred million people.


40 comments

  1. John Dowdell

    Here’s JavaScript control over cross-browser websockets today:
    http://github.com/gimite/web-socket-js#readme

    jd/adobe

    April 28th, 2010 at 10:38
  2. Su-Shee

    Well as plenty of web developers are already getting their apps and experiments out there and we’re all sadly relying on the Flash fallback as Firefox users and competitors as Chrome and Webkit already have it in and running – get the code in (and out) and give at least early adopters the possibility to activate it via configure.

    Web 3.5 (CSS3, HTML5 :) isn’t “widely used” yet as well and also not a released standard or anything like it and FF supports a huge part – why stopping before Web Sockets?

    So don’t ship it to the masses of binary-downloading users but give us web folks the possibility to use it.

    And seriously.. if code isn’t the issue..

    April 28th, 2010 at 11:11
  3. SchizoDuckie

    So how does this scale on the serverside? Is there any way to proxy a bunch of requests through a CDN? Or does every client need a direct open tcp connection to the server? (kinda painful on high traffic sites)

    April 28th, 2010 at 13:59
  4. Aaron

    Hey

    While we’re on the talk of HTML5 Web Sockets, I was curious to know if at present or in the near future will HTML5 allow web apps to make peer-to-peer HTTP connections? Via UDP?

    – Aaron

    April 28th, 2010 at 14:12
  5. Tomer

    While WebSockets is a wonderful technology which will speed up the web, I am wondering if there is any progress with Structured Storage API draft, which is already implemented by Chromium and Google Gears, and still has some open issues prohibiting it from being implemented in Firefox.

    Google have stopped updating Gears for Firefox, and unless it will be supported natively on Firefox, some users including me will have to maintain a Firefox 3.5 installation for traveling because this is the best option to keep your gmail mailbox available while being offline.

    April 28th, 2010 at 15:42
  6. Brendan Miller

    I don’t see why the W3 doesn’t just expose TCP sockets… I guess because the W3C really wants people to keep using plugins?

    Without raw TCP support you can’t implement telnet/ssh/smtp/bittorrent/ftp/irc clients on the browser side without plugins.

    April 28th, 2010 at 15:56
  7. George

    I’m sorry to be a wiseacre, but why did W3 have to rewrite the Server-Sent Events spec which Opera implemented *four* years ago? Why didn’t anyone else seem interested in it?

    April 28th, 2010 at 16:38
  8. Arun

    is Firefox 4 is 3.7? Or it is something planned after that?

    April 28th, 2010 at 21:10
  9. Lars Gunther

    It’s a shame that some developers have not learned the lessons from the 90’s. Shipping half baked, non secure and not standard compliant technologies will in the end cause a lot of trouble.

    Please continue to keep your cool Mozilla! Do not make this available to the masses until the spec is more mature.

    However, a switch in about:config, like WebGL has, and the HTML5 parser had until a few days ago, would be nice.

    April 29th, 2010 at 00:54
  10. Simon Willison

    SchizoDuckie: scaling on the server-side is hard but not impossible – compare it to IM services such as AIM / Y!M / GTalk which have solved the lots-of-open-connections problem at scale for years. Take a look at the various event-based network frameworks like Node.js, Twisted (Python) and Event Machine (Ruby). They can easily handle thousands of open connections on relatively unimpressive hardware.

    April 29th, 2010 at 04:08
  11. Max Williams

    It is a bit of a virtuous circle really, people will start making cool stuff with websockets when the browsers support them.

    We’re trying to break out of this cycle, and stir up early adoption, because we think websockets are the shizzle. Hence, we made http://pusherapp.com :)

    Really looking forward to native Firefox support!

    April 29th, 2010 at 07:22
  12. Cyrus Omar

    I don’t understand why the standard TCP/UDP protocols could not be exposed (possibly with some same-origin security considerations?). WebSockets could be a client library then.

    April 30th, 2010 at 11:01
  13. Brett Zamir

    Thank you for yet another informative article on important topics. Hacks.mozilla.org is by far the most interesting and well-written site I have seen for Mozilla and also web developers…

    April 30th, 2010 at 22:48
  14. Alexander Schulze

    WebSockets are available for ALL common browsers by using the flash bridge from http://github.com/gimite/web-socket-js until the browser natively supports WebSockets like Chrome. jWebSocket is a crossbrowser compatible WebSocket client/server solution with a simple API, lots of demos and documentation. Have a look at http://jWebSocket.org. Alex

    May 5th, 2010 at 10:41
  15. puran

    It’s great that firefox is also coming up with websocket support. We already have a good implementation of websocket as a communication project using websockets
    http://jwebsocket.org

    May 5th, 2010 at 12:18
  16. Vitaliy Kupets

    >> While allowing for bi-directional communication it also is bound by the HTTP same-origin model.

    Aw.. that sucks pretty much. I got an application, which runs distributed over diverse domains and stays in contact with one specific controller server. @ the moment we use Flash for socket communication and it works pretty well, except the fact that Flash must be installed on every user’s machine. I really hope the specification for WebSockets will allow cross-domain communication somehow, otherwise we will have to stick with Flash, which isn’t an optimal solution.

    May 17th, 2010 at 08:51
    1. Christopher Blizzard

      It’s my understanding that there will is a cross-domain method for WebSockets as part of the protocol, just like there is for HTTP.

      May 17th, 2010 at 20:13
    2. james

      So Flash have to be installed on every computer? Isn’t that the industry standard where government and school did adopt FP10 for their works?

      You still have to install FF4 on every computers, isn’t that making more effort and you have to reinvent the wheel on your existing code and we still yet to see the benchmark test if websocket have any benefits in performance and secure? No?

      It too early to tell if Flash lose out, because you surely know all designers and developers love IDE and interoperability. HTML 5 may be another technology, Amazon, Borders, Facebook or any other business website won’t even consider as those are already a mature technology and widely used, so does Flash.

      Tell me how long can you take to develop 3D app in HTML 5 vs iPhone SDK and Flash?

      July 10th, 2010 at 06:05
      1. james

        I refer to Vitaliy Kupets’s comment

        July 10th, 2010 at 06:06
        1. Vitaliy Kupets

          @james:

          – we had potential clients, who did not wish to use Flash plugin, because of their’s security clauses (e.g. banks), so they fell off;
          – I wasn’t talking about FF4, but about the standard itself, which provides that ’same-origin’ model;
          – I didn’t mean, that Flash should ‘lose out’, but merely that if the discussed w3c standard won’t allow cross-domain connections – it’s of no really use for many applications; but when it will, we will happily drop that ‘workaround’ with Flash, as soon as major browsers sit on the HTML5 train;
          – I don’t really care about 3D developing as of now

          July 12th, 2010 at 01:38
        2. Vitaliy Kupets

          @james:

          – we had potential clients, who did not wish to use Flash plugin, because of their’s security clauses (e.g. banks), so they fell off;
          – I wasn’t talking about FF4, but about the standard itself, which provides that ’same-origin’ model;
          – I didn’t mean, that Flash should ‘lose out’, but merely that if the discussed w3c standard won’t allow cross-domain connections – it’s of no really use for many applications; but when it will, we will happily drop that ‘workaround’ with Flash, as soon as major browsers sit on the HTML5 train;
          – I don’t really care about 3D developing as of now;

          July 12th, 2010 at 01:39
  17. Vitaliy Kupets

    @james:

    – we had potential clients, who did not wish to use Flash plugin, because of their’s security clauses (e.g. banks), so they fell off;
    – I wasn’t talking about FF4, but about the standard itself, which provides that ‘same-origin’ model;
    – I didn’t mean, that Flash should ‘lose out’, but merely that if the discussed w3c standard won’t allow cross-domain connections – it’s of no really use for many applications; but when it will, we will happily drop that ‘workaround’ with Flash, as soon as major browsers sit on the HTML5 train;
    – I don’t really care about 3D developing as of now

    July 12th, 2010 at 01:38
  18. Vitaliy Kupets

    oops, sorry for my commenting redundancy :) please delete the repeated ones + this one

    July 12th, 2010 at 01:45
  19. DerFichtl

    Here is my WebSockets example … but it don’t work with Firefox 4 Beta … i don’t know why … Chrome and Safari (Mac) doing fine …

    http://bohuco.net/blog/2010/07/html5-websockets-example/

    July 12th, 2010 at 02:36
  20. James

    @Vitaliy Kupets, of course, I refer to those have Flash player installed. Not without.

    July 12th, 2010 at 05:19
  21. James

    and you don’t have to reply since I’m not using my email and will bother to read again

    July 12th, 2010 at 05:20
  22. James

    I meant will not bother.

    July 12th, 2010 at 05:20
  23. James

    I mean will NOT bother.

    July 12th, 2010 at 05:21
  24. […] HTML5, аппаратное ускорение видео высокой четкости, WebSockets и улучшенную поддержку дополнений через […]

    July 26th, 2010 at 04:09
  25. […] Websockets, HTML History APIs の実装 […]

    July 27th, 2010 at 17:37
  26. Nathan Sweet

    I always find it funny when people rail against flash when it offers the best solution out there for doing client-side socket stuff. I’m no flash evangelist, and will always prefer the standard over the plug-in (things, like flash based navigation menus, which still exist btw, are ridiculous and should be quelled ASAP). However, flash offers some serious features that just aren’t available in the standard browser.

    The web is getting more complex, not less. Flash 10 enjoys a 97% user rate in developing countries. I just finished a project in which Flash 10 was my only option. I had to create a socket connection to a special kind of server and manipulate the byte data directly, compressing it in the player, and using the new Vector class in Flash 10 to manipulate the data. While HTML 5 is bumbling along, trying to finalize a standard for basic socket connection, Flash is implementing advanced features to manipulate the socket, that originally could only be accomplished with a custom plug-in. Oh, and let’s not forget that I didn’t have to do one thing to make sure that my flash app worked in different browsers appropriately, it works in IE 6 just as well as it works in Chrome 5 (theoretically, it’s likely that a computer using IE6 couldn’t handle the cache load, but that’s a whole other cat-in-the-bag).

    This is probably the biggest hurdle for HTML 5 in competing with Flash. I personally think the problem is that getting a set standard for something as complex as binary manipulation is just not doable. HTML 5 should, IMHO:
    1. Lay off the socket entirely
    2. Support very basic socket connection
    3. Wait for JS Harmony to be finished and allow JavaScript to carry the lions share of the data manipulation.

    Implicit in the discussion of HTML 5 is a mistrust of even JavaScript. Nobody comes out in say, but why on earth would I want the browser to do something so complicated, when I know it won’t be implemented in a standardized way? We simply are going to have to wait until JS 2.0 come out before HTML 5 can truly supplant Flash.

    July 29th, 2010 at 11:52
  27. John Deer Tractor

    I heard that websockets protocol will finally handle request
    interruptions properly (where user navigates away and/or
    presses stop button) — sending a disconnect packet to the
    server. Is this accurate? I also heard that FF4 doesn’t
    yet implement this behavior properly, and fails to send
    the disconnect packet.

    August 10th, 2010 at 10:58
  28. Sebastien

    I just want to point this out… comments like this always makes me laugh… no offense:

    “Since WebSocket isn’t used widely yet …” Of course it’s not widely used, it’s not available. Make it available and we will use it! Then you’ll be able to judge if it’s widely use or not. ahahaha!

    August 10th, 2010 at 13:54
  29. […] WebSockets kan bruges realtids-webapplikationer som fx online spil og chat. […]

    August 12th, 2010 at 06:19
  30. Hector Santos

    I came across WebSocket via the recent IETF I-D draft submission. What I finished noticed when including all the relevant documents, how Apple, Google and now Microsoft are involved (presumingly with an eye for SmartPhone server-centric usage).

    I think it is good to see this effort. It should help our own 25+ year old package by bringing back interactive I/O designs with centralized hosting packages.

    I do see two things though:

    1) Allocation of (session) sockets, probably should not be a problem for small to mid systems. IP6 should probably help.

    2) Security, WebSocket should not be “loophole” for cross-domain hacks.

    Reading the IETF working group, it looks like these issues are being addressed.

    August 24th, 2010 at 04:47
  31. ender

    maybe is a stupid question, but if i want to implement p2p over websockets and web-workers i need a websocket´s server integrated on both browsers, to transfer and recive data parts of a file browser-to-browser directly serverless, because the tracker only knows who has parts of a file but doesnt transfer any data of the file.

    So my question is, is a small websocket´s server going to be implemented into the browser?? (because i need browser-to-browser comunication serverless)

    thanks

    September 10th, 2010 at 18:04
    1. Adam Rochford

      As far as I know making a server on the client side in the browser is against the standard. It’s a security thing, they don’t want every website to secretly be running a server off your computer.

      September 22nd, 2010 at 14:53
  32. ender

    i understant the security implications, but maybe it will be easyly regulated by the browser, because the browser implement the html5 websocket… this is only an idea, interesant idea, isnt it?

    September 23rd, 2010 at 00:13
  33. […] pooh-poohed rival browsers’ eagerness to add WebSocket before it was fully tested. Safari, Firefox, Opera, and Chrome all had support, though sometimes disabled by default. And right before the IE9 […]

    March 21st, 2011 at 07:27
  34. […] it sleeker than before. There are also a few behind the scenes improvements such as support for WebSockets, improved Scratchpad, a new Web Developer menu item, an improved Web Console, and reduced browser […]

    August 17th, 2011 at 02:06

Comments are closed for this article.