Web applications represent the dominant paradigm for delivering software to users. Built on the foundational protocols of HTTP/HTTPS and running in web browsers, web applications have evolved from simple document viewers to sophisticated platforms rivaling native desktop and mobile applications in capability and user experience.

From a computer networks perspective, web applications are fascinating systems that leverage the entire network stack—from TCP connections and TLS encryption to HTTP semantics and DNS resolution. Understanding web application architecture requires understanding how these network layers interact to deliver reliable, secure, and performant user experiences.

The evolution of web applications mirrors the evolution of network protocols and client capabilities:

• Web 1.0 (1990s-2000s): Static HTML documents, server-side rendering, stateless request-response
• Web 2.0 (2000s-2010s): Dynamic content, AJAX, rich client-side interactions, RESTful APIs
• Modern Web (2010s-present): Single-page applications, real-time communication, progressive web apps, edge computing

Each era introduced new network communication patterns, security requirements, and performance optimization techniques. Today's web applications are complex distributed systems spanning browsers, CDNs, load balancers, application servers, databases, and external services.

A modern web application comprises multiple layers and components, each playing a distinct role in processing and delivering content to users. Understanding this architecture is fundamental for designing, operating, and troubleshooting web systems.

The Complete Request Flow:

When a user types a URL or clicks a link, a cascade of network operations occurs:

┌─────────────────────────────────────────────────────────────────────────┐
│                        USER REQUEST FLOW                                 │
│                                                                         │
│  User Action: Types "example.com" in browser                            │
│        │                                                                │
│        ▼                                                                │
│  1. DNS Resolution ────────────────────────────────────────────────────│
│     Browser → Local DNS Cache → Recursive Resolver → Root/TLD/Auth     │
│     Result: example.com → 203.0.113.50                                  │
│        │                                                                │
│        ▼                                                                │
│  2. TCP Connection ────────────────────────────────────────────────────│
│     Browser → [SYN] → Server:443                                        │
│     Browser ← [SYN-ACK] ← Server                                        │
│     Browser → [ACK] → Server                                            │
│        │                                                                │
│        ▼                                                                │
│  3. TLS Handshake ──────────────────────────────────────────────────────│
│     ClientHello + ServerHello + Certificate + Key Exchange              │
│     Result: Encrypted channel established                               │
│        │                                                                │
│        ▼                                                                │
│  4. HTTP Request ───────────────────────────────────────────────────────│
│     GET / HTTP/2                                                        │
│     Host: example.com                                                   │
│     Accept: text/html                                                   │
│        │                                                                │
│        ▼                                                                │
│  5. Server Processing ──────────────────────────────────────────────────│
│     Load Balancer → Application Server → Database → Response            │
│        │                                                                │
│        ▼                                                                │
│  6. HTTP Response ──────────────────────────────────────────────────────│
│     HTTP/2 200 OK                                                       │
│     Content-Type: text/html                                             │
│     <html>...</html>                                                    │
│        │                                                                │
│        ▼                                                                │
│  7. Resource Loading ───────────────────────────────────────────────────│
│     CSS, JavaScript, Images loaded in parallel (HTTP/2 multiplexing)   │
│        │                                                                │
│        ▼                                                                │
│  8. Page Rendering ─────────────────────────────────────────────────────│
│     Browser parses HTML, executes JS, renders UI                        │
└─────────────────────────────────────────────────────────────────────────┘

Typical Latency Breakdown:

Network Optimization Opportunities:

Every phase presents optimization opportunities that network-aware engineers exploit:

• DNS: Preconnect hints, DNS-over-HTTPS, edge DNS
• TCP: Connection pooling, HTTP/2 multiplexing, QUIC
• TLS: Session resumption, 0-RTT, OCSP stapling
• HTTP: Caching, compression, efficient payloads
• Resources: CDN distribution, lazy loading, code splitting

The strategy for rendering HTML content has profound implications for network communication patterns, perceived performance, and server architecture. Modern web applications choose from several approaches—often combining them for optimal results.

Server-Side Rendering (SSR):

The server generates complete HTML for each request:

┌──────────┐    GET /products    ┌──────────────────────┐
│ Browser  │ ──────────────────▶ │   Application Server │
│          │                     │                      │
│          │                     │  1. Execute logic    │
│          │                     │  2. Query database   │
│          │                     │  3. Render HTML      │
│          │ ◀────────────────── │                      │
│          │    Complete HTML    └──────────────────────┘
│          │                     
│  Render  │ ← User sees content immediately
└──────────┘

