How Your Network Affects User Interactivity
The internet was designed to move data worldwide, despite technological advancements, global catastrophes, or your geography.
It’s meant to be reliable, no matter any of those conditions.
But the evolution of the internet has seen an increased pressure to deliver a larger volume of data while maintaining the same level of reliability.
For example, real-time applications have begun to take over the internet. While they don’t necessarily rely on transferring large amounts of data, they do require stable connections and the lowest possible latency to avoid minimal delays or interruptions.
Enter WebRTC.
Google first announced WebRTC as an open-source package to facilitate real-time audio and video streaming in a browser-agnostic fashion. Fast forward roughly ten years since the release in 2011, and we have reached a point where we can’t imagine life without using these real-time communication applications.
While the support of WebRTC is still a work in progress, to say the least (Safari being the most notorious offender of all major browsers), both WebRTC and the applications employing WebRTC have come a long way, to the point where for the most part our online communication feels as good as real-time with a decent frame rate and overall video/audio quality.
A vast majority of the applications employing WebRTC rely heavily upon an underlying API present in most modern-day browsers called “getUserMedia.” Here’s where we can draw a correlation-causation analogy. getUserMedia is used to fetch either the audio or video streams from the user’s microphone and camera. Since most WebRTC based applications rely on either voice or video or both, we can make an informed guess that an upward trend in microphone and camera use would imply an increased usage of WebRTC based products, too.
We can glance over the Chrome platform status; for this API (getUserMedia), you can see that the trend keeps going upwards! The slight downward trend can be attributed to the fact that offices started opening up – this isn’t necessarily indicative of the fact that WebRTC’s usage has gone down – remember, we are making a correlation-causation analogy here!
One can quickly realize that this leads to a central point of failure – if a malicious actor understands how to game the WebRTC protocol, they can essentially apply the same formula to most communication tools to overtake them. Since the pandemic caused in-person meetings to be a thing of the past, all talks, be it random jibber-jabber or highly secretive/sensitive business topics, happen over these applications. Security needs to be one of the top concerns of a software group deploying WebRTC.
What exactly would a company that relies heavily on WebRTC in their application want to achieve? Given the current state of WebRTC, there are three things to consider:
- Latency
- Security of communications
- Maintenance cost of infrastructure
Latency
To understand what affects latency, we need to know how WebRTC functions. The diagram below describes the handshaking and eventual secure communication between Peer A and Peer B.
A quick takeaway from looking at this picture is that Peer A and Peer B cannot somehow magically communicate with each other. WebRTC needs an intermediary infrastructure in place to somehow connect these two peers.
Suppose Peer A wishes to speak with B, then A generates something called an offer, and the task of the WebRTC protocol is to relay the offer to B. Hiding the underlying intricacies, Peer A’s “offer” includes information that can help Peer B link back to Peer A, the protocol facilitating this transfer is called Session Description Protocol & the act of exchanging the offer is managed by signaling methods which can either be SIP (Session Initiation Protocol) over a WebSocket or a JSON over WebSocket. Once this initial offer/answer combination is exchanged, ICE (Interactive Connectivity Establishment) swoops in and processes the inbound SDP (Session Description Protocol) to then determine the optimal path to connect through – here’s where STUN, TURN & Signalling servers come into the picture.
A STUN server is required by the party initiating the offer (in our case Peer A) to generate a list of ICE candidates. Once that’s done, using the signaling servers, we transmit the offer to the intended Peer (Peer B in our example).
Skipping a few steps ahead, Peer B would now employ the signaling servers again to send an answer to the offer generated by Peer A. Then, based on the answer, the two peers may begin communicating.
You might wonder how and why TURN servers never came into the picture in this entire description. And you’re right – TURN servers are a sort of fallback. In cases where your clients cannot generate a direct Peer-to-Peer connection, TURN (Traversal Using Relay NAT) servers come into the picture and facilitate your peers to connect to each other.
TURN is a must-have for any application that is heavily reliant on WebRTC since not all clients can have a P2P connection. However, these are notorious for introducing latency into your network.
An application like Subspace provides a managed solution to this problem. GlobalTURN is a way to achieve managed TURN servers providing the least latency! The graph below indicates the latency savings achieved when using Subspace instead of normal internet routing.
Think about it – you’d ideally have to figure out the best server pairing by investing development time behind this. Even after investing all this time, as your application expands and your user base grows, this data becomes irrelevant since users from different parts of the world start connecting. By eliminating the act of self-managing, you free up time that can be invested behind actual business logic and let a network experienced in managing these to the most optimal degree do it for you – ensuring your users get the best experience possible. Traffic bottlenecks are one of the significant sources of delay in RTC. GlobalTURN avoids this altogether, making even the TURN-based connections feel as if they were genuinely peer-to-peer.
Security
Building on top of what we’ve established so far – we can realize there are many points of failure in this entire communication channel, leaving the peers and subsequently the whole network-wide open to attacks.
A bunch of possibilities includes:
- Taking over the initial offer to forge the identity of a malicious actor as Peer A
- Taking over the STUN server(s) to make Peer A believe that the malicious actor is in fact Peer B
- Taking over the communication channel to listen to the actual data being transmitted between A and B
- Taking over the TURN servers and listening to the data being relayed via them.
The worst offender of all would be a Distributed Denial of Service (DDOS) attack on your infrastructure that would overload both the STUN and TURN servers, causing users to not connect in the first place.
Subspace comes to the rescue in this scenario too – providing solid security in every managed solution it provides (PacketAccelerator, GlobalTURN, or SIPTeleport). It does so by masking the IP Addresses of the peers involved by passing their messages through a proxy to prevent the malicious actors from tracing back packets to original machines.
Alongside this, it also performs packet analysis using anomaly detection algorithms to get a hold of unusual activity before it causes significant damage. Not to forget, all of this security generally would end up coming at a price – a price paid by latency, but since Subspace has optimized routing algorithms, the additional security doesn’t come with a majorly noticeable performance hit.
Subspace achieves this level of latency by providing optimization on all seven layers of the OSI model, i.e. from the physical infrastructure to the application layer.
Maintenance cost of infrastructure (TURN, STUN, etc)
All the servers mentioned above need to be configured during setup and need to be expanded as your organization needs increased capacity. As mentioned previously, figuring out the right balance & placement of these servers is quintessential to having a highly performant application; however, figuring out the balance is not easy.
With the use of PacketAccelerator, GlobalTURN & SIPTeleport you offload the work of upkeep away from your team and get the peace of mind that your application is running in the most optimized fashion possible.
SIPTeleport comes packed with proprietary algorithms to ensure the least packet drops, reducing the jittery/laggy feeling we often associate with low-quality RTCApplications. It helps in establishing the connections much faster, providing customers with instant access/responses.
PacketAccelerator provides enhancements in layers 3 and 4 of the TCP & UDP packet delivery phase, providing improvements of up to 80% reduced jitter & 99% reduced packet loss.
GlobalTURN, as described previously, provides a managed TURN solution without having to deal with the hassle of maintenance and acquiring personnel with the required networking knowledge. Global TURN essentially allows connecting to a single TURN IP address – simplifying and accelerating your ICE negotiations.
Subspace provides a managed solution for handling pretty much every communication need for a product that relies on real-time communications – be it scaling up in real-time or maintaining low latency while providing excellent security. A solution like Subspace alleviates the stress of managing these services, allowing your team to focus on your business logic!
Go to softwareengineeringdaily.com/subspace to learn more.