What happen when…

When we browse the Internet, a simple action like typing a web address into a browser might seem trivial. However, behind the scenes, it triggers a complex orchestration of technical processes, involving numerous components and protocols.

So, what really happens when you type https://www.google.com and hit Enter?

This article aims to demystify that seemingly simple action by walking through each critical step of the process — from DNS resolution to secure HTTPS connection, through the firewall, load balancer, web server, application server, and finally the database.

Whether you’re a student, a developer, or simply curious, this journey behind the scenes of the web will give you a clearer understanding of the infrastructure that powers our everyday digital experience.

What is DNS?

When you type an address like www.google.com into your browser, it cannot use that name directly.
Why? Because computers don’t understand names like “google.com”. They need a numerical IP address, like 142.250.74.36, to know where to connect on the network.

The DNS (Domain Name System) acts like a global phone book for the Internet.
It translates human-readable domain names into IP addresses that machines can understand and use to communicate.

DNS Resolution — Step by Step

DNS resolution works like a chain of requests — each server points to the next, until the answer is found.
Here’s what happens when your browser looks for www.google.com:

1. Recursive DNS Resolver

Your device starts by asking a local DNS resolver (often provided by your OS or ISP):

“What is the IP address of www.google.com?”

This resolver takes care of the entire lookup process by contacting other servers on your behalf.

2. Root Server

The resolver first queries a root server, which knows where to find all the top-level domains like .com, .org, .net, etc.

The root server replies:

“I don’t know google.com, but I can point you to the .com name servers.”

3. TLD Server (Top-Level Domain)

The resolver then contacts the TLD server responsible for .com and asks about google.com.

It replies:

“Ask the authoritative name servers for google.com.”

4. Authoritative Name Server

Finally, the resolver contacts the authoritative DNS server for Google’s domain.

This server responds:

“The IP address for www.google.com is 142.250.74.36.”

The browser can now initiate the connection to that IP address.

DNS Record Types

DNS servers don’t just return raw numbers — they return DNS records.
Each record type serves a specific function:

For visiting a website, an A (IPv4) or AAAA (IPv6) record is most commonly used.

DNS Cache

Once a domain has been resolved, the result is stored temporarily in a DNS cache, either on your device or by your DNS provider.
This allows faster browsing on repeated visits to the same site.

The cache duration is defined by a TTL (Time To Live) value.
Once the TTL expires, the lookup is repeated. This process is known as DNS propagation, and it is especially important when a domain’s IP address changes.

DNS Lookup Tools (Terminal)

You can inspect DNS records manually using common command-line tools.

1. dig

Command:

dig www.google.com

Typical output:

;; ANSWER SECTION:
www.google.com.  300  IN  A  142.250.74.36

A powerful tool to inspect DNS resolution and query paths.

2. nslookup

Command:

nslookup www.google.com

Typical output:

Server:  8.8.8.8
Address: 8.8.8.8#53

Non-authoritative answer:
Name:    www.google.com
Address: 142.250.74.36

Easy to use and beginner-friendly, but less detailed than dig.

3. host

host www.google.com

Typical output:

www.google.com has address 142.250.74.36

A lightweight and fast utility for quick lookups.

What is the TCP/IP stack?

When your browser knows the IP address of a website (e.g., 142.250.74.36), it cannot just send data directly.
It must follow a set of rules and steps of communication. This is the role of the TCP/IP stack.

The TCP/IP stack is a layered architecture. Each layer has a specific role and works with the others to transport information reliably.

The HTTP protocol runs on top of TCP, which in turn relies on IP.

Quick reminder: the OSI model

Before going further, it is useful to recall the OSI model (Open Systems Interconnection).
It is a theoretical 7-layer model, designed to explain how data travels from point A to point B across a network.

The OSI model is mainly educational, while the TCP/IP stack used in practice has only 4 layers:
Application — Transport — Internet — Network Access

Public vs Private IP