Network Characteristics:

• First Contentful Paint (FCP): Fast—content arrives in first response
• Time to Interactive (TTI): Depends on JavaScript hydration
• Server Load: Higher—rendering on every request
• Caching: Possible but complex for personalized content
• Bandwidth: Complete HTML sent each request (larger payloads)

Technologies: Next.js (React), Nuxt.js (Vue), Rails, Django, PHP

Client-Side Rendering (CSR) / Single-Page Applications (SPA):

The server sends minimal HTML; JavaScript builds the UI in the browser:

┌──────────┐    GET /             ┌──────────────────────┐
│ Browser  │ ──────────────────▶  │   Application Server │
│          │                      │                      │
│          │ ◀────────────────── │ Minimal HTML + JS    │
│          │                      └──────────────────────┘
│  Load JS │                      
│  Bundle  │                      ┌──────────────────────┐
│          │  GET /api/products   │   API Server         │
│          │ ──────────────────▶  │                      │
│          │                      │  Return JSON data    │
│          │ ◀──────────────────  │                      │
│   Build  │                      └──────────────────────┘
│    UI    │ ← User sees content after JS executes
└──────────┘

Network Characteristics:

• FCP: Slower—requires JavaScript execution first
• TTI: Better after initial load (no full-page reloads)
• Server Load: Lower—static HTML, API calls only
• Caching: Excellent—static assets cached aggressively
• API Traffic: Separate API calls increase request count

Technologies: React (CRA), Vue, Angular, Svelte

Static Site Generation (SSG):

HTML generated at build time, not request time:

Build Time:
┌────────────────────────────────────────────────────┐
│  Build Process                                      │
│    │                                                │
│    ├── Fetch data from CMS/API                      │
│    ├── Generate HTML for each page                  │
│    └── Output: /products.html, /about.html, ...    │
└────────────────────────────────────────────────────┘

Request Time:
┌──────────┐    GET /products.html    ┌─────────────┐
│ Browser  │ ────────────────────────▶│    CDN      │
│          │                          │             │
│          │ ◀────────────────────────│ Pre-built   │
│          │    Static HTML           │ HTML file   │
└──────────┘                          └─────────────┘

Network Characteristics:

• Latency: Minimal—served from CDN edge
• Origin Traffic: Near zero (CDN cache hit)
• Scalability: Unlimited (static files)
• Freshness: Stale until rebuild

Incremental Static Regeneration (ISR):

Static pages regenerated on-demand with configurable staleness:

1. User requests page
2. CDN serves cached version (fast)
3. If stale, trigger background regeneration
4. Next request gets fresh version

This combines SSG's performance with reasonable content freshness.

Technologies: Next.js, Gatsby, Hugo, Astro

HTTP is a stateless protocol—each request is independent, with no inherent connection to previous requests. Yet web applications routinely need to maintain user state across requests: recognizing logged-in users, remembering shopping carts, personalizing content. Session management bridges this gap.

The Session Problem:

Request 1: POST /login {username, password}
           → Server validates credentials
           → Server needs to remember: "User Alice is authenticated"

Request 2: GET /dashboard
           → How does the server know this is Alice?
           → HTTP provides no built-in user identity

Cookie-Based Sessions:

The traditional approach stores session state on the server, with a session identifier in a cookie:

┌──────────────────────────────────────────────────────────────────────┐
│                    Cookie-Based Session Flow                          │
│                                                                       │
│  1. Login Request                                                     │
│     POST /login                                                       │
│     Body: {username: "alice", password: "***"}                       │
│                                                                       │
│  2. Server Response                                                   │
│     HTTP/1.1 200 OK                                                   │
│     Set-Cookie: session_id=abc123; HttpOnly; Secure; SameSite=Strict  │
│                                                                       │
│     Server stores: sessions["abc123"] = {userId: "alice", roles: []}  │
│                                                                       │
│  3. Subsequent Requests                                               │
│     GET /dashboard                                                    │
│     Cookie: session_id=abc123                                         │
│                                                                       │
│     Server lookup: sessions["abc123"] → {userId: "alice", ...}        │
│     Server knows: This is Alice                                       │
└──────────────────────────────────────────────────────────────────────┘

Session Storage Options:

Token-Based Authentication (JWT):

JSON Web Tokens store claims in a cryptographically signed token:

