What Really Happens When You Type a URL in Your Browser?

curiouswomen

20 min read

·

Oct 8, 2026

--

Listen

Share

A beginner-friendly journey through DNS, IP, TCP, TLS, HTTP, routing, load balancers, servers, and browser rendering

You type:

https://www.example.com/products/123

into Chrome and press Enter.

A second later, a webpage appears.

It feels almost instantaneous.

But here is the interesting question:

How does your browser know where www.example.com is? How does it know which server to contact? How does the request travel across the Internet? How does the server know that /products/123 means a particular page? And how does the response finally become the webpage you see?

This single question takes us through some of the most important concepts in computer networking:

• URL
• DNS
• IP addresses
• MAC addresses
• ARP
• DHCP
• Routers
• Switches
• Packets
• Ports
• TCP
• UDP
• TLS
• HTTPS
• HTTP
• HTTP methods
• HTTP headers
• Load balancers
• Reverse proxies
• CDNs
• Web servers
• Application servers
• Databases
• Cookies
• Caching
• Browser rendering
• HTTP/1.1
• HTTP/2
• HTTP/3
• QUIC

So let’s follow one request from your browser to the server and back.

1. First: What exactly did you type?

Suppose you enter:

https://www.example.com/products/123?color=red

This is a URL — Uniform Resource Locator.

We can break it down:

https://www.example.com/products/123?color=red
│       │                │          │
│       │                │          └── Query parameter
│       │                └───────────── Path
│       └────────────────────────────── Host/domain
└────────────────────────────────────── Protocol/scheme

More formally:

https://
www.example.com
/products/123
?color=red

Scheme

https

This tells the browser which protocol to use.

For a modern website, this is usually:

HTTPS

which means:

HTTP communication protected by TLS encryption.

Host

www.example.com

This is the human-readable name of the destination.

Computers don’t ultimately route packets using this name.

They need an IP address.

For example:

www.example.com
        ↓
93.184.216.34

DNS performs this translation.

Path

/products/123

This tells the web application which resource you are requesting.

For example:

/products/123

could mean:

“Give me product whose ID is 123.”

The important distinction is:

DNS helps you find the machine/network endpoint.

HTTP tells the application what resource you want.

We’ll come back to this distinction.

2. The Internet is not one giant computer

Before discussing DNS or HTTP, understand this fundamental idea:

The Internet is a network of networks.

Your laptop might be connected to:

Laptop
   ↓
Wi-Fi Router
   ↓
ISP
   ↓
Internet
   ↓
Destination network
   ↓
Server

The actual path can contain many routers and networks.

Your request is not normally one giant piece of data travelling directly from your laptop to the destination server.

It is divided into packets.

For example:

Your computer
     │
     ├── Packet 1 ────────────────┐
     ├── Packet 2 ────────────────┤
     ├── Packet 3 ────────────────┤
     └── Packet 4 ────────────────┘
                                   ↓
                              Internet
                                   ↓
                                Server

Packet switching is one of the fundamental ideas behind how the Internet operates. (Cloudflare)

3. But how does my laptop even get onto the network?

Suppose you’re connected to Wi-Fi.

Your laptop needs network configuration such as:

IP address
Subnet mask
Default gateway
DNS server

Typically, this information is provided using DHCP — Dynamic Host Configuration Protocol.

For example, your laptop might receive:

IP address:       192.168.1.20
Subnet mask:      255.255.255.0
Default gateway:  192.168.1.1
DNS server:       1.1.1.1

You don’t normally configure all of this manually.

Your home router can provide it automatically.

4. What is an IP address?

Think of an IP address as a network-level address.

Your laptop might have:

192.168.1.20

The server might have:

93.184.216.34

But there is an important distinction.

Your:

192.168.1.20

is a private IP address.

It is not directly routable across the public Internet.

Your router may have a public IP such as:

49.x.x.x

Your router performs NAT — Network Address Translation.

So the simplified picture is:

Laptop
192.168.1.20
     ↓
Home Router
Public IP
     ↓
Internet
     ↓
Destination

5. Now you press Enter

Let’s begin the actual journey.

You enter:

https://www.example.com/products/123

and press Enter.

The browser first needs to determine:

Where is www.example.com?

This is where DNS enters the story.

6. DNS — The Internet’s Phone Book

