Topic 6.4
TCP vs UDP
In one line
Reliable ordered streams vs fast lossy datagrams — and why video/real-time apps pick the lossy one.
Think of it like this
A phone call vs a walkie-talkie. A phone call (TCP) confirms every word got through and repeats anything missed. A walkie-talkie (UDP) just blasts the message out fast — if a bit gets lost in static, nobody stops to resend it. That's fine for a live video call where a missed frame doesn't matter as much as speed.
Key ideas
- 01
TCP: connection-oriented, ordered, retransmits, flow control, congestion control. Cost: handshake, head-of-line blocking.
- 02
UDP: connectionless datagrams, no retransmit, no ordering — lowest overhead; apps rebuild reliability on top.
- 03
Three-way handshake: SYN → SYN-ACK → ACK (and why connection pooling saves it).
- 04
Head-of-line blocking: one lost TCP segment stalls every later segment — agonizing for real-time games/video.
- 05
QUIC (HTTP/3) runs over UDP + its own reliability — the modern compromise.
- 06
Interview: 'DNS over UDP, video over UDP, JSON APIs over TCP'.
Java / Spring map
- →
java.net.Socket/SocketChannel (TCP); DatagramSocket (UDP); NIO selectors for many sockets.
Code & diagrams
Why TCP has a 'cost' before the first byte even moves, and UDP doesn't.
Explain without notes
Why does WebRTC prefer UDP even though it can lose frames?
Practice
List 5 protocols/apps for TCP and 5 for UDP and defend each choice.
Trade-offs
- ↔
TCP's reliability IS its latency problem; UDP's speed IS its reliability problem. No free lunch.
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Completion checklist
I can explain why the same payload behaves differently over TCP vs UDP.