An IP address is a unique identifier on a network.
However, not all IP addresses are accessible from the Internet.

Public IP

• Visible on the Internet
• Assigned by your ISP or cloud provider
• Example: 152.145.88.32

Private IP

• Used only within local networks
• Not routable on the Internet
• Examples:
• 192.168.x.x
• 10.x.x.x
• 172.16.x.x to 172.31.x.x

If your computer has a private IP, your router will handle communication with the outside world using a mechanism called NAT.

NAT (Network Address Translation) and Routing

NAT is an address translation system used by routers to allow local machines (private IPs) to communicate with the outside (public IPs).

Example:

1. Your computer sends a request:

• Source: 192.168.1.24
• Destination: 142.250.74.36

2. The NAT router rewrites the source:

• New source: 84.198.32.7 (public IP of the router)

3. The server replies to 84.198.32.7

4. The router redirects internally to 192.168.1.24

Result: the remote server never sees your private address, but the response still reaches you.

TCP — The “3-way handshake”

The TCP (Transmission Control Protocol) ensures a reliable connection between two machines.
To establish communication, TCP uses a 3-step sequence called the 3-way handshake:

Once this process is complete, both parties can exchange data reliably.

TCP Ports

Every Internet service listens on a specific port.
A port acts like a logical entry point on a machine.

Example: Google’s web servers listen on port 443 (HTTPS). The client will use an ephemeral port, e.g., 49721.

IPv4, IPv6, MTU, Fragmentation

IPv4

• 32-bit address (4 bytes)
• Example: 192.168.0.1
• Limit: about 4.3 billion addresses
• Problem: exhaustion → solutions: NAT + IPv6

IPv6

• 128-bit address
• Example: 2001:0db8:85a3::8a2e:0370:7334
• Much larger address space
• Security features built-in via IPSec

MTU — Maximum Transmission Unit

Every network technology has a maximum packet size called the MTU.
Example: Ethernet has an MTU of 1500 bytes.

If a packet is larger than the MTU, it will be fragmented (split into smaller pieces).

Useful Shell Commands for TCP/IP

ping

ping www.google.com

Tests connectivity and measures round-trip time (in ms).

traceroute (or tracert on Windows)

traceroute www.google.com

Displays each hop between you and the destination.

tcpdump

sudo tcpdump -i any port 443

Captures network packets on port 443 (HTTPS).

netstat

netstat -tunlp

• t: TCP
• u: UDP
• n: numeric addresses
• l: listening sockets
• p: associated program

ss

ss -tuna

Modern tool to display active TCP/UDP connections.

What is a firewall?

A firewall is a network traffic filtering system.
It acts like a gatekeeper, positioned between a private network (such as a server or a machine) and the outside (the Internet or another network).

It can be:

• Hardware-based (a physical device placed between two network segments),
• or Software-based (built into the operating system, such as iptables or ufw).

Its main role is to inspect every packet of data that enters or leaves, and decide whether it should be allowed or blocked.

How a firewall works: IP, ports, protocols

A firewall can filter traffic based on several criteria:

This means it operates at multiple levels of the TCP/IP stack.

Inbound vs Outbound rules (IN vs OUT)

Firewall rules are usually defined in two directions:

• Inbound (IN): controls traffic coming into the machine
• Outbound (OUT): controls traffic going out of the machine

Stateful mode

Most modern firewalls are stateful, which means they remember the state of a connection.

Example:

• You send an HTTPS request (outbound)
• The firewall allows the outgoing request
• When the response comes back (inbound), the firewall automatically allows it, because it belongs to an existing, tracked connection

Without this feature, you would have to write explicit rules for every single return packet, which would be unmanageable.

Demilitarized Zones (DMZ)

A DMZ (Demilitarized Zone) is an intermediate zone between the Internet and a private network.
It allows exposing certain services without compromising the internal network.

Typically, a DMZ contains:

• a web server accessible to the public
• a proxy server or an SSH bastion
• any other service that must be reachable from the outside

