WebRTC Vs Websocket: Which is best for your application

WebRTC and Websockets are both real time technologies, these technologies enable instantaneous exchange of data.

Both the technologies are important for applications that require live interactions

Common use-cases for these technologies include online gaming, live chats, live streaming and other low latency applications

WebRTC (Web Real Time Communications)

Webrtc allows peer to peer communication. With Webrtc you can share data and conduct video calling and live streaming. It is best for media streaming applications.

WebSocket

Websocket provides full duplex communication channels. It is best for chat applications, real time notifications and updates.

Websockets also maintains persistent connections thus enabling instant data transfer between client and server.

Understanding WebRTC

WebRTC is an open source tech that enables video and data transfer from peer to peer, that is different web browsers and mobile applications

WebRTC is part of the W3C consortium and thus supported by all major browsers.

Although WebRTC can be used to conduct peer2peer callling after Network traversal service is required such as a TURN server.

This is because NAT devices and firewall rules often block direct communication between devices on the internet.

1. P2p Communication

2. Media Streaming

3. Low Latency

Webrtc vs Websockets

Here are some of the key differences between WebRTC and Websockets

Communication Models

WebRTC's Peer to Peer Model

WebRTC has a Peer to Peer communication model, where one device connects to another device, although this is not possible most of the time because of NAT devices, routers and firewalll rules

Video communication and data transfers are all possible with WebRTC, but these often require TURN servers to navigate the NAT

If you are looking for a TURN server service, then we recommend going for Metered TURN servers

WebRTC is generally lower latency than websockets, but has reduced server load and has end to end encryption leading to enhanced privacy

WebSocket's Client Server Model

Websocket has a persistent connection between client and server, there is no scope of device to device communication in websockets.

It works between client and server. Websockets have a full duplex connection that is long lived, and this model is best for scenarios where you need a persistant connection for real time updates

These use-cases include real time notifications, real time chat

Data always passes through a central server. The reliance on server simplifies certain aspects of communication such as broadcasting to a wide user base and state management for the application

Performance and Latency

Latency

WebRTC generally has lower latency due to its peer to peer model and also it only requires a server to traverse NAT.

WebRTC is ideal for video calling and live streaming applications

On the other hand, Websockets exhibit higher latency because of their client server model and having a persistent connection with the server

Scalability Considerations

WebRTC: When you add TURN servers in the mix WebRTC becomes infinitely scalable.

WebSocket: Websockets are also easily scalable with load balencers and clustering, although this is quite difficult as it reqires professional expertise to properly setup scalable websocket connections

Data Transmission

Webrtc is optimized for video calling and stream but can also transmit any kind of data including including documents and files

Websocket is ideal choice for message based data including text and notifications

Security and encryption

Webrtc uses end to end encryption using DTLS and SRTP, the communication is very secure, not even the TURN servers that are transmitting the data from one device to another cannot access the data.

