One click, a million exact steps: how computers work

You click a button on your screen and something happens: a page loads, a game opens, a message sends. Between that click and what you see, your computer has done an enormous amount of work, and it did all of it by following rules so literal that a machine would never survive a single human conversation.

This tutorial is one long answer to one question: what is your computer actually doing between your click and the result on screen? We will build the answer layer by layer, starting from what computation even means, then how a machine got built to do it, then the software that runs our programs, and finally the networks that connect millions of these machines. By the end, you will be able to trace one action, opening a webpage, through every layer of the machine. That mental map is the real goal; the terms are just signposts along the way.

What is computation, really — and why does a machine take you literally?

The questions that organize the whole discipline

The course this material comes from opens with a promise, and it is a good one: every app you open is worth the question "what is this computer actually doing?" With that question in hand, let's first see how computer science organizes itself, because the structure of the discipline is also the structure of this tutorial.

Computer science is far broader than programming. It contains programming languages, algorithms and data structures, complexity theory, graphics, operating systems, databases, artificial intelligence, computer architecture, networking, and more. That list looks like a grab bag, but four questions organize almost all of it.

Every topic in the list above answers one of these four. The course's own recommended textbook uses the same framing: Forouzan's Foundations of Computer Science presents the field as a survey of computation, programming, hardware, and networks, which is exactly the shape of this tutorial. Forouzan 5th edition, Cengage EMEA, content covered through February 2023.Forouzan

This is the book the course names on its first slides, worth recognizing when you see it.

Caption: The fifth-edition cover of Behrouz Forouzan's Foundations of Computer Science, the course's recommended textbook. This is a bibliographic anchor, not a content diagram; the ideas it covers are what the rest of this tutorial builds.Forouzan

Keep those four questions in your pocket. Every new idea you meet from here on can be filed under one of them.

Computation: input, process, output, and a contract

So what is a computation, exactly? Here is the cleanest definition: a computation takes an input, applies a process, and produces an output. Summing the list [4, 8, 15, 16, 23, 42] to get 108 is a computation. Sorting that same list into descending order is also a computation, even though no arithmetic happened. The process, not the data, defines the task.

The course sharpens this into a contract view, and the contract has three clauses: what input is allowed, what rules will be followed, and what output must be produced. Try writing the contract for sorting six numbers. The input is a list of six values. The rule says compare and reorder. The output must contain the same six values in the requested order. That last clause is where contracts bite: drop one value on the way out and you have violated the contract, even if the remaining values are perfectly sorted.

A picture may help before we add any terminology. Harvard's CS50 course opens with the same idea and draws it as a black box.

Caption: An input bubble saying "hello, world" enters a black box holding three Scratch blocks (the middle one, say, does the work), and out comes the cat speaking "hello, world". This is the input → process → output shape of every computation: something goes in, something happens inside, something comes out.

The black box is the honest part. Later chapters open the box: the Turing machine (rules), the von Neumann model (hardware), the operating system (the layer that runs programs), and the network stack (how boxes on different machines talk). Until then, treat the box as a promise that a specific input produces the promised output.CS50

The machine takes you literally

Here is the tension that drives the entire field, and the reason precision is the first thing computer science teaches. Humans communicate by intention. A computer communicates by letter.

The course uses a robot experiment to make this visceral. Tell a robot: "Put the books over there in order." Which books? All of them, or just the ones on the desk? Where is "there"? Order by what, title, size, color? A person fills those gaps using context. A robot cannot, because context is not part of the message. The instruction "put the books over there in order" is not a program. It is a wish.

So an algorithm, which is just a step-by-step recipe for a computation, must satisfy three properties: it must be finite (it ends), ordered (steps happen in sequence), and unambiguous (every step has exactly one meaning). The course puts it bluntly on one slide: "Computers only know what you tell them." Speed does not give a machine intention. If your instructions are wrong, the machine produces the wrong result very quickly. That is why computer science is not chiefly about powerful machines; it is about precise representations and reliable methods.

The recipe and the cook

Before we build anything, clear up one confusion that trips up almost every beginner: a program and a computer are two different things, and they are the two things this tutorial separately constructs.

Think of a program as a recipe. A recipe is a finite, ordered, unambiguous list of instructions: bake at 180 degrees for 25 minutes, then let cool. Think of the computer as the cook. The cook does not decide what to make; the cook follows the recipe, exactly, every time. The recipe can be brilliant or fatally vague, and the cook will faithfully produce either result. Everything else in this tutorial, from the Turing machine to the operating system to the Internet, is a mechanism for getting a human wish safely from the recipe side of the kitchen to the cook side without losing precision along the way.

