What is the difference between TCP and UDP?
TCP is connection-based and reliable, with ordering, retransmission and flow control, so it suits web pages, email and file transfer. UDP just sends datagrams with no guarantees, so it is faster and lighter and suits video calls, games, DNS and live streaming.
Explain it simply
TCP is like a registered post parcel: the post office confirms delivery, resends it if it is lost and makes sure the pages arrive in order. UDP is like shouting across a playground: very fast, but if someone misses a word, you do not repeat it. For a video call, a missed word is fine because the next sentence is more important than repeating the old one.
Example
| Feature | TCP | UDP |
|---|---|---|
| Connection | Three-way handshake first | No handshake |
| Reliability | Lost packets are resent | Lost packets are gone |
| Order | Delivered in order | May arrive out of order |
| Speed | Slower, more overhead | Faster, less overhead |
| Header size | 20 to 60 bytes | 8 bytes |
| Flow and congestion control | Yes | No |
| Used for | HTTP/1 and HTTP/2, email, SSH, file transfer | DNS, video calls, online games, live streams, QUIC |
How it works
TCP numbers every byte with a sequence number. The receiver sends acknowledgements (ACKs). If an ACK does not arrive in time, the sender retransmits. A sliding window controls how much data can be in flight so a fast sender does not flood a slow receiver (flow control), and congestion control algorithms slow the sender down when the network is busy. A connection starts with SYN, SYN-ACK, ACK and ends with FIN messages.
UDP only adds source port, destination port, length and checksum to the data, and sends it. If the application needs reliability, it builds its own on top, which is exactly what QUIC (used by HTTP/3) does.
Real-world use
When you open a website, your browser mostly uses TCP because every byte of HTML must be correct. When you join a Google Meet or play BGMI, the audio, video and game positions travel over UDP because late data is useless. DNS uses UDP for quick small queries and falls back to TCP for large answers.
Common mistakes
- Saying "UDP is unreliable so it is bad". It is a trade-off, not a weakness.
- Saying TCP guarantees delivery no matter what. It guarantees delivery or an error; it cannot beat a cut cable.
- Thinking HTTP is always TCP. HTTP/3 runs over QUIC, which runs over UDP.
What to say in the interview
"TCP is connection-oriented. It does a handshake, numbers bytes, acknowledges them, resends lost data and keeps order, plus flow and congestion control. That makes it reliable but adds latency. UDP is connectionless: it sends independent datagrams with an 8-byte header and no guarantees, so it has lower latency. I would choose TCP for web pages, APIs and file transfer, and UDP for real-time audio, video, gaming and DNS, where speed matters more than a lost packet."
Follow-up questions
- Walk me through the TCP three-way handshake.
- What is head-of-line blocking?
- Why did HTTP/3 move to QUIC over UDP?
- How does TCP congestion control react to packet loss?
Go deeper
Read these once the basics above feel easy.
TIME_WAIT keeps a closed connection's port reserved briefly so late packets do not confuse a new connection. Nagle's algorithm batches small writes, which can hurt interactive apps, so they set TCP_NODELAY.
Compare congestion algorithms like Reno, CUBIC and BBR, discuss SYN flood attacks and SYN cookies, and explain how QUIC puts connection IDs in packets so a phone can move from Wi-Fi to mobile data without dropping the connection.