AiTechWorlds
AiTechWorlds
University learning companion
Computer Networks · TCP vs UDP: Reliability vs Speed
A student can open some websites but cannot join a video call. Follow the request through the network layers, name the evidence you would inspect at each boundary, and avoid blaming the whole network before locating the failing step.
Use this course-level map to place “TCP vs UDP: Reliability vs Speed” in the larger system. It complements—not replaces—a topic-specific worked diagram.
TCP is a certified letter. You hand it to the post office, they track it, they confirm delivery, and if it gets lost they resend it. You get a receipt. The recipient signs for it. It takes longer, but you know it arrived.
UDP is a flyer dropped from a plane. You print thousands, push them out the door, and hope they land where you intended. Fast, cheap, no tracking, no guarantee, no receipt. Some land in gardens. Some blow away. You do not know which.
Neither is better in absolute terms. The right choice depends entirely on what the application needs.
TCP is connection oriented, which means two parties must establish a connection before any data flows (the three way handshake). Once connected, TCP guarantees:
Reliability: Every segment sent is acknowledged. Missing segments are retransmitted.
Ordering: Segments carry sequence numbers. Even if they arrive out of order, TCP reassembles them correctly at the receiver.
Flow Control: The receiver advertises a window size how many bytes it can accept. The sender never floods a slow receiver.
Congestion Control: TCP monitors packet loss as a signal of network congestion and slows down when the network is struggling (algorithms: Slow Start, Congestion Avoidance, Fast Retransmit, Fast Recovery).
Error Detection: A checksum covers the header and data. Corrupted segments are discarded and retransmitted.
The cost of all this: overhead. TCP headers are 20–60 bytes. Each acknowledged exchange adds round trip latency. For latency sensitive applications, that cost is unacceptable.
UDP strips away everything TCP provides except the bare minimum needed to deliver a datagram to the right application on the right machine.
The entire UDP header is 8 bytes:
| Field | Size | Purpose |
|---|---|---|
| Source Port | 2 bytes | Sending application's port |
| Destination Port | 2 bytes | Receiving application's port |
| Length | 2 bytes | Total datagram size |
| Checksum | 2 bytes | Optional error detection |
No handshake. No acknowledgment. No sequence numbers. No retransmission. No flow control.
What you get: Minimal latency, minimal CPU overhead, minimal bandwidth waste. The application itself can implement only the reliability features it needs (some do; most do not).
Both TCP and UDP use port numbers to direct traffic to the correct application on a host.
| Range | Name | Purpose |
|---|---|---|
| 0 1023 | Well Known Ports | Reserved for standard services (HTTP, DNS, SSH) |
| 1024 49151 | Registered Ports | Assigned to specific applications by IANA |
| 49152 65535 | Ephemeral Ports | Dynamically assigned to client side connections |
| Port | Protocol | Service |
|---|---|---|
| 20, 21 | TCP | FTP (data, control) |
| 22 | TCP | SSH |
| 25 | TCP | SMTP (email sending) |
| 53 | UDP (and TCP) | DNS |
| 67, 68 | UDP | DHCP |
| 80 | TCP | HTTP |
| 110 | TCP | POP3 |
| 143 | TCP | IMAP |
| 443 | TCP | HTTPS |
| 161 | UDP | SNMP |
| 3306 | TCP | MySQL |
| 5432 | TCP | PostgreSQL |
This is the classic question. Surely reliability matters for a video call?
The answer: for real time media, latency is more important than perfection.
Consider a video call. If a packet carrying 20ms of audio arrives 500ms late (because TCP retransmitted it), inserting it into the stream causes a jarring stutter worse than the brief glitch from a dropped packet. Real time protocols prefer a small gap over a late arrival.
Applications like Zoom, Skype, YouTube Live, DNS, online games use UDP and implement their own strategies: forward error correction, jitter buffers, graceful quality degradation. They accept occasional imperfection to avoid unacceptable delay.
HTTP/3 (QUIC) also uses UDP as its base because QUIC implements its own, smarter reliability layer without TCP's head of line blocking.
| Feature | TCP | UDP |
|---|---|---|
| Connection model | Connection oriented | Connectionless |
| Reliability | Guaranteed delivery | Best effort |
| Ordering | Guaranteed in order | Not guaranteed |
| Retransmission | Yes | No |
| Header size | 20–60 bytes | 8 bytes |
| Flow control | Yes (window size) | No |
| Congestion control | Yes | No |
| Error checking | Checksum (mandatory) | Checksum (optional in IPv4) |
| Latency | Higher (handshake + ACKs) | Lower |
| Throughput | Lower under packet loss | Higher for continuous streams |
| Broadcast/Multicast support | No | Yes |
| Use cases | HTTP, email, file transfer | DNS, video, VoIP, games |
When developers write network applications, they choose between:
SOCK_STREAM (TCP)
socket(AF_INET, SOCK_STREAM, 0)SOCK_DGRAM (UDP)
socket(AF_INET, SOCK_DGRAM, 0)The socket type determines which transport protocol the OS uses for that application.
Ask three questions:
Does lost data invalidate the result?
Is latency more important than completeness?
Can the application tolerate or handle loss itself?
Most internet traffic is TCP. Most real time and latency sensitive traffic is UDP. Understanding why is the foundation of network application design.
University learning companion
Computer Networks · TCP vs UDP: Reliability vs Speed
Complete the steps without looking at the answer first; record evidence rather than only a final result.
These are primary or established learning references for this subject. Check the relevant chapter or specification for the exact topic and version.
Get this course's notes on Telegram!
Free cheat sheets, summaries & practice exercises