DNS stands for:

Domain Name System

Humans prefer:

google.com
amazon.com
example.com

Computers communicate using IP addresses:

142.250.x.x
...

DNS maps a hostname/domain name to an IP address. (Cloudflare)

Conceptually:

www.example.com
       ↓
      DNS
       ↓
93.184.216.34

Now the browser knows where to send traffic.

But DNS lookup itself is more interesting than this simple diagram suggests.

7. Where does DNS lookup happen?

Your browser doesn’t necessarily ask a DNS server every time.

There can be multiple layers of caching.

Conceptually:

Browser DNS cache
       ↓
Operating system DNS cache
       ↓
Local router/cache
       ↓
DNS Resolver
       ↓
DNS hierarchy
       ↓
Authoritative DNS server

If the answer is already cached, DNS resolution can be very fast.

For example:

Browser:
"Do I already know the IP for example.com?"

YES
 ↓
Use cached result

If not, the request may go to a recursive DNS resolver.

8. Recursive DNS Resolver

Your configured DNS resolver might be:

1.1.1.1

or:

8.8.8.8

or your ISP’s resolver.

The resolver’s job is to find the answer on your behalf.

Eventually it may query the DNS hierarchy.

A simplified version looks like:

Browser
   ↓
Recursive Resolver
   ↓
Root DNS
   ↓
.com DNS
   ↓
Authoritative DNS
   ↓
IP address

For example:

www.example.com
        ↓
93.184.216.34

The resolver caches the result according to DNS caching rules, so subsequent lookups may not need to repeat the entire process.

9. DNS doesn’t necessarily point directly to your application server

This is an important real-world concept.

You might imagine:

example.com
      ↓
Application Server

But modern architectures often look more like:

example.com
      ↓
DNS
      ↓
CDN / Edge / Reverse Proxy
      ↓
Load Balancer
      ↓
Application Servers

For example, a DNS record may point users toward a CDN or reverse-proxy network rather than directly exposing the origin server.

Cloudflare describes this kind of setup as using DNS together with a reverse proxy, where traffic can pass through its network before reaching the origin. (Cloudflare Docs)

This gives us another important concept:

DNS finds an address. It doesn’t decide which application method should execute.

10. DNS answered “where”, but we still haven’t communicated

Suppose DNS gives us:

93.184.216.34

Now the browser knows the destination IP.

But another question appears:

Which application on that machine should receive my request?

A server can run many applications.

For example:

Server
93.184.216.34

Port 22   → SSH
Port 80   → HTTP
Port 443  → HTTPS
Port 5432 → PostgreSQL

That’s where ports become important.

11. IP + Port

An IP address identifies a network endpoint.

A port identifies a service/application endpoint on that machine.

For HTTPS, the conventional port is:

443

So conceptually your browser wants to communicate with:

93.184.216.34:443

This is much more specific than:

93.184.216.34

You can think of it like:

IP address = Building address
Port       = Apartment/office number

12. Now comes TCP

For traditional HTTPS over TCP, before HTTP data can be exchanged, the client and server establish a TCP connection.

TCP stands for:

Transmission Control Protocol

TCP provides reliable, ordered delivery.

Suppose the browser sends:

A
B
C
D

TCP ensures the receiving application gets the byte stream correctly and handles retransmission when packets are lost.

13. TCP Three-Way Handshake

Before sending application data, TCP traditionally establishes the connection using a three-way handshake.

Simplified:

Client                         Server
  │                              │
  │ -------- SYN --------------> │
  │                              │
  │ <------- SYN + ACK --------- │
  │                              │
  │ -------- ACK --------------> │
  │                              │
  │       Connection ready       │

The three messages are:

SYN
SYN-ACK
ACK

Now the TCP connection exists.

14. But HTTPS needs encryption

TCP gives us reliable transport.

It does not by itself provide the encryption we want for HTTPS.

We don’t want this:

Browser ─────── "password=abc123" ───────> Server

to be readable by someone observing the network.

We need:

TLS — Transport Layer Security

15. TLS

TLS provides important security properties including:

Encryption

Someone intercepting traffic shouldn’t be able to read the protected application data.

Authentication

The browser can verify that the server’s identity corresponds to the certificate presented for the domain.

Integrity

Attackers shouldn’t be able to silently modify protected data without detection.

