Choosing, and meeting QUIC

Two questions sort most applications. If a message is lost, does the program need it back? And if a newer message has arrived, is the older one worth anything? An application where the newest value replaces the old one has little use for repair. An application where every byte must arrive, in order, wants the network to do the repair for it.

Where the usual ones sit

DNS is a small question and a small answer on port 53, and the program asks again if nothing comes, so it normally uses UDP. A reply too big for a UDP message sets a flag and the client asks again over TCP, and a DNS server has to support both. NTP is UDP on port 123. mDNS is UDP on port 5353, multicast to 224.0.0.251 on the local network.

HTTP on port 80, HTTPS on 443 and MQTT on 1883 and 8883 use TCP, as does WebSocket: a page or a message that arrives with a hole in it is no use. Live pixel streams such as sACN and WLED's realtime mode use UDP, and DDP is normally sent that way too, because a frame that arrives late is no use, so nobody resends it. That is a design reason and not a rule of the protocol.

Where they do not

That list is a tendency. The same job gets done both ways: DNS uses both, a live score can sit on a TCP connection when every update matters, and a game can send UDP and add its own numbers and its own acknowledgements for just the messages that matter. UDP leaves that choice to the application. It is the reason the answer is never "UDP for speed, TCP for important data". Speed comes from the network.

QUIC

QUIC, published as RFC 9000 in May 2021 after beginning at Google, is not just UDP. Its packets are carried in UDP datagrams, and on top of them QUIC does its own work: several streams in one connection, loss recovery and congestion control of its own, and the TLS 1.3 handshake built in. A gap in one stream does not stop the others, where a gap in a TCP stream holds back every byte behind it. HTTP/3, RFC 9114 of June 2022, runs on QUIC, on port 443 over UDP, while HTTPS on 443 over TCP carries on.

Whether QUIC is quicker than TCP on a given network is a measurement, not a property of the design.

What it costs

Choosing UDP means writing the repair yourself or living without it. Choosing TCP means accepting that one late segment holds everything behind it. Neither is right for every job. MQTT on the ESP32 and the mDNS and NTP page show one of each.

Common mistakes

• Choosing UDP because it is faster. It leaves out the waiting and the repair, and the network is as fast as it was.
• Assuming DNS is only UDP. Large answers and zone transfers use TCP, and servers must support it.
• Calling QUIC "UDP with extras". It is a transport of its own, carried in UDP datagrams.