Home
/ Blog /
WebRTC vs WebSocket: Key Differences & Which One is Right For You?June 21, 202311 min read
Share
In today's digital world, real-time communication has become crucial for businesses to stay connected with their clients and customers. And speaking of real-time communication, two fundamentally different technologies that serve different purposes are often compared: WebRTC and WebSockets. In this blog post, we will delve into the basics and working of both WebRTC and WebSockets, to help you decide which one to pick for your use case. So, without wasting any time let’s begin.
WebSocket is a communication protocol that was first introduced in 2010 as a part of the HTML5 specification. It was developed to overcome the limitations of traditional HTTP, which was originally designed as a request-response protocol that didn't support real-time communication. With WebSocket, the client and server can communicate with each other in real-time without the need for frequent connections, which makes it ideal for applications that require low latency and high responsiveness.
Here’s a quick step-by-step working of how Websocket connections work:
Handshaking
When the client makes a request to the server to initiate a WebSocket connection, the server responds with a handshake that includes an Upgrade
header field in the HTTP response. This indicates that the server is willing to switch the connection protocol to WebSocket.
Upgrading the Connection
After receiving the handshake response, the client sends a second HTTP request to the server, indicating that it wants to upgrade the connection to WebSocket. This request includes an Upgrade
header field and a Sec-WebSocket-Key
field, which is a random string generated by the client.
Server Response
The server responds to the client's upgrade request with an HTTP response that includes an Upgrade
header field, the Connection
header field set to "Upgrade", and the Sec-WebSocket-Accept
header field that is computed from the Sec-WebSocket-Key
value that the client sent in its upgrade request.
Data Transfer After the server sends the response, the connection is considered upgraded to WebSocket, and the client and server can exchange messages over the persistent connection. Data is sent and received through WebSocket using frames, where each frame consists of a header and a payload. The header includes information about the data, such as its type (text or binary), length, and whether it is the final frame in a message. And the payload contains the actual data being transmitted.
Let us now take a look at how to create a simple Websocket chat application in javascript. Here, the server will act as a middleman with n
clients communicating with each through it.
Server
A WebSocket server is created using the ws
package in this server code, and incoming connections on port 8080 are listened for. When a new connection is established, a message is logged to the console, and event listeners for the message
and close
events are attached by the server. When a message
event is received, the message is logged to the console, and a response is sent back to the client using the ws.send
method. And finally, when a close
event is received, a message is logged to the console by the server.
const WebSocket = require('ws');
// create a WebSocket server and listen for incoming connections on port 8080
const wss = new WebSocket.Server({ port: 8080 });
// when a new connection is established, log a message and attach event listeners
wss.on('connection', (ws) => {
console.log('WebSocket connection opened');
// when a message is received, log it and send a response back to the client
ws.on('message', (message) => {
console.log(`Received message: ${message}`);
ws.send(`Received: ${message}`);
});
// when the connection is closed, log a message
ws.on('close', () => {
console.log('WebSocket connection closed');
});
});
// log a message when the server starts listening for connections
console.log('WebSocket server started on port 8080');
Client
A WebSocket connection is created to the server using the WebSocket API in this client code, and event listeners for the open
, message
, and close
events are attached. A click
event listener is attached to the button
element, which sends the value of the input
element to the server using the ws.send
method when clicked. And when a message
event is received, the message is appended to the messages
element in the HTML document using innerHTML
.
const WebSocket = require('ws');
// select the input, button, and messages elements from the HTML document
const input = document.querySelector('#input');
const button = document.querySelector('#button');
const messages = document.querySelector('#messages');
// create a WebSocket connection to the server
const ws = new WebSocket('ws://localhost:8080');
// attach event listeners for the open, message, and close events
ws.onopen = () => {
console.log('WebSocket connection opened');
};
ws.onmessage = (event) => {
const message = event.data;
console.log(`Received message: ${message}`);
messages.innerHTML += `<p>${message}</p>`;
};
ws.onclose = () => {
console.log('WebSocket connection closed');
};
// attach a click event listener to the button element
button.addEventListener('click', () => {
const message = input.value;
console.log(`Sending message: ${message}`);
ws.send(message);
input.value = '';
});
TL;DR - WebSockets are used to transport real-time data between clients (with a server in the middle). It can be used for media transfer as well, but you have to take care of encoding/decoding, media capture, and reconnection - which makes it the not-so-ideal choice for audio-video applications in real life.
WebRTC is a free and open-source technology that enables real-time communication between web browsers and mobile applications using simple APIs. With WebRTC, developers can directly embed real-time communication capabilities into web and mobile applications, including voice and video calling, chat, file sharing, and screen sharing, without requiring any plugins or external software. WebRTC utilizes a combination of media codecs, encryption, and network protocols to provide secure and efficient real-time communication. It is built on top of several web technologies and is designed to be easy to use for developers.
Media Channels Media channels are used for exchanging audio and video data between peers. WebRTC supports real-time audio and video communication using codecs such as VP8, VP9, and H.264. Media channels are used to send and receive audio and video streams between peers, and WebRTC provides APIs for capturing, encoding, decoding, and rendering audio and video data.
Data Channels Data channels are used for exchanging arbitrary data between peers, such as text messages or game data. Data channels are built on top of the SCTP (Stream Control Transmission Protocol) transport protocol and can be used for reliable or unreliable data transfer. Data channels can also be used to exchange metadata related to the media streams, such as resolution, frame rate, and codec information.
Both media and data channels use the same peer connection to exchange data, and they can be used together to build powerful real-time applications. For example, a video conferencing application might use media channels to exchange audio and video data between peers, while using a data channel to exchange text messages and other data.
Here's a high-level overview of how WebRTC works:
Signaling Before two peers can establish a WebRTC connection, they need to exchange information about each other, such as IP addresses and session descriptions. This is done using a signaling server, which acts as an intermediary between the peers. The signaling server is not part of the WebRTC specification and can be implemented using any technology.
Peer connection Once the peers have exchanged information via the signaling server, they can establish a peer connection. The peer connection allows the peers to exchange audio, video, and data directly, without going through a server.
Media capture and processing Before the peers can exchange audio and video, they need to capture it from their devices. WebRTC provides APIs for capturing audio and video from webcams and microphones. Once the audio and video are captured, they need to be encoded using a codec. The encoded media is then sent over the peer connection.
Media rendering Once the media is received by the other peer, it needs to be decoded and rendered on the screen. WebRTC provides APIs to help render audio and video on the web page.
NAT traversal When direction connections are not possible due to network issues, WebRTC uses NAT(Network Address Translators) traversal mechanisms to overcome them. These techniques include STUN (Session Traversal Utilities for NAT) and TURN (Traversal Using Relay NAT).
To understand the step-by-step process of how connections are made, check out this blog on how to build your first WebRTC app.
A basic example of how to establish a WebRTC peer-to-peer connection using the JavaScript WebRTC API:
This code creates a new RTCPeerConnection
object, adds the local audio and video stream to the connection, and creates an offer
to start the WebRTC handshake. The other peer would respond with an answer
and then the local description is set and sent to the other peer via a signaling server, along with any ICE candidates that are gathered during the handshake process. Incoming streams from the other peer are played using HTML5 audio and video elements.
// Get local audio and video streams
navigator.mediaDevices.getUserMedia({ audio: true, video: true })
.then(function(stream) {
// Create a new RTCPeerConnection object
var peerConnection = new RTCPeerConnection();
// Add the local stream to the peer connection
peerConnection.addStream(stream);
// Create an offer to start the WebRTC handshake
peerConnection.createOffer()
.then(function(offer) {
// Set the local description and send it to the other peer
return peerConnection.setLocalDescription(offer);
})
.then(function() {
// Send the offer to the other peer via signaling server
// The signaling process can be implemented using WebSocket or HTTP
signalingServer.send(offer);
});
// Listen for ICE candidates from the peer
peerConnection.onicecandidate = function(event) {
if (event.candidate) {
// Send the ICE candidate to the other peer via signaling server
signalingServer.send({ candidate: event.candidate });
}
};
// Listen for incoming streams from the other peer
peerConnection.onaddstream = function(event) {
// Play the incoming audio and video streams
var audio = document.createElement('audio');
audio.srcObject = event.stream;
audio.play();
};
});
TL;DR - WebRTC is used to transport real-time audio-video between 2 clients. It can be used for data transfer as well.
Here’s a useful comparison between WebRTC and Websockets.
WebSockets | WebRTC | |
---|---|---|
Purpose | Enables real-time communication between a client and a server. | Facilitates real-time peer-to-peer communication directly between web browsers. |
Communication | Client to server. | Usually peer-to-peer, but it can change with the architecture. |
Data Transfer | Supports text and binary data. | Supports audio, video, and data transfer. |
Protocol | TCP for data transfer. | UDP for media and TCP for data channel. |
Signaling | Offers built-in signaling for connection establishment. | Requires a custom signaling mechanism to establish connections. |
Automatic reconnection | Not supported. | Supported. |
NAT Traversal | Requires additional server infrastructure for communication across NATs and firewalls. But it’s not usually required. | Handles NAT traversal through built-in mechanisms. |
Media Streams | Not directly supported; Custom protocols are needed for media streaming. | Supports real-time audio and video streaming. |
Latency | Low latency. | Low latency. |
Scaling | Can be scaled with distributed computing. | Can be scaled with routing architecture. |
Use Cases | Real-time chat applications, real-time notifications, and collaborative apps. | Video conferencing, multiplayer gaming, and remote desktop sharing. |
Did you know that while WebRTC is commonly used for real-time communication in web applications, the applications often end up using WebSocket for signaling? WebSocket serves as a reliable and efficient method for establishing and maintaining connections between clients, allowing them to exchange signaling messages with a central server. Beyond signaling, WebSocket can also facilitate features like real-time chat, polls, whiteboard, and annotations, and co-exist with WebRTC.
In conclusion, WebRTC offers several advantages over WebSocket when it comes to media. One key advantage is its built-in support for the simulcast, allowing the sender to transmit multiple video streams with varying quality levels for adaptive video streaming. This feature enables receivers to choose the appropriate stream based on their network bandwidth and device capabilities.
Additionally, WebRTC provides automatic reconnection capabilities, seamlessly handling network interruptions without manual intervention. With broader browser support, WebRTC is a viable option for various platforms. However, WebSocket excels in certain scenarios, such as chat services requiring guaranteed message delivery and server scalability, as well as flexibility in message types. Ultimately, the choice between WebRTC and WebSocket depends on the specific requirements and priorities of the application at hand.
The simple question is - are you transferring audio-video? If yes, then you should use WebRTC. If not, you’re better off with WebSockets.
WebRTC and WebSockets are not directly comparable in terms of speed because they serve different purposes and operate at different layers of the web stack.
No, WebRTC is not built on WebSockets. WebRTC and WebSockets are two separate technologies with different purposes and functionality.
Basics
Share
Related articles
See all articles