So the chapter's honest summary: a computer does not guess, it executes the literal meaning, and the first job of this whole discipline is to turn intention into finite, ordered, unambiguous steps. Now let's see what the most precise description of a step ever devised looks like.

What can be computed? From Turing's tape to the stored-program computer

Turing's machine: four parts, no more

In 1936, Alan Turing was not designing a laptop. He was trying to answer a question from the 1930s: what does computation even mean, precisely enough that we can reason about its limits? His answer, now called the Turing machine, deliberately strips away every engineering detail and keeps only four parts.

First, a tape: an endless strip divided into cells, where each cell holds one symbol, say a 0 or a 1. The tape is the machine's memory. Second, a read/write head: it can read the symbol in the current cell, write a new symbol there, and move one cell left or right. The head is the machine's processor. Third, a state: a small label, like A or B, that summarizes where the computation is right now. Fourth, a table of rules: a finite list that says, for every combination of current state and scanned symbol, what to write, which way to move, and which state to enter next.Turing machine

Here is what a single moment in such a computation looks like. The drawing follows Kleene's classic diagram: a finite stretch of tape, and above the cell about to be processed, the machine's current state.

Caption: A strip of tape with symbols in its cells; the label q₄ sits above the cell that is about to be processed, marking the machine's current state. The head's position is implied by where the state label sits; no head symbol is drawn.

One rule from the course's rule table reads: "If you are in state A and you read a 1, then write a 0, move right, and change to state B." Nothing mystical happens in a long computation. It is just many of these precise little transitions chained together.

One step: read, decide, write, move

What is a single step of a Turing machine? Exactly four verbs. Read the symbol under the head. Decide which rule applies by combining the state with that symbol. Write a symbol into the cell. Move one cell left or right and update the state. Then the cycle repeats.

That four-verb cycle is the heart of the whole idea, and the course's own example rule maps onto it one-to-one. The classic 3-state busy-beaver diagram makes the "table of rules" visible as a picture.

Caption: Four states (A, B, C, and the double-circle H for halt) with arrows between them. Each arrow is labeled like 0/P,R: the symbol that triggers the transition, then what the machine prints and which way it moves. Each arrow is exactly such a conditional rule — given a state and a symbol, it says what to write, which way to move, and which state to enter; the course's example rule is a rule of this same format.

Each arrow is one conditional rule: given this state and this symbol, do this. The table of rules guarantees that every (state, symbol) pair selects exactly one next action. If no rule exists for the current pair, the machine halts.

Turing complete: expressive power, not speed

A system is Turing complete if it can simulate a Turing machine. And because a Turing machine can perform any calculation given enough time and enough tape, a Turing-complete system can too, in principle. This is a statement about expressive power, not about practicality. "Can compute" is not "can compute efficiently." If a calculation takes longer than the age of the universe, theoretical possibility gives little practical comfort, but it is still a clean boundary: whatever a Turing machine cannot do, no computer can do at all.

Nearly all programming languages are Turing complete, if the limitations of finite memory are ignored. Strictly speaking, your laptop and your phone — real machines with finite memory — are finite-state machines; they count as Turing complete only under the idealized abstraction of unlimited memory. Wikipedia's own surprising example is Conway's Game of Life, a simple cellular automaton that can simulate a Turing machine.Turing machine The course adds its own favorites, PowerPoint and the redstone circuits in Minecraft, which are the course's own examples. The lesson is the same: expressive power has nothing to do with how normal the system looks.

The universal machine: the program becomes data

Here is the step that quietly invented the modern computer. Turing also described a universal Turing machine: a single machine that can read, from its own tape, the description of any other machine, and then simulate it.

Think about what that means. The description of another machine is just symbols on tape, which is to say it is data. So the "program" for the universal machine lives in the same medium as the data it works on. The program has become data. Turing himself wrote that such a machine "can be used to compute any computable sequence," and Marvin Minsky called the idea "in essence, the invention of the modern computer." The stored-program computer, which we meet next, is this idea made out of hardware.

For the curious: this model also has hard limits. The Church–Turing thesis asserts that anything computable by any finite means can be computed by a Turing machine, and the halting problem shows that there are well-posed questions, like "will this program ever stop?", that no computer can answer in general. Those two results mark the boundary of the entire field.SEP

From abstract model to buildable machine