So the simplified HTTPS stack becomes:

HTTP
 ↓
TLS
 ↓
TCP
 ↓
IP
 ↓
Network interface

For modern web traffic, HTTPS means HTTP is protected by TLS. (MDN Web Docs)

16. TLS Handshake

The browser and server perform a TLS handshake.

A simplified view:

Browser                         Server
   │                               │
   │ ---- ClientHello -----------> │
   │                               │
   │ <---- ServerHello ----------- │
   │ <---- Certificate ----------- │
   │                               │
   │ ---- Key exchange ----------> │
   │                               │
   │ ===== Encrypted channel ===== │

The real TLS handshake is more sophisticated than this simplified diagram, and TLS 1.3 reduced the number of round trips compared with older TLS versions.

The important beginner concept is:

TCP establishes reliable transport; TLS establishes a secure cryptographic channel; HTTP communicates the application’s request.

17. Now we finally reach HTTP

This is where many beginners mix things up.

HTTP is not responsible for finding the server.

HTTP is an application-layer protocol used by the browser and server to communicate about resources.

MDN describes HTTP as a client-server protocol where the browser sends requests and the server sends responses. (MDN Web Docs)

Our browser can now send something conceptually like:

GET /products/123 HTTP/1.1
Host: www.example.com
Accept: text/html
User-Agent: Chrome

The actual wire representation differs for HTTP/2 and HTTP/3, but the conceptual semantics remain.

18. What does GET mean?

HTTP defines methods.

Common ones include:

GET
POST
PUT
PATCH
DELETE

For example:

GET /products/123

means approximately:

“Give me the representation of the resource identified by /products/123."

Whereas:

POST /orders

might mean:

“Create/process something using the data I’m sending.”

HTTP methods express the intended operation. (MDN Web Docs)

19. What is /products/123?

Now we reach an extremely important distinction.

You may think:

“The browser is requesting a folder called products and a file called 123.”

Not necessarily.

In modern applications:

/products/123

is usually a route handled by application code.

For example, a Spring Boot application might contain:

@GetMapping("/products/{id}")
public Product getProduct(@PathVariable Long id) {
    ...
}

When the request reaches the application:

GET /products/123

Spring may route it to:

getProduct(123)

The application could then query:

SELECT * FROM products WHERE id = 123;

and generate a response.

So:

The URL path doesn’t magically know which Java method to execute. The server-side application defines the routing rules.

20. How does the request physically reach the server?

This is where networking becomes fascinating.

Your HTTP request is inside TLS.

TLS data is transported through TCP.

TCP segments are carried using IP packets.

Conceptually:

HTTP request
     ↓
TLS encrypted data
     ↓
TCP segment
     ↓
IP packet
     ↓
Ethernet/Wi-Fi frame
     ↓
Physical transmission

Different networking layers add their own information.

21. The OSI / TCP-IP Layer Perspective

You don’t need to memorize the OSI model initially.

Instead, understand the responsibilities.

A simplified Internet stack:

Application
   │
   │ HTTP
   ▼
Transport
   │
   │ TCP / UDP
   ▼
Internet
   │
   │ IP
   ▼
Link
   │
   │ Ethernet / Wi-Fi
   ▼
Physical

For our traditional HTTPS example:

HTTP
 ↓
TLS
 ↓
TCP
 ↓
IP
 ↓
Wi-Fi/Ethernet

Each layer solves a different problem.

22. MAC Address vs IP Address

This is another common beginner confusion.

Suppose your laptop wants to send traffic to its local router.

It needs to deliver the frame to the router’s network interface.

That’s where MAC addresses matter.

An IP address is used at the IP/network layer.

A MAC address is associated with the local network interface/link layer.

You can roughly think:

IP address
=
Where is the destination in the network?

MAC address
=
Which local network interface should receive this frame?

23. ARP

For IPv4 local networks, ARP — Address Resolution Protocol can help map an IPv4 address to a MAC address.

Suppose:

Laptop:
192.168.1.20

Router:
192.168.1.1

The laptop needs the router’s MAC address.

It can ask:

Who has 192.168.1.1?

The router responds with its MAC address.

Then the laptop can construct the local Ethernet/Wi-Fi frame.

IPv6 uses Neighbor Discovery rather than ARP.

