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

Brahma Nanda — Wed, 09 Sep 2026 19:13:24 +0000

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.

What DNS server chain gets queried, and why caching at each layer (browser, OS, ISP) matters for speed.

Brahma Nanda — Wed, 09 Sep 2026 19:06:38 +0000

When a browser needs to resolve a domain name, it first checks the browser's DNS cache. If the address is not cached, the operating system's DNS cache is checked. If the OS does not have the answer, the request is sent to a recursive DNS resolver, often provided by the ISP.

If the recursive resolver does not have the answer cached, it queries the DNS hierarchy: the root DNS servers, then the appropriate TLD server (such as .com), and finally the domain's authoritative nameserver. The authoritative nameserver provides the DNS record, such as the IP address.

Caching at the browser, OS, and recursive DNS resolver reduces the number of DNS queries that need to travel through this hierarchy. This makes DNS resolution faster and reduces network traffic.

DEV Community: Brahma Nanda

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

What DNS server chain gets queried, and why caching at each layer (browser, OS, ISP) matters for speed.