Two ways to send data over the internet. TCP builds a reliable, ordered stream and resends anything lost; UDP just fires datagrams and accepts that some may never arrive. Here is the difference, side by side.
TCP and UDP are the two transport protocols of the internet. Both carry data between applications, but they make opposite promises. TCP promises that data arrives complete and in order; UDP promises nothing at all — it just sends.
Everything else follows from that choice. To keep its promise, TCP must open a connection, number and acknowledge every byte, and resend what is lost. To stay light, UDP skips all of it, which is why some applications still prefer it.
The difference is easiest to see as two panels: on one hand a numbered, acknowledged stream; on the other, independent datagrams with no replies. Laid out together, the trade-off between reliability and speed becomes obvious.
Before any data, TCP performs a handshake so both sides agree on starting sequence numbers. This extra step costs a round trip, but it is what lets the two ends track one continuous stream of data between them.
TCP breaks data into segments and numbers every byte. The receiver uses those numbers to put segments back in order and to spot gaps, and it sends acknowledgements back so the sender knows what has arrived.
If an acknowledgement does not come back, the sender assumes the segment was lost and retransmits it. To the application this looks like a clean, ordered stream — the retries and reordering are hidden underneath.
UDP has no handshake and no state. The sender simply addresses each datagram and transmits it. There is nothing to set up, so the first message can leave immediately, and the protocol itself is small and quick.
Because UDP never acknowledges anything, a datagram that is dropped along the way is simply gone, and neither side is told. Datagrams may also arrive out of order or be duplicated, so any reliability has to be added by the application.
Use TCP when correctness matters — web pages, files, email, anything where every byte must arrive. Use UDP when timeliness matters more — live voice and video, games, or one-shot lookups like DNS. The right choice depends on whether a late packet or a missing one hurts more.
When speed matters more than perfection and the application can tolerate or recover from loss: live video and voice, online games, streaming, and short request-response lookups such as DNS. A late packet is often worse than a missing one.
UDP itself provides no guarantee: datagrams can be lost, duplicated or arrive out of order, and it never tells you. That does not make it bad — it means any reliability has to be added by the application when it is needed.
A DNS lookup is usually one small question and one small answer. Setting up a connection first would add a round trip for little benefit, so the common case is a single datagram. If the answer is too large or a reply is lost, DNS can fall back to TCP.
Yes, by building it on top. Protocols such as QUIC add connection setup, acknowledgements and retransmission over UDP, gaining reliability without TCP's head-of-line blocking, which is why modern HTTP/3 uses it.
UDP usually has less overhead, since it skips connection setup and per-segment acknowledgements. But faster depends on the job: on a clean, reliable link TCP's extra work is cheap, and when TCP has to retransmit, UDP can appear to win.