Mozilla

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.

Posted by on at

40 comments

Comments are now closed.

  1. John Dowdell wrote on April 28th, 2010 at 10:38 am:

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

    jd/adobe

  2. Su-Shee wrote on April 28th, 2010 at 11:11 am:

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

  3. SchizoDuckie wrote on April 28th, 2010 at 1:59 pm:

    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)

  4. Aaron wrote on April 28th, 2010 at 2:12 pm:

    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

  5. Tomer wrote on April 28th, 2010 at 3:42 pm:

    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.

  6. Brendan Miller wrote on April 28th, 2010 at 3:56 pm:

    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.

  7. George wrote on April 28th, 2010 at 4:38 pm:

    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?

  8. Arun wrote on April 28th, 2010 at 9:10 pm:

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

  9. Lars Gunther wrote on April 29th, 2010 at 12:54 am:

    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.

  10. Simon Willison wrote on April 29th, 2010 at 4:08 am:

    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.

  11. Max Williams wrote on April 29th, 2010 at 7:22 am:

    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!

  12. Cyrus Omar wrote on April 30th, 2010 at 11:01 am:

    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.

  13. Brett Zamir wrote on April 30th, 2010 at 10:48 pm:

    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…

  14. Alexander Schulze wrote on May 5th, 2010 at 10:41 am:

    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

  15. puran wrote on May 5th, 2010 at 12:18 pm:

    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

  16. Vitaliy Kupets wrote on May 17th, 2010 at 8:51 am:

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

    1. Christopher Blizzard wrote on May 17th, 2010 at 8:13 pm:

      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.

    2. james wrote on July 10th, 2010 at 6:05 am:

      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?

      1. james wrote on July 10th, 2010 at 6:06 am:

        I refer to Vitaliy Kupets’s comment

        1. Vitaliy Kupets wrote on July 12th, 2010 at 1:38 am:

          @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

        2. Vitaliy Kupets wrote on July 12th, 2010 at 1:39 am:

          @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;

  17. Vitaliy Kupets wrote on July 12th, 2010 at 1:38 am:

    @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

  18. Vitaliy Kupets wrote on July 12th, 2010 at 1:45 am:

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

  19. DerFichtl wrote on July 12th, 2010 at 2:36 am:

    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/

  20. James wrote on July 12th, 2010 at 5:19 am:

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

  21. James wrote on July 12th, 2010 at 5:20 am:

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

  22. James wrote on July 12th, 2010 at 5:20 am:

    I meant will not bother.

  23. James wrote on July 12th, 2010 at 5:21 am:

    I mean will NOT bother.

  24. Pingback from Вышел в свет Firefox 4 Beta 1 | Новости Интернета, Социальные сети, Интернет-стартапы и Веб советы on July 26th, 2010 at 4:09 am:

    [...] HTML5, аппаратное ускорение видео высокой четкости, WebSockets и улучшенную поддержку дополнений через [...]

  25. Pingback from MozillaZine.jp » Blog Archive » Firefox 4 Beta 1 がリリースされた on July 27th, 2010 at 5:37 pm:

    [...] Websockets, HTML History APIs の実装 [...]

  26. Nathan Sweet wrote on July 29th, 2010 at 11:52 am:

    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.

  27. John Deer Tractor wrote on August 10th, 2010 at 10:58 am:

    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.

  28. Sebastien wrote on August 10th, 2010 at 1:54 pm:

    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!

  29. Pingback from Prøv Firefox 4 Beta! « MozillaDanmarks blog on August 12th, 2010 at 6:19 am:

    [...] WebSockets kan bruges realtids-webapplikationer som fx online spil og chat. [...]

  30. Hector Santos wrote on August 24th, 2010 at 4:47 am:

    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.

  31. ender wrote on September 10th, 2010 at 6:04 pm:

    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

    1. Adam Rochford wrote on September 22nd, 2010 at 2:53 pm:

      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.

  32. ender wrote on September 23rd, 2010 at 12:13 am:

    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?

  33. Pingback from Browser communication boost back on track « Mohinder's Blog on March 21st, 2011 at 7:27 am:

    [...] 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 [...]

  34. Pingback from Mozilla launches Firefox 6 « Engrmuh's Blog on August 17th, 2011 at 2:06 am:

    [...] 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 [...]

Comments are closed for this article.