Chapter 1: Introduction to the Web and Internet Technologies#

Imagine typing an address into your browser. Less than a second later, a complete page appears. Behind that everyday magic is a carefully organised system of rules, servers, and code — a system so reliable we rarely think about it. This chapter shows you how it works, so you have the big picture before you write any HTML.

Hypertext Transfer Protocol (HTTP): A set of rules for how clients and servers exchange messages. It's a request-response protocol: the client asks, the server answers, and then the conversation is over.

The Big Picture#

The web isn't one thing. It's a set of agreements that let computers talk to each other, find each other, and turn raw text into the pages we see. This chapter takes you on the journey of a web request — from pressing Enter to seeing a full page. By the end, you'll understand the client‑server model, HTTP's stateless requests, how domain names translate to IP addresses, the steps a browser takes to show a page, the groups that keep the web open, and the three languages that give pages structure, style, and interactivity.

The Web's Conversation: HTTP and the Request‑Response Cycle#

When you visit a website, your browser and a faraway computer talk using a set of rules called the Hypertext Transfer Protocol (HTTP). It's a simple system: your browser (the client) sends a request, and the server sends back a response — or explains why it can't.

HTTP is a request‑response protocol. The client always starts the conversation. The request has:

• a method (like GET to grab a page, or POST to send form data),
• a Uniform Resource Locator (URL) saying what it wants,
• a set of headers with extra info (browser type, accepted languages),
• and sometimes a body (used mainly with POST to carry data).

The server reads the request, does whatever work is needed, and sends back a response with:

• a status code — a three‑digit number like 200 (OK, here is your content), 404 (I can't find that), or 500 (something went wrong on the server),
• response headers with details about the content (type, length, caching hints),
• and a body — the actual HTML, image, or data.

Stateless: HTTP is designed to be stateless. The server does not remember anything about a previous request when it handles the next one. Every request is treated as brand new. That keeps the protocol simple and makes it easy to scale — later we add memory with cookies, tokens, and databases.

Think of HTTP like ordering at a fast‑food counter. You walk up, say "I'd like a cheeseburger and fries," the cashier hands you the food (or tells you they're out of fries), and the transaction is over. If you walk up again two minutes later and ask for a drink, the cashier doesn't assume you still want the same meal — you have to say it again. That is statelessness in action.

📝 Section Recap: HTTP is a stateless request‑response protocol where a client sends a request (method, URL, headers, optional body) and a server replies with a status code, headers, and content. Every request stands alone, which makes the web scalable.

The Client‑Server Model: A Partnership of Roles#

The web is built on the client‑server model. A client is any device or program that asks for information. A server is a program (running on a powerful computer) that waits for requests and sends back responses. Your laptop running a browser is a client; the machine at example.com that sends you a webpage is a server.

Client‑server model: Clients ask for resources; servers provide them. They are separate programs, often on different machines.

This separation brings several advantages:

• Specialisation. Servers can focus on storing data, running business logic, and handling thousands of requests per second. Clients can focus on displaying graphics, capturing user input, and running interactive code.
• Centralised resources. One server can serve millions of clients. Update the server once, and every client sees the change immediately.
• Scalability. Because the server doesn't keep a permanent connection and HTTP is stateless, you can spread the work across many servers behind a load balancer. The client doesn't need to know which physical machine answers.
• Security boundaries. The client never gets direct access to the server's database or file system. It can only ask for things through the safe interface the server exposes.

A helpful analogy is a library. You (the client) ask the librarian (the server) for a specific book. The librarian goes to the back room, retrieves the book, and hands it to you. You never walk into the back room yourself. The librarian does not need to remember that you asked for a book yesterday; each request is handled independently.

📝 Section Recap: The client‑server model splits responsibilities: clients request resources, servers provide them. This enables specialisation, centralised management, scalability, and a clear security boundary.

Finding Servers: DNS and Domain Names#

You type www.example.com into your browser, but computers on the internet identify each other by numerical IP addresses, like 93.184.216.34. The Domain Name System (DNS) is the internet's phonebook — it translates the friendly names we use into the numbers machines need.

Domain Name System (DNS): The internet's directory service. It turns domain names like google.com into IP addresses, so you don't have to memorise long numbers.

DNS is organised as a hierarchy, read from right to left. Take the domain www.example.com. (the trailing dot is usually hidden):

• The rightmost part (.) is the root.
• Next comes the top‑level domain (TLD): .com, .org, .net, or country codes like .uk.
• Then the second‑level domain: example.
• Finally, the subdomain: www (just a convention; you could use blog.example.com or shop.example.com).

When you first visit a site, your browser asks a DNS resolver (often provided by your internet service provider) to look up the name. The resolver may already have the answer saved (cached). If not, it walks down the hierarchy: it asks a root server for the .com TLD server, then asks that TLD server for the server that knows about example.com, and finally asks that authoritative server for the IP address of www.example.com. The whole chain usually completes in tens of milliseconds.

Caching: DNS results are stored temporarily at every level — in your browser, your operating system, your router, and your ISP's resolver — so repeated lookups are lightning fast.

Think of DNS like a giant, shared phone book. You know your friend's name, but your phone needs their number. You check your phone's contact app, which might already have it. If not, it asks a company directory, which asks a department directory, until the right number is found.

📝 Section Recap: DNS converts domain names into IP addresses through a hierarchical lookup, with caching at every step to make the process fast and efficient.

From URL to Pixels: The Browser Rendering Pipeline#

What happens between pressing Enter and seeing a page? The journey is a browser rendering pipeline — a sequence of steps that turns a URL into interactive pixels on your screen.

Browser rendering pipeline: The step‑by‑step process a browser uses to transform HTML, CSS, and JavaScript into the visual page you see.

1. URL Parsing. The browser checks if you typed a search term or a URL. If it's a URL, it picks out the protocol (https), domain, port (usually implied), path, and any query parameters.
2. DNS Lookup. If the domain's IP address isn't already saved, the browser does a DNS resolution to get the server's IP address.
3. Establishing a Connection. The browser opens a Transmission Control Protocol (TCP) connection to the server's IP address on port 443 for HTTPS. TCP ensures data arrives reliably and in order. If the URL uses https, a Transport Layer Security (TLS) handshake follows. This encrypts the connection and verifies the server's identity through a digital certificate.
4. Sending the HTTP Request. With a secure connection up, the browser sends an HTTP request — usually a GET for the main HTML document.
5. Server Processing and Response. The server receives the request, runs any necessary back‑end code (querying a database, assembling a page), and sends back an HTTP response containing the HTML.
6. Parsing HTML and Building the DOM. The browser reads the HTML and builds a tree called the Document Object Model (DOM). The DOM represents the page's content and structure as objects that JavaScript can later change.
7. Fetching Sub‑resources. As the parser finds references to external resources — stylesheets (<link>), scripts (<script>), images (<img>), fonts — it requests them, often in parallel. CSS files are downloaded and turned into a second tree called the CSS Object Model (CSSOM).
8. Constructing the Render Tree. The browser combines the DOM and CSSOM into a render tree. This tree contains only the visible elements and their final computed styles.
9. Layout (Reflow). The browser calculates the exact position and size of every element on the screen, based on the viewport size and CSS rules.
10. Paint. The browser fills in pixels for each element: colours, text, borders, shadows. It may create multiple layers for complex elements.
11. Compositing. The separate painted layers are assembled into the final image you see. This step is heavily optimised by the graphics hardware.

If the browser meets a <script> tag, it may pause and run the JavaScript before continuing. Modern sites use async or defer attributes to avoid that pause.

The whole pipeline feels like a factory assembly line, but each stage is tuned so that most pages appear in under a second.

📝 Section Recap: The browser rendering pipeline transforms a URL into a visible page through DNS lookup, TCP/TLS connection, HTTP request, HTML/CSS parsing, DOM and CSSOM construction, render tree, layout, paint, and compositing.

The Rules of the Road: Web Standards and the W3C#

The web works across billions of devices because everyone follows the same web standards. These are written by groups like the World Wide Web Consortium (W3C), the Web Hypertext Application Technology Working Group (WHATWG), and the Internet Engineering Task Force (IETF).

Web standards: Openly developed specifications that define how the web should work. Browser makers choose to follow them so that code runs the same everywhere.

The W3C, started by Tim Berners‑Lee in 1994, publishes specifications for HTML, CSS, and many other web technologies. Browser vendors (Google, Apple, Mozilla, Microsoft) voluntarily implement these specifications. The WHATWG maintains a "living standard" for HTML — one document that is constantly updated instead of having version numbers.

Other important bodies:

• IETF oversees core internet protocols like HTTP and TCP, published as "Request for Comments" (RFCs).
• Ecma International standardises ECMAScript, the official specification behind JavaScript.
• Web Accessibility Initiative (WAI), part of the W3C, develops guidelines (WCAG) to make the web usable by people with disabilities.

Standards evolve through proposal, discussion, and consensus. Browser makers often test new features behind flags. Once a specification stabilises and multiple browsers ship it, developers can use it safely. This open, collaborative process keeps the web from breaking into incompatible pieces.

📝 Section Recap: Web standards, developed by the W3C, WHATWG, IETF, and others, ensure that the web works consistently. They are openly discussed and voluntarily adopted by browser makers.

The Building Blocks: HTML, CSS, and JavaScript#

Every web page is made from three core technologies, each with its own job:

• HyperText Markup Language (HTML) gives the page structure and meaning. It uses tags to mark headings, paragraphs, lists, links, images, and more. Think of HTML as the skeleton and organs — it says "this is a navigation bar," "this is an article," "this is a button."

HTML: A markup language that defines the content and structure of a web page. It's the universal skeleton every page is built on.

• Cascading Style Sheets (CSS) controls presentation and layout. It handles colours, fonts, spacing, positioning, and animations. CSS is the skin and clothing — it makes the skeleton look good and adapt to different screen sizes.

CSS: A styling language that sets how a page looks — colours, layout, fonts, and movement. It separates design from content.

• JavaScript (JS) adds behaviour and interactivity. It can respond to button clicks, check form inputs, fetch new data without reloading the page, and change the HTML and CSS on the fly. JavaScript is the muscles and brain — it makes the page do things.

JavaScript: A programming language that brings web pages to life, handling everything from simple clicks to complex, dynamic web apps.

These three languages are deliberately kept separate. You can redesign a site's entire look by swapping the CSS file without touching the HTML. You can add a new interactive feature with JavaScript while leaving the structure and style alone.

Here's a real‑world analogy: building a house. HTML is the blueprint that defines rooms, doors, and windows. CSS is the interior design — paint colours, furniture placement, curtains. JavaScript is the electrical wiring and plumbing that makes lights turn on when you flip a switch and water flow when you turn a tap.

Progressive enhancement: A key principle: the content should be readable even without CSS or JavaScript. A well‑structured HTML document works on a basic screen reader or an old phone. CSS and JS enhance the experience, but the content remains the foundation.

📝 Section Recap: HTML gives a page structure and meaning, CSS controls its visual presentation, and JavaScript adds interactivity. They work together but are kept separate for easier maintenance and better accessibility.

Summary#

We've gone behind the scenes of a web request. You now know that the web uses a stateless protocol called HTTP, with a client‑server model that splits jobs. DNS translates names to numbers. The browser builds a page step by step. Web standards make sure everything works together. And HTML, CSS, and JavaScript give each page structure, style, and action. With these ideas, you're ready to start building.