A Turing machine is a brilliant way to think about computation, but you cannot build one. Its tape is infinite, and nothing physical is infinite. So a second model, the von Neumann model, answers a different question: how do we organize real hardware so that it computes? The course sums up the difference in one sentence: Turing defines what computation is, abstractly; von Neumann organizes a practical stored-program computer. They are not competing brands.

The von Neumann model names four components: an arithmetic logic unit (ALU) that does calculations, a control unit that directs instruction execution, storage that holds both programs and data, and input/output that brings data in and sends results out.

Caption: The course's von Neumann block diagram: inside a frame labeled Input/output sit three modules, the orange Arithmetic Logic Unit, the light-blue Control Unit, and the green Storage, joined by white connector bars (no arrows are drawn). Together these four roles, input, processing, storage, output, are the machine.

The stored-program idea: one memory for both

The breakthrough, and the single most important idea in this tutorial, is the stored-program concept. In von Neumann's design, one addressable read-write memory holds both the program (the instructions) and the data (the values those instructions work on), and both are stored as binary patterns, sequences of 0s and 1s. The program is not wired into the machine; it is loaded into the same memory where the numbers live.von Neumann

Why is that such a big deal? Because before it, reprogramming a computer meant physically rewiring it. ENIAC, the great machine that preceded EDVAC, could take weeks to set up and debug for a new task. With a stored program, the same hardware behaves differently depending on what is loaded into memory. Load a photo editor and the machine edits photos; load a game and the same machine plays it. A computer becomes a general-purpose device instead of a one-task calculator. This is also why the concept has a credit footnote: the stored-program idea was already described in writing by J. Presper Eckert and John Mauchly of the ENIAC team in late 1943 and January 1944, before John von Neumann's famous report. Von Neumann's First Draft of a Report on the EDVAC, a 101-page typed document distributed on 30 June 1945, is the first full published description of the design, and it bears von Neumann's name alone, which is precisely why the architecture's name is contested.First Draft

The modern computer's secret, then, is one sentence: put "what to do" and "what to do it to" into the same memory, and you can swap one program for another to turn the same machine into any machine you want.

The modern variant: everything on shared buses

If you open a modern laptop, you won't find a clean diagram with four boxes; you'll find a CPU, memory chips, and input/output devices all connected by buses. The modern variant of the von Neumann model draws the same three groups, CPU, Memory, I/O, hung onto three parallel highways: a control bus, an address bus, and a data bus.

Caption: CPU, Memory, and I/O connected by short stubs to three parallel horizontal buses, labeled control, address, and data. No arrows are shown; the buses are the shared paths over which instructions and data travel.

This single-shared-bus design has a well-known cost, the von Neumann bottleneck: because instructions and data travel over the same bus, the CPU often waits for data to arrive from memory. The fix is caching, and caching is the subject of the next chapter's memory hierarchy. Notice the bridge: the block diagram tells us memory holds everything, and the bus tells us data must keep moving. Where does it move to and from? That's what "inside the machine" looks like.

From vacuum tubes to your laptop: how a model became a machine

History as a causal chain, not a date list

The history of computing is easy to misread as a timeline to memorize. The course wants you to read it as a repeating four-part pattern instead.

The abacus encodes numbers as beads on rods: a representation and a mechanism for human-assisted arithmetic. Mechanical calculators automate the operations. The Jacquard loom encodes a pattern as a sequence of punched cards, which is a program stored outside the machine. Hollerith's punched cards make data processing scalable. In every case, someone had a need, invented a representation, built a mechanism, then improved it. The key transition runs through all of them: from a device that performs one fixed operation to a machine whose behavior changes when you change an encoded sequence.

ENIAC: enormous, electronic, and programmed by hand

The pattern reaches its explosive stage with ENIAC, the Electronic Numerical Integrator and Computer, built at the University of Pennsylvania's Moore School for the U.S. Army. ENIAC was the first programmable, general-purpose, electronic, digital computer, completed in 1945 and dedicated in February 1946. Every word in that qualification does work. It was electronic (vacuum tubes, not gears or relays), digital (it worked with discrete digits), general-purpose (it could be set up for many kinds of problems), and programmable (its behavior could be changed). The qualifier matters: Britain's Colossus was electronic earlier, but ENIAC was the first machine with all four properties at once, so "first programmable general-purpose electronic digital computer" is the phrase to trust, not "first electronic computer."

The scale is the part nobody forgets. ENIAC used about 18,000 vacuum tubes, weighed 30 tons, and filled a 50-by-30-foot basement with 40 panels arranged in a U-shape. It could do roughly 5,000 additions per second. Today that sounds nothing, but for its time it was, by the University of Pennsylvania engineering school's account, a roughly 1,440× speed-up over a hand calculator on a real ballistics problem.

