Client-serveur
Cet article ne cite pas suffisamment ses sources ().
Si vous disposez d'ouvrages ou d'articles de référence ou si vous connaissez des sites web de qualité traitant du thème abordé ici, merci de compléter l'article en donnant les références utiles à sa vérifiabilité et en les liant à la section « Notes et références ».
En pratique : Quelles sources sont attendues ? Comment ajouter mes sources ?
Le protocole client–serveur désigne un mode de transmission d'information (souvent à travers un réseau) entre plusieurs programmes ou processus : l'un, qualifié de client, envoie des requêtes ; l'autre, qualifié de serveur, attend les requêtes des clients et y répond[1],[2]. Le serveur offre ici un service au client.
Par extension, le client désigne souvent le terminal ou la machine sur lequel est exécuté le logiciel client, et le serveur, l'ordinateur sur lequel est exécuté le logiciel serveur. Les machines serveurs sont généralement dotées de capacités supérieures à celles des ordinateurs personnels en ce qui concerne la puissance de calcul, les entrées-sorties et les connexions réseau, afin de pouvoir répondre de manière efficace à un grand nombre de clients. Les clients sont souvent des ordinateurs personnels ou terminaux individuels (téléphone, tablette), mais pas systématiquement. Un serveur peut répondre aux requêtes de plusieurs clients : c'est le cas d'un serveur d'impression contrôlant le partage d'imprimantes, des sites d'achat en ligne ou des jeux massivement multijoueurs ; mais parfois, client et serveur sont sur la même machine : c'est le cas pour le système d'affichage X Window[2].
Il existe une grande variété de serveurs et de clients en fonction des besoins ou services à fournir : un serveur Web publie des pages Web demandées par des navigateurs Web ; un serveur de messagerie électronique transmet les courriels à des clients de messagerie ; un serveur de fichiers permet de partager des fichiers sur un réseau aux machines qui le sollicitent ; un serveur de base de données permet aux clients de récupérer des données stockées dans une base de données, etc.
Le client et le serveur doivent bien sûr utiliser le même protocole de communication au niveau de la couche transport. Depuis 1978, la communication de tous les systèmes informatiques en réseau est régie par une norme, le modèle OSI.
Bien que souvent confondues, les notions de « programme client » (ou processus client) et de programme serveur sont différentes de celles de « machine client ». En effet, il est courant qu'un seul ordinateur exécute à la fois un ou plusieurs programmes serveur et un ou plusieurs programmes client.
Caractéristiques[modifier | modifier le code]
Caractéristiques d'un programme serveur :
- il attend une connexion entrante sur un ou plusieurs ports réseaux locaux ;
- à la connexion d'un client sur le port en écoute, il ouvre un socket local au système d'exploitation ;
- à la suite de la connexion, le processus serveur communique avec le client suivant le protocole prévu par la couche application du modèle OSI.
- l'action réalisée par le serveur en réponse à la requête client est souvent appelée service.
Caractéristiques d'un programme client :
- il établit la connexion au serveur à destination d'un ou plusieurs ports réseaux ;
- lorsque la connexion est acceptée par le serveur, il communique comme le prévoit la couche application du modèle OSI.
Caractéristiques de leur protocole d'échange:
- le client et le serveur doivent bien sûr utiliser le même protocole de communication au niveau de la couche transport du modèle OSI.
- les échanges peuvent se faire à travers un réseau, ou parfois en local
- ce protocole doit être défini, connu et compris des clients et des serveurs
Environnement client–serveur[modifier | modifier le code]
L'organisation d'un environnement client–serveur diffère selon le type d'architecture du réseau et le type de client[3].
Types d'architecture standard[modifier | modifier le code]
Architecture pair à pair[modifier | modifier le code]
Une architecture pair à pair (peer-to-peer ou P2P en anglais) est un environnement client–serveur où chaque programme connecté est susceptible de jouer tour à tour le rôle de client et celui de serveur. Le programme est client lorsqu'il demande et récupère des données, et devient serveur lorsqu'il fournit des données.
Architecture à deux niveaux[modifier | modifier le code]
De base la relation entre un client en un serveur se fait entre deux processus, deux logiciels ou deux machines. On peut parler d'une architecture à deux niveaux ou une architecture deux tiers (two-tier architecture en anglais). Dans ce cas, le client demande une ressource au serveur qui la fournit directement à partir de ses propres ressources, sans solliciter d'autres machines.
Types d'architecture évoluées[modifier | modifier le code]
Architecture à trois niveaux[modifier | modifier le code]
Une architecture à trois niveaux ou une architecture trois tiers (three-tier architecture en anglais) ajoute un niveau permettant de spécialiser les serveurs, ce qui apporte un avantage de flexibilité, de sécurité et de performance[4] :
- un client demande une ressource via une interface utilisateur (généralement un navigateur web) chargée de la présentation de cette ressource ;
- un serveur d'application (appelé middleware) fournit la ressource, mais en faisant appel à un autre serveur[5]
- un serveur de données fournit au serveur d'application la ressource requise pour répondre au client.
Il faut noter que le serveur d'application est ici client du serveur de données.
Architecture à N niveaux[modifier | modifier le code]
Une architecture à N niveaux ou architecture N tiers (N-tier architecture en anglais) n'ajoute pas de niveau à l'architecture à 3 niveaux, mais introduit la notion d'objet qui offre la possibilité de distribuer les services entre les 3 niveaux selon N couches, permettant ainsi de spécialiser plus finement les serveurs.
Types de clients applicatifs[modifier | modifier le code]
Les clients applicatifs, sont des logiciels qui tournent sur les machines ou terminaux des utilisateurs. Il est possible d'en distinguer 3 types majeurs.
Client léger[modifier | modifier le code]
Un client léger est une application où le traitement des requêtes du client (le plus souvent un navigateur Web, avec des pages web n'utilisant pas ou peu de JavaScript côté client, terminaux Terminal Services, Secure Shell, Apple Remote Desktop, Citrix XenApp, TeamViewer, etc.) est entièrement effectué par le serveur, le client se contente de recevoir et mettre en forme pour afficher les réponses calculées et envoyées par les serveur. Quelques avantages:
- peu de puissance de calcul est nécessaire au niveau du client.
- la mise à jour de l'application s'effectue uniquement sur le serveur, excepté l'éventuelle mise à jour du client Web.
- plus grande indépendance du développement de l'application et du serveur vis-à-vis de la machine cliente et de son environnement.
- un travail de développement concentré sur le serveur
Client lourd[modifier | modifier le code]
Un client lourd est une application (applications de bureau, applications mobile) où les traitements sont principalement effectués sur la machine locale dite cliente. Le serveur se contentant principalement de répondre aux demandes de données du client.
Quelques avantages:
- le client peut parfois fonctionner même en cas de déconnexion du serveur
- une partie des traitements est réalisé par le client, ce qui soulage les ressources du serveur.
- plus grande indépendance vis-à-vis des temps de réponse réseau et serveur
Client riche[modifier | modifier le code]
Un client riche est une application où le traitement des requêtes du client (applications Web utilisant beaucoup de JavaScript côté client) est effectué majoritairement par le serveur, le client recevant les réponses « semi-finies » et les finalisant. C'est un client léger plus évolué permettant de mettre en œuvre des fonctionnalités comparables à celles d'un client lourd. C'est un compromis entre les clients légers et lourds.
Comparaison des architectures centralisées et distribuées[modifier | modifier le code]
Fonctionnement[modifier | modifier le code]
Avant que n'apparaisse l'environnement client–serveur, les réseaux informatiques étaient configurés autour d'un ordinateur central (mainframe en anglais) auquel étaient connectés des terminaux passifs (écran adjoint d'un clavier sans unité centrale et n'effectuant aucun traitement). Tous les utilisateurs étaient alors connectés sur la même unité centrale.
Avantages des architectures centralisées[modifier | modifier le code]
- Toutes les données sont centralisées sur un seul serveur, physique ou virtuel, ce qui simplifie les contrôles de sécurité, l'administration, la mise à jour des données et des logiciels.
- La complexité du traitement et la puissance de calculs sont à la charge du ou des serveurs, les utilisateurs utilisant simplement un client léger sur un ordinateur terminal qui peut être simplifié au maximum.
- Recherche d'information : les serveurs étant centralisés, cette architecture est particulièrement adaptée et véloce pour retrouver et comparer de vastes quantités d'informations (moteur de recherche sur le Web), par rapport à l'architecture distribuée beaucoup plus lente, à l'image de Freenet.
- Maintenance matériel minime. [Passage contradictoire] [réf. souhaitée]
- Grande vélocité sur des grands volumes de données et de traitements. [Passage contradictoire] [réf. souhaitée]
Inconvénients des architectures centralisées[modifier | modifier le code]
Ces inconvénients sont ordinairement ceux des files d'attente[6] :
- si trop de clients veulent communiquer avec le serveur au même moment, ce dernier risque de ne pas supporter la charge (alors que les architectures distribuées peuvent répartir la charge si les serveurs sont démultipliés) ;
- si l'ordinateur serveur n'est plus disponible, plus aucun des clients ne fonctionne (les architectures distribuées peuvent continuer à fonctionner, si les serveurs utilisés sont démultipliés) ;
- pour cette raison même, la mise à jour (logicielle ou matérielle) du serveur demande un soin particulier, afin de minimiser le temps d'interruption du service. Cette opération étant critique, elle est peu fréquente, et l'architecture client-serveur est sujette à obsolescence.
Exemples client-serveur[modifier | modifier le code]
- La consultation de pages sur un site Web fonctionne sur une architecture client–serveur. Un internaute connecté au réseau via son ordinateur et un navigateur Web est le client, le serveur est constitué par le ou les ordinateurs contenant les applications qui fournissent les pages demandées. C'est le protocole de communication HTTP ou XML socket qui est utilisé.
- Les courriels sont envoyés et reçus par des clients et gérés par un serveur de messagerie[7]. Ce sont les protocole de communication SMTP, POP ou IMAP qui sont utilisés[8],[9].
- Le système X Window fonctionne sur une architecture client–serveur[1],[2]. En général le client (une application graphique, xeyes par exemple) tourne sur la même machine que le serveur mais peut être aussi bien lancé sur un autre ordinateur faisant partie du réseau.
- L'organisation en client léger, façon terminal-serveur, a donné naissance à des projets innovants comme le projet LTSP ou la technologie NX.
Notes[modifier | modifier le code]
- (en) Adrian Nye, Xlib Programming Manual, Sebastopol, Californie, O'Reilly & Associates, (ISBN 1565920023), « 1.2.2 The client-server model », p. 5
- (en) Chris Tyler, X Power Tools, Sebastopol, Californie, O'Reilly & Associates, (ISBN 0596101953), « 1.6 Where is the server? », p. 9
- Jean-François Pillou, Tout sur les systèmes d'information, Dunod, , 208 p. (ISBN 9782100791132)
- (en) Bill Blunden, Message passing server internals, McGraw-Hill Professional, (ISBN 9780071416382)
- (en) Qusay H. Mahmoud, Middleware for communications, John Wiley and Sons, (ISBN 9780470862063), p. 54.
- Elio Ventura et Patrick Gordon (ill. Michel Frezellier), La Drogue-miracle du Professeur Kashinawa : Dix sketches sur la recherche opérationnelle., CLE (Cercle du Livre Économique), , 220 p.
- (en) J. Rhoton, Programmer's Guide to Internet Mail: SMTP, POP, IMAP, and LDAP, Elsevier, (ISBN 978-1-55558-212-8).
- R. Blum et D.-A. LeBlanc, LINUX pour les Nuls, First, (ISBN 9782754042017), « X. Le courrier électronique : mise en place d'Evolution »
- (en) « Mail server », sur ArchLinux wiki
