UDP is unreliable. How can an application still get reliable delivery over it?
The application adds what it needs on top: sequence numbers to order and detect gaps, acknowledgements and retransmission for missing data, and timers. QUIC, used by HTTP/3, does exactly this over UDP, along with congestion control and encryption.
Explain it simply
If the postal service will not track parcels, you can number your own parcels and ask the receiver to confirm each number. If number 7 never gets confirmed, you send it again. That is reliability built by the sender, not by the post office.
Example
Sender Receiver
[seq=1, data] ---->
[seq=2, data] ----> (lost)
[seq=3, data] ---->
<---- ack 1, ack 3
timer expires for seq 2 -> resend [seq=2]
<---- ack 2Building this yourself needs: sequence numbers, ACKs, a retransmission timer, duplicate detection, and ideally congestion control so you do not flood the network. Real examples are QUIC (HTTP/3), WebRTC data channels, and old protocols like TFTP.
Why not just use TCP? TCP's reliability is bundled with strict ordering of the whole byte stream. Over UDP an app can choose per-stream reliability, so one lost packet need not block unrelated data, and updates can be rolled out without waiting for operating systems to change their TCP.
What to say in the interview
"You implement sequencing, acknowledgements, retransmission and congestion control in the application or a library. QUIC is the prominent example, giving per-stream reliability without TCP's head-of-line blocking across streams."
Common mistakes
- Forgetting congestion control. A home-made reliable protocol without it can harm the network.