And here is the part that connects to the stored-program story: programming ENIAC meant physically rewiring it. Operators set thousands of switches on portable function tables and re-plugged patch cables, a process that took days for every new problem.

Caption: Betty Snyder (foreground, at a portable function table) and Glenn A. Beck (background, near the main equipment rack) programming ENIAC at the U.S. Army's Ballistic Research Laboratory. Programming meant manipulating switches and patch cables by hand; no keyboard exists in this picture.

The six women who became ENIAC's first programmers, among them Jean Jennings Bartik and Frances "Betty" Snyder Holberton, were trained mathematicians hired as "subprofessionals." They wrote the first programs for the machine by working out the wiring and switch settings on paper. They were not invited to ENIAC's public dedication dinner in 1946; their credit came decades later.

The machine's physical presence is worth one more look, because "40 panels in a U-shape" deserves a picture.

Caption: ENIAC's 40-panel U-shaped arrangement fills a Moore School basement room; a technician sets switches on one of the function tables (1946, U.S. Army Signal Corps photo). The room extends around a corner, so this is a corner of the machine, not the whole thing. ENIAC truly was 18,000 vacuum tubes in a room-sized U.

EDVAC delivers the stored program

ENIAC's successor, EDVAC, was the payoff of the stored-program idea from the previous chapter. Built at the same Moore School, EDVAC was binary rather than decimal, and it was designed as a stored-program computer: its instructions lived in memory alongside its data, so changing the task no longer required physical rewiring. It became operational in 1949. The architectural bridge is exact: the machine described in von Neumann's 1945 First Draft is the machine that EDVAC built.

Five generations of improvement

From there, the course organizes sixty years of history into five generations, each defined by its enabling technology rather than by a year boundary.

Each generation answered a failing of the last. Vacuum tubes were large, hot, and unreliable; several ENIAC tubes burned out almost daily. Transistors replaced them and shrank computers dramatically. Integrated circuits, invented by Jack Kilby in 1958 and Robert Noyce in 1959, packed many components onto one chip. The microprocessor, beginning with the Intel 4004 in November 1971, concentrated a whole CPU on a single chip and made the personal computer possible. The course's five-generation framing adds a fifth stage of parallel and high-performance machines after 1985, an industry convention rather than a strict historical classification.ENIAC

The visual evidence for "improvement" is the famous Moore's law chart: the number of transistors on a chip, plotted year by year on a log scale.

Caption: Transistor counts on microprocessors from 1970 to 2020 (Our World in Data), plotted on a logarithmic scale. The near-straight upward march is the empirical regularity called Moore's law: the number of transistors doubles roughly every two years. This is the "improvement" stage of the pattern made visible.

Open the box: four jobs that never change

Here is the deep continuity the history section is really teaching. The physical technology changed from gears to vacuum tubes to transistors to integrated circuits. The jobs never did. Every machine in that history receives information (input), transforms it according to instructions (processing), keeps state (storage), and communicates a result (output). A smartphone and a supercomputer differ in scale and specialization; both still do those four jobs.

Why memory has layers

Now open the box further. Modern computers don't have one memory; they have a ladder of them, and the reason is a hard trade-off: memory that is fast is expensive, and memory that is cheap is slow.

The canonical picture of this ladder comes from Bryant & O'Hallaron's classic textbook Computer Systems: A Programmer's Perspective (CSAPP). At the top sit the CPU registers, a handful of words the processor can touch instantly. Below them come small, fast SRAM caches (L1, L2, L3), then main memory built from DRAM, then local disks, then remote storage on other machines.

Caption: The memory hierarchy pyramid: registers at the top, then SRAM caches (L1, L2, L3), DRAM main memory, local disks, and remote secondary storage at the bottom. The left side of the pyramid carries the whole trade-off: smaller, faster, costlier per byte going up; larger, slower, cheaper per byte going down.

Why does a ladder work instead of just buying the fastest memory everywhere? Because speed costs money at every rung. A register access takes essentially zero cycles. A cache access takes one to thirty cycles. Main memory takes fifty to two hundred. A disk access takes tens of millions of cycles. That gap of six orders of magnitude is why a programmer who keeps working data in cache can be far faster than one who thrashes to disk. The trick of the hierarchy is that most programs reuse recently accessed data, so a small fast layer can serve most access requests.CSAPP

