1. Généralités

S'il y a bien des termes qui reviennent souvent (et plus particulièrement dans ces articles) ce sont bien les termes "serveur" et "client". Mais que représentent-ils au juste ?

Concrètement, ce ne sont jamais que des ordinateurs plus ou moins évolués. On a souvent tendance à dire "Le client est l'ordinateur du visiteur et le serveur celui du fournisseur d'accès". C'est vrai et faux.

2. Définition de client et serveur

On pourrait voir une approche d'une vraie définition ainsi :

Le serveur fournit des données (il sert des données, tout comme on servirait un plat), le client vient "consommer" les données servies.

Ainsi, n'importe quelle machine peut être serveur ET client à la fois. Lorsqu'elle a une application à laquelle on fait appel pour tirer des données, on parlera d'application type serveur, et lorsqu'une de ses applications demande des données à une machine tierce, on parlera d'application type client.

Il est vrai que, de manière générale, le client est souvent associé à l'ordinateur du client qui visite un site web et le serveur est associé à la machine sur laquelle sont présents les fichiers dudit site. Cette définition peut suffire pour la suite de mon article.

"Une machine peut être serveur et client à la fois" disais-je plus haut ... Ceci ne veut pas dire qu'il y a 2 machines dans la boîte; mais 2 applications dont le mode de fonctionnement diffère puisque l'une fournit les données alors que l'autre les consomme. Ces 2 applications peuvent tourner "en boucle" (A donne à B, B demande à A) tout comme elles peuvent être en relation chacune avec une application externe (A donne à C, B demande à D).

3. Principes de communication serveur / client

Les serveurs et clients utilisent des langages de communication. On appelle ces langages "protocoles". Ce sont des normes de transfert de données, qui bénéficient d'une certaine "universalité", c.à.d. que beaucoup de machines ayant des logiciels différents et des architectures différentes arrivent à se comprendre. (On parle également de portabilité : le fait qu'une série de données ou qu'une norme soit compatible sur plusieurs systèmes.)

Pour le Web (puisque c'est la partie qui intéresse cet article), il y a plusieurs principaux protocoles qui peuvent éventuellement se décliner en "variantes" et/ou versions.

3.1. HTTP : HyperText Transfert Protocol

c'est LE protocole le plus connu. Il sert au transfert de pages Web sur un navigateur. On le note http:// suivi de l'adresse machine (adresse IP, ou encore nom de domaine) et éventuellement de la ressource recherchée.

Il utilise un port machine (par défaut le port 80) et cette norme envoie des codes à 3 chiffres en tant que réponse :

• 100
• 200 : "Ok, transfert réussi".
• 300
• 400 : "Erreur". La plus connue étant l'erreur 404 : ressource inexistante.
• 500 : erreur interne au serveur.

Variante : HTTPS : HyperText Transfert Protocol Secure, qui est de l'HTTP crypté (donc à privilégier pour des formulaires/pages avec des données sensibles par exemple).

3.2. FTP : File Transfert Protocol

Ce protocole permet de transférer des fichiers (Ne me dites pas que vous étiez au courant ?!?) en plusieurs modes, ASCII, binaire, texte ... selon le type de données à transférer.

Le FTP répond aussi par chiffres, et utilise les ports 20 et 21. Ce protocole passe par une connexion à une adresse machine via un identifiant et un mot de passe. Certaines machines acceptent les FTP "anonymes", càd sans compte utilisateur particulier.

3.3. SSL : Secure Socket Layer

Il s'agit là d'un protocole de cryptage pour échanger des données entre un serveur et un client (par exemple le S de httpS://). Utilisé pour les systèmes de paiement en ligne.

Je ne passerai pas en revue tous les protocoles, puisqu'il en existe beaucoup d'autres, le HTTP et le FTP m'intéressent l'un pour les adresses absolues et l'autre pour la mise en ligne de site.

4. Langages serveur et client

Pour cet article ayant trait au développement Web, il existe des langages des 2 cotés.
Leur particularité est que ... chacun reste chez soi !

En effet, le client ne saura rien des traitements côté serveur, il n'en verra que le résultat. De même, le serveur envoie un résultat au client et une fois celui-ci envoyé, le serveur n'a plus de contrôle dessus.

Le client ne comprend que le langage client. Pour les sites Web, il s'agit de l'HTML, du Javascript et des styles CSS. c.à.d. que l'exécution serveur doit renvoyer ce type de langage au client.

4.1. Exemple simple :

<?php
	if ($lang == "english")
	{
		echo '<a href="index.php" title="Home">Home page</a>';
	}
	else
	{
		echo '<a href="index.php" title="Accueil">Page d\'accueil</a>';
	}
?>

4.2. Que verra le navigateur ?

Là, il y aura un traitement PHP par le serveur qui va exécuter la condition. Cette condition dit que le serveur envoie un lien vers index.php, mais soit avec des intitulés anglais, soit des intitulés français; le client reçoit la page, il ne reçoit qu'un seul lien ! (français ou anglais selon la langue). Il n'y a aucune trace de l'exécution d'une telle commande en langage serveur sur le client.

On pourrait le transcrire ainsi : le langage client est un langage "simplifié", et le langage serveur est un langage qui permet de produire du langage simplifié. Seulement le langage "brut" (serveur) doit être exécuté pour donner le langage "net" (client).

Remarque annexe : Par cet exemple, le serveur envoie un lien HTML, mais on peut tout aussi bien générer du Javascript ou des styles CSS ... Ou encore un code d'insertion de fichier Flash ...

5. Langage client : quel intérêt ?

Le langage client est exécuté directement sur l'ordinateur du visiteur, il n'a pas besoin d'avoir un serveur annexé pour fonctionner. Une page écrite en HTML peut être lue depuis un disque dur, une clé USB ou encore un support type CD/DVD sans avoir besoin d'autre chose qu'un navigateur internet.

6. Langage serveur : quel intérêt ?

Puisque le serveur génère un langage client "simplifié", pourquoi a-t-on besoin de passer parfois par un serveur ?

Les raisons sont multiples. On pourrait effectivement n'envisager d'écrire que des pages en "langage client", mais on serait confronté à plusieurs problèmes, notamment :

• La synchronisation des données (Ce que voit Paul, Pierre doit le voir aussi : par exemple, un compteur de visites. C'est bien de savoir que Paul est venu 5 fois sur la page, Pierre aussi ... Mais chacun d'eux n'a accès qu'à ses informations. Pas à celles de l'autre, or le but du webmaster est aussi de savoir la popularité de ses pages ... Ainsi l'idée d'un point central qui comptabilise tout est une piste intéressante...)
• des questions de sécurité (Si on met le mot de passe chez Paul, rien ne prouve qu'il ne cherchera pas à le trouver...)