HTML 5 Websockets will replace Comet?

问题:

It looks like Websockets in HTML 5 will become a new standard for server push.

Does that mean the server push hack called Comet will be obsolete?

Is there a reason why I should learn how to implement comet when Websockets soon (1-2 years) will be available in all major browsers?

Then I could just use Beaconpush or Pusher instead till then right?

回答1:

Does that mean the server push hack called Comet will be obsolete?

WebSockets are capable of replacing Comet, AJAX, Long Polling, and all the hacks to workaround the problem when web browsers could not open a simple socket for bi-directional communications with the server.

Is there a reason why I should learn how to implement comet when WebSockets soon will be available in all major browsers?

It depends what "soon" means to you. No version of Internet Explorer (pre IE 9) supports the WebSockets API yet, for example.

---

UPDATE:

This was not intended to be an exhaustive answer. Check out the other answers, and @jvenema's in particular, for further insight into this topic.

回答2:

There are 2 pieces to this puzzle:

Q: Will the client-side portion of "comet" be necessary?

A: Yes. Even in the next 2 years, you're not going to see full support for WebSockets in the "major" browsers. IE8 for example doesn't have support for it, nor does the current version of FireFox. Given that IE6 was released in 2001, and it's still around today, I don't see WebSockets as replacing comet completely anytime soon.

Q: Will the server-side portion of "comet" be necessary?

A: Yes. Comet servers are designed to handle long-lived HTTP connections, where "typical" web servers do not. Even if the client side supports WebSockets, the server side will still need to be designed to handle the load.

In addition, as "gustavogb" mentioned, at least right now WebSockets aren't properly supported in a lot of HTTP Proxies, so until those all get updated as well, we'll still need some sort of fallback mechanism.

In short: comet, as it exists today, is not going away any time soon.

As an added note: the versions of WebSockets that currently ARE implemented in Chrome and Safari are two different drafts, and work on the "current" draft is still under very heavy development, so I don't even believe it is realistic to say that WebSockets support is functional at the moment. As a curiosity or for learning, sure, but not as a real spec, at least not yet.

[Update, 2/23/11]

The currently shipping version of Safari has a broken implementation (it doesn't send the right header), Firefox 4 has just deprecated WebSockets, so it won't ship enabled, and IE9 isn't looking good either. Looks like Chrome is the only one with a working, enabled version of a draft spec, so WebSockets has a long way to go yet.

回答3:

Consider using a web socket library/framework that falls back to comet in the absence of browser support.

Checkout out Orbited and Hookbox.

回答4:

In the medium term websockets won't replace comet solutions not only because of lack of browsers support but also because of HTTP Proxies. Until most of HTTP Proxies will be updated to support websockets connections, web developers will have to implement alternative solutions based on comet techniques to work in networks "protected" with this kind of proxies.

In the short/medium websockets will be just an optimization to be used when available, but you will still need to implement long-polling (comet) to rely on when websockets are not available if you need to make your website accessible for a lot of customers with networks/browsers not under your control.

Hopefully this will be abstracted by javascript frameworks and will be transparent for web developers.

回答5:

Yes, because "soon" is a very slippery term. Many web shops still have to support IE6.

No, because a rash of comet frameworks and servers has emerged in recent times that will soon make it largely unnecessary for you to get your hands dirty in the basement.

Yes, because "soon" is a very slippery term...

回答6:

Charter for the [working group] working group tasked with websockets, BiDirectional or Server-Initiated HTTP (hybi):

Description of Working Group

HTTP has most often been used as a request/response protocol, leading to clients polling for new data, or users hitting the refresh button in their browsers. Recent web applications are finding ways to communicate with web servers in realtime, pushing data from the server-side to the client as soon as it is available. However, these applications at present can only use a variety of HTTP mechanisms (e.g. long polling requests) to communicate with web servers bidirectionally.

The Hypertext-Bidirectional (HyBi) working group will seek standardization of one approach to maintain bidirectional communications between the HTTP client, server and intermediate entities, which will provide more efficiency compared to the current use of hanging requests.

HTTP still has a role to play; it's a flexible message oriented system. websockets was developed to provide bidirectionality and avoid the long polling issue altogether. [it does this well]. but it's simpler than http. and there's a lot of things that are useful about http. there will certainly be continued progress enriching http's bidirectional communication, be it comet or other push technologies. my own humble attempt is [http://github.com/rektide/pipe-layer].