The two memory technologies at the heart of this are SRAM and DRAM. SRAM stores each bit in a six-transistor cell and is fast but costs roughly a hundred times more per bit; DRAM stores each bit as a tiny charge in a capacitor plus one transistor, so it is cheap but leaks, which is why DRAM must be periodically refreshed. That is the trade-off compressed into silicon.

Every layer is a cache for the one below

The single mechanism that holds the ladder together is caching. Each layer keeps a copy of the most-used pieces of the layer below it. Registers cache the L1 cache; L1 caches L2; the caches cache main memory; main memory caches the local disk; the local disk caches remote servers. Every adjacent pair behaves the same way, which is why the general diagram uses the placeholder names "Level k" and "Level k+1".

Caption: The generic caching mechanism: the smaller, faster device at Level k holds a subset of the blocks stored in the larger, slower device at Level k+1 (here 4 of 16, purely illustrative numbers), and data moves between the two levels in block-sized chunks.

The course's everyday version of the ladder is the desk analogy: the page you are reading is in your hand, the books you are using sit on the desk, more books are on the shelf, and the library holds everything else. You don't keep the entire library in your hand; you arrange access by likely need. That is exactly the memory hierarchy, and it is also the reason the program lifecycle in the next chapter is a climb: instructions and data start on disk and get pulled upward, rung by rung, as they are needed.

This is also the right moment for the CPU's working rhythm. Inside the processor, every instruction cycles through four stages, which the course presents as fetch, decode, execute, store, the textbook naming used in Patterson & Hennessy's Computer Organization and Design, another course citation. Read the next instruction from memory, decode what it means, execute the operation, store the result, and repeat, millions or billions of times per second.

Binary: everything becomes patterns

You've seen the word "binary" several times now; let's make it concrete. A bit is one binary digit, a 0 or a 1. A byte is 8 bits. Storage sizes climb by powers of two: 1 KB = 1024 bytes, 1 MB = 1024 KB, 1 GB = 1024 MB, and so on up to terabytes and petabytes. Everything in a computer, numbers, text, images, video, and program instructions, is ultimately a pattern of bits. Meaning comes from how software interprets the pattern.

Any decimal number can be converted to binary by subtracting powers of two. The course works through 13:

So decimal 13 is binary 1101. Check it backward: 8 + 4 + 0 + 1 = 13. And because each bit doubles the possibilities, 8 bits give 256 distinct patterns, enough for values 0 to 255.

The takeaway of the whole chapter stands: hardware changed from gears to tubes to chips, yet the four jobs, input, processing, storage, output, never changed, and "memory" turned out not to be one thing but a ladder on which you buy speed with money.

From Python to electrons: languages, the operating system, and pressing run

The language ladder

We now have a machine whose memory holds patterns of bits. But nobody wants to write programs as patterns of bits. So the software layer exists to let humans express intent on one end while the machine executes literals on the other, and the bridge between the two is a sequence of languages.

The ladder has four rungs. At the top is natural language (English, Chinese), rich but ambiguous. Below it are high-level languages like Python, C++, and Java, which use precise syntax and hide processor details. Below those is assembly language, which gives symbolic names to the machine's actual low-level instructions. At the bottom is machine language, the binary patterns the processor literally executes.

The course shows the ladder with one task, printing all primes between 0 and 100, expressed at two rungs:

Same meaning, dramatically different length. Python is not automatically faster; it is easier for humans to read, test, and maintain, precisely because it hides registers, jumps, and machine-specific details. That hiding is the point of the ladder: each rung preserves meaning while removing detail.

Compiler vs interpreter: before or during

How does a program in a high-level language get down to machine code? Two classic strategies. A compiler translates the whole program before execution: source code goes in, an executable file comes out, and that executable can be reused without recompiling. An interpreter executes the source code at run time, line by line, which makes experiments and updates convenient but usually slower in execution.

The course's honest caveat: real implementations mix both. Python, for instance, compiles your source into an intermediate form called bytecode and then interprets that bytecode. Modern systems also use just-in-time (JIT) compilation, which compiles hot parts of a program while it runs. So the useful question is never "is this language compiled or interpreted?" but "when does translation happen, and what trade-off does this implementation make?"

(Nothing in the reference material for this tutorial covers compilers in depth; the mechanism above follows the course's own slides. If you want the deeper view, the canonical target is a compiler textbook or a toolchain's own documentation.)

Software: system and application

On top of languages, software splits into two camps. System software exists to run the computer and other software: operating systems like Windows, Linux, and Android; compilers and language tools; security and disk utilities. Application software exists to solve a user's problem directly: browsers, office suites, games, messaging apps, and specialized systems like library management or industrial control. The boundary is fuzzy in practice, so the course suggests asking a role question: does this software primarily enable the system and other programs, or does it directly serve a user task?

