User Datagram Protocol (UDP)
To understand UDP, we need to understand what a Datagram is. It is a self independent data carrying entity which has sufficient information of source and destination nodes and can travel to destination without any information of the previous nodes it travelled from. Packets are used in terms of reliable transfer of data whereas datagram is used for unreliable form of data, which has no guarantees of delivery. Which lead to the name UDP “unreliable datagram protocol”.
As TCP and UDP are layers above IP. Let’s talk a little about IP. IP layer’s main purpose is to encapsulate message within its source ip, destination ip and other parameters. IP doesn’t take care about reliable delivery, failure handling, retransmission and other mechanism build for data integrity. TCP adds all these layers above it from data integrity(for more information read my other blog). But in case of UDP, It just adds 4 more fields source port, destination port , length of the packet and checksum. In which 2 parameters source port and checksum are optional. As checksum is part of IP encapsulation, TCP checksum is optional.
So UDP has no ACK, no retransmission, no in-order stuffs, no head of line blocking, no connection establishment, no congestion flow/control. Which makes UDP stateless. Whatever you need above this is implemented by the application. UDP datagram are read as full messages at a time. It is the smallest independent unit of data transfer.
Out of Context
Because of the above aspects of UDP, QUIC is a protocol build over it. Which does all the things that TCP does but using UDP and in a different way so that it does not have constraints like head of line blocking etc and multiplexing is easier. This is used in HTTP 3, which is gaining popularity in recent time. We will talk about this in my later blogs.
This is it for UDP but then NAT came into picture. Which changed everything. NAT (Network Address Translator) is a way to basically save public IPs from exhausting and create a local network which is provided with a NAT instance. So when a call goes out of the local network it uses NAT public IP to address the call over Internet. Now as datagrams are stateless it doesn’t have any mechanism for connection establishment. Because of this, a call going from a machine in a LAN to the internet can easily send data but what about receiving data. It cannot receive it as the public IP used is of the NAT server. It cannot know from which local machine the call came from. Even if we maintain state(IP and port of the call) in our NAT instance for UDP, we don’t have any connection termination or connection keep alive mechanism for UDP so NAT doesn’t know when to delete the entry.
STUN
Due to above problem STUN (Session Traversal Utilities for NAT) protocol came into existence and STUN servers are required to keep the public IP and PORT of the receiver(NAT) in the public network/Internet. You need to configure STUN servers in your application which uses DNS discovery to find the server and then get the public IP and port of the destination peer. Now when the call travels it makes an entry in the NAT entries table and reaches the destination. If the destination is also inside a NAT, it would have already gone through the STUN mechanism and have an entry in its own NAT. So before the data transfer starts using their public IP and PORT, the entires in their NAT instance is already established using STUN. STUN protocol also has a simple keep alive mechanism to refresh timeouts for the entries in NAT.
TURN
STUN is sometimes not enough for data transfer to start. In those cases TURN(Traversal using relays around NAT) protocol which uses relay servers as a fallback and can even switch to TCP if everything fails. TURN depends on a reliable public relay server. So when the connection starts it basically calls the same TURN server which handles negotiation and when it is completes data transfer can start. But this is not peer to peer as a relay server is involved. And it might get under a lot of load when multiple data flows start. So, this is a last resort for data communication.
So to manage all the above aspects of UDP ICE(Interactive Connectivity Establishment) protocol was established which does all the above out of box.
However you need a proper mechanism like TCP to setup a custom way using UDP in your application. Which lead to the invention of WebRTC. We are skipping WebRTC for later blogs.
Conclusion
UDP is meant for audio/video communication across peers. If 3–4 video/audio frames are lost it doesn’t effect too much which is called Jitters. Sometimes jitters are too much which means either STUN servers are not working properly or it has gone to TURN mechanisms and relay servers are hit by lot of peers. Scaling this system out is another challenge itself. So please don’t shout on your OTT provider when you miss a wicket or a goal watching a live broadcast. Ask them to scale there systems based on region/viewers, maybe add more STUN servers. If this doesn’t serve us them go for http based video delivery after the video/audio frame reaches your region. Scaling STUN servers is more important as they might introduce jitters into the data stream. Which will anyway be streamed by the http servers, as once added cannot be reframed(maybe use AI based restoration of frames).
Keep Learning!!
Reference :