24. Your laptop cannot directly send an Ethernet frame across the entire Internet

This is important.

Your laptop’s Wi-Fi network only handles the local link.

So:

Laptop
   ↓
Home router

The router then forwards traffic toward the next network.

For example:

Laptop
  ↓
Home Router
  ↓
ISP Router
  ↓
ISP Network
  ↓
Internet Router
  ↓
Another Router
  ↓
Destination Network
  ↓
Server

There may be many hops.

25. How does a router know where to send the packet?

This is the job of IP routing.

Routers maintain routing information.

Conceptually:

Destination IP
      ↓
Routing table
      ↓
Next hop

For example, a router might know:

Destination network      Next hop
10.0.0.0/8               Router A
172.16.0.0/12            Router B
192.168.0.0/16            Router C
Everything else           ISP

The router examines the destination IP and chooses the appropriate next hop.

26. The Internet uses networks, not individual routing entries for every website

A router doesn’t need a giant rule saying:

google.com → router A
amazon.com → router B
netflix.com → router C

Instead, routing works with IP prefixes/networks.

Large-scale Internet routing uses BGP — Border Gateway Protocol between autonomous systems.

At a beginner level, think:

BGP helps networks on the Internet advertise which IP address ranges they can reach.

For example:

Network A says:

"I can reach this IP prefix."

Other networks learn this information and use it when deciding how to forward traffic.

27. Your packet may pass through many routers

Imagine:

Laptop
  ↓
Router 1
  ↓
Router 2
  ↓
Router 3
  ↓
Router 4
  ↓
CDN
  ↓
Server

Each router makes a forwarding decision.

The packet doesn’t carry a complete human-readable itinerary like:

Go through Router 1
then Router 2
then Router 3

Instead, each router independently forwards it toward the destination based on its routing information.

28. What about packet loss?

Networks aren’t perfect.

Packets can be:

• delayed
• duplicated
• reordered
• dropped

TCP handles reliability at the transport layer.

Suppose:

Packet 1 ✓
Packet 2 ✓
Packet 3 ✗
Packet 4 ✓

TCP can detect missing data and arrange retransmission.

That’s one reason TCP is called a reliable transport protocol.

29. What if the server has millions of users?

Now we reach real-world architecture.

A popular website usually isn’t:

Internet
   ↓
ONE SERVER

Instead:

┌── Server 1
                 │
Internet → Load Balancer ── Server 2
                 │
                 └── Server 3

The load balancer distributes incoming requests across multiple backend servers.

30. Reverse Proxy

There may also be a reverse proxy:

Client
  ↓
Reverse Proxy
  ↓
Application Server

Examples of technologies used for reverse proxy/load-balancing roles include:

• NGINX
• HAProxy
• Envoy
• cloud load balancers

A reverse proxy sits in front of backend servers and can forward requests, terminate TLS, cache content, enforce policies, and perform other functions.

31. CDN

Now suppose you are in Hyderabad and the application server is physically located in the United States.

Sending every static image from the US could introduce unnecessary latency.

A CDN — Content Delivery Network — can place cached content closer to users.

Conceptually:

User in India
      ↓
Nearby CDN edge
      ↓
Cached image

instead of:

User in India
      ↓
US origin server
      ↓
Image

CDNs use distributed servers to efficiently deliver Internet content and can improve performance and reliability. (Cloudflare)

32. CDN vs Application Server

Suppose you request:

GET /logo.png

The CDN might already have:

logo.png

cached.

Then:

Browser
  ↓
CDN
  ↓
Cache HIT
  ↓
Image

The origin application server doesn’t even need to process the request.

But for something dynamic like:

GET /my-account/orders

the request may need to reach the backend.

So:

Static content
→ CDN/cache

Dynamic content
→ Application

is a useful mental model.

33. Let’s say the request reaches our Spring Boot application

Eventually, the request may arrive at:

Spring Boot

Suppose we have:

@GetMapping("/products/{id}")
public Product getProduct(@PathVariable Long id) {
    return productService.getProduct(id);
}

The server receives:

GET /products/123

Spring’s routing mechanism finds the matching controller.

Then:

Controller
   ↓
Service
   ↓
Repository
   ↓
Database

For example:

ProductController
       ↓
ProductService
       ↓
ProductRepository
       ↓
PostgreSQL

34. Database

