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.