While looking at frequently asked questions about WebRTC on Google, the query “WebRTC vs WebSockets” caught my attention. Normally these two terms are quite different from each other. However, if there are so many searches, it would be good to explain both of them in one article.
What are WebSockets?
A WebSocket is a persistent bi-directional communication channel between a client (e.g. a browser) and a backend service. Unlike HTTP request/response connections, WebSockets can transport any protocols and provide server-to-client content delivery without polling.
WebSockets establishes browser-compatible TCP connections using HTTP during the initial setup. Messages over WebSockets can be provided in any protocol, freeing the application from the sometimes unnecessary overhead of HTTP requests and responses. But most critical ability is to deliver messages to connected clients.
WebSockets are available on many platforms, including the most common browsers and mobile devices. They’re often applied to solve problems of millisecond-accurate state synchronization and publish-subscribe messaging, both of which leverage Websockets’ provision for downstream pushes.
A challenge of operating a WebSocket-based system is the maintenance of a stateful gateway on the backend. A WebSocket is erected by making a common HTTP request to that server with an Upgrade header, which the server (after authenticating and authorizing the client) should confirm in its response. After this, the connection remains established between that physical client-server pair; if at some point the service needs to be redeployed or the load redistributed, its WebSocket connections need to be re-established.
Google Chrome was the first browser to include standard support for WebSockets in 2009. RFC 6455—WebSocket Protocol—was officially published online in 2011. The WebSocket Protocol and WebSocket API have been standardized by the W3C and IETF, and support across browsers is widespread.
What is WebRTC?
WebRTC stands for web real-time communications. It is a very exciting, powerful, and highly disruptive cutting-edge technology and streaming protocol.
WebRTC is HTML5 compatible and you can use it to add real-time media communications directly between browsers and devices. One of the best parts, you can do that without the need for any prerequisite plugins to be installed in the browser. Webrtc is progressively becoming supported by all major modern browser vendors including Safari, Google Chrome, Firefox, Opera, and others.
Thanks to WebRTC, you can embed real-time video directly into your solutions to create an engaging and interactive streaming experience for your audience without worrying about latency.
How WebSocket connections work
Before a client and server can exchange data, they must use the TCP (Transport Control Protocol) layer to establish the connection. WebSockets effectively run as a transport layer over the TCP.
Once connected through an HTTP request/response pair, the clients can use an HTTP/1.1 mechanism called an upgrade header to switch their connection from HTTP over to WebSockets. A WebSocket connection is established through a WebSocket handshake over the TCP.
During a new WebSocket handshake, the client and server also communicate which subprotocol will be used for their subsequent interactions. After this is established, the connection will be running on the WebSocket protocol.
It is important to note that when running on the WebSocket protocol layer, WebSockets require a uniform resource identifier (URI) to use a “ws:” or “wss:” scheme, similar to how HTTP URLs will always use an “HTTP:” or “HTTPS:” scheme.
How Does WebRTC Work?
- WebRTC sends data directly across browsers – it is called “P2P”
- It can send audio, video, or data in real-time
- It needs to use NAT traversal mechanisms for browsers to reach each other
- P2P needs to be gone through a relay server (TURN)
- With WebRTC you need to think about signaling and media. They are different from each other.
- One of the main features of the tech was that it allowed peer-to-peer (browser-to-browser) communication with little intervention from a server, which is usually used only for signaling.
- It’s possible to hold video calls with multiple participants using peer-to-peer communication. A media server helps reduce the number of streams a client needs to send, usually to one, and can even reduce the number of streams a client needs to receive.
- Servers you’ll need in a WebRTC product:
- Signaling server
- STUN/TURN servers
- Media servers (It is up to your use case
WebRTC vs Websockets
Let me briefly summarize the WebRTC vs WebSockets search to the point why I find it interesting. WebRTC allows sending random data between browsers (P2P) without the need to transfer this data through a server.
WebRTC has no signaling of its own and this is necessary in order to open a WebRTC peer connection. This is achieved by using other transport protocols such as HTTPS or secure WebSockets.
Does WebRTC use WebSockets?
You don’t have to use WebSockets in your WebRTC application. As I mentioned above WebRTC needs a transport protocol to open a WebRTC peer connection. WebSockets are widely used for this purpose. Hence, from this point of view, WebSocket is not a replacement for WebRTC, it is complimentary. That’s why WebRTC vs Websocket search is not the right term.
Can WebRTC replace WebSockets?
You need to signal the connection between the two browsers to connect a WebRTC data channel. To do this, you need them to communicate via a web server. This is achieved using a secure WebSocket or HTTPS. So the answer is that WebRTC cannot replace WebSockets.
After two peers are connected via WebRTC, messages or files can be sent directly over the WebRTC data channel instead of forwarding them through a server. At this point, the WebRTC data channel meets the need for WebSocket.
I tried to explain WebRTC and WebSocket in this blog post. I hope this blog post clears up confusion for people searching WebRTC vs WebSockets.