The application might execute something conceptually like:

SELECT *
FROM products
WHERE id = 123;

PostgreSQL finds the data.

For example:

id: 123
name: Laptop
price: 75000

The application converts that data into a response representation.

For an API, that might be JSON:

{
  "id": 123,
  "name": "Laptop",
  "price": 75000
}

For a traditional web page, the server might return HTML.

35. The server sends an HTTP response

For example:

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: ...

followed by the response body.

HTTP responses contain a status code, headers, and optionally a body. (MDN Web Docs)

Common status codes:

200 → Success
301 → Permanent redirect
302 → Temporary redirect
400 → Bad Request
401 → Unauthorized
403 → Forbidden
404 → Not Found
500 → Internal Server Error

36. But how does the response get back?

The reverse journey happens:

Server
  ↓
Router
  ↓
Internet
  ↓
ISP
  ↓
Home Router
  ↓
Laptop
  ↓
Browser

Packets arrive at your machine.

TCP reconstructs the byte stream.

TLS decrypts/verifies the protected data.

HTTP processing interprets the response.

The browser then processes the content.

37. The browser doesn’t just receive one HTML file

This is one of the most important concepts.

Suppose the server returns:

<html>
  <head>
    <link rel="stylesheet" href="/style.css">
  </head>

  <body>
    <img src="/logo.png">
    <script src="/app.js"></script>
  </body>
</html>

The browser now discovers additional resources:

HTML
 ├── style.css
 ├── logo.png
 └── app.js

So the browser makes additional HTTP requests.

MDN describes this behavior: the browser initially fetches the HTML and then requests resources such as CSS, JavaScript, images, and other subresources referenced by the document. (MDN Web Docs)

So loading a page can actually mean:

1 initial request
+
dozens/hundreds of additional requests

depending on the application.

38. This explains something important about browser URLs

Suppose you visit:

https://example.com/products/123

The browser doesn’t know what the product is.

It simply asks the server:

GET /products/123

The server/application defines what that route means.

It might return:

Product 123

or:

404 Not Found

or:

Redirect somewhere else

The browser doesn’t contain a magical database of every URL on the Internet.

39. Then how does clicking a link work?

Suppose the page contains:

<a href="/products/456">Product 456</a>

You click it.

The browser constructs:

https://example.com/products/456

and starts another navigation/request.

So:

Click link
   ↓
URL determined
   ↓
DNS may be needed
   ↓
Connection reused or established
   ↓
HTTP request
   ↓
Server routing
   ↓
HTTP response
   ↓
Browser renders

40. What if DNS is already cached?

This is where real networking differs from the simplified diagram.

You might think every page load does:

DNS
→ TCP
→ TLS
→ HTTP

Not necessarily.

The browser can reuse existing connections.

DNS answers can be cached.

TCP connections can be reused.

TLS sessions can sometimes be resumed.

HTTP/2 can multiplex multiple requests over one connection.

So the actual experience can be much faster.

41. HTTP/1.1 vs HTTP/2

HTTP has evolved.

HTTP/1.1

Conceptually:

TCP connection
   ↓
HTTP requests/responses

Persistent connections allow reuse.

HTTP/2

HTTP/2 introduced multiplexing.

Instead of requiring separate connections for many requests:

TCP connection
 ├── Request 1
 ├── Request 2
 ├── Request 3
 └── Request 4

multiple streams can share one connection.

This can improve efficiency when loading pages with many resources.

MDN notes that HTTP/2 moved beyond HTTP/1.1 pipelining by multiplexing messages within a connection. (MDN Web Docs)

42. HTTP/3 changes the transport story

HTTP/3 uses:

QUIC

instead of TCP as its transport foundation.

QUIC runs over UDP but provides reliable, secure transport features needed for HTTP.

So the simplified stacks become:

HTTP/1.1

HTTP
 ↓
TCP
 ↓
IP

HTTP/2

HTTP/2
 ↓
TLS
 ↓
TCP
 ↓
IP

HTTP/3

HTTP/3
 ↓
QUIC
 ↓
UDP
 ↓
IP

This is why you shouldn’t memorize:

“HTTP always uses TCP.”

That’s an oversimplification.

HTTP/1.1 and HTTP/2 commonly use TCP, while HTTP/3 uses QUIC over UDP.

