WebSockets, in fact, a new technology. Long polling is a kind of workaround and dirty maneuver to prevent the creation of a new connection for each new request, as AJAX does. But long polling was created when WebSockets did not exist at all. And technologies are developing, evolving and now they are gaining popularity.
My little ad-libbing recommendation: read and familiarize yourself with WebSockets .
But nonetheless.
How different methods of communication work on the Internet:
AJAX - запрос → ответ . It creates a connection with the server, sends request headers with some data, receives a response from the server, closes the connection. Requests are sent frequently. Supported in all major browsers.
As a plus: just implement, the data can be compressed.
As a minus: too many unnecessary requests (this is probably the main minus :-)). And also big delays between creating and receiving data. The server sends the data not when they appear, but when a new request arrives.
Long poll - запрос → ожидание → ответ . It creates a connection to the server, like AJAX, but leaves the connection open for a while (not very large). The server does NOT respond to the requested information and waits until new information appears. While the connection is open, the client is waiting for data from the server. As soon as something new appeared at the server, it sends it to the client. The client received new information or if the waiting time expired IMMEDIATELY sends another request to the server, starting the waiting process on it again. As a rule, the connection is usually reinstalled once in 20-30 seconds (for VKontakte, for example, 29 seconds), in order to avoid possible problems, for example with an HTTP proxy. Supported in all major browsers.
As a plus: a small number of requests (compared with the usual AJAX then)
WebSockets - клиент ↔ сервер . A TCP connection is created with the server and is kept open for as long as required. Server or client can easily close it. When connecting, a so-called "handshake" occurs, i.e. client sends special headers that are encrypted by base64. If the server liked everything, it will return the Accept header. It should be remembered that the client handshake will always have a Origin header that will be sent to the server, whether they want to receive clients from various sources or not. After the connection is established, the server and the client can send each other messages when new information is available (either on the server or on the client) - in both directions at any time. This is very effective if the application requires frequent data exchange in both directions. Also, the data sent from the client to the server is somewhat encrypted. Another plus.
[than supported] ( already well developed )
WebRTC (Web Real Time Communication - real-time web communication) - peer peer (P2P - equal to equal). Transport for establishing communication between clients (two or more) through which ordinary data and media streams can be transmitted. Uses UDP, TCP, and even more abstract layers. Typically, this is used to transfer large amounts of data such as media (audio and video). Both parties (peers) can transmit data to each other independently of each other. [than supported] ( medium support )
Server-Sent Events - клиент ← сервер . The client establishes a permanent and lasting connection to the server. Only the server can send data to the client. If the client wants to send something to the server, then it will have to use another technology / protocol. This HTTP protocol is easy to implement on most server platforms. This is the preferred protocol for use than Long Polling. [than supported] (IE as always lagging behind)
Benefits:
Each method has its advantages and disadvantages. However, now WebSockets is considered good and promising. The main advantage of WebSockets for the server is that it is not an HTTP request, but the actual communication protocol based on messages. This allows for tremendous performance and architecture benefits. For example, in node.js, you can divide the same memory for different socket connections, thus gaining access to shared variables. So you do not need to use the database as an exchange point in the middle (like using AJAX or Long Polling and, for example, PHP). You can store data in RAM ...
Only you can decide what to use!
The answer is translated, slightly modified and supplemented by ad- lib with enSO