Typical structure:

[ Internet ] ⇄ [ Firewall ] ⇄ [ DMZ ] ⇄ [ Internal firewall ] ⇄ [ Private network ]

Shell commands for managing firewalls

ufw – Uncomplicated Firewall (Ubuntu/Debian)

Enable:

sudo ufw enable

Allow HTTPS port (443):

sudo ufw allow 443

List rules:

sudo ufw status numbered

Simple, quick, and suited for basic needs.

iptables – Historical low-level tool

Allow HTTPS (port 443 TCP inbound):

sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT

Block a port:

sudo iptables -A INPUT -p tcp --dport 23 -j DROP

Very powerful but with a complex syntax. Rules are lost on reboot unless iptables-persistent is used.

firewalld – Modern tool (RHEL, CentOS, Fedora…)

List allowed services:

sudo firewall-cmd --list-all

Add HTTP to the public zone:

sudo firewall-cmd --zone=public --add-service=http --permanent

Apply changes:

sudo firewall-cmd --reload

nftables – Modern successor to iptables

List all rules:

sudo nft list ruleset

More efficient with a cleaner syntax. Considered the future standard.

HTTPS/SSL

SSL vs TLS: What’s the difference?

• SSL (Secure Sockets Layer) is the older protocol that was historically used to secure Internet communications.
• Today, TLS (Transport Layer Security) is the modern and secure replacement.

Key point: today, we say TLS, even if many still say “SSL” out of habit.

X.509 Certificates

An SSL/TLS certificate is a digital file that:

• Verifies the identity of the server (e.g., ensures you are really on www.google.com)
• Provides the server’s public key
• Is validated by a trusted certificate authority

A certificate typically includes:

• The site name (Common Name or CN)
• The server’s public key
• The expiration date
• The digital signature of the Certificate Authority (CA)

HTTPS: How encryption works

When a browser connects to a site using HTTPS, several steps take place:

1. Client Hello

The browser sends a message to the server containing:

• the list of supported encryption algorithms (cipher suites)
• a random value (nonce)
• the requested site name

2. Server Hello

The server responds with:

• its X.509 certificate
• its own random value
• the chosen encryption algorithm

3. Certificate Verification

Get Benjamin’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

The browser checks that:

• The certificate is signed by a trusted authority
• It has not expired
• The name matches the domain contacted

4. Session Key Exchange

• The browser generates a session key (symmetric) and encrypts it with the server’s public key.
• The server decrypts it with its private key.
• From then on, both sides use this session key to encrypt and decrypt data (e.g., AES or ChaCha20).

Reminder: asymmetric cryptography (public/private key) is used only to exchange the session key. After that, symmetric cryptography is used because it is faster.

Cryptographic mechanisms summary

PKI — Public Key Infrastructure

CA (Certificate Authority)

Certificate Authorities (CAs) like Let’s Encrypt, DigiCert, or Sectigo issue and sign certificates.

Chain of Trust

• Each certificate is signed by a CA.
• Browsers already contain a list of trusted root CAs (built into the OS).
• The digital signature is verified mathematically.

HSTS (HTTP Strict Transport Security)

Mechanism that forces the browser to always use HTTPS for a given domain.
Prevents downgrade attacks (forcing a fallback from HTTPS to HTTP).

Example of HTTP header:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Commands to test HTTPS

openssl s_client

openssl s_client -connect www.google.com:443

Example output:

SSL handshake has read 3662 bytes and written 456 bytes
---
Certificate chain
 0 s:CN = www.google.com
   i:C = US, O = Google Trust Services LLC, CN = GTS CA 1C3

curl -v https://google.com

curl -v https://www.google.com

Example output:

* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* Server certificate:
*  subject: CN=www.google.com
*  start date: Aug  7 00:00:00 2023 GMT
*  expire date: Oct 30 23:59:59 2023 GMT

Load Balancer

Why use a load balancer?

A load balancer is a component that:

