I'm developing simple browser real-time multiplayer (2 players in a gameplay atm) game. It involves fast and frequent player moves and changes of direction, so informations must be exchanged very quickly - I decided to try websockets (would be happy to use pubnub service instead of self-hosting socket server).
My problem is, pubnub always decides to use xhr fallback instead of websockets - don't know why. Are there any specific requirements that must be fulfilled to run communication via websockets? Http is obviously too slow and kills the experience. I'm using latest Chrome on a Mac, so browser compatibility is not an issue.
Or maybe, there is so many variables to determine communication protocol, that the question cannot be answered? And my only solution is to use self-hosted socket server?
Realtime Protocol WebSockets and XHR with PubNub
Modern data stream networks and open source solutions start with XHR. For several reasons this is optimal to start with including speed. Performance is dependent on the speed of light and how fast Ethernet Frames are able to be transmitted between devices on the internet. This is the foundation for protocol independence and the core determinator for latency and speed of messages across the internet. The PubNub client SDKs, such as JavaScript, do not provide a setting to force a particular protocol.
How PubNub Works
See How PubNub Works scroll down for mouse demo.
PubNub is the fastest global data stream network available today with 15 data centers world wide to support your high speed and low latency requirements. Over 1/4 billion devices connected to the PubNub data stream network experience send/receive speeds from 10ms to 100ms per message.
What is Protocol Independence?
The people behind the PubNub Data Stream Network believe in the Protocol Independence and the open mobile web; meaning that we will use the best protocol to get connectivity through any environment. Protocols, like WebSockets, can get tripped up by cell tower switching, double NAT environments, and even some anti-virus software or proxy boarder authorities.
PubNub provides client libraries specifically so we can auto-switch the protocol and remove socket-level complexities making it easy for developers to build apps that can communicate in realtime.
PubNub has used a variety of protocols over time, like WebSockets, MQTT, COMET, BOSH, long polling and others, and we are exploring currently prototyping future designs using SPDY, HTTP 2.0, and others. The bottom line is that PubNub will work in every network environment, and has very low network bandwidth overhead, as well as low battery drain on mobile devices.
You could also try other cloud services that use WebSockets as the first-option protocol (with XHR fallbacks), like Pusher and Realtime (the company I work for).
Related
I am working on a project where i need my mobile application to talk to my web browser on a pc, where both devices are connected over wifi. The app would send data which would be received by the computer browser followed by some client side code execution. The browser then may send some feedback.
My initial approach is to make the app talk to an endpoint which in turn talks to client side of the browser (javascript).
What could be the best approach to do this ?
Update
I am not sure if Socket.io is a possible solution since it requires a server to be hosted. Is it possible to solve this using sockets ?
You've now edited your question to mention P2P. That's quite hard to achieve PHONE TO BROWSER (i.e., by hard I mean 6 to 12 man-months of work - and/or plain not possible). However in MOST situations you can instantly (ie "one line of code on each platform") resolve the problem by using a service like pubnub. Much as nobody has back-ends anymore and everything is just done with parse.com or game center, networking like you mention is now just done with pubunb (or any competitor).
This is an extremely common use case problem - and everyone just uses PubNub as mentioned below or one of its competitors.
These days it couldn't be easier, just use pubnub.com
It's the world's biggest data-messaging service for a reason!
There's essentially no other realistic approach, it's so simple - a few lines of code.
So short answer would be: A real peer-to-peer (P2P) communication is currently not possible with all browsers. So instead you have the following options:
App + Server with a WebUI (maybe)
App + Chrome App (Chrome Apps can start an web server, see http://www.devworx.in/news/misc/chrome-apps-can-now-run-a-web-server-135711.html)
App + WebApp with Plugin (Flash, Silverlight or Java)
I personally would prefer solution 1.
You need a server. If you consider this problem strictly from the typical firewall point of view, a PC or a mobile device are going to ignore connections unless they initiate the connection themselves. So neither the PC nor the mobile device can start a connection with the other.
My understanding is that web browsers do not support standard sockets within javascript. You can use the analagous websocket, but sockets and websockets are not directly compatible.
You can setup a simple server on the PC, and have this server relay messages between the mobile device and the PC browser. Both the mobile device and the PC browser connect to the server. This is basically what an external service will do for you.
PeerJS is what you're looking for:
http://peerjs.com
I'm working on a web app that is accessible to users via multiple platforms from smartphones to desktops which needs to sometimes make a communication between two clients for example if I want my friend to join my network I'd send him a friend request but I want that request to be seen by my friend without him having to refresh the page.
In this scenario which would be a better choice?
And also since I want this to work on as many platforms and browsers as possible which has more browser support?
Is there a better option?
Some things to keep in mind when making this choice.
Attempting to fetch content over a WebSocket connection is a poor
design decision because WebSockets is a different protocol nested
inside an HTTP connection and it can't leverage caching (neither the
browsers nor CDNs).
Some older proxies won't pass on a Websocket connection unless its hidden within a secure connection while Server
Sent Events remains an HTTP connection and won't suffer from
this.
Neither WebSockets nor SSE are supported in the native Android
browser until 4.4 (when they switched to using Chrome) - thus if
you're considering a hybrid mobile app, you will need a fallback such
as SocketIO since, as of this writing, 4.4 is only 20% of the market
and hybrid apps use the native Android browser.
WebSockets is the
most battery efficient protocol for mobile devices, since all other
options require many HTTP connections and it is the repeated
negotiating of the headers that will burden the cpu and drain the
battery.
Another option may be notifications. All mobile devices now support notifications that can be targeted to an App and a number of browsers have as well. In all cases a connection already exists from the client to the messaging center (Apple, Google, Microsoft, etc) and all notifications are sent over this channel.
Here's a good overview of WebSockets vs. SSE:
http://www.html5rocks.com/en/tutorials/eventsource/basics/
Server Sent Events: A persistent connection server-2-client only, for sending text messages and that is implemented in all major browsers, but Internet Explorer. It can reconnect itself if connectivity is lost. http://caniuse.com/eventsource
WebSokets: A full duplex persistent connection capable of transmitting UTF8 text and binary data. http://caniuse.com/websockets
WebSocket is better, and the future.
From what I understand, SSEs are simpler and easier to implement, whereas WebSockets offer bi-directional data transfer but are their own protocol/API you need to understand to take advantage of. Honestly I've never really bothered with SSEs, Socket.IO does all I've needed as far as real time web app communication fairly easily and is built to be cross-browser.
If you just want him to be able to see a notification, then SSEs should be fine. If you want him to be able to reply to your friend request from the same page, then have the server send you a notification that he's accepted, you'll probably want to use a WebSockets implementation.
I plan to develop browser multiplayer turn-based game (2-6 players per game). Server part planed to write on Java. I have to choose between websockets and AJAX for exchange data in game process. I'm wondering which is the better choice.
I thought to use websockets, because it is not critically to support old browsers for me and latest version of browser supports websockets. But I know about websockets problem with proxies and routers. How do you think these problems affect most users? And what is better way to reduce the impact of these problems: use secured websockets instead usual, run websockets server on another (not 80) port? Or it's better to use AJAX?
I know about such libraries as socket.io and sockJS. But it's interested about pure websockets.
You should go for secure WebSocket. This will work in almost all network enviroments. Mobile. Enterprise. Etc. The exception potentially being so-called Man-in-the-Middle proxies which can unwrap TLS, and then WebSocket will depend on the proxy supporting and allowing it.
Note that with AJAX alone you don't have a push channel. If you want push and go with Comet, that can have it's own issues with proxies also.
WebSocket is a persistent bidirectional connection. AJAX is just request-response. For a game, websockets make more sense. WSS should go through proxies, routers should not be a problem for either WS or WSS. However, some proxies are not friendly to persistent connections and could cut it after a while, there is no workaround for that.
Both WebSockets and Server-Sent Events are capable of pushing data to browsers. To me they seem to be competing technologies. What is the difference between them? When would you choose one over the other?
Websockets and SSE (Server Sent Events) are both capable of pushing data to browsers, however they are not competing technologies.
Websockets connections can both send data to the browser and receive data from the browser. A good example of an application that could use websockets is a chat application.
SSE connections can only push data to the browser. Online stock quotes, or twitters updating timeline or feed are good examples of an application that could benefit from SSE.
In practice since everything that can be done with SSE can also be done with Websockets, Websockets is getting a lot more attention and love, and many more browsers support Websockets than SSE.
However, it can be overkill for some types of application, and the backend could be easier to implement with a protocol such as SSE.
Furthermore SSE can be polyfilled into older browsers that do not support it natively using just JavaScript. Some implementations of SSE polyfills can be found on the Modernizr github page.
Gotchas:
SSE suffers from a limitation to the maximum number of open connections, which can be specially painful when opening various tabs as the limit is per browser and set to a very low number (6). The issue has been marked as "Won't fix" in Chrome and Firefox. This limit is per browser + domain, so that means that you can open 6 SSE connections across all of the tabs to www.example1.com and another 6 SSE connections to www.example2.com (thanks Phate).
Only WS can transmit both binary data and UTF-8, SSE is limited to UTF-8. (Thanks to Chado Nihi).
Some enterprise firewalls with packet inspection have trouble dealing with WebSockets (Sophos XG Firewall, WatchGuard, McAfee Web Gateway).
HTML5Rocks has some good information on SSE. From that page:
Server-Sent Events vs. WebSockets
Why would you choose Server-Sent Events over WebSockets? Good question.
One reason SSEs have been kept in the shadow is because later APIs like WebSockets provide a richer protocol to perform bi-directional, full-duplex communication. Having a two-way channel is more attractive for things like games, messaging apps, and for cases where you need near real-time updates in both directions. However, in some scenarios data doesn't need to be sent from the client. You simply need updates from some server action. A few examples would be friends' status updates, stock tickers, news feeds, or other automated data push mechanisms (e.g. updating a client-side Web SQL Database or IndexedDB object store). If you'll need to send data to a server, XMLHttpRequest is always a friend.
SSEs are sent over traditional HTTP. That means they do not require a special protocol or server implementation to get working. WebSockets on the other hand, require full-duplex connections and new Web Socket servers to handle the protocol. In addition, Server-Sent Events have a variety of features that WebSockets lack by design such as automatic reconnection, event IDs, and the ability to send arbitrary events.
TLDR summary:
Advantages of SSE over Websockets:
Transported over simple HTTP instead of a custom protocol
Can be poly-filled with javascript to "backport" SSE to browsers that do not support it yet.
Built in support for re-connection and event-id
Simpler protocol
No trouble with corporate firewalls doing packet inspection
Advantages of Websockets over SSE:
Real time, two directional communication.
Native support in more browsers
Ideal use cases of SSE:
Stock ticker streaming
twitter feed updating
Notifications to browser
SSE gotchas:
No binary support
Maximum open connections limit
According to caniuse.com:
98.35% of global users natively support WebSockets
98.03% of global users natively support Server-sent events
You can use a client-only polyfill to extend support of SSE to many other browsers. This is less likely with WebSockets. Some EventSource polyfills:
EventSource by Remy Sharp with no other library dependencies (IE7+)
jQuery.EventSource by Rick Waldron
EventSource by Yaffle (replaces native implementation, normalising behaviour across browsers)
If you need to support all the browsers, consider using a library like web-socket-js, SignalR or socket.io which support multiple transports such as WebSockets, SSE, Forever Frame and AJAX long polling. These often require modifications to the server side as well.
Learn more about SSE from:
HTML5 Rocks article
The W3C spec (published version, editor's draft)
Learn more about WebSockets from:
HTML5 Rocks article
The W3C spec (published version, editor's draft)
Other differences:
WebSockets supports arbitrary binary data, SSE only uses UTF-8
Websocket VS SSE
Web Sockets - It is a protocol which provides a full-duplex communication channel over a single TCP connection.
For instance a two-way communication between the Server and Browser
Since the protocol is more complicated, the server and the browser has to rely on library of websocket
which is socket.io
Example - Online chat application.
SSE(Server-Sent Event) -
In case of server sent event the communication is carried out from server to browser only and browser cannot send any data to the server. This kind of communication is mainly used
when the need is only to show the updated data, then the server sends the message whenever the data gets updated.
For instance a one-way communication between the Server to Browser.
This protocol is less complicated, so no need to rely on the external library JAVASCRIPT itself provides the EventSource interface to receive the server sent messages.
Example - Online stock quotes or cricket score website.
Opera, Chrome, Safari supports SSE,
Chrome, Safari supports SSE inside of SharedWorker
Firefox supports XMLHttpRequest readyState interactive, so we can make EventSource polyfil for Firefox
One thing to note:
I have had issues with websockets and corporate firewalls. (Using HTTPS helps but not always.)
See https://github.com/LearnBoost/socket.io/wiki/Socket.IO-and-firewall-software
https://github.com/sockjs/sockjs-client/issues/94
I assume there aren't as many issues with Server-Sent Events. But I don't know.
That said, WebSockets are tons of fun. I have a little web game that uses websockets (via Socket.IO) (http://minibman.com)
they are different in semantics.
websocket has a native semantic meaning of "bidirectional data stream".
while sse has a native semantic meaning of "publish-subscribe pattern" or "request-respond pattern, despite the response is a stream".
of course you can implement a layer of "pub-sub pattern" or "req-res pattern" over websocket by yourself.
In 2023 the situation is not quite as it used to be.
Years ago, when IE still had a significant market share, one downside of SSE was the total lack of native support by IE (whereas WebSockets was supported by IE 10+). Nowadays, according to caniuse.com, both technologies are supported almost equally well on the client side: 98.35% for WebSockets vs 98.03% for SSE (those stats are for global users).
Historically, one severe limitation of SSE, the 6-connections-per-domain limit (a problem when yourapp.com is opened in many browser tabs) is not an issue anymore with HTTP/2. All modern browsers support HTTP/2 (97.16% of global users) and on the server-side HTTP/2+ has also surpassed HTTP/1 the last couple of years.
Various things need to be considered when chosing between SSE and WebSockets:
SSE is generally simpler to implement and easier to test/debug (a simple curl could be used).
WebSockets support bidirectional (full-duplex) communication. That said, SSE could be used in conjunction with AJAX if bidirectional communication is needed. WebSockets are often said to be the simpler option in those cases, but I think such generalizations can be misleading, as it largely depends on the type of application, how it's designed and the technologies used.
SSE supports UTF-8 text messages only, whereas WebSockets can also transmit binary data.
From a practical standpoint, I'd also recommend to research how well your application server supports each of those technologies. Note that some rely on additional modules and/or libraries. You might want to look at some examples and maybe build a quick PoC.
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.
Thanks!
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.
Some great answers from others that cover a lot of ground. Here's a little bit extra.
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.
If by this you mean that you can use Java Applets, Flash, or Silverlight to establish a socket connection, then yes, that is possible. However you don't see that deployed in the real world too often because of the restrictions.
For example, intermediaries can and do shutdown that traffic. The WebSocket standard was designed to be compatible with existing HTTP infrastructure and so is far less prone to being interfered with by intermediaries like firewalls and proxies.
Moreover, WebSocket can use port 80 and 443 without requiring dedicated ports, again thanks to the protocol design to be as compatible as possible with existing HTTP infrastructure.
Those socket alternatives (Java, Flash, and Silverlight) are difficult to use securely in a cross-origin architecture. Thus people often attempting to use them cross-origin will tolerate the insecurities rather than go to the effort of doing it securely.
They can also require additional "non-standard" ports to be opened (something administrators are loathe to do) or policy files that need to be managed.
In short, using Java, Flash, or Silverlight for socket connectivity is problematic enough that you don't see it deployed in serious architectures too often. Flash and Java have had this capability for probably at least 10 years, and yet it's not prevalent.
The WebSocket standard was able to start with a fresh approach, bearing those restrictions in mind, and hopefully having learned some lessons from them.
Some WebSocket implementations use Flash (or possibly Silverlight and/or Java) as their fallback when WebSocket connectivity cannot be established (such as when running in an old browser or when an intermediary interferes).
While some kind of fallback strategy for those situations is smart, even necessary, most of those that use Flash et al will suffer from the drawbacks described above. It doesn't have to be that way -- there are workarounds to achieve secure cross-origin capable connections using Flash, Silverlight, etc -- but most implementations won't do that because it's not easy.
For example, if you rely on WebSocket for a cross-origin connection, that will work fine. But if you then run in an old browser or a firewall/proxy interfered and rely on Flash, say, as your fallback, you will find it difficult to do that same cross-origin connection. Unless you don't care about security, of course.
That means it's difficult have a single unified architecture that works for native and non-native connections, unless you're prepared to put in quite a bit of work or go with a framework that has done it well. In an ideal architecture, you wouldn't notice if the connections were native or not; your security settings would work in both cases; your clustering settings would still work; your capacity planning would still hold; and so on.
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.
It's not as simple as opening up an HTTP stream and sitting back as your data flows for minutes, hours, or longer. Different clients behave differently and you have to manage that. For example some clients will buffer up the data and not release it to the application until some threshold is met. Even worse, some won't pass the data to the application until the connection is closed.
So if you're sending multiple messages down to the client, it's possible that the client application won't receive the data until 50 messages worth of data has been received, for example. That's not too real-time.
While HTTP streaming can be a viable alternative when WebSocket is not available, it is not a panacea. It needs a good understanding to work in a robust way out in the badlands of the Web in real-world conditions.
Are there any other significant differences that I am missing?
There is one other thing that noone has mentioned yet, so I'll bring it up.
The WebSocket protocol was designed to a be a transport layer for higher-level protocols. While you can send JSON messages or what-not directly over a WebSocket connection, it can also carry standard or custom protocols.
For example, you could do AMQP or XMPP over WebSocket, as people have already done. So a client could receive messages from an AMQP broker as if it were connected directly to the broker itself (and in some cases it is).
Or if you have an existing server with some custom protocol, you can transport that over WebSocket, thus extending that back-end server to the Web. Often an existing application that has been locked in the enterprise can broaden it's reach using WebSocket, without having to change any of the back-end infrastructure.
(Naturally, you'd want to be able to do all that securely so check with the vendor or WebSocket provider.)
Some people have referred to WebSocket as TCP for the Web. Because just like TCP transports higher-level protocols, so does WebSocket, but in a way that's compatible with Web infrastructure.
So while sending JSON (or whatever) messages directly over WebSocket is always possible, one should also consider existing protocols. Because for many things you want to do, there's probably a protocol that's already been thought of to do it.
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.
This was a great question, and the answers have all been very informative!
If I may ask one additional thing: I came across in an article somewhere that says that http streaming may also be cached by proxies while websockets are not. what does that mean?
(StackOverflow limits the size of comment responses, so I've had to answer here rather than inline.)
That's a good point. To understand this, think about a traditional HTTP scenario... Imagine a browser opened a web page, so it requests http://example.com, say. The server responds with HTTP that contains the HTML for the page. Then the browser sees that there are resources in the page, so it starts requesting the CSS files, JavaScript files, and images of course. They are all static files that will be the same for all clients requesting them.
Some proxies will cache static resources so that subsequent requests from other clients can get those static resources from the proxy, rather than having to go all the way back to the central web server to get them. This is caching, and it's a great strategy to offload requests and processing from your central services.
So client #1 requests http://example.com/images/logo.gif, say. That request goes through the proxy all the way to the central web server, which serves up logo.gif. As logo.gif passes through the proxy, the proxy will save that image and associate it with the address http://example.com/images/logo.gif.
When client #2 comes along and also requests http://example.com/images/logo.gif, the proxy can return the image and no communication is required back to the web server in the center. This gives a faster response to the end user, which is always great, but it also means that there is less load on the center. That can translate to reduced hardware costs, reduced networking costs, etc. So it's a good thing.
The problem arises when the logo.gif is updated on the web server. The proxy will continue to serve the old image unaware that there is a new image. This leads to a whole thing around expiry so that the proxy will only cache the image for a short time before it "expires" and the next request goes through the proxy to the web server, which then refreshes the proxy's cache. There are also more advanced solutions where a central server can push out to known caches, and so on, and things can get pretty sophisticated.
How does this tie in to your question?
You asked about HTTP streaming where the server is streaming HTTP to a client. But streaming HTTP is just like regular HTTP except you don't stop sending data. If a web server serves an image, it sends HTTP to the client that eventually ends: you've sent the whole image. And if you want to send data, it's exactly the same, but the server just sends for a really long time (like it's a massively gigantic image, say) or even never finishes.
From the proxy's point of view, it cannot distinguish between HTTP for a static resource like an image, or data from HTTP streaming. In both of those cases, the client made a request of the server. The proxy remembered that request and also the response. The next time that request comes in, the proxy serves up the same response.
So if your client made a request for stock prices, say, and got a response, then the next client may make the same request and get the cached data. Probably not what you want! If you request stock prices you want the latest data, right?
So it's a problem.
There are tricks and workarounds to handle problems like that, it is true. Obviously you can get HTTP streaming to work since it's it's in use today. It's all transparent to the end user, but the people who develop and maintain those architectures have to jump through hoops and pay a price. It results in over-complicated architectures, which means more maintenance, more hardware, more complexity, more cost. It also means developers often have to care about something they shouldn't have to when they should just be focussing on the application, GUI, and business logic -- they shouldn't have to be concerned about the underlying communication.
HTTP limits the number of connections a client can have with a server to 2 (although this can be mitigated by using subdomains) and IE has been known to enforce this eagerly. Firefox and Chrome allow more (although I can't remember of the top of my head exactly how many). This might not seem like a huge issue but if you are using 1 connection constantly for real-time updates, all other requests have to bottleneck through the other HTTP connection. And there is the matter of having more open connections from clients puts more load on the server.
WebSockets are a TCP-based protocol and as such don't suffer from this HTTP-level connection limit (but, of course, browser support is not uniform).