Websockets you need to enable the security as it is not enabled by default, websockets uses TLS (ess://) to encrypt data between client and server, but the server has access to data unlike in webrtc where server does not have access to the data

Implementation Complexity

Setup and configuration requirements

Webrtc requires a TURN server for most cases to tranverse NAT and firewall rules and for connection establishment

Websocket is a simple setup with a websocket server it does not require a TURN server but requires a websocket server

Required Internet systems and third party systems

Webrtc needs STUN and TURN servers and browser support for webrtc api, which is almost universally available as webrtc is implement by all the major browsers.

websockets require a websocket server TLS certificates and secure connections and handling of persistent connections, without a server websockets cannot work.

WebRTC can work without server in certain cases where the NAT rules are lax and easy to navigate.

Websockets need a websocket server, TLS certificate for secure connection and reliable server for persistent connections

Browser and device support

WebRTC is supported by almost all browsers including chrome, firefox, edge safari and almost all other browsers.

Websocket is not as widely supported as webrtc, there are fallbacks available however including long polling with AJAX and server sent events if websockets are not available

Metered TURN servers

1. API: TURN server management with powerful API. You can do things like Add/ Remove credentials via the API, Retrieve Per User / Credentials and User metrics via the API, Enable/ Disable credentials via the API, Retrive Usage data by date via the API.

2. Global Geo-Location targeting: Automatically directs traffic to the nearest servers, for lowest possible latency and highest quality performance. less than 50 ms latency anywhere around the world

3. Servers in all the Regions of the world: Toronto, Miami, San Francisco, Amsterdam, London, Frankfurt, Bangalore, Singapore,Sydney, Seoul, Dallas, New York

4. Low Latency: less than 50 ms latency, anywhere across the world.

5. Cost-Effective: pay-as-you-go pricing with bandwidth and volume discounts available.

6. Easy Administration: Get usage logs, emails when accounts reach threshold limits, billing records and email and phone support.

7. Standards Compliant: Conforms to RFCs 5389, 5769, 5780, 5766, 6062, 6156, 5245, 5768, 6336, 6544, 5928 over UDP, TCP, TLS, and DTLS.

8. Multi‑Tenancy: Create multiple credentials and separate the usage by customer, or different apps. Get Usage logs, billing records and threshold alerts.

9. Enterprise Reliability: 99.999% Uptime with SLA.

10. Enterprise Scale: With no limit on concurrent traffic or total traffic. Metered TURN Servers provide Enterprise Scalability

11. 5 GB/mo Free: Get 5 GB every month free TURN server usage with the Free Plan

12. Runs on port 80 and 443

13. Support TURNS + SSL to allow connections through deep packet inspection firewalls.

14. Support STUN

15. Supports both TCP and UDP

16. Free Unlimited STUN

How Webrtc Works

WebRTC enables real time communication between devices.  WebRTC is designed to handle a wide range of data transfer applications including video calling and file transfer application.

In this section we are going to learn how the webrtc works:

Core Components WebRTC Architecture

Media Capture and Encoding

• Media Devices: The media devices are handled by the getUserMedia() api method. It captures the media from cameras, microphones, and other input devices

• Encoding: Encoding automatically compresses the media streams using codecs like VP8/VP9 for video and audio

Signalling

• Purpose: Signalling exhanges the connection information like session descriptions and ICE candidates between devices that want to connect to each other

• Mechanism: WebRTC needs a signalling server to exchange messages but does not specify any perticular messagign system. You can use any messaging system that you prefer including WebSockets, SIP or XMPP

• Process: The signalling process involves exchange of SDP data and ICE candidates necessary for the connection

NAT Traversal

• STUN Servers (Session Traversal utilities for NAT): Helps devices that are behind NAT discover their own IP addresses, which they can use to echange with each other and establish a direct connection. You can learn more about STUN servers

• TURN Servers ( Traversal Using Relays around NAT): TURN servers relay traffic between devices that are behind strict NAT and firewall rules where direct connection is not possible. You need TURN servers to be near your client devices that is why when considering a TURN server provider you need one that has server all over the world. One such provider is Metered.ca TURN server service provider with TURN server all over the world.

Peer Connection

• RTCPeerConnection: This api manages the webrtc connection , handles media echange and performs ICE negotiation for the best path between peers.

• ICE framework (Interactive connectivity establishment) ICE servers gathers ICE candidates and network paths and establishes the connection using the best path possible. The ICE framework first tries to establish a direct connection using STUN servers but this often fails due to NAT and routers and firewall rules

Data Channels

RTCDataChannels: This API allows transmission of arbitary data such as for file transfer, text chats and other media streams

Signalling Process, STUN / TURN servers

STUN server

Function: The STUN server replies back to any request that comes it with the request IP address and port number of the device from which the request is comming from. Thus letting the device which are behind a NAT know their own IP address and port number.

Usage: Once device knows what their IP address and port number is, the device can then exchange this information with another device across the internet with which it want to establish a direct webrtc connection. This fails may times because NAT and firewall rules block direct connection with external devices and then the ICE frameworks tries to establish the network using TURN servers between devices.

TURN servers

Function: Relays encrypted data through its servers in a peer to peer connection to traverse NAT

Usage: Sure shot way to traverse NAT when all other options fail. TURN server succeeds

Peer to Peer Connection establishment

Signalling Exchange

• Device X. sends a SDP offer to Device Y Through a signalling server

• Device Y recieves the offer, creates and SDP answer and sends it back

• Both the devices exchange ICE candidates using the signalling server

ICE Candidates Gathering

• Devices gather all the possible network paths that could be taken to reach other device. That is using STUN and if that fails using TURN servers

Connection Checks

• Both the devices perform connectivity checks to test the gathered candidates to make sure which route to take that is direct connection via STUN or relay connection through TURN servers

Media Path Establishment

• Once the route is establsihed then the devices connecgt with each other and start the connection and video call

How Websockets Works

Websocket is a communication protocol using which you can establish a full duplex communication channel that is always on. That is until and unless it is disconnected

Websockets work over TCP connection, which is widely used. The Websocket protcol is designed to be lightweight, simple and easy to use

Key aspects of Websocket protocol

The Websocket protocol is designed to facilitate real time full duplex communication, which is different from http because http connection ends when a request reaches its destination and get a reply for that request

A new connection is created for another request. In Websockets the connection is active unless it is closed by the server or the client

The full duplex connection in websocket means that the server and the client can recieve the messages simultaneously

Single TCP connection

The websockets work over a single TCP connection which is open till the either the server or the client closes the connection.

Message framing

Websocket data have message frameming where a single message contains both 1. a Metadata with information about type of data being sent and other misc technological data. 2. It also contains the payload the action data that a client wants to send to the server and to other clients

Low Latency

The websocket connection is always open, therefore once the connection is established there is low latency when sending messages from the client to the server and from the server to the client