┌──────────────────────────────────────────────────────────────────────┐
│                    JWT-Based Authentication                           │
│                                                                       │
│  1. Login Request                                                     │
│     POST /login → Server validates credentials                        │
│                                                                       │
│  2. Server Response                                                   │
│     {"token": "eyJhbGciOiJIUzI1NiIs..."}                              │
│                                                                       │
│     JWT Structure:                                                    │
│     ┌─────────────────────────────────────────────────────────────┐  │
│     │ Header.Payload.Signature                                     │  │
│     │                                                               │  │
│     │ Header:  {"alg": "HS256", "typ": "JWT"}                      │  │
│     │ Payload: {"sub": "alice", "exp": 1705312800, "roles": [...]} │  │
│     │ Signature: HMAC(header.payload, secret)                       │  │
│     └─────────────────────────────────────────────────────────────┘  │
│                                                                       │
│  3. Subsequent Requests                                               │
│     GET /dashboard                                                    │
│     Authorization: Bearer eyJhbGciOiJIUzI1NiIs...                     │
│                                                                       │
│     Server validates signature → Trusts claims → Knows user           │
│     NO database lookup required                                       │
└──────────────────────────────────────────────────────────────────────┘

Cookies vs. JWT Tokens:

Refresh Token Pattern:

For JWTs, short-lived access tokens combined with long-lived refresh tokens balance security and usability:

1. Login → Access Token (15 min) + Refresh Token (7 days)
2. Access token used for API calls
3. When access token expires:
   POST /refresh (with refresh token)
   → New access token issued
4. Refresh token rotation: Each refresh issues new refresh token

This limits exposure from stolen access tokens while maintaining long sessions.

Traditional HTTP follows a request-response pattern: client initiates, server responds, connection returns to idle. Real-time web applications require bidirectional communication—servers pushing updates to clients without waiting for requests. This fundamental shift in communication pattern has driven the development of several technologies.

Evolution of Real-Time Techniques:

1. Polling (Naive Approach):

while (true) {
    response = GET /api/updates        // Request
    if (response.hasUpdates) {          // Maybe stale
        processUpdates(response);
    }
    sleep(5000);                         // Wait 5 seconds
}

Problems: High server load, delayed updates, wasted bandwidth

2. Long Polling (Comet):

Client → GET /api/updates
         (Server holds connection open for up to 30 seconds)
         (When update available, server responds immediately)
Client ← Update data
Client → GET /api/updates (immediately reconnect)

Improvement: Near-real-time, lower request volume Problems: Still request-response, connection overhead, not truly bidirectional

3. Server-Sent Events (SSE):

Client → GET /api/events
         Accept: text/event-stream

Server → HTTP/1.1 200 OK
         Content-Type: text/event-stream
         Cache-Control: no-cache
         Connection: keep-alive

Server → data: {"type": "update", "content": "..."}
         
         (Connection stays open)
         
Server → data: {"type": "notification", "content": "..."}
         ...

Advantages: Simple, built-in browser support, automatic reconnection Limitations: Unidirectional (server → client only), HTTP/1.1 connection limits

4. WebSocket:

WebSocket provides full-duplex communication over a single TCP connection:

┌─────────────────────────────────────────────────────────────────────────┐
│                    WebSocket Connection Lifecycle                        │
│                                                                         │
│  1. HTTP Upgrade Request                                                │
│     GET /ws HTTP/1.1                                                    │
│     Host: example.com                                                   │
│     Upgrade: websocket                                                  │
│     Connection: Upgrade                                                 │
│     Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==                         │
│     Sec-WebSocket-Version: 13                                           │
│                                                                         │
│  2. Server Upgrade Response                                             │
│     HTTP/1.1 101 Switching Protocols                                    │
│     Upgrade: websocket                                                  │
│     Connection: Upgrade                                                 │
│     Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=                  │
│                                                                         │
│  3. Full-Duplex Communication                                           │
│     ┌─────────┐                           ┌─────────┐                   │
│     │ Client  │ ◄═══════════════════════► │ Server  │                   │
│     │         │    Binary/Text Messages   │         │                   │
│     │         │    sent in either         │         │                   │
│     │         │    direction at any time  │         │                   │
│     └─────────┘                           └─────────┘                   │
│                                                                         │
│  4. Connection Closure (graceful)                                       │
│     Close frame sent by either party                                    │
│     (opcode 0x8, optional status code and reason)                       │
└─────────────────────────────────────────────────────────────────────────┘

