Accessing a website

Understanding Web Networking & Hosting

What Happens When You Access a Website?

When you type a URL into your browser and press Enter, a complex sequence of events unfolds in milliseconds:

DNS Lookup: Your browser doesn't know where "example.com" is located, so it asks a DNS (Domain Name System) server to translate the domain name into an IP address like 93.184.216.34

TCP Connection: Your browser establishes a connection with the server at that IP address using the TCP protocol. This involves a "three-way handshake" (SYN, SYN-ACK, ACK) to ensure both sides are ready to communicate

HTTP/HTTPS Request: Your browser sends an HTTP request to the server asking for specific resources (like GET /index.html HTTP/1.1)

Server Processing: The web server receives your request, processes it, and prepares the appropriate response

Response: The server sends back the requested files (HTML, CSS, JavaScript, images, etc.)

Rendering: Your browser receives these files and renders them into the webpage you see

This entire journey typically takes just 100-500 milliseconds, depending on internet speed, geographic distance, and website complexity.

HTTP vs HTTPS: The Security Difference

HTTP (HyperText Transfer Protocol)

HTTP is the original protocol for transferring data on the web. It defines how messages are formatted and transmitted between browsers and servers.

Key characteristics:

Operates on port 80 by default

Sends all data in plain text

No encryption whatsoever

Fast but completely insecure

The Problem: Anyone intercepting the connection (like someone on the same public WiFi) can read everything — passwords, credit cards, personal messages. It's like sending postcards instead of sealed letters.

HTTPS (HTTP Secure)

HTTPS is HTTP wrapped in TLS/SSL encryption. It's the same protocol but with a security layer protecting your data.

Key characteristics:

Operates on port 443 by default

All data is encrypted end-to-end

Server identity is verified through SSL/TLS certificates

Slightly slower due to encryption overhead, but secure

Comparison:

Feature	HTTP	HTTPS
Port	80	443
Encryption	None	TLS/SSL
Data visibility	Readable by anyone	Encrypted
Authentication	No	Yes (via certificates)
Browser warning	Yes (shown as "Not Secure")	No
SEO ranking	Lower	Higher

Modern websites should always use HTTPS. Browsers now warn users about HTTP sites, and many web features (geolocation, camera access, service workers) only work on HTTPS.

Hosting a Website: Static Files

Static websites consist of fixed HTML, CSS, and JavaScript files that are served exactly as they are stored on the server. These files don't change based on user input or database queries.

How Static Hosting Works

To host static files, you need:

A web server (like Nginx, Apache, or Caddy) installed on a machine

Your files placed in a specific directory (commonly /var/www/html)

Port exposure so the web server can receive requests from the internet

Example Nginx configuration:

server {
    listen 80;
    server_name example.com;
    
    root /var/www/html;
    index index.html;
    
    location / {
        try_files $uri $uri/ =404;
    }
}

Port Exposure

Your server must allow incoming traffic on the web port. This involves:

Firewall configuration: Opening port 80 (HTTP) or 443 (HTTPS) on your server's firewall

Network configuration: If hosting from home, setting up port forwarding on your router to direct traffic from the internet to your server

Cloud hosting: If using a cloud provider, configuring security groups or network ACLs to allow inbound traffic

When someone visits your website, their browser connects to your server's public IP address on port 80/443, and the web server responds by sending the requested files.

Static hosting is ideal for:

Personal portfolios

Documentation sites

Landing pages

Blogs

Any content that doesn't require real-time data or user-specific customization

Hosting Modern React Applications

React applications are JavaScript-based frameworks that create dynamic, interactive user interfaces. Unlike static HTML files, React apps involve significant client-side logic. There are two main approaches to hosting React applications.

Single Page Application (SPA)

In the SPA approach, your entire React application is bundled into static files during the build process.

How it works:

You run npm run build which creates optimized HTML, CSS, and JavaScript files

These static files are deployed to a web server (just like static hosting)

When a user visits your site, the server sends the HTML file and JavaScript bundle

The JavaScript runs in the user's browser and renders the interface

All subsequent navigation and interactions happen in the browser without page reloads

The app makes API calls to backend servers for data

Hosting requirements:

Same as static hosting: expose port 80/443

Server configuration to handle client-side routing (redirect all routes to index.html)

Example Nginx config for SPA:

server {
    listen 80;
    server_name example.com;
    
    root /var/www/react-app/build;
    index index.html;
    
    location / {
        try_files $uri /index.html;
    }
}

Characteristics:

Initial load can be slow (downloading entire JavaScript bundle)

Fast navigation after initial load (no page refreshes)

Poor SEO for content-heavy sites (search engines see empty HTML initially)

Rich, app-like user experience

All rendering happens in the browser

Server-Side Rendering (SSR)

With SSR, your React components are rendered on the server for each request, generating complete HTML before sending it to the browser.

How it works:

User requests a page from your server

The Node.js server runs your React code and renders components to HTML

Server sends fully-rendered HTML to the browser

Browser displays content immediately (fast First Contentful Paint)

React JavaScript loads and "hydrates" the page (makes it interactive)

Subsequent navigation can use client-side routing or fetch new pages from server

Hosting requirements:

Node.js server running constantly (not just static file serving)

More CPU and memory resources (server does rendering work)

Port exposure (typically port 3000 or behind a reverse proxy on port 80/443)

Example deployment with Next.js:

# Server runs Node.js application
node server.js
# Or with PM2 for production
pm2 start npm --name "my-app" -- start

Nginx reverse proxy config:

server {
    listen 80;
    server_name example.com;
    
    location / {
        proxy_pass http://localhost:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }
}

Characteristics:

Faster initial page load (HTML is pre-rendered)

Excellent SEO (search engines see complete content)

Better performance on slow devices (less client-side work)

Requires a Node.js server running 24/7

Higher hosting costs and complexity

SPA vs SSR: Quick Comparison

Aspect	SPA	SSR
Initial Load	Slower (download JS bundle)	Faster (pre-rendered HTML)
SEO	Poor to moderate	Excellent
Hosting	Simple (static files)	Complex (Node.js server)
Server Resources	Minimal	Moderate to high
Navigation Speed	Very fast (no reload)	Depends on implementation
Best For	Web apps, dashboards	Content sites, e-commerce
Examples	Gmail, Figma	News sites, blogs

Choosing Your Approach

Use static hosting when:

Content rarely changes

No user authentication needed

Simple, informational websites

Want the lowest hosting costs

Use SPA when:

Building an interactive web application

Rich client-side interactions needed

SEO is not critical

Want fast navigation between views

Use SSR when:

SEO is crucial

Fast initial page load matters

Content is dynamic but needs to be crawlable

You have resources for server infrastructure

All three approaches require exposing your web server to the internet through proper port configuration, but the complexity and resource requirements increase as you move from static to SPA to SSR hosting.