Every packet sent over the internet is wrapped in either TCP or UDP (well, almost). The choice depends entirely on the application. Do you need every byte to arrive perfectly (Email), or do you need the data to arrive instantly even if some is lost (Video Call)?
TCP (Reliable)
- Connection Oriented: Handshake required.
- Ordered: Packets 1, 2, 3 arrive as 1, 2, 3. If 2 is lost, TCP re-requests it.
- Heavy: Large header (20 bytes min).
- Use Cases: HTTP (Web), SMTP (Email), FTP (Files), SSH.
UDP (Fast)
- Connectionless: Fire and forget. No handshake.
- Unordered: Packets arrive whenever. If one is lost, it's gone forever.
- Lightweight: Small header (8 bytes).
- Use Cases: DNS, VoIP (Skype), Online Gaming, Streaming.
1. The Headers (Under the Microscope)
You can tell a lot about efficiency by looking at the overhead.
TCP Header (Complex)
Includes: Source Port, Destination Port, Sequence Number, Acknowledgment Number, Header Length, Flags (SYN, ACK, FIN), Window Size, Checksum, Urgent Pointer.
UDP Header (Simple)
Includes: Source Port, Destination Port, Length, Checksum.
That's it. It effectively says "This is for Port 53. Good luck."
2. Why Gamers use UDP
In a shooter game (CS:GO), 60 packets are sent per second describing player positions.
If Packet #30 is dropped (lost in the network):
TCP would: Pause the game. Ask the server "Please resend #30". Wait. Receive #30. Then show #31, #32. Result: Lag/Stutter.
UDP does: Ignore it. Packet #30 is old news. Show Packet #31 immediately. Result: Smooth movement with a tiny microscopic glitch.
3. QUIC (HTTP/3): The best of both worlds?
Google developed QUIC (Quick UDP Internet Connections). It is now standardized as HTTP/3.
It runs on top of UDP (for speed) but implements reliability and congestion control in the application layer (instead of the kernel).
It solves TCP's "Head-of-Line Blocking" problem, making the web significantly faster on unreliable mobile networks.