43. Why UDP if TCP already exists?

UDP is much simpler as a transport protocol.

It doesn’t provide TCP’s exact connection and reliability mechanisms.

QUIC builds the required reliability, encryption, multiplexing, and connection-management features on top of UDP.

This allows HTTP/3 to avoid some limitations associated with TCP’s transport-level behavior.

You don’t need to understand QUIC deeply to understand your first web request.

Just remember:

HTTP = application protocol

TCP/QUIC = transportIP = network addressing/routing

44. Where does HTTPS fit?

A common beginner misunderstanding is:

“HTTPS is a completely different protocol from HTTP.”

A better mental model is:

HTTP
 +
TLS security
 =
HTTPS

More precisely, HTTPS means HTTP communication secured using TLS.

So:

HTTP
 ↓
TLS
 ↓
TCP

is a useful model for HTTP over TLS/TCP.

45. What does TLS protect?

Suppose you log in:

username=nandini
password=secret

With HTTPS, the application data is protected on the connection.

An attacker observing the network should not simply see:

password=secret

Instead they see encrypted traffic.

Conceptually:

Browser
   ↓
Encrypted bytes
   ↓
Internet
   ↓
Server
   ↓
Decryption
   ↓
HTTP/application data

This is why HTTPS is essential for modern web applications.

46. How does the browser know it is talking to the right server?

This is where certificates matter.

Suppose you visit:

https://bank.example

The server presents a TLS certificate.

The browser verifies important certificate information, including whether the certificate is valid for the requested hostname and whether it chains to a trusted certificate authority.

This helps prevent an attacker from simply pretending to be the destination website.

47. Cookies and Sessions

HTTP itself is fundamentally stateless.

That means one HTTP request doesn’t inherently remember the previous HTTP request.

But websites need state.

For example:

You log in

Then later:

GET /my-account

How does the server know you’re logged in?

One common mechanism is cookies.

The server might send:

Set-Cookie: sessionId=abc123

The browser stores it.

Later:

Cookie: sessionId=abc123

The server uses that identifier to associate the request with your session.

MDN notes that HTTP is stateless while cookies can provide stateful sessions. (MDN Web Docs)

48. Authentication with APIs

Modern applications frequently use tokens.

For example:

Authorization: Bearer eyJ...

The browser/application sends the token with a request.

The backend verifies it.

Then:

Request
   ↓
API Gateway
   ↓
Authentication
   ↓
Authorization
   ↓
Controller

This becomes especially important when discussing microservices and distributed systems.

49. API Gateway

A modern architecture might look like:

┌── User Service
                    │
Browser
   ↓
Internet
   ↓
CDN
   ↓
Load Balancer
   ↓
API Gateway
   ├── Product Service
   ├── Order Service
   ├── Payment Service
   └── User Service

Now /products/123 might be routed by an API gateway to:

Product Service

while:

/orders/456

might go to:

Order Service

This is application-level routing, not Internet routing.

That distinction is extremely important.

50. Internet Routing vs Application Routing

Let’s make this crystal clear.

There are two different meanings of “routing.”

Network routing

Routers decide:

Where should this IP packet go next?

Based on:

Destination IP

Application routing

Your web server decides:

Which application/controller should handle this HTTP request?

Based on things such as:

HTTP method
Host
Path
Headers

For example:

GET /products/123

might route to:

ProductController.getProduct(123)

These are completely different concepts.

51. Host-based routing

Suppose the same infrastructure serves:

api.example.com
www.example.com
admin.example.com

The HTTP request contains:

Host: api.example.com

A reverse proxy or load balancer can use the hostname to determine where to send the request.

For example:

api.example.com
      ↓
API servers

www.example.com
      ↓
Web serversadmin.example.com
      ↓
Admin application

This is another reason the URL matters beyond DNS.

52. What if the URL contains a port?

Suppose:

http://example.com:8080

The browser uses port:

8080

instead of the default HTTP port:

80

For HTTPS:

https://example.com

normally means:

port 443

So:

https://example.com

can conceptually become:

example.com
      ↓
DNS
      ↓
IP
      ↓
TCP/QUIC
      ↓
port 443
      ↓
HTTPS

53. Redirects

Suppose you type:

http://example.com

The server may respond:

301 Moved Permanently
Location: https://example.com

The browser then makes another request:

