Ars Cultura

Comment Fonctionne Un Site Internet ?

Et comment créer le vôtre en un rien de temps.

Dans cet article didactique nous allons comprendre le fonctionnement d’un site internet et apprendre à en monter un le plus simplement possible sur un système Linux. Dans une démarche basse-technologie, nous cherchons à minimiser la complexité de l’infrastructure technologique qui nous entoure – le principe est simple : les seules technologies durables sont celles que nous sommes en mesure de comprendre.

Prérequis :

  • Quelques connaissances basiques en informatique
  • Quelques connaissances dans les systèmes Linux : utilisation d’un terminal, savoir (dés)installer des packets, contrôle d’accès des fichiers, etc.
    • Ressources utiles à cet effet :
      • Introduction to Linux – A Hands on Guide, Machtelt Garrels, The Linux Documentation Project : https://tldp.org/guides.html#intro-linux
      • Unix and Linux System Administration Handbook, Evi Nemeth et al., Prentice Hall Press

Matériel nécessaire et prérequis :

  • Vieil ordinateur ou Raspberry Pi (fera office de serveur)
  • Une box internet
  • De l’électricité
  • Acheter un nom de domaine chez un registraire, comme Gandi ou OVH (aucun hébergement requis)

Logiciels nécessaires :

  • Système d’exploitation GNU/Linux (comme Debian) ou UNIX (comme FreeBSD) ;
    • La distribution Linux n’a pas grande importance, et logiquement le processus devrait marcher aussi sur FreeBSD1 ; si vous hésitez, prenez Debian ;
  • Serveur web, actif en permanence, comme NGINX ;
  • (Optionnel) Générateur de site statique, comme Hugo2 ou saait.3

La langue des oiseaux numériques

Esquissons tout d’abord à gros traits les principes de communication entre les machines.
Pour communiquer, les machines sont identifiées par une adresse IP précise. Le format des messages est défini selon un protocole identifié – le plus souvent le TCP/IP – et elles les destinent à un “port” précis. On formate généralement les adresses selon la syntaxe suivante : [IP]:[PORT], p. ex. 135.75.94.206:8888.

Certains ports ont des fonctions qui leurs sont officiellement attribuées : p. ex. les ports 80 et 443 sont réservés aux serveurs internet et sont utilisés par les connexions HTTP et HTTPS respectivement. Ainsi, lorsqu’on entre une adresse web dans un navigateur, celui-ci interroge en fait les ports 80 et 443 du serveur rattaché au nom de domaine du site : ouvrir la page d’accueil de monsite.com revient à envoyer une requête HTTP “GET” à l’adresse IP du serveur correspondant (p. ex. 135.75.94.206) sur les ports 80 et 443. D’autres programmes utilisent d’autres ports pour communiquer : BitTorrent utilise les ports 6881 à 6889 pour envoyer des fichiers, SSH (qui permet de se connecter à distance à une machine) le port 22, etc.

Qui répond à ces messages, et comment ?
C’est le logiciel de serveur web qui répond aux requêtes reçues, le plus souvent sur les ports 80 et 443 donc, la plupart du temps en envoyant des pages HTML en retour. Ainsi une connexion sur monsite.com va envoyer une requête à 135.75.94.206:80, et le serveur web de la machine (comme Apache, NGINX ou lighttpd) va répondre en envoyant la page index.html.

Mise en place de votre serveur

Passons maintenant à la pratique.
Vous pouvez récupérer un exemple de site rudimentaire avec quelques fichiers de configuration ici : téléchargez les fichiers.

NGINX

NGINX est un des systèmes de serveur les plus utilisés au monde. La syntaxe de ses fichiers de configuration est très accessible, proche de celle du C. Vous pouvez facilement l’installer depuis n’importe quelle distribution Linux ou UNIX.
Dans un premier temps, il faut s’assurer que votre serveur reste actif en permanence. Sur la plupart des systèmes Linux, c’est systemd via la commande systemctl qui gère l’exécution des processus d’arrière-plan ; sur FreeBSD c’est service.
Les commandes suivantes active puis lance le processus d’arrière-plan sur Debian et Ubuntu :

