Interaction client-serveur et protocole HTTP : cours de 1re NSI

Quand tu ouvres une page dans ton navigateur, tout semble immédiat : tu tapes une adresse, la page apparaît. Pourtant, entre ces deux instants, deux machines ont dialogué, parfois situées à des milliers de kilomètres l'une de l'autre. Ce dialogue suit des règles très précises, sans quoi un ordinateur sous Windows, un téléphone et un serveur sous Linux ne pourraient pas se comprendre.

Dans ce cours, tu vas découvrir ces règles. Tu as déjà vu comment écrire une page avec HTML et CSS, et comment la rendre vivante avec des événements et du JavaScript. Il manque une pièce : comment la page arrive-t-elle jusqu'à ton écran, et comment ce que tu fais dans la page repart-il vers un serveur ? C'est exactement le sujet de ce chapitre.

Le plan est le suivant. D'abord, les deux rôles : le client et le serveur. Ensuite, le protocole HTTP, qui fixe la façon de se parler. Puis la manière dont le client retrouve le bon serveur (adresse, DNS, port). Nous suivrons ensuite un échange complet, avant d'étudier les pages dynamiques, la mémoire d'une session (les cookies) et les limites de ressources d'un serveur. Le chapitre suivant, consacré aux formulaires et aux méthodes GET et POST, s'appuiera directement sur ce que tu vas voir ici.

Sur le Web, les pages ne sont pas stockées sur ton ordinateur : elles sont rangées sur une autre machine, qui les distribue à la demande. Cette organisation en deux rôles s'appelle le modèle client-serveur.

Pense à un restaurant. Toi, tu es à table : tu passes commande, tu ne cuisines pas. La cuisine prépare et renvoie le plat. Le navigateur joue le rôle du client à table, le serveur Web celui de la cuisine. Cette comparaison a une limite : à la différence d'une cuisine débordée, un serveur Web bien conçu répond à beaucoup de monde à la fois, comme nous le verrons plus loin.²

Pour que deux machines se comprennent, il faut un langage commun et des règles d'échange : un protocole. Pour le Web, ce protocole s'appelle HTTP.

Le Web repose donc sur deux ingrédients complémentaires : un langage de balisage pour décrire les documents (le HTML que tu connais) et un protocole client-serveur pour transférer l'information (HTTP).² Le HTML dit ce que contient la page ; HTTP dit comment elle voyage.

HTTP ne travaille pas seul. Il est construit sur TCP, un protocole de transport en mode connecté.² Cela signifie que le client et le serveur commencent par établir une connexion, puis échangent leurs messages à l'intérieur de cette connexion. Plus largement, le Web est un ensemble de logiciels et de protocoles basés sur TCP/IP.¹ On peut se représenter l'ensemble comme des couches : TCP/IP s'occupe de faire circuler les données d'une machine à l'autre, HTTP donne un sens aux messages échangés entre un navigateur et un serveur.

Avant d'envoyer une requête, le navigateur doit savoir où est le serveur et à quelle porte frapper. Deux informations sont nécessaires, et toutes deux se déduisent de l'adresse que tu saisis.

Le DNS joue le rôle d'un annuaire : tu connais le nom d'un site, le DNS permet de retrouver la machine qui l'héberge.² Sans lui, il faudrait retenir une suite de chiffres pour chaque site.

Le port n'est pas choisi au hasard : il se déduit du protocole. Par exemple, le port 80 correspond à HTTP et le port 21 à FTP.² Pour HTTP, un serveur Web attend les connexions sur le port 80 par défaut.¹ Les clients et serveurs utilisent en général des sockets, avec le port 80 côté serveur par défaut.²

Rassemblons tout ce que nous avons vu. Tu saisis une adresse dans la barre de ton navigateur et tu valides. Voici ce qui se passe, dans l'ordre.

Remarque que chaque échange est une paire : une requête, une réponse. Le serveur ne garde pas l'initiative. Si tu veux une autre page, ton navigateur doit émettre une nouvelle requête, et le serveur y répondra à nouveau.

Jusqu'ici, nous avons supposé que le serveur renvoie un fichier tel quel. C'est le cas d'une page statique. Mais un serveur peut aussi fabriquer la page au moment de la demande : c'est une page dynamique. Les systèmes embarqués eux-mêmes ont besoin de pages Web statiques et dynamiques.³

Le serveur peut aussi effectuer des réécritures d'adresses : il transforme l'adresse demandée en une autre adresse interne avant de calculer la réponse.¹ Pour le visiteur, cela reste invisible.

C'est ici que ton cours sur JavaScript retrouve son sens : le code exécuté chez le client, c'est celui que tu as appris à écrire pour réagir aux événements de la page. Avec AJAX, ce code peut demander des données au serveur sans que toute la page soit rechargée, puis ne mettre à jour qu'une partie de ce qui est affiché.

Dans le cycle requête-réponse, chaque échange est indépendant du précédent. Que se passe-t-il alors quand tu te connectes à un site, puis changes de page ? Le serveur doit pourtant se souvenir que c'est toi.

Les versions du protocole ont aussi leur importance. Avec HTTP 1.1, une même connexion peut servir à une série de requêtes successives entre un client et un serveur, mais il reste possible de fonctionner en mode HTTP 1.0.² Un serveur très simple peut choisir HTTP 1.0, plus simple à implémenter que HTTP 1.1.³

Un serveur Web n'a pas un seul client à servir. Quand un site est populaire, des milliers de navigateurs envoient leurs requêtes en même temps. Comment un serveur s'en sort-il ?

Ce n'est pas anodin. Un navigateur peut ouvrir plusieurs connexions vers un même serveur : certaines versions de Firefox, par exemple, pouvaient en ouvrir jusqu'à 15 par serveur.³ Si chaque visiteur en ouvre autant, le nombre de connexions que le serveur doit gérer se multiplie vite. Un serveur doit donc être capable de gérer plusieurs clients à la fois.³

À l'inverse, les applications Web modernes sont de plus en plus gourmandes en ressources, du côté des serveurs comme de celui des clients.³ D'où l'intérêt d'AJAX, vu plus haut : répartir le travail soulage le serveur.³