UDP, A Disclaimer, And QUIC
The main justification for using UDP in a production application is latency. yet it seems like the culprits, and extreme lack of reliability in UDP, are not emphasized enough.
UDP is messy, it guarantees virtually nothing, and in many cases, requires the developer to implement subpar reliability mechanisms in the application level.
UDP Does not guarantee packets will arrive in order,
UDP Does not guarantee packets will arrive uncorrupted,
UDP Does not guarantee packets will even arrive.
TCP does, (mostly) guarantees all of the above, with the help of sequence numbers (ordering), checksums (data corruption), and ACKs (successful transmission).
A rarely known feature of TCP is that it implements congestion control, UDP doesn't.
Most TCP/IP stack implementations use a simple AIMD (additive increase/multiplicative decrease) algorithm, which in oversimplified terms, can be described as "every cycle, increase the bandwidth estimate by a constant, when a binary error flag is triggered (default flag is a packet loss) - reduce bandwidth estimate by a multiple (usually 0.5)
The above algorithm, while logically simple, makes network communication faster, and more reliable.
QUIC, UDP Done Right
QUIC is a newish protocol implemented on top of UDP, in user space.
QUIC's end goal is to replace TCP, it offers both encryption and authentication in-protocol, faster handshakes, and multiplexing.
The main bottleneck of QUIC is the lack of server-side / hardware offloads, which significantly hurts throughput.
Notes
- The article doesn't state UDP shouldn't be used, but more of a postmortem / note after observing and troubleshooting multiple high-impact bugs which stem from lack of network protocol understanding.
- TCP has other features, like flow control, which I didn't write about.
- TCP provides a stream of bytes, not a stream of packets.
- Cloudflare is a prominent developer and adopter of QUIC.