The operating system: allocator, isolator, abstractor, server

The most important piece of system software is the operating system (OS). Its textbook definition: system software that manages computer hardware and software resources and provides common services for computer programs.OS

The course unpacks this into four roles. The OS allocates CPU time and memory among running programs so no single app monopolizes the machine. It isolates applications from one another's bugs and security holes. It abstracts the hardware, hiding physical details behind clean interfaces, for example virtual memory, which gives a program the illusion of more memory than physically exists. And it serves common needs such as disk and network access, so applications don't have to talk to every kind of hardware directly.

Where does the OS sit? Between you and the machine, in a four-layer stack.

Caption: The four-layer placement: User on top, then Application, then the Operating System, then Hardware, with bidirectional arrows between adjacent layers. This diagram shows where the OS lives, not what's inside it; the internals come next.

The kernel: the always-running core

The part of the operating system that is always running is the kernel. Its central job is protection: keeping applications and users from interfering with each other, so a misbehaving program cannot crash the system or read another user's private data. To do that, most chips support two modes of operation: user mode, where applications run under restriction, and kernel mode (supervisor mode), where the OS itself runs with full privileges. Applications request privileged services by making system calls, and the hardware enforces that ordinary programs can only touch their own memory.

Caption: The kernel as a middle layer: Applications at top, the Kernel in the middle, and CPU, Memory, and Devices at the bottom, with arrows between each pair. The figure shows only the kernel's position as intermediary, not its internal subsystems.

The life of a program, from double-click to close

Now watch the software layer and the hardware layer work together. The course traces the life of a program as a small story, which is where the previous chapter's memory ladder finally gets used.

You double-click a .exe file. The file system reads the file from disk. The operating system allocates memory, creates a process (a running program with its own protected memory space), loads the program's instructions and data into that memory, and schedules the process on a CPU. Inside the CPU, instructions run through fetch, decode, execute, store, pulling data up the hierarchy as needed: from disk into DRAM, from DRAM into cache, from cache into registers, where the ALU can actually operate on it. When the program wants to change the display, it sends a signal, the display updates, and you see the result. When you close the program, the OS stops scheduling it, reclaims its memory, and updates the display again. Cleanup matters: resources that are never released slowly eat the machine.

The point of the whole software layer is now clear. Compilers, interpreters, and the operating system are all doing the same job from the first chapter: letting humans stay on the "express intention" side while machines stay on the "execute the literal words" side, with the software in between absorbing the difference.

How do computers talk? Networks, addresses, and the agreements that make them work

From one machine to many

Everything so far has been one machine. Networks extend the story: one idea, executed by a stored-program machine, now shared among billions of them.

A network is a set of interconnected devices that communicate. The devices come in two kinds. Hosts are endpoints, machines that create and consume data: your laptop, your phone, a web server. Connecting devices sit in between and forward data: a switch connects devices in one place, a router connects one network to another. Transmission can be wired (copper cable, optical fiber) or wireless (radio signals).

Networks are named by how far they span. A local area network (LAN) covers one home, office, or campus. This is the network inside your router.

Caption: A residential LAN: desktop PC, smart TV, and game console connect by wired Ethernet (solid lines), while the notebook, smartphone, and printer join by Wi-Fi (dashed lines). Everything meets at the router, which connects through a modem, the wall socket, and the ISP's infrastructure up to the Internet.

A wide area network (WAN) connects LANs across a city, country, or the world, and notably, it interconnects routers and networks rather than individual hosts. The Internet is the global system of interconnected networks that communicate using the TCP/IP protocol family: a network of networks.

One confusion to kill early: the Internet is not the Web. The course's analogy is roads and delivery services. The Internet is the road infrastructure; the Web is one delivery service using the roads, and email, file sharing, voice calls, and online games are other delivery services on the same roads. When a website fails while email still works, the diagnosis is often that the road is fine and one delivery service is broken.

Why protocols: agreed rules beat perfect bits

Why do networks need protocols at all, instead of just sending bits? Because bits arriving perfectly can still fail to communicate. The course's example: one side puts the address at the start of a message, the other expects it at the end. Every bit arrives intact, and the message is meaningless. Communication requires prior agreement on the message format, on the order of exchanges and expected responses, and on what to do when data is lost or corrupted. A protocol is exactly that agreement, written down and followed by both sides. Machines cannot repair ambiguity with social context the way people can, so the agreement must be complete before communication starts.