https://example.com

So one URL entered by the user can result in multiple network requests.

54. Caching

Your browser doesn’t always need to download everything again.

It may have cached resources.

For example:

style.css
logo.png
app.js

HTTP caching headers can tell the browser how long resources may be reused.

There are multiple caching layers:

Browser cache
      ↓
CDN cache
      ↓
Reverse proxy cache
      ↓
Application
      ↓
Database

Caching can dramatically reduce latency and server load.

55. The complete journey

Now let’s put everything together.

You enter:

https://www.example.com/products/123

Step 1 — Browser parses URL

Scheme: https
Host: www.example.com
Path: /products/123

Step 2 — Check caches

The browser/OS may already know the DNS answer.

Step 3 — DNS resolution

If needed:

www.example.com
        ↓
DNS
        ↓
IP address

DNS translates human-readable domain names into IP addresses used to locate network endpoints. (Cloudflare)

Step 4 — Determine destination

For HTTPS:

IP:443

Step 5 — Routing begins

Your machine sends traffic toward its default gateway.

Laptop
 ↓
Router
 ↓
ISP
 ↓
Internet

Step 6 — Packets travel

Routers forward packets toward the destination network.

Step 7 — TCP connection

For HTTP/1.1 or HTTP/2 over TCP:

SYN
SYN-ACK
ACK

Step 8 — TLS handshake

The browser and server establish a secure cryptographic connection.

Step 9 — HTTP request

Conceptually:

GET /products/123 HTTP/1.1
Host: www.example.com

Step 10 — CDN / reverse proxy / load balancer

The request may pass through:

CDN
 ↓
Reverse Proxy
 ↓
Load Balancer

Step 11 — Application routing

The backend sees:

GET /products/123

and routes it to the appropriate handler.

Step 12 — Business logic

For example:

Controller
 ↓
Service
 ↓
Repository
 ↓
Database

Step 13 — Response

Server returns:

200 OK

with HTML/JSON/etc.

Step 14 — Response travels back

Server
 ↓
Routers
 ↓
ISP
 ↓
Home Router
 ↓
Laptop

Step 15 — Browser processes the response

It parses HTML.

Then discovers:

CSS
JavaScript
Images
Fonts
APIs

and makes additional requests.

Step 16 — Browser renders

Eventually:

HTML
 ↓
DOM

CSS
 ↓
CSSOMDOM + CSSOM
 ↓
Render tree
 ↓
Layout
 ↓
Paint
 ↓
Composite
 ↓
Pixels on screen

And finally…

You see the webpage.

56. The entire architecture in one diagram

This is the diagram I recommend keeping in your notes:

USER
                           │
                           │
                           ▼
                     ┌───────────┐
                     │  Browser  │
                     └─────┬─────┘
                           │
                           │ URL
                           ▼
                     ┌───────────┐
                     │    DNS    │
                     └─────┬─────┘
                           │
                     IP Address
                           │
                           ▼
                    ┌─────────────┐
                    │    Router   │
                    └──────┬──────┘
                           │
                           ▼
                    ┌─────────────┐
                    │     ISP     │
                    └──────┬──────┘
                           │
                           ▼
                    ┌─────────────┐
                    │  Internet   │
                    │   Routers   │
                    └──────┬──────┘
                           │
                           ▼
                    ┌─────────────┐
                    │ CDN / Edge  │
                    └──────┬──────┘
                           │
                           ▼
                  ┌─────────────────┐
                  │ Reverse Proxy / │
                  │ Load Balancer   │
                  └────────┬────────┘
                           │
                           ▼
                  ┌─────────────────┐
                  │ Application     │
                  │ Server          │
                  └────────┬────────┘
                           │
                           ▼
                  ┌─────────────────┐
                  │ Business Logic  │
                  └────────┬────────┘
                           │
                           ▼
                  ┌─────────────────┐
                  │    Database     │
                  └─────────────────┘

And the communication stack underneath looks roughly like:

Application
    │
    │ HTTP
    ▼
Security
    │
    │ TLS
    ▼
Transport
    │
    │ TCP / QUIC
    ▼
Network
    │
    │ IP
    ▼
Link
    │
    │ Ethernet / Wi-Fi
    ▼
Physical network

57. The five questions you should ask when learning networking

