Hosting 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:

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.

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.