TCP vs UDP: which protocol and why it matters

TCP and UDP: Two Different Guarantees

HTTP runs on TCP. Understanding why — and when UDP is the better choice — shapes how you design networked systems.

TCP: reliability first

TCP is connection-oriented. Before any data moves, both sides perform the three-way handshake:

Client → Server: SYN          (I want to connect)
Server → Client: SYN-ACK      (OK, I hear you)
Client → Server: ACK          (Great, let's go)

After the handshake, TCP guarantees:

• Delivery — Lost packets are retransmitted automatically.
• Order — Packets arrive in the order they were sent.
• Flow control — Sender slows down if the receiver is overwhelmed.

UDP: speed first

UDP has no handshake, no acknowledgements, no ordering. You send a packet and hope it arrives. This sounds bad — but for real-time use cases it is exactly right:

• Video calls (a lost frame is better than a frozen one)
• DNS lookups (tiny payloads, one round trip)
• Online games (stale position data is useless anyway)

HTTP/3 uses QUIC, which is built on UDP but re-implements reliability at the application layer — getting the best of both worlds.

The core trade-off: TCP costs latency for reliability. UDP sacrifices reliability for latency. Match the protocol to what your application actually needs.