The TCP/IP stack: four layers

The Internet's actual architecture is a layered model, and a layer is a way of dividing one huge problem into smaller agreed jobs. The TCP/IP model, formalized in 1989 in RFC 1122 and RFC 1123, has four layers. At the bottom, the link layer moves data across one physical network (Ethernet, Wi-Fi). Above it, the internet layer (where IP lives) handles addressing and routing across many networks. Above that, the transport layer (where TCP lives) provides end-to-end communication between hosts. At the top, the application layer is where the protocols people actually use live: HTTP for web pages, DNS for name lookup, SMTP for email.

The classic diagram shows why layering works: from the application's point of view, the two hosts appear to talk directly, as though the network in between did not exist.

Caption: Two hosts, A and B, each wrapped in four concentric layers (Application, Transport, Internet, Link), with two routers between them. At the application layer the hosts appear directly connected; at the internet layer the routers appear as visible intermediaries. This is the TCP/IP model, not the OSI model.

Layering means each layer offers a service to the one above and uses the one below, and a layer can change internally without forcing everything else to be rewritten. A new Wi-Fi technology can replace the old one at the link layer, and your browser, sitting at the application layer, never notices.

Who does what: IP and TCP

Within that stack, two protocols do most of the visible work, and it helps to keep their jobs straight. IP, the Internet Protocol, answers "where does this packet go?" It gives every host a numbered address and routes packets hop by hop toward the destination, but it is best-effort: packets can be lost, duplicated, or arrive out of order, and IP does not care.RFC 791

TCP, the Transmission Control Protocol, answers "did it all arrive, in order?" It establishes a connection, numbers every byte, retransmits what is lost, and hands the application a clean, ordered byte stream.RFC 9293

A useful shorthand from the course: IP works on where packets should go; TCP works on reliable, ordered delivery.

Addresses: IPv4 and IPv6

An IP address is a numeric label that lets the network move a packet toward a destination. Be careful with one common misreading: an IP address is delivery information, not a person's identity. Addresses can change, one device can have several, and the same private address can appear on many home networks.

The current standard, IPv4, uses 32-bit addresses written as four decimal numbers separated by dots, one byte each. The course's example:

Caption: The IPv4 address 192.168.43.241 shown as four decimal octets, each labeled 8 Bits (1 Byte), with a brace underneath marking the total: 32 Bits (4 Bytes). The dots do not create four separate addresses; the four octets together form one 32-bit address.

Thirty-two bits means about 4.3 billion possible addresses, and with billions of connected devices, that pool is long exhausted. The successor, IPv6, uses 128-bit addresses. The slide's framing gets the point across: 128 bits is four times as many bits, and the number of possible patterns does not merely quadruple, it explodes, since 2^128 = (2^32)⁴. With IPv6 the address problem is solved for practical purposes.

DNS: the Internet's phone book

IP addresses are what the network uses, but people remember names like google.com. The Domain Name System (DNS) translates between the two; the course calls it the phone book of the Internet. The flow is short: you type www.google.com, a DNS server is asked to resolve the name, it returns an IP address, and then the browser contacts that address to request the page. DNS does not deliver the webpage itself, it only supplies the destination information; other protocols carry the actual request and response. Note the division of labor the first chapter predicted: people stay on the name side, machines stay on the address side, and DNS is the software absorbing the difference.

OSI: a conceptual map of the same idea

You will also meet a seven-layer model, the OSI model (Open Systems Interconnection). It defines seven layers: Physical, Data Link, Network, Transport, Session, Presentation, and Application, each with a focused task, from transmitting raw bits, to routing, to end-to-end delivery, to application access.AWS OSI

The honest takeaway: OSI is a conceptual reference model for education and design thinking, while TCP/IP is the four-layer architecture the Internet actually runs. The seven-layer model's detail is useful for talking about networks; the four-layer model is what packets actually follow. The standard behind the OSI model is ISO/IEC 7498-1:1994, published jointly as ITU-T Recommendation X.200, approved 1 July 1994.X.200

One last picture for the intuition behind layering: encapsulation. The sender's data descends the stack, and each layer wraps the data with its own header before handing it lower. The receiver ascends the stack, unwrapping one header per layer, until the application gets precisely the original data back.

Caption: Build-up packets: on the sender's side, each layer adds its own header to the data as it descends toward the physical layer; on the receiver's side, each layer strips its header as the data climbs back up.

