What is the difference between WebSockets and WebRTC?
Compare WebSockets and WebRTC: server-mediated TCP messaging versus peer-to-peer UDP media, use cases, and how signaling connects them.
Expected Interview Answer
WebSockets provide a persistent, bidirectional client-to-server channel over TCP, ideal for chat, notifications, and dashboards, while WebRTC enables direct peer-to-peer media and data exchange over UDP, optimized for low-latency audio, video, and file transfer between browsers. The core difference is topology and transport: WebSockets go through a server over reliable TCP; WebRTC connects peers directly, favoring low latency over guaranteed delivery.
WebSockets are simple to run because every message passes through your server, giving you a central point for authentication, routing, and persistence, but that hop adds latency and the server carries all the traffic. WebRTC establishes a direct connection between peers using ICE, STUN, and TURN to traverse NATs and firewalls, then streams media or arbitrary data with configurable reliability, which is why it powers video calls. Notably, WebRTC still needs a signaling channel to set up the connection — and that signaling is very often a WebSocket, so the two technologies are complementary rather than competitors.
- Choose WebSockets for server-mediated messaging
- Choose WebRTC for direct low-latency media
- WebSockets centralize auth and persistence
- WebRTC minimizes latency with peer-to-peer UDP
- They combine: WebSocket signaling sets up WebRTC
AI Mentor Explanation
WebSockets are like every message going through the on-field umpire who relays each call to both teams — reliable and central, but everything routes through one official. WebRTC is two players signaling directly with hand gestures across the pitch, instant and private, with no umpire in the loop for the exchange itself, though the umpire still sets up the match beforehand like signaling starts a peer link.
Step-by-Step Explanation
Step 1
Compare the topology
WebSockets route all traffic through a server; WebRTC connects peers directly after setup.
Step 2
Compare the transport
WebSockets use reliable, ordered TCP; WebRTC typically uses UDP for low latency with configurable reliability.
Step 3
Identify the use case
Pick WebSockets for chat, notifications, and dashboards; pick WebRTC for audio, video, and direct data channels.
Step 4
Understand NAT traversal
WebRTC uses ICE, STUN, and TURN to connect peers across NATs and firewalls; WebSockets just reach the server.
Step 5
See how they combine
WebRTC needs a signaling channel to exchange offers and ICE candidates — frequently implemented with a WebSocket.
What Interviewer Expects
- Clear distinction between server-mediated and peer-to-peer
- Knowing WebSockets use TCP and WebRTC typically uses UDP
- Appropriate use cases for each technology
- Awareness of ICE, STUN, and TURN for NAT traversal
- Understanding that WebRTC needs signaling, often over WebSockets
Common Mistakes
- Calling them competitors rather than complementary
- Thinking WebRTC needs no server at all
- Assuming WebSockets can do low-latency peer media well
- Ignoring NAT traversal challenges in WebRTC
- Not knowing WebRTC still requires a signaling channel
Best Answer (HR Friendly)
“WebSockets keep an open line between a user and the server so both can send messages instantly, which is great for chat and live updates. WebRTC connects two users directly for things like video calls to keep delay low, and it often uses a WebSocket behind the scenes just to set up that direct connection.”
Code Example
const signaling = new WebSocket('wss://signal.example.com')
const pc = new RTCPeerConnection()
// Send our ICE candidates to the peer via the WebSocket
pc.onicecandidate = (e) => {
if (e.candidate) {
signaling.send(JSON.stringify({ type: 'ice', candidate: e.candidate }))
}
}
// Create and share an offer
async function call() {
const offer = await pc.createOffer()
await pc.setLocalDescription(offer)
signaling.send(JSON.stringify({ type: 'offer', sdp: offer }))
}Follow-up Questions
- Why does WebRTC need a signaling server if it is peer-to-peer?
- What are STUN and TURN servers used for?
- When would you prefer WebSockets over WebRTC data channels?
- How does UDP-based transport help WebRTC latency?
- Can WebRTC data channels replace WebSockets entirely?
MCQ Practice
1. The primary topology difference is that...
WebSockets pass traffic through a server, while WebRTC establishes a direct connection between peers after signaling.
2. WebRTC typically uses which transport for media?
WebRTC favors UDP so real-time audio and video stay low-latency, accepting some loss over head-of-line blocking.
3. What role does a WebSocket often play with WebRTC?
WebRTC needs a signaling channel to negotiate the connection, and a WebSocket is a common choice for that exchange.
Flash Cards
WebSockets vs WebRTC topology — WebSockets route through a server; WebRTC connects peers directly after signaling.
Transport difference — WebSockets use reliable TCP; WebRTC typically uses UDP for low-latency media.
Does WebRTC need a server? — Yes — for signaling and often STUN/TURN to traverse NATs, even though media flows peer-to-peer.
Are they competitors? — No — complementary. WebSocket signaling frequently sets up a WebRTC connection.