$ sudo systemctl enable nginx.service
$ sudo systemctl start nginx.service

À chaque changement de configuration, il faudra redémarrer le programme :

$ sudo nginx -s reload

Configuration

Tout d’abord, on range les pages HTML dans un dossier précis et identifié, p. ex. /var/www/html (répertoire classique des sites web sur les systèmes d’exploitation Linux). La configuration NGINX suivante permet de “servir” un site sur le port 80 dont les pages se situent dans votre répertoire racine :

# Configuration nginx à placer dans /etc/nginx/nginx.conf
http {
	server {
		listen 80;
		listen [::]:80;
		server_name _;
		# Répertoire des pages du site
		root /var/www/html;
		# Page par défaut
		index index.html;
		error_page   404 = /404.html;
	}
}

À noter que certaines distributions Linux (comme Ubuntu), répartissent des sous-configurations dans les dossiers /etc/nginx/sites-enabled/ ou /etc/nginx/conf.d/ – dans ce cas seul les blocs server {...}, insérés avec la directive include ..., sont écrits dans ces fichiers, tandis le bloc http {...} reste dans /etc/nginx/nginx.conf.

# /etc/nginx/nginx.conf
http {
	...
	include /etc/nginx/conf.d/*.conf;
        include /etc/nginx/sites-enabled/*;
}
# /etc/nginx/conf.d/monsite.com.conf
	server {
		...
	}

Comme on le devine facilement, ce serveur “écoute” ici sur le port 80, c’est-à-dire pour des connexions HTTP uniquement – et non HTTPS. Cela signifie que les échanges entre les visiteurs et votre serveur ne sont pas encryptés. Dans l’absolu ce n’est pas forcément un grave problème mais les navigateurs modernes se méfient désormais de toute connexion qui n’est pas sécurisée. On évoquera plus loin un moyen de contourner ce manquement.

Pour faciliter votre travail sur les pages du site, on prendra soin d’affecter au dossier racine les bonnes autorisations (remplacez [utilisateur] par votre nom d’utilisateur) avant d’y copier le contenu du site :

$ sudo chown -R [utilisateur] /var/www/html/
$ chmod -R ug+r /var/www/html/
$ cp -r monsite/racine/* /var/www/html/

Exemple d’organisation sommaire du répertoire racine d’un site :

$ tree /var/www/html
/var/www/html/
├── 404.html
├── blog
│   └── 2024
│       ├── encore-mon-article
│       │   └── index.html
│       └── mon-article
│           └── index.html
├── index.html
└── style.css

Une fois nginx lancé (ou relancé), une simple connexion à localhost (qui correspond à l’adresse IP de la machine actuel) devrait afficher la page index.html présente dans le répertoire.

Connexion à `http://localhost` réussie !
Connexion à http://localhost réussie !

Votre site est désormais en ligne… sur le réseau local uniquement. Une tablette connectée en wi-fi au même réseau doit pouvoir afficher votre site internet en passant par l’adresse IP local de l’ordinateur qui nous sert de serveur.

Connexion à l'IP du serveur depuis une autre machine du réseau local.
Connexion à l’IP du serveur depuis une autre machine du réseau local.

Plonger dans le grand bain

Nous allons maintenant relier votre petite machine aux vastes contrées de l’internet mondial. Pour ce faire, un point sur le fonctionnement des réseaux s’impose.

Les adresses IP des machines sont attribuées par le routeur qui se charge de nous connecter à internet – si vous avez une box internet, votre routeur est tout simplement votre box.
Dans le contexte du grand bain international, votre réseau est identifié par l’adresse IP de votre routeur.
Dans le contexte d’un réseau local, chaque machine se voit assigner une adresse IP locale par le routeur. Ainsi, il est attribué une adresse IP locale à votre téléphone et à votre ordinateur s’ils utilisent la connexion de votre box. Par convention, ces adresses respectent systématiquement le format 192.168.X.X, où les deux derniers nombres sont compris entre 0 et 255.

$ ip addr | grep "inet "
    inet 127.0.0.1/8 scope host lo
    inet 192.168.1.20/24 metric 100...

127.0.0.1 et localhost sont équivalents. 192.168.1.20 est ici l’adresse IP de la machine sur le réseau local. ifconfig est une alternative à ip addr si cette dernière commande n’est pas disponible.

Ces adresses peuvent cependant changer à mesure que les machines se connectent et se déconnectent du réseau – ce sont des adresses IP dites “dynamiques”. Dans le cas d’un serveur, il faut faire en sorte que l’adresse IP reste fixe et identifiable.

Par défaut, les ports 80 et 443 sont évidemment fermés. Mettre en place un serveur revient tout simplement à créer une passerelle, passant par un port précis, depuis votre routeur, et son adresse IP publique, vers votre serveur, et son adresse IP local.
On peut généralement accéder à l’interface de gestion de votre routeur en pointant votre navigateur sur l’adresse local 192.168.1.1. Elle nous permet :

  • l’identification de l’adresse IP de votre routeur sur le réseau étendu (p. ex. 28.172.9.132) ;
    • peut être aussi identifiée avec la commande : curl https://ipinfo.io/ip ;
  • la configuration d’une adresse IP fixe pour votre serveur (p. ex. 192.168.1.20) ;
  • la configuration d’un transfert des requêtes du réseau étendu vers le réseau local, par les ports 80 et 443 (p. ex. 28.172.9.132:80 vers 192.168.1.20:80, idem pour le port 443).
Exemple d'interface de routeur, avec deux règles de transfert vers la machine appelée "raspi-2b".
Exemple d’interface de routeur, avec deux règles de transfert vers la machine appelée “raspi-2b”.

Avec ces ajustement votre serveur devient accessible depuis l’internet mondial.
On peut s’en assurer en tapant p. ex. http://28.172.9.132 dans un navigateur. À noter que https://28.172.9.132 ne fonctionnera pas car les requêtes HTTPS (qui passent par le port 443) nécessite une configuration supplémentaire.
Enfin, la touche finale : donnons un vrai nom à votre site internet.

Associer un nom de domaine à votre serveur

Ce sont les serveur DNS (Domain Name System) qui associent des noms intelligibles (p. ex. “monsite.com”) à des adresses IP précises, ou d’autres informations entre elles. Les “enregistrements DNS” définissent ces associations. Ils sont accessibles et modifiables pour tous les domaines dont vous êtes propriétaire, via l’interface de l’hébergeur web ou du registraire (p. ex. Gandi, OVH, LWS, etc.).

Pour associer un nom de domaine à votre adresse IP public exposée, on définit un paramètre A (Adresse) comme suit lié au domaine principal (indiqué avec @) :

@ IN A 92.154.113.89

On peut aussi créer des redirections de domaines, ce qui permet aussi de créer des sous-domaines. Ainsi, ajouter le paramètre CNAME (Canonical NAME) suivant permet de rediriger www.monsite.com vers monsite.com :

www IN CNAME monsite.com.

Attention : le point final est important dans cette ligne de configuration.

Exemple d'interface de gestion de la zone DNS d'un nom de domaine.
Exemple d’interface de gestion de la zone DNS d’un nom de domaine.

Ces deux lignes suffisent à rendre accessible votre serveur depuis l’adresse “(www.)monsite.com”. Si vous avez suivi les étapes correctement, alors à l’heure où vous lisez ces mots, vous êtes devenu un webmaistre.

Les générateurs de site statique

Pour faciliter la production des pages qui composent un site, il existe des générateurs de sites statiques : les pages sont générés selon des modèles précis et l’arborescence des fichiers est créée automatiquement. Un des plus connus – et selon l’auteur de ces pages le meilleur – est Hugo.2 Une alternative plus élémentaire existe avec saait3, de l’inénarrable collectif d’autistes Suckless.4

Ces sites sont dits “statiques” car ils n’exposent que des pages “prêtes à l’emploi”, en HTML “pur”, contrairement à la plupart des sites modernes qui utilisent PHP, Python ou d’autres langages de programmation pour générer des pages “à la demande” dont le contenu doit (logiquement) varier régulièrement – p. ex. la page d’accueil d’un important site d’actualités (comme Le Figaro, https://lefigaro.fr) ou d’une encyclopédie collaborative (comme Wikipédia, https://fr.wikipedia.org/wiki/Wikipédia:Accueil_principal). Ce système permet également de déployer des solutions d’hébergement unifiées (la plus populaire étant Wordpress) qui s’adapte au contenu qu’y injecte chaque utilisateur.
Mais cette donne complexifie et alourdit considérablement le processus de création d’un site. Dans une démarche basse-technologie, nous cherchons à minimiser la complexité et à être en mesure de comprendre et concevoir nous-mêmes l’architecture de notre système. Les sites dynamiques, impliquant un nombre de dépendances et de requêtes pharamineux – entre autres responsables de l’alourdissement sans précédent de la page web moyenne5 – s’opposent par essence à cette disposition d’esprit.

Sécuriser votre site internet

Comme évoqué précédemment, permettre les connexions HTTPS sécurisées nécessite une configuration supplémentaire : il est nécessaire d’obtenir un certificat délivré par un organisme officiel, correspondant en fait à une clé publique. Pour ce faire il faut prouver être administrateur du serveur, p. ex. en plaçant un fichier particulier selon un chemin précis. Fort heureusement, le fantastique utilitaire certbot6 nous décharge largement de cette tâche.

$ sudo certbot --nginx

Vous trouverez de plus amples informations sur le site officiel : https://certbot.eff.org/.

À noter qu’une autre option, plus simple techniquement mais (légèrement) plus complexe à mettre en œuvre, existe avec hitch7 ou stunnel8 qui créent pour ainsi dire un “pont de sécurisation”. Cette approche est recommandée par le collectif Suckless.9

Administration du serveur

Un nouveau pouvoir implique de nouvelles responsabilités…
Pour prévenir les problèmes susceptibles de survenir sur votre serveur, il faut comprendre quelques principes essentiels.

Premièrement, où trouver les messages d’erreur ? – Ils sont écrits, comme tous les autres messages des programmes d’une machine, dans les journaux système, généralement dans /var/log/. Selon les systèmes d’exploitation, ils sont consultables avec journalctl (systemd) ou des utilitaires traditionnels (tail -f, less, etc.).

Où trouver les réponses à vos questions ? – Généralement dans les manpages (les manuels) des logiciels installés. Par ex. pour savoir comment marche NGINX, entrez : man nginx.
Pour rechercher un mot-clé dans un en-tête de manuel, utilisez apropos, p. ex. apropos web.

Comment programmer des tâches ? – Pour programmer des tâches ponctuelles ou régulières, on utilise at ou cron (avec crontab -e).

Les outils du webmaistre. – Enfin, voici une liste de programmes légers et performants permettant la surveillance d’un serveur : darkstat, sar, atop, iftop, iotop et htop.

❧

Attribution de l’image de bandeau utilisée dans cet article : “Apple IIe Workstation Card”, ken fager (CC BY-NC-SA 2.0) : https://flickr.com/photos/kenfagerdotcom/3608542712/in/gallery-nicolibrarian-72157622696913339/

  1. L’auteur de ces lignes recommande vivement FreeBSD à tous les gens qui aimeraient découvrir un système moins chaotique et au fonctionnement plus rigoureux que la plupart des distributions Linux. Le FreeBSD Handbook est une référence incontournable qui vous fera comprendre les rouages du système sans avoir besoin d’effectuer une seule recherche Google. ↩︎

  2. https://gohugo.io ↩︎

  3. https://git.codemadness.org/saait/file/README.html ↩︎

  4. https://suckless.org/philosophy/ ↩︎

  5. “La page web moyenne fait désormais la taille du jeu vidéo Doom” — https://www.wired.com/2016/04/average-webpage-now-size-original-doom/ ↩︎

  6. https://certbot.eff.org/ ↩︎

  7. https://hitch-tls.org/ ↩︎

  8. https://www.stunnel.org/ ↩︎

  9. https://tools.suckless.org/quark/ ↩︎