WebSocket Frame Format:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-------+-+-------------+-------------------------------+
|F|R|R|R| opcode|M| Payload len |    Extended payload length    |
|I|S|S|S|  (4)  |A|     (7)     |           (16/64)             |
|N|V|V|V|       |S|             |                               |
| |1|2|3|       |K|             |                               |
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - -+
|                 Masking-key (if MASK set)                      |
+-------------------------------+-------------------------------+
|                            Payload Data                        |
+--------------------------------------------------------------+

Opcode values:
  0x0 = Continuation frame
  0x1 = Text frame
  0x2 = Binary frame
  0x8 = Connection close
  0x9 = Ping
  0xA = Pong

Content Delivery Networks (CDNs) are globally distributed networks of servers that cache and deliver content from locations geographically close to users. For web applications, CDNs are essential infrastructure for performance, reliability, and security.

The Latency Problem:

The speed of light limits how fast data can travel. A request from Tokyo to a server in Virginia takes approximately 80-100ms just for network propagation—before any processing occurs.

Without CDN:
User (Tokyo) → Ocean Cable → US East Coast → Server → Response
                  ~100ms RTT × multiple resources = Slow

With CDN:
User (Tokyo) → Local CDN Edge (Tokyo) → Response
                  ~5ms RTT × resources = Fast

CDN Architecture:

┌─────────────────────────────────────────────────────────────────────────┐
│                         Global CDN Network                               │
│                                                                         │
│    User Request                                                         │
│         │                                                               │
│         ▼                                                               │
│    ┌─────────────┐                                                      │
│    │ Anycast DNS │ → Resolves to nearest edge server                    │
│    └──────┬──────┘                                                      │
│           │                                                             │
│     ┌─────┴─────────────────────────────────────────────────────┐      │
│     │                Edge Server Layer                           │      │
│     │  ┌────────┐  ┌────────┐  ┌────────┐  ┌────────┐          │      │
│     │  │ Tokyo  │  │ London │  │ NYC    │  │ Sydney │   ...     │      │
│     │  └────┬───┘  └────────┘  └────────┘  └────────┘          │      │
│     │       │                                                    │      │
│     │       │ Cache Miss                                         │      │
│     └───────┼────────────────────────────────────────────────────┘      │
│             ▼                                                           │
│    ┌─────────────────────────────────────────────┐                     │
│    │              Origin Shield Layer             │                     │
│    │  (Reduces origin requests, consolidates)    │                     │
│    └─────────────────┬───────────────────────────┘                     │
│                      │                                                  │
│                      ▼                                                  │
│    ┌─────────────────────────────────────────────┐                     │
│    │                 Origin Server                │                     │
│    │            (Your application)               │                     │
│    └─────────────────────────────────────────────┘                     │
└─────────────────────────────────────────────────────────────────────────┘

Cache-Control Headers:

# Long cache for versioned static assets
Cache-Control: public, max-age=31536000, immutable

# Short cache for API responses
Cache-Control: public, max-age=60, stale-while-revalidate=300

# No caching for personalized content
Cache-Control: private, no-store

# Browser can cache but must revalidate
Cache-Control: no-cache

CDN Beyond Caching:

Modern CDNs provide services beyond simple caching:

Edge Computing:

Edge compute platforms run application code closer to users:

Traditional:    Request → CDN Edge → Origin (Virginia) → Response
                         [cache hit only]

Edge Compute:   Request → CDN Edge → [Execute JavaScript] → Response
                         [dynamic personalization at edge]

Use cases: A/B testing, authentication, personalization, redirects, API responses

Web applications face a unique threat landscape due to their public exposure, the complexity of the browser environment, and the sensitive data they handle. Security must be designed into the application architecture, not added as an afterthought.

Transport Security (HTTPS):

All web application traffic should be encrypted with TLS/HTTPS:

• Encryption in Transit: Protects data from eavesdropping
• Integrity: Detects tampering with content
• Authentication: Verifies server identity via certificates

HSTS (HTTP Strict Transport Security):

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

Forces browsers to only use HTTPS for the domain, preventing downgrade attacks.

Common Attack Vectors:

Content Security Policy (CSP):

CSP restricts what resources the browser can load, mitigating XSS and data injection:

Content-Security-Policy: 
    default-src 'self';
    script-src 'self' 'unsafe-inline' https://cdn.example.com;
    style-src 'self' 'unsafe-inline';
    img-src 'self' data: https:;
    font-src 'self' https://fonts.googleapis.com;
    connect-src 'self' https://api.example.com;
    frame-ancestors 'none';
    base-uri 'self';
    form-action 'self'

CORS (Cross-Origin Resource Sharing):

CORS controls which origins can access resources via JavaScript:

