Learning Objectives

By the end of this chapter, you will understand the physical and logical layers that power modern web applications. You will be able to trace a web request from the CPU and memory of a client device, through the operating system and network, across routers, to a server, and back.

Prerequisites

None. We begin at the absolute foundation of computing.

Why Does This Exist?

Software is not magic; it is instructions executed on physical hardware, communicating over physical cables. To build scalable, reliable full-stack applications, you must understand the underlying constraints: how long it takes to read from memory versus disk, how network packets are lost and retransmitted, and how operating systems manage resources. Without this foundation, debugging complex production issues becomes guesswork.

The Problem Before the Solution

Before modern operating systems and networking, computers were isolated calculators. A program had to manage its own hardware interactions (CPU, memory, storage) directly. Sharing data meant physically moving disks. There was no concept of a "process" safely isolated from another, or a standardized way to request data from a machine across the world.

Why the Old Approach Breaks

Direct hardware management does not scale. If a single program crashes, the whole computer crashes. If networks use proprietary protocols, global communication is impossible. We needed abstractions: Operating Systems to manage hardware (CPU, memory, storage) and standardize execution (processes, threads), and standardized networking protocols (TCP/IP, HTTP) to allow universal communication.

History

From the ENIAC (1940s) to Unix (1969) which introduced hierarchical filesystems and standardized processes, to the ARPANET (1969) which evolved into the internet. The creation of TCP/IP (1983) standardized network communication, and Tim Berners-Lee's invention of HTTP and URLs (1989) birthed the Web, turning isolated networks into a global information system.

Mental Model (Analogy -> Reality)

The CPU is a chef. Memory (RAM) is the kitchen counter (fast but small). Storage (Disk) is the pantry (slow but huge). Processes are individual recipes being cooked; Threads are the chef's hands working on parts of a recipe simultaneously. The Operating System (OS) is the restaurant manager, making sure chefs don't fight over counter space. The Filesystem is the filing cabinet for recipes.

Networking is the postal service. An IP Address is a house address. DNS is the phonebook. A Port is a specific person at that house. TCP is certified mail (guaranteed delivery), UDP is a postcard (fast, no guarantee). TLS is sending the mail in a locked box. HTTP is the language written in the letter. URLs specify exactly which document you want. A Proxy is a mail forwarding service. CDNs are local distribution centers for popular magazines. Browsers are the readers, and Servers are the publishers.

Internal Working (Memory, stack, process, network, etc.)

When you start a program via the Terminal, the OS loads its binary from Storage into Memory, creating a Process. The process has environment variables injected into it for configuration. The CPU fetches and executes instructions. If it's a web server, it asks the OS to bind to a Port on Localhost (127.0.0.1) or a public IP.

When a client connects, the OS handles the TCP handshake and TLS encryption, delivering the raw HTTP bytes to the server process, which parses them and responds.

Visual Explanation (ASCII diagrams)

[ Browser ] --- (URL: https://example.com) ---> [ DNS Resolver ]
                                                      |
                                                Returns IP: 93.184.216.34
                                                      |
[ Browser ] --- (TCP Handshake + TLS) --------> [ Internet / Routers ]
                                                      |
                                                      V
                                                [ CDN Edge Server ] --(Cache miss)--> [ Reverse Proxy ]
                                                                                            |
                                                                                    [ Backend Web Server Process ]
                                                                                    (Reads from Storage, uses CPU/RAM)
        

Syntax

While concepts are language-agnostic, here is how you interact with these layers in a Unix environment:

# View processes
ps aux

# Check environment variables
printenv

# Find listening ports
lsof -i -P -n | grep LISTEN

# DNS lookup
dig example.com
        

Tiny Example

Creating a simple HTTP server using Node.js that listens on a port, demonstrating CPU execution, memory usage, and networking.

const http = require('http');
// The OS assigns memory for this process
const server = http.createServer((req, res) => {
  res.writeHead(200, { 'Content-Type': 'text/plain' });
  res.end('Hello from the CPU and RAM!\n');
});
// Binds to a specific port on localhost
server.listen(3000, '127.0.0.1', () => {
  console.log('Listening on http://127.0.0.1:3000');
});
        

Walkthrough

1. The OS starts a new process for the Node runtime.

2. V8 engine compiles the JavaScript to machine code for the CPU.

3. The script asks the OS to open port 3000.

4. When you visit http://localhost:3000, your browser sends a TCP SYN packet to the OS.

5. The OS completes the handshake, reads the HTTP GET request, and passes it to the Node process.

6. Node fires the callback, writing data to memory, which the OS flushes back out over the network.

Break It

What happens if you try to start the server twice?

node server.js &
node server.js
        

The OS will throw an error: EADDRINUSE: address already in use :::3000. A port can only be bound by one process at a time.

Debug It

If you see EADDRINUSE, you must find which process owns the port and terminate it.

# Find the Process ID (PID)
lsof -i :3000
# Terminate it
kill -9 <PID>
        

Mini Project

Write a bash script that reads an environment variable `TARGET_URL`, performs a DNS lookup, pings the IP address, and uses `curl` to fetch the HTTP headers, simulating the full network stack.

#!/bin/bash
export TARGET_URL="example.com"
echo "DNS Lookup:"
dig +short $TARGET_URL
echo "Fetching Headers:"
curl -I https://$TARGET_URL
            

Real Application Feature

When a user uploads a profile picture, it hits a Reverse Proxy, is routed to a Node.js Process, which streams the file into Storage (or a CDN). The application uses threads (via libuv in Node) to handle file I/O without blocking the CPU from serving other users.

Production Implementation

In production, you do not run `node server.js` directly in a terminal. You use a process manager (like Systemd or PM2) or a container (Docker) to ensure the process restarts if it crashes. You place a reverse proxy (Nginx) in front to handle TLS encryption and serve static files directly from the filesystem, offloading work from the Node process.

Production Usage

Monitoring tools (like Prometheus) will track CPU usage, memory leaks (when a process fails to release RAM), and network I/O. If a server goes down, health checks route traffic to healthy instances.

Performance

Network latency (the time it takes a packet to travel) is often the biggest bottleneck. CDNs improve performance by caching static assets physically closer to the user. Using HTTP/2 or HTTP/3 allows multiple requests over a single TCP connection, reducing handshake overhead.

Best Practices

• Never store secrets in code; use Environment Variables.
• Always use HTTPS (TLS) for production data.
• Use connection pooling for databases to avoid TCP handshake overhead.
• Understand the difference between CPU-bound tasks (which block Node.js) and I/O-bound tasks.

Interview Questions (Easy, Medium, Hard, Senior)

Engineering Challenge

Create a simple TCP server (using the `net` module in Node) and manually implement the absolute bare minimum HTTP/1.1 response by writing the raw strings to the socket. This forces you to understand what HTTP actually is: plain text over TCP.

Revision Sheet

CPU/RAM/Disk: Compute, fast short-term storage, slow long-term storage.

Process/Thread: Executing program / concurrent execution context.

Env Vars: Configuration injected by the OS.

TCP/IP: Network transport and addressing.

DNS: Domain name to IP.

HTTP/TLS: Application protocol and security layer.

Connections

These foundational networking and operating system concepts will be essential when we discuss Backend Engineering, where we write the processes that bind to ports, and Cloud Infrastructure, where we configure the routers, CDNs, and load balancers that direct the traffic.