Networking · intermediate
TCP vs UDP
TCP provides applications with an ordered, reliable byte stream between connected endpoints and includes flow and congestion control. UDP sends individual datagrams with preserved message boundaries but does not itself guarantee delivery, ordering, duplicate suppression, or congestion control.
Why it matters
Protocol choice changes framing, latency, failure handling, and what reliability an application must provide. It also prevents misleading diagnoses such as expecting a UDP service to appear in TCP listener output.
Mental model
How to reason about tcp vs udp
TCP turns network packets into a continuous stream and repairs loss before exposing later bytes in order. UDP exposes each received datagram independently, leaving any recovery, ordering, and pacing strategy to the application protocol.
Analogy
TCP is a checked, numbered conveyor that delivers one continuous sequence in order; UDP is a set of separately addressed postcards whose boundaries remain visible but whose arrival is not promised by the postal method itself.
Examples
See the boundary, not just the happy path
Worked example · Open a TCP connection
nc example.com 80A typical netcat invocation creates a TCP byte stream. The application must provide its own message syntax, such as an HTTP request followed by the required line endings.
Worked example · Send one UDP datagram
printf 'probe' | nc -u -w 1 192.0.2.1 9999With common netcat variants, -u sends UDP. Finishing without an error does not prove a receiver processed the datagram, because UDP has no connection handshake or delivery acknowledgment.
Useful contrast · Reliable protocols can run over UDP
HTTP/3 uses QUIC over UDPUDP's minimal service does not prohibit an application protocol from implementing reliable delivery, encryption, and congestion control above it. Reliability is a property of the whole protocol stack, not the UDP label alone.
Common mistakes
Misconceptions to remove early
Treating one TCP write as one received message
TCP preserves byte order, not application write boundaries. A receiver can read a write in pieces or combine bytes from several writes, so the application needs explicit framing.
Calling UDP inherently fast and TCP inherently slow
UDP has less built-in machinery, but application requirements, network conditions, connection reuse, QUIC, retransmissions, and implementation quality determine observed performance.
Quick check
Can you predict the result?
1. Which boundary does TCP preserve for an application?
- • Byte order, but not the boundaries of individual writes.
- • Every application's write call as a separate message.
- • IP packet boundaries exactly as sent.
2. Why can a reliable application protocol still use UDP?
Keep building