┌─────────────────────────────────────────────────────────────────────────┐
│                    CORS Preflight Flow                                   │
│                                                                         │
│  1. Browser detects cross-origin request with 'risky' characteristics   │
│                                                                         │
│  2. Preflight Request (automatic)                                       │
│     OPTIONS /api/data                                                   │
│     Origin: https://frontend.example.com                                │
│     Access-Control-Request-Method: POST                                 │
│     Access-Control-Request-Headers: Content-Type, Authorization         │
│                                                                         │
│  3. Server Response                                                     │
│     Access-Control-Allow-Origin: https://frontend.example.com          │
│     Access-Control-Allow-Methods: GET, POST, OPTIONS                   │
│     Access-Control-Allow-Headers: Content-Type, Authorization          │
│     Access-Control-Max-Age: 86400                                       │
│                                                                         │
│  4. If headers match, browser proceeds with actual request              │
│                                                                         │
│  5. Actual Request                                                      │
│     POST /api/data                                                      │
│     Origin: https://frontend.example.com                                │
│     Content-Type: application/json                                      │
│     Authorization: Bearer ...                                           │
└─────────────────────────────────────────────────────────────────────────┘

Security Headers Summary:

# Prevent XSS
Content-Security-Policy: default-src 'self'; ...
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block  # Legacy, CSP preferred

# Prevent clickjacking
X-Frame-Options: DENY

# Force HTTPS
Strict-Transport-Security: max-age=31536000; includeSubDomains

# Control referer information
Referrer-Policy: strict-origin-when-cross-origin

# Restrict browser features
Permissions-Policy: geolocation=(), camera=(), microphone=()

Web performance directly impacts user experience, engagement, SEO rankings, and business outcomes. Optimization requires understanding the network, browser rendering, and the interplay between them.

Core Web Vitals:

Google's Core Web Vitals measure real-world user experience:

Network Optimization Techniques:

1. HTTP/2 and HTTP/3:

• Multiplexing eliminates head-of-line blocking
• Header compression reduces overhead
• Server push preemptively sends resources
• HTTP/3 (QUIC) eliminates TCP head-of-line blocking

2. Resource Optimization:

<!-- Preconnect to critical origins -->
<link rel="preconnect" href="https://api.example.com">

<!-- Prefetch resources for likely navigation -->
<link rel="prefetch" href="/next-page.html">

<!-- Preload critical resources -->
<link rel="preload" href="/critical.css" as="style">
<link rel="preload" href="/hero.jpg" as="image">

3. Compression:

• Brotli compression (15-20% smaller than gzip for text)
• Image optimization (WebP, AVIF formats)
• Font subsetting (only needed characters)

Resource Loading Strategies:

┌─────────────────────────────────────────────────────────────────────────┐
│                    Optimal Resource Loading                              │
│                                                                         │
│  Critical Path (render blocking):                                       │
│  ├── HTML (initial request)                                             │
│  ├── Critical CSS (inline or preloaded)                                 │
│  └── Critical fonts (preloaded)                                         │
│                                                                         │
│  First Paint ──────────────────────────────────────────────────────────│
│                                                                         │
│  Deferred Loading:                                                      │
│  ├── Non-critical CSS (rel="preload" as="style")                        │
│  ├── JavaScript bundles (defer or async)                                │
│  └── Analytics, third-party scripts                                     │
│                                                                         │
│  Lazy Loading (on demand):                                              │
│  ├── Below-fold images (loading="lazy")                                 │
│  ├── Route-specific JavaScript (dynamic import)                         │
│  └── User-triggered features                                            │
│                                                                         │
│  Speculative Loading:                                                   │
│  ├── Prefetch likely next pages                                         │
│  └── Preconnect to origins for anticipated requests                     │
└─────────────────────────────────────────────────────────────────────────┘

Caching Strategies:

Monitoring and Measurement:

Use Real User Monitoring (RUM) to measure actual performance:

• Google Lighthouse (lab testing)
• Chrome UX Report (field data)
• Custom RUM with Performance API
• Server-side metrics (TTFB, throughput)

We've explored web application architecture through the lens of computer networking—understanding how HTTP, caching, session management, real-time communication, and content delivery work together to create the modern web.

Transition to Mobile Backends:

With web applications thoroughly covered, we'll next examine mobile backends—the server-side systems that power iOS, Android, and cross-platform mobile applications. While sharing many patterns with web applications, mobile backends face unique constraints around offline operation, push notifications, bandwidth sensitivity, and API versioning that shape their network architecture.