---
title: 'Hosting Models'
source: 'https://academia.sh/en/courses/how-the-internet-works/hosting-models'
course: 'How the Internet Works'
language: en
updated: '2026-08-17T18:07:03+00:00'
license: 'CC BY-SA 4.0'
---

# Hosting Models

The requirement that a server keep running continuously, how name-based virtual hosting works, and the trade-offs among shared, virtual, dedicated and managed models.

The previous lesson established that the name `example.test` points to the address
`192.0.2.10`. What remains is the question: what is at that address?

The answer is a relative of the program written in the Client-Server Model lesson: a
process waiting on a port, taking a request and answering it. This lesson covers where
and how that process is run.

## The Problem Hosting Solves

Three conditions must be met for a server program to run; all three were established
separately in earlier lessons.

**A stable, reachable address.** As seen in the IP Address Concept lesson, a machine
with a private address cannot be reached from outside, and automatically assigned
addresses change. The server needs a public, unchanging address.

**Continuous operation.** As established in the Client-Server Model lesson, a server
does not know when a request will arrive; it must be listening at all times. This means
the machine must not shut down, the network connection must not drop, and the process
must be restarted if it crashes.

**Operation.** Hardware failure, software updates, backups and rising load all have to
be handled.

**Hosting** is providing these three conditions as a service. An organization keeping a
machine running continuously in its own building is also hosting; the difference lies in
who meets the conditions.

## One Address, Multiple Names

The technical basis that makes hosting operable is that a single address can serve
multiple domain names. Addresses are a limited resource; needing a separate address for
every domain name would make the cost prohibitive.

The problem is this: a packet arrives at an address, and the address denotes a single
machine. How is the server to know which domain name the request was made for?

The answer is carried in the request itself. The client states the name it connected to
in the request's `Host` header. This line already appeared in the output of the
Client-Server Model lesson:

```
> GET / HTTP/1.1
> Host: example.test:8080
```

The server decides which site to serve by looking at this header. This scheme is called
**name-based virtual hosting**.

The server below listens on a single address and port but serves two separate sites:

```python
from http.server import BaseHTTPRequestHandler, HTTPServer

SITES: dict[str, bytes] = {
    "example.test": b"<h1>Example Site</h1>\n",
    "demo.test": b"<h1>Demo Site</h1>\n",
}


class Handler(BaseHTTPRequestHandler):
    protocol_version = "HTTP/1.1"

    def log_message(self, format_: str, *arg: object) -> None:
        pass

    def do_GET(self) -> None:
        host = self.headers.get("Host", "").split(":")[0]
        body = SITES.get(host, b"<h1>Unknown host</h1>\n")
        status = 200 if host in SITES else 404
        self.send_response_only(status)
        self.send_header("Content-Type", "text/html; charset=utf-8")
        self.send_header("Content-Length", str(len(body)))
        self.end_headers()
        self.wfile.write(body)


HTTPServer(("127.0.0.1", 8080), Handler).serve_forever()
```

While the server is running, three requests are made. All three go to the same address;
only the declared name changes.

```sh
curl -s --resolve example.test:8080:127.0.0.1 http://example.test:8080/
curl -s --resolve demo.test:8080:127.0.0.1    http://demo.test:8080/
curl -s --resolve other.test:8080:127.0.0.1   http://other.test:8080/
```

```
<h1>Example Site</h1>
<h1>Demo Site</h1>
<h1>Unknown host</h1>
```

All three requests went to port 8080 on address `127.0.0.1` and got three different
answers. The only thing that made the distinction was the `Host` header.

This has two consequences. First, sites sharing an address cannot see each other at the
address level; the distinction is made inside the server program. Second, this header is
mandatory: a client that fails to declare it makes it impossible for the server to
determine which site to serve.

## Hosting Models

Who meets the three conditions, and at what level, is what separates the models.

### Shared Hosting

A single machine runs many customers' sites on the same operating system. The virtual
hosting scheme above is directly the basis for this model.

Because resources are shared, this is the lowest-cost model, and the entire operational
burden sits with the provider. The price is weak isolation: the resources one site
consumes affect the other sites on the same machine. Configuration options are limited
to whatever the provider allows; there is no operating-system-level control.

### Virtual Private Server

A single physical machine is split, through virtualization, into multiple virtual
machines isolated from one another. Each customer has its own operating system and its
own administrative privileges.

Because resources are separated by defined limits, the neighbor effect is markedly
reduced; software choice and configuration are under the customer's control. In
exchange, operating system maintenance, security updates and backups become the
customer's responsibility.

How isolation is achieved — namespaces, control groups and virtualization — is covered
in the Kernel Interfaces and Isolation course.

### Dedicated Server

The entire physical machine is assigned to a single customer. There is no resource
sharing; hardware choice and predictability of performance are at their highest.

Cost is paid for the whole machine whether it is used or not. The impact of a hardware
failure is direct, and redundancy has to be set up separately.

### Managed Hosting

The distinguishing criterion is not hardware but **the boundary of responsibility.** In
a managed model, the provider takes on not just the machine but the operation of the
software running on it as well: updates, backups, monitoring and scaling.

The customer gives up part of its configuration freedom in exchange for being relieved
of the operational burden. This model does not sit on the same axis as the other three;
a virtual private server or a dedicated server can equally well be offered in managed
form.

### Comparison

| Criterion | Shared | Virtual private | Dedicated | Managed |
|---|---|---|---|---|
| Isolation | Weak | Defined limits | Full | Depends on model |
| Administrative privilege | None | Yes | Yes | Limited |
| Operational burden | Provider | Customer | Customer | Provider |
| Performance predictability | Low | Medium | High | Depends on model |
| Relative cost | Lowest | Medium | Highest | Depends on service |

No single option is superior on every criterion. The choice depends on the balance
between the site's requirements and the effort that can be devoted to operating it.

## Static and Dynamic Content

Another distinction that shapes hosting requirements is how the content is produced.

With **static content**, the server sends a file from disk as is. Every request produces
the same response. This kind of content requires no computation and is cheap to
replicate.

With **dynamic content**, the response is computed when the request arrives: a database
is queried, sections specific to the user are generated. Every request consumes
processor time and memory; scaling it is markedly harder than scaling static content.

This distinction leads to a placement decision. Static content can be replicated across
servers distributed close to users. In this scheme a user's request goes to the copy
nearest to it; because latency, as established in the What Is a Network lesson, is
bounded by propagation distance, the gain is direct. Dynamic content, on the other hand,
stays tied to where its state is held and cannot be replicated this way.

This is why the two kinds of content are separated in practice: a page's unchanging
parts come from distributed copies, its user-specific parts from the origin server.

## Summary

- Hosting provides a stable address, continuous operation and operational conditions for
  a server program.
- Name-based virtual hosting serves multiple sites at a single address by looking at the
  request's `Host` header; the distinction is made not at the address level but inside
  the server program.
- Shared hosting gives the lowest cost and weakest isolation, a dedicated server the
  opposite; a virtual private server sits between the two.
- Managed hosting is defined not by hardware but by the boundary of responsibility, and
  can be layered on top of the other models.
- Static content can be replicated to bring it closer to users; dynamic content stays
  tied to where its state is held.

## Next Step

This topic built, start to finish, how a name typed into the address bar reaches a
server: the structure of the name, the resolution chain, the records and the machine at
that address. Yet what is said once the server is reached has been glossed over with the
same two lines throughout. The next topic opens that exchange itself: what parts a
request and a response are made of, what status codes report, and why the server
remembers nothing between requests.
