UDP vs TCP
Compare UDP and TCP: protocols, use cases, reliability vs speed trade-offs.
What are TCP and UDP?
Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) are transport-layer protocols that carry application data between network endpoints identified by IP addresses and ports. TCP exposes a reliable, ordered byte stream with connection state, flow control, and congestion control. UDP exposes independent best-effort datagrams with a small fixed header and no built-in delivery, ordering, or pacing contract.
The choice matters because responsibility moves between layers. TCP can recover missing stream bytes, but it cannot define application messages or prove a payment committed. UDP preserves message boundaries, but the application must decide what loss, reordering, duplication, expiry, congestion, and retries mean.
The core invariant is the application must state the delivery value of its data before choosing a transport. Complete bytes, latest state, live media, commands, and replicated events need different recovery behavior.
Choose from application semantics, not protocol slogans
Files, database streams
Complete ordered data
Every byte matters and later bytes cannot be interpreted before missing earlier bytes. A reliable ordered stream is a natural fit.
Position, sensors, live media
Timely replaceable state
New state may supersede old state. Sequence numbers and expiry can be more useful than retransmitting stale payloads.
Payments, mutations
Business commands
Transport success does not prove one business effect. Use message IDs, authorization, idempotency, durable state, and reconciliation.
Move reliability, latency, and state to the right layer
Choose application semantics first, then compare TCP and UDP under the same path. The model is an explanatory envelope, not a packet-level throughput predictor.
Semantic fit
TCP matches the selected delivery value
Complete ordered data needs retransmission and framing. TCP supplies transport recovery; UDP would require the application to rebuild it.
4167/s
40-byte IP plus transport header
3.2%
Excludes link and security headers
391 KiB
Bandwidth-delay product per saturated path
375 MiB
Illustrative transport state across peers
Loss consequence
Packets affected
20.8/s
Recovered by retransmission when possible
Recovery delay
~120 ms
Illustrative head-of-line delay, not an exact predictor
Congestion duty
Transport
Both designs must avoid overwhelming the path
The calculator is an explanatory envelope. Real throughput depends on operating-system buffers, congestion algorithm, security, packet pacing, path variation, middleboxes, implementation, and competing flows.
Follow TCP from connection to close
1 SYN
Establish connection state
The client and server exchange initial sequence state through the three-way handshake. TLS or another application-security handshake may add more round trips.
2 Sequence
Send a byte stream
TCP numbers bytes, acknowledges received ranges, retransmits missing data, and exposes ordered bytes rather than original write boundaries.
3 Flow control
Respect receiver capacity
The advertised receive window limits in-flight data so a fast sender does not overrun one receiver's buffers.
4 Congestion control
Respect path capacity
The sender adapts its congestion window and pacing to loss, delay, and acknowledgements so one connection does not assume the network is infinite.
5 FIN or reset
Close each direction
A graceful half-close lets each direction finish independently; reset and timeout paths can leave the application uncertain about remote processing.
Size the path window
Bandwidth-delay product estimates how many bytes must be in flight to fill a path. A 1 Gbit/s path with 100 ms RTT holds roughly 12.5 MB in flight. Socket buffers and window scaling must support the required envelope, but excessive buffers can add queueing delay.
Treat UDP as a primitive, not a complete protocol
UDP preserves datagram boundaries and avoids connection establishment in the transport layer. It does not promise that a datagram arrives, arrives once, arrives before later datagrams, fits through the path, or is accepted by the application.
Build only the semantics the workload needs
- Add sequence numbers when receivers must reject stale or reordered state.
- Add IDs and bounded deduplication when duplicates would change an outcome.
- Add selective acknowledgement and retransmission only for data still valuable after one RTT.
- Add expiry for media or state that becomes useless while queued.
- Pace traffic and respond to congestion; UDP is not permission to overwhelm the network.
- Authenticate and encrypt the application protocol, including replay protection where required.
Keep datagrams below the effective path MTU. IP fragmentation makes one datagram depend on every fragment and is frequently fragile across tunnels, firewalls, NAT, and heterogeneous paths.
Inject delivery failures against real data meaning
Loading delivery lab
Preparing packet incidents...
Separate three guarantees
- Transport: byte or datagram movement, connection state, order, flow, and congestion behavior.
- Application protocol: message framing, sequence, acknowledgement, retry, expiry, and deduplication.
- Business operation: authorization, idempotency, transaction commit, external side effects, and reconciliation.
TCP can deliver the same application request again after a client retry. UDP can carry a perfectly idempotent command. Exactly-once business effects require durable application state, not a transport label.
Frame messages on a TCP stream
One call to send does not map to one call to recv. The network stack can split one write, combine multiple writes, or return any currently available byte prefix. Define framing with a fixed size, delimiter, length prefix, or self-describing format, and enforce maximum lengths before allocation.
Defend the stream parser
- Bound frame length, nesting, decompression, and per-connection buffered bytes.
- Apply read, idle, write, and total request deadlines separately.
- Handle half-close, reset, partial frame, duplicate application request, and slow-reader behavior.
- Use TLS for peer authentication, confidentiality, and integrity where the threat model requires it.
Sequence latest-state UDP updates
For replaceable state, keep the highest accepted sequence per source and discard stale or duplicate updates. Define wraparound, source restart, authentication, expiry, and bounded state cleanup before production.
This pattern is not suitable for non-idempotent commands by itself. A charge, booking, or inventory mutation needs an authenticated logical operation ID and durable deduplication at the business boundary.
Account for middleboxes and abuse
NAT and state
Idle mappings expire, addresses change, and inbound UDP may require discovery or relay. Reconnect and rebinding must preserve identity safely.
Amplification
Spoofable UDP requests can reflect larger responses. Authenticate reachability, limit amplification, rate-limit, and avoid unauthenticated expensive work.
Resource exhaustion
TCP connections consume queues, buffers, descriptors, and application state. Bound handshake, idle, and per-peer resources.
Encryption
Use TLS over TCP or a proven secure protocol over UDP. Encryption does not replace authorization, framing, replay protection, or input validation.
Operate from transport and application evidence
Monitor TCP
- Connection attempts, handshake failure, resets, closes, idle age, descriptors, accept queue, and per-peer limits
- RTT distribution, retransmission, duplicate acknowledgements, congestion window, receive window, zero-window events, and buffer pressure
- Message parse failure, partial frames, request deadlines, response completion, application retries, and idempotency outcomes
Monitor UDP
- Datagrams and bytes by source, loss inferred from sequence gaps, reordering, duplication, jitter, and expiry
- Socket receive drops, kernel buffers, MTU and fragmentation signals, NAT rebinding, relay use, and path changes
- Application acknowledgements, retries, deduplication state, pacing, congestion response, and business outcomes
Test the path
- Inject delay, jitter, loss, duplication, reordering, corruption, fragmentation, black holes, and asymmetric connectivity.
- Test mobile handoff, NAT expiry, firewall policy, load balancer behavior, peer restart, process pause, and rolling deployment.
- Verify that retries stay bounded and cannot duplicate external effects.
Choose TCP or UDP only after defining which data must arrive, how late is too late, what may be replaced, and which correctness guarantees belong above the transport.