How web hosting works

What a server is

A server is a computer that answers requests. It has the same parts as the machine on your desk: a processor, memory, a disk, a network card, an operating system, usually Linux. The difference is that nobody sits in front of it. It runs in a data centre, on a network that is never switched off, and it is managed over SSH.

On the server, programs called services listen on ports and wait for connections. A web request goes to port 80 for plain HTTP or 443 for HTTPS, mail to port 25 or 587, SSH to port 22. Each service is a process that systemd starts at boot and restarts when it dies. To see what is listening on your machine:

sudo ss -tlnp

State Recv-Q Send-Q Local Address:Port Peer Address:Port Process LISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=812,fd=6)) LISTEN 0 511 0.0.0.0:443 0.0.0.0:* users:(("nginx",pid=812,fd=7)) LISTEN 0 80 127.0.0.1:3306 0.0.0.0:* users:(("mariadbd",pid=944,fd=21)) LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=701,fd=3))

The list is short and every line should be explainable. Nginx answers the web on all addresses; MariaDB listens only on 127.0.0.1, so the database is reachable from the server itself and from nowhere else; SSH listens on all addresses because you have to reach it. A port you cannot explain is a service you should switch off or close in the firewall. That is the first habit of a server administrator, and lesson 8 builds on it.

The web server

The web server is the program that accepts HTTP requests and sends files back. Two programs do this almost everywhere: Nginx and Apache. Apache starts a pool of processes, allows configuration in .htaccess files inside the site folder, and can run PHP inside itself. Nginx uses an event loop, keeps all configuration in files under /etc/nginx/, ignores .htaccess completely, and passes PHP requests to a separate process.

Both are excellent. Shared hosting often runs Apache because its .htaccess support lets a customer change redirects without a system administrator. Servers you configure yourself often run Nginx for its lower memory use and its simple config files. The details are in nginx.conf: configuration and sites; here the important part is what a web server does for a site:

• It reads the request line, for example GET /about/ HTTP/1.1, and the headers that follow.
• It decides which site the request belongs to, from the Host header.
• It maps the path to a file under the folder of that site, or passes the request to PHP.
• It adds the response headers: content type, cache rules, security headers.
• It writes a line to the access log and, if something failed, to the error log.

Virtual hosts and the Host header

One server with one IP address serves hundreds of sites. The trick is the Host header: the browser sends the name it typed, and the web server picks the matching configuration. In Nginx each site is a server block and the name is server_name. In Apache it is a VirtualHost with ServerName. This is called name-based virtual hosting, and it is why an IP address alone is not a website.

sudo vi /etc/nginx/sites-available/example.com

server { listen 80; server_name example.com www.example.com; root /var/www/example.com/html; index index.php index.html; } server { listen 80; server_name shop.example.net; root /var/www/shop.example.net/html; }

Two names, two folders, one IP address. A request for example.com reaches the first block, a request for shop.example.net the second. The block with default_server, or the first one in the configuration when none is marked, answers requests for names it does not know: that is how a server reacts to a direct IP visit or to a domain that was pointed at it by mistake.

HTTPS adds a problem. The certificate is chosen during the TLS handshake, before any HTTP header exists, so the server cannot read Host yet. The solution is SNI, Server Name Indication: the browser sends the requested name in the handshake and the server picks the matching certificate. Every current browser supports it. The practical rule for you is to make sure the name is in server_name before you request a certificate for it, and to include both example.com and www.example.com.

PHP handlers and pools

A web server does not execute PHP by itself. It hands the request to a PHP handler, and there are two common arrangements. The old one is mod_php: the PHP interpreter runs inside each Apache process, so every site on the server shares one PHP setup. The modern one is PHP-FPM: a separate service with pools, each pool running as its own system user and listening on its own socket. The web server passes the request to the socket.

sudo vi /etc/php/8.3/fpm/pool.d/example.com.conf

[example.com] user = example group = example listen = /run/php/php8.3-fpm-example.sock listen.owner = www-data listen.group = www-data pm = dynamic pm.max_children = 10 pm.start_servers = 2 pm.min_spare_servers = 1 pm.max_spare_servers = 3 php_admin_value[open_basedir] = /var/www/example.com:/tmp

The pool runs as the user example, so a bug in one site cannot read the files of another site that runs as a different user. max_children caps how many requests that site can run at once, which stops one busy site from eating all the memory of the machine. open_basedir limits the folders PHP may open. In the site block, Nginx connects to the socket:

sudo vi /etc/nginx/sites-available/example.com

location ~ \.php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php8.3-fpm-example.sock; }

On shared hosting you do not write these files. The panel writes them when you choose a PHP version for a site, and the isolation they give you is one of the things you pay for.

Databases

A database server is another service, usually MariaDB or MySQL, listening on port 3306. One database server holds many databases, and each database has its own users and permissions. A site gets a database name, a user name and a password, and nothing else:

sudo mariadb

MariaDB [(none)]> CREATE DATABASE example_db; Query OK, 1 row affected (0.001 sec) MariaDB [(none)]> CREATE USER 'example_user'@'localhost' IDENTIFIED BY 'long-random-password'; Query OK, 0 rows affected (0.012 sec) MariaDB [(none)]> GRANT ALL ON example_db.* TO 'example_user'@'localhost'; Query OK, 0 rows affected (0.004 sec) MariaDB [(none)]> SHOW DATABASES; +--------------------+ | Database | +--------------------+ | example_db | | information_schema | | mysql | | performance_schema | +--------------------+ 4 rows in set (0.001 sec)

The user is allowed to work only inside example_db and only from localhost. That is the correct default: the site runs on the same machine as the database, so the database never needs to accept connections from the internet. A database port open to the world is one of the fastest ways to lose a site, and lesson 7 ranks it high on the list.

How one server keeps customers apart

Shared hosting puts strangers on one machine. The provider promises that your files, your database and your mail are yours alone, and the promise rests on a stack of mechanisms:

None of these is perfect. All sites share one kernel, and a kernel bug can break the wall between them. A provider that oversells puts too many busy sites on one disk, and everyone waits. This is not a reason to avoid shared hosting; it is a reason to understand what you buy. When the limits hurt, you move to a VPS, where the wall is a virtual machine and the kernel is still shared but the machine is yours.

Control panels

A control panel is a web application that runs as root and writes configuration for you: it creates the site folder and the system user, writes the Nginx or Apache block, creates the database, adds a DNS zone, issues a certificate, adds a mailbox. ispmanager, cPanel, Plesk, Hestia CP and CloudPanel are the common ones; a provider may also have its own simpler panel.

A panel turns ten command-line steps into ten clicks, and that is a real gain when you manage many sites. The cost is another service with root rights on the machine: it must be updated as carefully as the web server, its login must have two-factor authentication, and its own bugs are part of your attack surface. A panel also hides what it does, which is why this course shows the files underneath.

Shared, VPS, dedicated, cloud

The four words describe who owns which layer. The layers are the hardware, the operating system, the services on it, and your site.

Shared hosting is the cheapest and the least work: Which hosting to choose compares the offers. A VPS is a virtual machine on a bigger host, with its own kernel and root access; VPS hosting shows how to create one. A dedicated server is a whole physical machine, which matters when you need every core, a large disk array or a predictable network. Cloud platforms sell the same virtual machines plus databases, storage and load balancers by the hour.

Lessons 4 and 5 run the same small site on the first two: the same files, the same database, a very different amount of work.

Quiz

Article author: Arthur Isaev