The Internet, then, is fundamentally a pre-agreed set of speaking rules. Given the rules, the addresses, and the routing, "how does my data find the other machine?" stops being black magic and becomes a bookkeeping problem with a very good system behind it.

Open one webpage, see every layer: your mental map of the whole machine

The widening lens

Stop and notice the shape of the journey so far. It is a widening lens. We began with one idea, computation. We gave it a precise model, Turing's machine. We built that model out of hardware, von Neumann's stored-program computer. We zoomed into the hardware and saw a ladder of memories. We zoomed out to the software running on that hardware, then farther out to millions of machines talking over the Internet. One idea, one stored-program machine, many cooperating machines.

Now the closing exercise, which is the course's final question made concrete: take one action you do every day and identify one idea from each lecture inside it. Let's open a webpage.

Tracing www.google.com

Type www.google.com into the address bar and press Enter. Here is everything that happens, in order.

First, the browser asks DNS to turn the name into an IP address. That is networks doing the name-to-address translation we met in the last chapter, complete with the phone-book division of labor: you typed a name, the machine needs a number.

Second, the browser opens a connection to that IP address. The request is handed down the TCP/IP stack, wrapped in TCP and IP headers, and carried across your LAN, through the WAN, and across the Internet, hop by hop, to a machine belonging to Google.

Third, that machine is a stored-program computer, exactly the von Neumann design from the second chapter: instructions and data in one addressable memory. The server's program, a web server, is the product of compilers and interpreters, and it runs under an operating system, the fourth chapter's allocator, isolator, abstractor, and service provider. The OS read the server program from disk, created a process, and loaded it into memory.

Fourth, inside that machine, the CPU executes the server program instruction by instruction: fetch, decode, execute, store. Each instruction pulls its data up the memory hierarchy from the disk at the bottom of the ladder, through DRAM and cache into the registers, then pushes results back down. The page you requested is assembled and sent back along the same network path, wrapped and unwrapped at every layer.

Fifth, and this is the quietest layer, everything in that chain is in principle a Turing machine step. The web server, the OS, the router firmware, all of them are rule tables being followed one transition at a time, exactly the read, decide, write, move cycle from the second chapter, executed at enormous speed.

Here is the whole chain in one picture, with each branch pointing back to the chapter that explains it.

Every edge of that picture is a causal chain from the previous five chapters, not decoration. Which brings us to the course's final promise and this tutorial's purpose: a computer is not a pile of unrelated terms, it is a chain from intention to electrons, and you can now narrate every link between your click and the result on screen.

The habit

Keep one habit from this chapter. Whenever you open an app, ask: "what is this computer actually doing right now?" Then place what you find under one of the four organizing questions: is this about what can be computed, how we express a solution, how a machine executes it, or how machines cooperate? That single habit is the whole discipline in miniature. You clicked, you understood, and the million exact steps between the two are no longer invisible.

References

The core sources cited in this tutorial are listed below; we recommend reading the originals for deeper study:

1. Foundations of Computer Science, 5th Edition (Behrouz A. Forouzan, Cengage EMEA 2023) — https://www.cengage.uk/c/foundations-of-computer-science-5e-forouzan/9781473787322/
2. Turing machine — Wikipedia — https://en.wikipedia.org/wiki/Turing_machine
3. Turing Machines — Stanford Encyclopedia of Philosophy (Liesbeth De Mol) — https://plato.stanford.edu/entries/turing-machine/
4. Von Neumann architecture — Wikipedia — https://en.wikipedia.org/wiki/Von_Neumann_architecture
5. First Draft of a Report on the EDVAC — Wikipedia — https://en.wikipedia.org/wiki/First_Draft_of_a_Report_on_the_EDVAC
6. ENIAC — Britannica — https://www.britannica.com/technology/ENIAC
7. The Memory Hierarchy — Bryant & O'Hallaron, CSAPP3e Chapter 6 — https://csapp.cs.cmu.edu/2e/ch6-preview.pdf
8. Operating system — Wikipedia — https://en.wikipedia.org/wiki/Operating_system
9. CS50 Lecture 0 Notes (Spring 2026) — Harvard CS50 — https://cs50.harvard.edu/college/2026/spring/notes/0/
10. RFC 791 (Internet Protocol) / RFC 8200 (IPv6) / RFC 9293 (TCP) — https://www.rfc-editor.org/rfc/rfc791.html
11. What Is the OSI Model? — AWS — https://aws.amazon.com/what-is/osi-model/
12. ISO/IEC 7498-1:1994 / ITU-T X.200 (OSI Basic Reference Model) — https://www.itu.int/rec/T-REC-X.200/en