Transport Example: DNS, a Video Call and a Database Query

Three applications, three answers to "what if a packet is late", and the transport each one uses.

The choice between TCP and UDP depends on what a late or lost packet costs the application. Three common workloads give three different answers, and the transport each uses follows from that answer.

Three applications, the cost of a late packet, and the transport each uses
Application	What a late packet costs	Transport
DNS lookup	Little; the client asks again after a short timeout	UDP, with TCP for large answers
Video call	The moment has passed; a late frame is useless	UDP
Database query	The result is wrong without it	TCP

Three things are worth noticing.

DNS uses both, for a reason. A typical query and answer each fit in one datagram, so UDP answers in one round trip with no handshake. When an answer is too large for the size the two ends agreed on, the server sends a shortened reply with a "truncated" flag set, and the client asks again over TCP, on the same port 53. Transfers of whole zones between DNS servers always use TCP.

The video call accepts loss on purpose. It sends 30 or more frames a second, and the software hides a missing one by repeating or blending the last. Waiting for a resend would freeze the picture for longer than the gap it fills. The application handles what matters to it, such as lowering the quality when loss climbs.

The database cannot accept loss at all. A query result with a missing row is a wrong answer, not a degraded one, so the database protocol runs over TCP and lets it retransmit. The delay of a retransmission is a cost the application is glad to pay.

← → move through sections and cards