Difference between normal request/response, long-Polling, websockets, Webrtc and Server-Sent Events?

Question

I had the wrong idea long-time, I started to notice that in fact it is a "technique" that runs on top of a normal request, I started researching and noticed several questions on the site, but most are "how to do", I would like to understand the difference between Websockets, Webrtc, Server-Sent Events, normal HTTP requests and long-time.

I already know about websocket and HTTP, but I opened this question because I see that there are more technologies and I think it would be interesting to know where they differ.

Would you also like a detail on long-Polling, does it really help? Because this "wait" that it does I can not see any advantage, it seems to me that if there are multiple requests will be worse than a normal HTTP request.

while (true) {
    if (condição para liberar os dados) {
         Resposta
         break;
    }
}

Answer 1

Request/Answer "normal"

This is the protocol HTTP itself. It is the initiative of the client to make a request to the server. The server will give an answer. The server cannot take the initiative to send information to the client without it making a request in the version HTTP 1.1 (I think it changed in 2).

This is an additional explanation why it works that way

The HTTP protocol is an application-level protocol that uses the protocol TCP as a communication protocol. Communication protocols normally use sockets to transmit data.

Therefore the client and the server have to open a socket to send requests and receive responses (respectively). Sockets are bidirectional, meaning they allow communicating in both directions (receiving and sending).

However, it is possible to close one of the directions if it is not used (as is the case with HTTP). This is why the client can only send requests to the server.

Main difference between bidirectional and unidirectional sockets on SOEN

Long-Polling and Polling

Long-Polling

Long-Polling is a specific behavior at the application level. When using long-Polling the client is waiting for the server to send him a set of data.

Imagine you have a server with task web application. Imagine now that the server doesn’t have any data yet and a client asks to get a list of All. However the customer prefers that most of the time this list is not empty.

Then the server waits for other clients (or even the same client) to create tasks. And only when there is at least 1 task it sends a reply to the customer.

However the server can only "hold" the response for a certain period of time because it is normal for requests to have a maximum timeout (normally this timeout is configurable in the client). This means that long-Polling cannot give guarantees that there will be a data set to send (in this case tasks).

Polling

Already Polling works a little different. The client will send requests to the x server in x time waiting for the server to give you new information. Server does not block waiting for a client to create tasks.

---

As you mentioned, both long-Polling and Polling are primitive techniques that don’t really give any kind of guarantees. (Note that neither Polling nor long-Polling ensure that there will be new data).

Web-sockets

Web-sockets is a different protocol than HTTP. Unlike HTTP it allows two-way communication on the client and server.

Following the same example of the task application this means that the server can send a request to the client when it has new tasks. In this approach there is no type of blocking by the server nor does the server receive unnecessary requests from clients (who expect to obtain new data).

See also an example of a web-scoket javascript client. (working!!)

var ws = new WebSocket("wss://protocols.herokuapp.com/web-sockets");

ws.onopen = function()
{
    // Web Socket is connected, send data using send()
    ws.send("Message to send");
    console.log('Client sent message');
};

ws.onmessage = function (evt) 
{ 
    var received_msg = evt.data;
    console.log("Server sent: " + received_msg)
};

ws.onclose = function()
{ 
    // websocket is closed.
    console.log("Connection is closed..."); 
};

Server-Sent Events

This protocol is an application of the HTTP protocol. But this time it is the server who sends orders (it ends with the limitation of the client not being able to receive orders). Order processing is typically done by registering handlers for events.

See a more detailed explanation of Server-Sent Events in SOEN

  var source = new EventSource('https://protocols.herokuapp.com/sse-hello');

  source.addEventListener('message', function(e) {
    console.log(e.data);
  }, false);

View the server code!

Webrtc

Webrtc seems to be a specialized protocol for media transmission (video and audio). This protocol follows a model p2p where clients transmit data between them. This means that the number of requests made to the server containing the resource is minimal.

See a more detailed explanation of Webrtc in SOEN