Why TCP (not UDP) is used for HTTP — what would break with UDP.

Why TCP was traditionally used for HTTP
Imagine your browser requests:

GET /index.html

and the server sends:

The Internet can lose packets, duplicate them, or deliver them out of order.

TCP handles this for HTTP:

So HTTP can essentially say:

"Give me a reliable stream of bytes."

What would happen with plain UDP?
UDP does not guarantee delivery or ordering.

For example:

The browser might receive:

Packet 1
Packet 3
Packet 4

but Packet 2 is missing.

UDP itself doesn't say:

"Hey, Packet 2 was lost. Please send it again."

Similarly, packets could arrive:

1 → 3 → 2 → 4

instead of:

1 → 2 → 3 → 4

UDP doesn't fix that either.

So what would break?
Without adding another reliability mechanism, HTTP could receive incomplete or incorrectly ordered data.

For example, imagine downloading:

Hello World

If pieces arrive missing or out of order, the application has to figure out:

What was lost?
What order should the data be in?
Should it request the missing data again?
How fast should it send data?
How should it handle network congestion?
TCP already solves these problems.

Then why does HTTP/3 use UDP? 🤔
This is the interesting part.

HTTP/3 uses:

HTTP/3
↓
QUIC
↓
UDP
↓
Internet

QUIC uses UDP as a base transport, but QUIC itself provides things TCP normally provides, such as reliable delivery, ordering where needed, congestion control, and encryption integration.

So it's not:

HTTP → UDP → "hope nothing gets lost" 😅

It's:

HTTP/3
↓
QUIC ← reliability + security + transport features
↓
UDP

Easy exam/interview answer
TCP was traditionally used for HTTP because HTTP needs reliable, ordered delivery of data. UDP doesn't guarantee delivery, ordering, or retransmission, so using plain UDP would require HTTP or another protocol to implement those mechanisms itself. Modern HTTP/3 solves this differently by using QUIC over UDP.