skip to content

What are the core differences between TCP and UDP, and which kinds of workload call for each one?

level: juniorimportance: must knowfreq 82%

answer

  1. connection versus no connection
  2. what happens when a packet is lost
  3. stream versus independent datagrams
  4. every byte matters vs newest matters

basics

~20 s

TCP is a connection-oriented, reliable, ordered byte stream with flow and congestion control; UDP sends independent datagrams with no handshake, retransmission or ordering. Choose TCP when every byte must arrive in order, UDP when latency or statelessness matters more.

solid answer

~40 s

TCP opens a connection with a three-way handshake, numbers every byte, retransmits what is lost, hands bytes to the application in order, and runs flow control (the receiver's window) and congestion control (the sender's congestion window). UDP, defined in RFC 768, adds only ports, a length and a checksum to IP: no handshake, no retransmission, no ordering, no duplicate protection and no congestion control, though each datagram's boundaries are preserved. Its header is 8 bytes against TCP's 20-byte minimum. TCP fits web traffic, APIs, file transfer and database sessions, where every byte matters. UDP fits short request/response lookups such as DNS, broadcast discovery such as DHCP, time sync such as NTP, and real-time voice, video and game state, where a late packet is worthless. QUIC also builds its own transport on UDP.

go deeper

for a junior

Recall the contract on each side: TCP gives a connection, reliable in-order delivery and congestion control; UDP gives none of these. Have one workload ready for each.

for a middle

Explain what each TCP guarantee costs: the handshake round trip, per-connection state, waiting on a lost segment. Tie each UDP workload to what should happen on loss.

for a senior

Show that the choice follows from the loss policy the application needs, and that UDP applications rebuild selective reliability and congestion control themselves.

for a principal

Frame transport choice as a platform decision: when a team should reuse TCP or QUIC rather than own a custom UDP protocol, and what that ownership costs over years.

## Two different contracts on top of IP TCP and UDP both sit on top of **IP**, which delivers individual packets between hosts on a best-effort basis: packets can be lost, duplicated, reordered or delayed. A **transport protocol** decides what the application sees on top of that. TCP (specified in RFC 9293, which obsoleted RFC 793) and UDP (RFC 768) make opposite choices. | Property | TCP | UDP | |---|---|---| | Connection | Three-way handshake before data is delivered; per-connection state at both ends | None; each datagram stands alone | | Lost data | Retransmitted by the sender | Not retransmitted | | Ordering | Bytes handed to the application in order | Datagrams handed over as they arrive | | Duplicates | Discarded using sequence numbers | Not detected | | What the application reads | A byte stream with no message boundaries | Whole datagrams, boundaries preserved | | Flow control | The receiver advertises a window | None | | Congestion control | Built in (RFC 5681) | None; the application's job (RFC 8085) | | Header | 20 bytes minimum | 8 bytes | | Delivery modes | Unicast only | Unicast, broadcast and multicast | RFC 768 describes UDP as **transaction oriented** and states plainly that "delivery and duplicate protection are not guaranteed". Everything UDP adds to IP is a pair of ports, a length and a checksum. ## What TCP pays for its guarantees - **A handshake.** SYN, SYN-ACK, ACK. Data may ride on a SYN, but the receiver holds it until the connection reaches `ESTABLISHED`, so a fresh connection costs one round trip before the first request is usable. - **State.** Each side keeps a **Transmission Control Block (TCB)** per connection: addresses, ports, sequence numbers and window variables. A server with a million concurrent connections holds a million of them. - **Waiting.** Because bytes are delivered strictly in order, one lost segment holds back everything behind it until its retransmission arrives. This is **transport head-of-line blocking**. - **Rate adaptation.** Congestion control slows the sender when it sees loss. That protects the network but can hurt an application that cares about latency more than throughput. UDP pays none of these costs and offers none of these guarantees. Neither is better in general; they answer different questions. ## Matching the protocol to the workload The useful question is not "which is faster?" but "**what should happen when a packet is lost?**" If the answer is "wait for it, every byte matters", TCP already does that well. If the answer is "ask again", "skip it" or "the next packet makes it irrelevant", UDP lets the application decide. | Workload | Usual transport | Reason | |---|---|---| | Web pages, APIs, file transfer, database sessions | TCP | Every byte must arrive, in order; a round trip of setup is negligible | | DNS queries | UDP, with TCP also supported | One small question, one small answer; the client simply retries | | DHCP | UDP | The client has no address yet and must broadcast; TCP is unicast only | | NTP | UDP | Small timestamp exchanges; a delayed retransmission is a worse sample than the next poll | | Voice and video calls, fast-paced games | UDP | A late packet is worthless; the application would rather skip it | | QUIC, the transport under HTTP/3 | UDP | It builds its own reliability and congestion control on top | ## Two framings interviewers push back on 1. **"UDP is faster."** On the wire, the saving is 12 bytes of header at minimum. What UDP really removes is the handshake round trip and the wait for retransmissions. That is decisive for a one-packet lookup or a live audio stream and nearly irrelevant for a large transfer, where RFC 8085 notes that TCP's capacity probing quickly compensates for the setup delay. 2. **"UDP is unreliable, so it is for unimportant data."** DNS is critical infrastructure and runs mostly over UDP. Reliability is not abandoned; it moves into the application, which rebuilds exactly as much as it needs. A DNS client retransmits a lost query. A game ignores a lost position update because a newer one is already on its way. ## How to structure the answer - Start with the contract: connection, reliability, ordering, flow and congestion control on one side; none of those on the other. - Give at least one workload for each and tie the reason to what happens on loss. - Close with the nuance that UDP-based protocols usually rebuild **selective** reliability, and that QUIC is the modern example of a complete transport built on UDP.

  • If UDP gives no delivery guarantee, how does a DNS client cope with a lost query?
    It retransmits. RFC 1035 says queries sent over UDP may be lost, so a retransmission strategy is required, and it recommends trying other servers or server addresses before repeating a query to the same one. Reliability is rebuilt in the application with a simple timer, which is far cheaper for one question and one answer than setting up and tearing down a TCP connection.
  • Why does TCP's handshake matter more for a DNS lookup than for downloading a large file?
    The handshake costs one round trip before the first request can be delivered. A DNS lookup over UDP completes in one round trip; over a fresh TCP connection it needs two, so the setup doubles its latency. A large download spans many round trips, and RFC 8085 notes that TCP's capacity probing quickly compensates for the setup delay once more than a few segments are exchanged.

saying these in an interview costs you the question

  • UDP is always faster than TCP, so use it for anything performance-sensitive
  • UDP delivers every datagram as long as the network is not congested
  • TCP preserves the boundaries of each write the sender makes
  • UDP is unreliable, so nothing important should ever run on it
  • The TCP application must reorder segments that arrive out of order