Whenever you encounter a networking concept, ask:

1. Who am I talking to?

Usually answered through:

DNS → IP address

2. Which application am I talking to?

Usually:

IP + Port

3. How does the data reach that machine?

IP routing
Routers
BGP
Packets

4. How do we communicate?

HTTP

5. How do we protect the communication?

TLS

This gives you a very strong mental framework.

58. The most important distinction to remember

If you remember only one thing from this article, remember this:

URL
 ↓
DNS
 ↓
IP
 ↓
Routing
 ↓
TCP/QUIC
 ↓
TLS
 ↓
HTTP
 ↓
Application routing
 ↓
Business logic
 ↓
Database
 ↓
Response
 ↓
Browser rendering

But don’t treat these as one giant protocol.

They are different layers solving different problems.

59. One analogy to remember everything

Imagine ordering something from a huge company.

URL

You say:

“I want to visit example.com/products/123."

DNS

You ask:

“What’s the address of example.com?”

IP

You get:

“This is the network address.”

Port

You specify:

“I need the HTTPS service.”

Router

Each postal/network office asks:

“Where should I forward this next?”

TCP

You establish:

“Let’s make sure the conversation arrives reliably and in order.”

TLS

You say:

“Let’s encrypt our conversation and verify who we’re talking to.”

HTTP

You say:

“GET /products/123."

Load Balancer

The company says:

“Which available server should handle this request?”

Application

The application says:

“ /products/123 means fetch product 123."

Database

The database says:

“Here is product 123.”

HTTP Response

The server says:

“200 OK — here is your data.”

Browser

The browser says:

“I’ll turn this HTML/CSS/JavaScript into the webpage you can see.”

And that entire process happens incredibly quickly.

60. What you should learn next

If you’re learning backend development, don’t try to memorize all of networking at once.

Learn it in this order:

1. What is a network?
        ↓
2. IP addresses
        ↓
3. Private vs public IP
        ↓
4. MAC address + ARP
        ↓
5. DHCP
        ↓
6. DNS
        ↓
7. Ports
        ↓
8. TCP
        ↓
9. UDP
        ↓
10. TLS
        ↓
11. HTTP
        ↓
12. HTTP/1.1
        ↓
13. HTTP/2
        ↓
14. HTTP/3 + QUIC
        ↓
15. Reverse Proxy
        ↓
16. Load Balancer
        ↓
17. CDN
        ↓
18. API Gateway
        ↓
19. Caching
        ↓
20. WebSockets
        ↓
21. Distributed-system networking

Once you understand this sequence, topics like:

Spring Boot
REST APIs
Microservices
API Gateway
Kafka
Docker
Kubernetes
AWS
Load Balancing
Service Discovery
Distributed Systems

start making much more sense.

Final mental model

The next time someone asks you:

“What happens when you type a URL into your browser and press Enter?”

Don’t answer:

“DNS finds the IP and then HTTP request goes to the server.”

That’s correct, but incomplete.

A much stronger answer is:

The browser parses the URL and determines the scheme, hostname, port, path, and query parameters. It resolves the hostname through DNS, potentially using cached results. Once it has an IP address, the networking stack sends packets toward that destination through the local gateway and multiple routers. For HTTP over TCP, the client establishes a TCP connection and then performs a TLS handshake for HTTPS. The browser sends an HTTP request containing the method, path, headers, and possibly a body. The request may pass through a CDN, reverse proxy, and load balancer before reaching the application server. The server uses application-level routing to map the HTTP method and path to business logic, potentially querying a database. It returns an HTTP response, which travels back through the network. The browser receives the response, parses the HTML, fetches additional CSS, JavaScript, images, and other resources, and finally renders the page on the screen.

That answer demonstrates that you understand the entire request lifecycle rather than just memorizing DNS, TCP, and HTTP definitions.

And that is the real goal of learning networking.

References

The flow described above is consistent with the networking/web architecture documented by MDN and Cloudflare, particularly their explanations of DNS, HTTP, TCP/IP, packets, TLS, and browser navigation. (MDN Web Docs)

A good next article would be: “What exactly happens between DNS resolution and an HTTP request? — A deep dive into IP, MAC, ARP, routers, NAT, TCP three-way handshake, TLS 1.3, and packets.” That would let you take each layer above from beginner level to interview-level understanding.