• distributes incoming requests across multiple backend servers (called workers),
• prevents a single server from being overloaded,
• ensures better availability, improved scalability, and greater resilience against failures or traffic spikes.

Benefits:

Load balancing algorithms

A load balancer can use different algorithms to distribute requests.

Round Robin

• The simplest algorithm.
• Each request is sent to the next server in a circular sequence.

1st → Server A  
2nd → Server B  
3rd → Server C  
4th → Server A (start over)

IP Hash

• The load balancer calculates a hash of the client’s IP address.
• This ensures that the same client is always redirected to the same server.
• Useful for applications requiring session persistence (shopping cart, authentication, etc.).

Least Connections

• The request is sent to the server with the fewest active connections.
• This helps avoid overloading a server that is already busy.

Types of load balancers: L4 vs L7

Layer 4 — Transport (TCP/UDP)

• Distributes requests based on:
• source/destination IP address,
• ports,
• protocol (TCP/UDP).
• Does not inspect the content of the request.

Layer 7 — Application (HTTP/HTTPS)

• Distributes requests based on the content of the request:
• URL
• HTTP headers
• Cookies or User-Agent
• Enables advanced routing such as:
• /login → Server A
• /api → Server B
• /static → Server C

Popular tools and implementations

HAProxy

• Widely used open-source load balancer
• High performance, configurable, supports L4 and L7

# Example directive in haproxy.cfg
balance roundrobin
server web1 192.168.1.101:80 check
server web2 192.168.1.102:80 check

NGINX

• Web server that can also act as a reverse proxy and load balancer
• Simple to configure, especially for L7

http {
  upstream backend {
    server 192.168.1.101;
    server 192.168.1.102;
  }

  server {
    location / {
      proxy_pass http://backend;
    }
  }
}

AWS ELB / ALB / NLB

• Built-in AWS load balancing solutions
• Elastic Load Balancer (L4), Application Load Balancer (L7), Network Load Balancer (ultra-fast TCP)
• Support SSL, auto scaling, and monitoring

Web Server

What is a web server?

A web server is a software program (and sometimes the machine running it) responsible for:

1. Listening for HTTP/HTTPS requests arriving on a specific port (commonly port 80 for HTTP or 443 for HTTPS),
2. Analyzing the request (method, path, headers…),
3. Providing an HTTP response, which can be:

• an HTML page,
• an image, a video, a CSS or JavaScript file,
• a static document.

It can also act as a reverse proxy, meaning it forwards the request to another service, such as an application server.

How it works: step by step

1. A client (browser) sends an HTTP request to a domain (e.g., www.example.com).
2. The web server listens on port 443 (HTTPS).
3. It reads:

• the method (GET, POST, etc.),
• the path (/index.html, /images/photo.jpg),
• the headers (browser type, preferred language, cache settings, etc.).

4. It sends back an HTTP response containing:

• a status code (200, 404, 500, etc.),
• headers (additional metadata),
• a body (requested content, e.g., HTML or JSON).

The most popular web servers

Static vs dynamic content

A web server can serve two types of content:

Static: content stored exactly as it is on disk.

• Example: HTML, CSS, JS, images, PDF.
• Advantage: very fast, no server-side processing required.

Dynamic: content generated in real time on the server.

• Example: PHP, Python (Flask, Django), Node.js, Ruby on Rails.
• Requires an application server to execute code and generate the response.

Example of an HTTP response

Here is an example of a response returned by a web server:

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 4523
Date: Thu, 18 Sep 2025 13:00:00 GMT

<!DOCTYPE html>
<html>
  <head><title>Example</title></head>
  <body>
    <h1>Welcome to my website</h1>
  </body>
</html>

HTTP status codes

HTTP headers

Headers are metadata sent along with an HTTP request or response.
They provide information such as:

• Content: MIME type (text/html, application/json), size, language.
• Connection: keep-alive, compression, flow management.
• Security: CSP, HSTS, certificates.
• Caching: Cache-Control, ETag.

Application Server

What is an application server?

An application server is a software program or process responsible for handling dynamic requests. Unlike a web server, which serves static files (HTML, images, CSS…), the application server:

• applies business logic,
• often interacts with a database or external APIs,
• generates dynamic responses (HTML, JSON, XML, etc.),
• handles operations requiring calculations or complex checks.

In short: the web server is the entry point, while the application server is the brain that computes the response.

Role in the processing chain

1. A user makes a request to a specific resource (e.g., /missions/active).
2. The web server (e.g., Nginx, Apache) receives the request.
3. If the requested resource is dynamic, the web server forwards the request to the application server.
4. The application server processes the request by:

• verifying the user’s identity (authentication),
• fetching data from the database,
• executing business logic,
• generating a response (e.g., HTML or JSON).

5. The result is sent back to the web server, which then returns it to the client.

Popular application frameworks

Communication with the web server

A web server and an application server do not communicate directly in “human language.” They use standardized interfaces that allow the web server to delegate requests to the application.

WSGI (Web Server Gateway Interface)

• Standard interface between a web server and a Python application.
• Frameworks like Flask and Django are WSGI-compliant.
• Example implementation: gunicorn, uWSGI.

gunicorn app:app --bind 0.0.0.0:8000

FastCGI / SCGI / ASGI

• FastCGI: fast, binary protocol.
• SCGI: simpler alternative to FastCGI.
• ASGI: modern asynchronous protocol, used by frameworks like FastAPI (supports real-time features, WebSockets, etc.).

Database

Why a database?

An application server does not store data permanently.
Information is:

• too large in volume,
• too complex,
• too sensitive.

Therefore, it is stored in a DBMS (Database Management System), which allows you to:

• Query data (e.g., search for specific records),
• Create / Update / Delete entries,
• Enforce constraints (uniqueness, relationships, integrity),
• Secure access via authentication, roles, and permissions.

SQL vs NoSQL

SQL (Relational)

Best suited for structured, linked data: users, transactions, orders…

NoSQL (Non-relational)

Best suited for unstructured or massively distributed data: logs, messages, heterogeneous objects.

Common database systems

Connections: pooling and persistence

A web application can receive thousands of simultaneous requests.
However:

• Opening a database connection is expensive (authentication, handshake, session setup),
• it is inefficient to open/close a connection for each request.

Solution: connection pooling

• The application server maintains a pool of open connections.
• Each request uses an available connection.
• Once processed, the connection returns to the pool.

This avoids unnecessary overhead and improves performance.

Security: authentication and SQL injection

Authentication

• Each application (or user) should connect with a dedicated account.
• Access must be restricted through roles (READ ONLY, READ/WRITE, ADMIN).
• Connections should be encrypted (via TLS).

SQL Injection

Dangerous example:

SELECT * FROM users WHERE email = '$email';

If $email = ' OR 1=1 --, the query becomes:

SELECT * FROM users WHERE email = '' OR 1=1 --';

Consequence: the attacker retrieves all rows from the table.

Solution: parameterized queries

cursor.execute("SELECT * FROM users WHERE email = %s", (email,))

Here, the email is treated as data, not executable SQL code.
This prevents injection and secures the application.

Conclusion

What begins with a simple keystroke — https://www.google.com — actually triggers a series of complex technical operations.
Each step plays a crucial role:

• DNS translates a domain name into an IP address,
• the TCP/IP stack establishes and transports communication,
• the firewall filters and secures traffic
• the HTTPS/TLS protocol ensures confidentiality and integrity,
• the load balancer distributes requests across multiple servers,
• the web server serves static resources,
• the application server generates dynamic content,
• and finally, the database stores and provides information.

This journey highlights that a single click relies on a distributed, secure, and robust infrastructure, the result of decades of technical evolution.
Understanding this process not only clarifies how the web truly works, but also prepares us to design, optimize, and secure the applications of tomorrow.