TCP and UDP are the two ways data actually moves across the internet. Both sit on top of IP (which just gets packets from A to B). In simple language — TCP is the careful courier that guarantees delivery, UDP is the guy who throws the package over the fence and hopes for the best.
TCP — reliable and ordered
TCP (Transmission Control Protocol) is connection-oriented. Before any data moves, both sides shake hands and set up a connection. Then TCP promises three things:
- Reliable — every packet is acknowledged; lost ones get retransmitted.
- Ordered — packets are reassembled in the exact order they were sent, even if they arrive scrambled.
- Error-checked — corrupted packets are caught and resent.
The cost of all this bookkeeping is overhead and latency. But when we can’t afford to lose a byte, TCP is the answer.
UDP — fast and fire-and-forget
UDP (User Datagram Protocol) is connectionless. No handshake, no acknowledgements, no reordering. We just fling datagrams at the destination and move on.
That means UDP is lean and fast, but it makes no guarantees — packets can arrive out of order, duplicated, or not at all. If that matters, the application has to handle it itself.
Think of it like this: TCP is a registered letter with tracking and a signature. UDP is a postcard — cheap, quick, and if it gets lost, oh well.
When to use which
The rule of thumb: does losing data break things, or does waiting for it break things?
- Use TCP when every byte matters — web pages (HTTP), database connections, file transfers, emails. A missing chunk of a JSON response is useless.
- Use UDP when speed beats completeness — live video, voice calls, online gaming, DNS lookups. In a video call, a dropped frame from 200ms ago is worthless; we’d rather skip it and stay live than pause to re-fetch it.
Fun fact: HTTP/3 runs on UDP (via QUIC) and rebuilds reliability itself on top — getting UDP’s speed without giving up ordering. DNS uses UDP for quick lookups but falls back to TCP for large responses.
The 3-way handshake
This is how TCP opens a connection. Three packets, and interviewers love it.
SYN → SYN-ACK → ACK. After those three packets, both sides have agreed on starting sequence numbers and the pipe is live. (Closing is a separate 4-way FIN/ACK dance.) UDP does none of this — it just starts sending, which is exactly why it’s faster.
Ports & sockets
An IP address gets us to the right machine. A port gets us to the right program on that machine. One server can run a web server on 443, a database on 5432, and SSH on 22 all at once — the port number keeps the traffic sorted.
Well-known ports worth remembering: 80 (HTTP), 443 (HTTPS), 22 (SSH), 53 (DNS), 5432 (Postgres), 6379 (Redis), 3306 (MySQL).
A socket is the actual connection endpoint — the full combo of IP + port + protocol. A unique TCP connection is identified by four things: source IP, source port, destination IP, destination port. That’s why one server on port 443 can hold thousands of simultaneous connections — each client’s source IP/port makes the tuple unique.
# see what's listening on which ports
lsof -i -P -n | grep LISTEN
# curl an explicit port
curl http://localhost:5432Interview soundbite
TCP is connection-oriented, reliable, and ordered — it does a SYN/SYN-ACK/ACK handshake and retransmits lost packets, so we use it for HTTP, databases, and file transfer. UDP is connectionless and fire-and-forget with no guarantees, so it’s faster — great for video, VoIP, DNS, and gaming where being late is worse than being lossy. A port identifies which program on a host gets the traffic; a socket is the IP+port endpoint, and a TCP connection is uniquely keyed by the source/destination IP+port tuple.