A crucial part of WebRTC is exchanging media streams (and arbitrary data) between two or more nodes. How do we transport such data? This is where networking becomes crucial. While this post doesn’t pretend to be an extensive lesson about networking, we will look at some of the basic knowledge for understanding communication flow on WebRTC projects.
Your Online Purchase Just Came In: Introducing The Delivery “Network”
E-commerce and delivery platforms are a norm in today’s lifestyle. You can get almost anything you can think of right to your front door with just a couple of clicks (and a credit card). This is thanks to a complex delivery system that is behind the scenes taking care of planning, routing and finally delivering your package.
One of the core features of a network is that it provides the ability to deliver data to other nodes in the network. Think of the delivery system mentioned above as a big network. Our houses, delivery companies and shops are the nodes that belong to it. The roads are the wires that connect everything.
The main goal of a WebRTC application is to deliver media content (and arbitrary data, too) in real time. Let’s work through this analogy to better understand the flow of data between all the involved components.
Can You Deliver a Couch on a Bike? Meet Protocols and Ports
The inner details of how something can be delivered varies according to the characteristics of the package. While this is mostly transparent to us as consumers, it’s important when it comes to understanding how delivery works in terms of a network.
Depending on the nature of a package, it may be delivered by our friend Mr. Jones the postman on his bike, or by Larry the trucker on his truck. Delivery companies have a set of rules and guidelines about when, how and where a package will be delivered. For instance, having Larry truck over a letter is overkill. And you can’t definitely deliver a couch on a bike.
In the same way, it might not be a good idea for Mr. Jones to ride his bike on the highway. He might prefer to travel through a different channel. He’ll be safer in the city’s bike lane.
In networking, we have protocols and ports. In simple terms, a protocol defines the rules and guidelines to deliver a packet in the network. You can think of a port as the virtual channel where packets are transmitted. Ports and protocols are usually associated.
The internet is probably the most popular outcome of networking. Take a look at the address bar of your web browser. Click it a couple of times to show the whole string and you’ll notice an https prefix before the actual address.
Such a prefix is the protocol used to deliver the website you’re currently looking at, to your web browser. HTTPS is the secure version of HyperText Transfer Protocol (HTTP), which is the protocol used for web pages, in the same way that a bike is used for delivering letters and a truck for couches.
If the webpage were a letter, then the HTTP protocol is the set or rules that dictates how it should be delivered across the network (in our analogy by friendly Mr. Jones on his bike) and how web browsers consume it (in a mailbox.)
The HTTPS protocol is associated with the port 443 (yes, ports are expressed as numerical values.) This is the channel used to deliver web related packets. Ports are exposed at the server level.
Delivering Worldwide: Enter LAN, WAN and NAT
Getting back to our delivery analogy, let’s talk about the implications of delivering a package in your local community vs somewhere far away.
When shopping close to home, you can use a local address that makes sense in the context of your community. You can probably ask a local store to deliver your package to the “little house on the prairie.” Since both you and the store are in the same area, the delivery person can easily find it and deliver your package.
However, when you and the store are in different cities or even different countries, the local address will make no sense. Instead you need a public address that can help the store identify where the package needs to be delivered.
The latter scenario doesn’t necessarily require the package to travel directly from the store to your house. The store can send the package to a local delivery company near you, and then they can deliver the package. Because this local entity will know the area better, they can translate the public address provided to the store to a local one similar to the one in the first case.
One thing that should be considered is that this local entity can perform some security controls on the package it receives. Sometimes they can even deny the package if they consider that it can be dangerous for the community.
In networking, a Local Area Network (LAN) refers to a set of nodes that are connected to each other in the same physical location. Similar to delivering packages in the same city, they can connect to each other using a local address. This is known as an IP address. It is a set of numbers that are assigned to each node’s network interface.
A Wide Area Network (WAN) is a collection of LANs that connect to each other. Since local IP addresses only make sense within the same network, for two nodes in two different LANs to connect each other through a WAN, a public address is required instead.
A public IP address enables a packet to travel from one LAN to another. To know exactly where it needs to go, it uses a similar approach to the one mentioned above about using a local delivery company. In this case, it’s a device that performs Network Address Translation (NAT).
Simply put, NAT is about translating public addresses into local ones. This is usually performed by a Firewall. In our delivering analogy, the firewall is the local delivery company. Similar to what we discussed there, the firewall can perform security controls and either allow or deny a packet if it’s considered harmful.
This deny/allow behavior is defined through firewall policies which are usually based on ports and protocols. Firewall administrators define which type of traffic is allowed on which ports and which protocols. Any traffic outside of this definition is denied.
An Old-Fashioned Love Story: Sending packets through TCP vs UDP
For the last part of this post, we will look at a couple of modern Romeo and Juliets that, despite all the technology available, prefer to keep in touch using letters. Because of the enmity between their families, they want to be sure that each letter is actually delivered. For the conversation to make sense, each one needs to be delivered in order.
To do this they have made an agreement with the post office so the latter perform extra checks with each letter they deliver. If a letter is confiscated by the family, the postman needs to go back and ask the sender to send it back. This makes the process a bit slower, but guarantees that both lovers are able to communicate.
Alternatively, they could ask the post office to deliver the letters without signature or any other extra check. This will speed up the process, but won’t guarantee the delivery nor the order in which the letters are delivered. In the context of letters, the conversation won’t make sense if they are unordered.
They could simply send each other gifts and leave the conversation for their occasional secret encounters. In this case it wouldn’t matter the order of delivery. If at least some of the packets arrive, it will be enough to keep the fire of love turned on.
In networking, something similar happens with the transportation of data packets. The two main ways to deliver a packet are using Transmission Control Protocol (TCP) and User Datagram Protocol (UDP).
The difference between the two is that TCP is focused on delivery and UDP on speed. TCP will perform additional checks that guarantee that a packet is correctly transmitted following the right order. This makes TCP reliable, but a bit slower. UDP doesn’t perform any checks. Packets are delivered more quickly, but there is a risk that some packets are lost or are delivered late.
As with the above analogy, there are use cases where one will make sense over the other. In the context of real-time communication, speed is preferred over reliability. WebRTC supports both transport protocols, but UDP should be your first choice for the aforementioned reason.
In Summary
In this first post in our Networking series, we gave a quick overview of some of the most important networking concepts that you need to understand when working on a WebRTC project. You learned that data travels through networks following a specific set of rules (protocols) that depend on the type of packet. Packets also travel through different “ports” that are associated with the protocols.
You also learned that there are local networks (LAN) where each node has a local address. They can connect with nodes on a different LAN – forming a big wide network (WAN) – using public address. But in order to reach each other, we must use a translation process to convert a public address into a local one (NAT).
In the next post, we will start looking at the different protocols that are involved in WebRTC applications.
Are you ready to incorporate WebRTC into your application? Contact the experts at WebRTC.ventures!
Posts in this series:
