HTTP Polling, Long Polling, HTTP Streaming and WebSockets

I have read many posts on SO and the web regarding the keywords in my question title and learned a lot from them. Some of the questions I read are related to specific implementation challenges while others focus on general concepts. I just want to make sure I understood all of the concepts and the reasoning why technology X was invented over technology Y and so on. So here goes:

Http Polling: Basically AJAX, using XmlHttpRequest.

Http Long Polling: AJAX but the server holds on to the response unless the server has an update, as soon as the server has an update, it sends it and then the client can send another request. Disadvantage is the additional header data that needs to be sent back and forth causing additional overhead.

Http Streaming: Similar to long polling but the server responds with a header with "Transfer Encoding: chunked" and hence we do not need to initiate a new request every time the server sends some data (and hence save the additional header overhead). The drawback here is that we have to "understand" and figure out the structure of the data to distinguish between multiple chunks sent by the server.

Java Applet, Flash, Silverlight: They provide the ability to connect to socket servers over tcp/ip but since they are plugins, developers don‘t want to depend on them.

WebSockets: they are the new API which tries to address the short comings of above methods in the following manner:

• The only advantage of WebSockets over plugins like Java Applets, Flash or Silverlight is that WebSockets are natively built into browsers and does not rely on plugins.
• The only advantage of WebSockets over http streaming is that you don‘t have to make an effort to "understand" and parse the data received.
• The only advantage of WebSockets over Long Polling is that of elimination of extra headers size & opening and closing of socket connection for request.

Are there any other significant differences that I am missing? I‘m sorry if I am re-asking or combining many of the questions already on SO into a single question, but I just want to make perfect sense out of all the info that is out there on SO and the web regarding these concepts.

There are more differences than the ones you have identified.

Duplex/directional:

• Uni-directional: HTTP poll, long poll, streaming.
• Bi-direcitonal: WebSockets, plugin networking

In order of increasing latency (approximate):

• WebSockets
• Plugin networking
• HTTP streaming
• HTTP long-poll
• HTTP polling

CORS (cross-origin support):

• WebSockets: yes
• Plugin networking: Flash via policy request (not sure about others)
• HTTP * (some recent support)

Native binary data (typed arrays, blobs):

• WebSockets: yes
• Plugin networking: not with Flash (requires URL encoding across ExternalInterface)
• HTTP *: recent proposal to enable binary type support

Bandwidth in decreasing efficiency:

• Plugin networking: Flash sockets are raw except for initial policy request
• WebSockets: connection setup handshake and a few bytes per frame
• HTTP streaming (re-use of server connection)
• HTTP long-poll: connection for every message
• HTTP poll: connection for every message + no data messages

Mobile device support:

• WebSocket: iOS 4.2 and up. Some Android via Flash emulation or using Firefox for Android or Google Chrome for Android which both provide native WebSocket support.
• Plugin networking: some Android. Not on iOS
• HTTP *: mostly yes

Javascript usage complexity (from simplest to most complicated). Admittedly complexity measures are somewhat subjective.

• WebSockets
• HTTP poll
• Plugin networking
• HTTP long poll, streaming

Also note that there is a W3C proposal for standardizing HTTP streaming called Server-Sent Events. It is currently fairly early in it‘s evolution and is designed to provide a standard Javascript API with comparable simplicity to WebSockets.