Performance should always be tested, not theorized ... Having said that, I will quickly tell you why I believe that Websockets are more efficient and reliable :
The advantages of websockets over polling are two:
Before Http / 2, a new connection is required for each new polling request. Websockets will save you resources related to the new connection.
Obviously, when using Http / 2, this is no longer the case, since Http / 2 is designed to use the same connection . Transition to advantage No. 2:
Each new survey request is a request and requires all resources associated with the request (for example, polling a database to view changes, etc.).
Websockets will save you the resources associated with polling requests, since data will only be issued when it is available, which minimizes the number of intermediate requests.
In fact, websockets will still save you a lot of resources related to the actual survey . Most websocket updates (if not all) use data update hooks, so polling is not required (push starts immediately after the update, without the need to poll and view the changes).
Even when polling is used for websocket data, for all clients there is only one polling event, as well as a polling event for each client.
What about Http / 2 Push?
That should raise a performance question ... but, one might ask, "what about Http / 2 push? Doesn't that mean that websites are no longer needed?"
This is somewhat controversial, and you can find discussions about this (for example, here ).
As you can see from my answer in a related question, I believe websocket is more reliable, and here's why:
some information is missing from the original answer, and other information from my original answer was missing or summarized
As stated in the Http / 2 project (current standard?):
An intermediary agent can receive a click from the server and choose not to forward them to the client ...
This is also true for browsers (if you look at the documentation for settings frames). For example, when I played with the Iodine Http / 2 server (I am the author), I noticed that Safari set push notifications to “disable” ... I'm not sure if this is still the case, but for me it is very important when I Think Web Sites Against Http / 2.
In addition, the Http / 2 connection can be interrupted by the client (or the server or by anyone in between) while the browser is still visiting the page, effectively disabling HST / 2 push notifications. p>
If this happens on websockets, the onclose can be used to reconnect. With Http / 2 there is nothing you can do.
For these reasons (and a few others), I believe that Websockets provide better performance and better reliability.
EDIT (related to comments)
SSE (events sent by the server)
Let me point out why I think websites are superior to SSE.
SSE is a development based on a long survey of pre-web memory.
This could be great for server messages for the client, with the exception of a few things:
This server implementation mostly sucks.
As for Http / 2, I have not seen any implementations, so I can not comment on what might happen, but:
Many SSE implementations will open a new thread for each connection, or implement a second I / O reactor running along the IO server’s reactor, only to manage SSE connections.
This will waste resources compared to websockets (although I saw that some websocket implementations do the same - brrr ...).
SSE is unidirectional and cannot be used for messages sent by the client and server.
This means that you are still using Http + AJAX for data sent from the client to the server.
Unlike Websockets, SSE and Http + AJAX are idle , so you need to authenticate for each new message loop, decode the Http / 2 headers, encode the Http / 2 headers and use all the resources associated with the new request ...
Web descriptors let you skip all this while being discreet. This means that Http headers and authentication are performed only once when the connection is open and all messages are sent in this constant context, which lasts for the entire lifetime of the connection.
SSE is not supported by the community.
It's harder to find good libraries or SSE-related information compared to websites ... Even though SSE web forms are pre-date !
I think this is a good proof of the superiority of webwebsocket in actual production.
Websocket tunneling inside Http / 2
I consider this concept and idea to be a mistake and that tunneling should not be used.
I think that there is a reason why the proposal of February 14, 2014 was not renewed after its expiration on August 18, 2014 (to the best of my knowledge).
Here are a few reasons I can think of:
Web sites and Http / 2 are designed for different lifetimes and connection timeouts.
Although Http / 2 is durable compared to Http / 1.1, the browser (or server) can disable them at any time (with or without the implementation of the websocket disconnect pattern).
Routers, proxies, and balancing balances refer to Http / 2 for setting their connection timeout parameters. It is unlikely that the same settings will apply to the timeout settings that are used today for websites.
Web sites and Http / 2 are designed for different clients.
Http / 2 is intended for Http clients - primarily browsers.
Websockets, on the other hand, are designed for all web clients that help navigate through intermediaries, such as Internet service providers, firewalls, proxies, NAT routers, etc. ". (i.e. this package )
This means that when you decide to write your own application and use your web server as an internal server, this native application should use websockets for better compatibility (connection statistics are better than raw TCP / IP).
Your native application does not speak Http / 2, but it does have the truncated Http / 1 needed to establish a connection to web servers.
If you decide to use tunneling, you probably cannot use the current code for your own application.