Historique
Les systèmes clients/serveurs sont arrivés assez tôt dans l’histoire de l’informatique. En effet, le besoin de centraliser des informations et de les rendre accessibles à un grand d’utilisateurs était déterminant dans le monde de la recherche universitaire.
Avant d’être un réel environnement client/serveur, les utilisateurs accédaient à des ordinateurs centralisés (mainframe) au moyen d’un simple terminal (couple écran + clavier). Rapidement, les ordinateurs personnels ont remplacés les terminaux.
Ces nouveaux « clients » pouvaient exécuter des applications plus complexes parmi lesquelles la possibilité d’envoyer des requêtes à des serveurs et
traiter les réponses de ces derniers.
Principe général
Une application dite cliente, installée sur un ordinateur (ou périphérique), peut envoyer des requêtes à un serveur selon un protocole défini. Le serveur traite la requête et renvoie la réponse au client. Le serveur peut traiter de multiples requêtes venant de nombreux clients. Les échanges peuvent se réaliser au travers de n’importe quel réseau (internet ou local) pour peu que
le protocole soit supporté sur le réseau.
A besoins divers, clients/serveurs divers
Pour la consultation de pages web (protocole HTTP) :
- Quelques serveurs : Apache, Nginx, IIS, Lighthttpd...
- Quelques clients : Firefox, Chrome, Safari, Opéra, Edge...
Pour l’accès à des informations stockées en bases de données.
- Quelques serveurs : MySQL, PostgreSQL, Oracle, Access, dBase, SQL Server...
- Quelques clients : Mysql, Postgre...
Pour envoyer et recevoir des emails (Protocole SMTP)
- Quelques serveurs : Qmail, postfix, Sendmail...
- Quelques clients : Thunderbird, Outlook, Gmail, Apple Mail...
Il existe, bien sûr, de nombreuses autres applications d’environnement clients/serveurs.
Architecture centralisée et architecture distribuée.
Architecture centralisée
Dans le cadre d’une architecture centralisée, une seule entité serveur assure la fourniture des réponses
aux requêtes. Celle-ci est facile à maintenir, sauvegarder, mettre à jour et garantie que les données
fournies sont cohérentes puisqu’il n’y a qu’une source de données.
Parmi ses inconvénients, nous notons : La surcharge éventuelle, la fragilité d’une architecture unique, le
manque de flexibilité, des performances fluctuantes en fonction de l’implantation géographique des
clients comme du serveur.Architecture distribuée
Dans une architecture distribuée, les données à servir peuvent être réparties entre plusieurs serveurs.
Les données peuvent être découpées en plusieurs catégories (par exemple, un serveur s’occupe
uniquement des données des clients d’Amérique du Nord, un autre de l’Asie, etc).
Les données peuvent être également dupliquées entre plusieurs serveurs afin que ceux-ci puissent
supporter un très grand nombre de clients.
C’est une architecture pouvant être complexe et difficile à maintenir. En contre-partie, c’est une
architecture robuste à la panne et flexible à la montée en charge.
Architecture distribuée
Dans une architecture distribuée, les données à servir peuvent être réparties entre plusieurs serveurs.
Les données peuvent être découpées en plusieurs catégories (par exemple, un serveur s’occupe
uniquement des données des clients d’Amérique du Nord, un autre de l’Asie, etc).
Les données peuvent être également dupliquées entre plusieurs serveurs afin que ceux-ci puissent
supporter un très grand nombre de clients.
C’est une architecture pouvant être complexe et difficile à maintenir. En contre-partie, c’est une
architecture robuste à la panne et flexible à la montée en charge.
