If you're writing an application that sends data over a network, you have an important choice to make. How will it communicate? In some cases you can - and probably should! - reuse an existing application-layer protocol like HTTP. But maybe you need something specialized to your needs.
In this case you'll be writing your own application-layer protocol. Your new protocol will build on either TCP, UDP or QUIC. Which one should you pick and why?
For a detailed look at the differences between the three protocols, you might want to watch this animated video:
What your best choice is depends on the nature of your application. Here are some important considerations.
- TCP and UDP are well-established protocols that are pretty mature. QUIC is a relatively new alternative to TCP that may outperform it, but its development is still ongoing.
- TCP and QUIC provide reliable data transfer. This means you can be reasonably sure that what you send comes out correctly on the receiver's end. UDP provides no such guarantees. Data may be delivered in a different order, parts of your message may get lost, or data may be delivered to your application in a corrupted state.
- UDP provides the lowest possible lag because it doesn't have to provide any reliability guarantees. TCP and QUIC negotiate a connection before sending data, and may delay sending new data as they await delivery confirmations from the receiver.
- Unlike TCP, UDP is able to support multicast and broadcast transmissions.
- QUIC provides encryption out of the box. For TCP connections you can use TLS 1.3 with some additional setup. UDP transmissions can use DTLS.
- If your application maintains open connections over a longer period, they may get disrupted when your users switch between WiFi, Ethernet and cell towers. QUIC has an edge here: its connection migration feature can handle those network switches.
Top comments (3)
QUIC isn't like TCP or UDP. Even though it is labeled as Transport Layer it is more between Transport Layer and Application Layer.
Effectively QUIC provides a TCP-like connection using UDP, where all packet handling is performed by the application, and not the network stack of an OS/router/etc.
In the OSI model QUIC would probably more fit in the Session layer.
Adding a new Transport Layer protocol is nearly impossible. It would take a really long time before it would be even usable in part of the world. Piggy backing on UDP, which is the most accessible Transport Layer protocol in an OS is the only way to hope for quick adoption.
What you're saying is valid, I just kept some of the details out of the article to make it more accessible.
I approached writing this from the point of view of an application developer, not a network engineer. I would argue that QUIC is like TCP and UDP in the sense that they're your three choices if you're building an application-layer protocol. I do think QUIC is similar to TCP in the sense that both offer reliable data transfer, and that QUIC is similar to UDP in the sense that it's UDP with reliable connection-oriented data transfer and other bells and whistles like built-in TLS on top.
From the point of view of a network engineer who's used to OSI's architecture model, this will indeed be an unconditional way to frame things. But I think it makes sense from the perspective of a layperson who doesn't necessarily need a nuanced view of the full protocol stack to make an online game.
A layperson making an online game, God bless that day!