Chapitre 1 : Interactions

Client/Serveur
1.1 Objectifs de ce chapitre.
Nous allons aborder, dans ce chapitre, différentes notions nécessaires à la compréhension du
fonctionnement général d'une architecture informatique basée sur des interactions clients/serveurs.
Nous définirons les termes de serveur et de client, ainsi que la relation client/serveur en donnant
des exemples simples puis le concept d'architecture Client/Serveur. Enfin les différents types de
serveurs seront présentés en insistant sur leur fonction principale et les caractéristiques de mise en
oeuvre.
Au terme de ce chapitre, le lecteur devrait connaître les différents éléments d'une architecture
informatique et aura eu un aperçu du vocabulaire que l'on peut rencontrer dans le domaine.

1.2 Définitions
1.2.1 Client, Serveur, Relation Client/serveur

En informatique, un serveur est une machine (ordinateur) qui propose un service. Ce service sera
proposé à toute machine pouvant accéder via un réseau informatique à la machine serveur.

Serveur : ordinateur qui propose un service

Par symétrie, un client est une machine qui utilise un service mis à disposition par une autre
machine.
Client : ordinateur qui utilise un service

Ces définitions simples nécessitent toutefois de préciser ce qu'est un service :

un service est la mise à disposition par une machine de ressources locales pour d'autres ordinateurs
qui peuvent y accéder par un réseau.

Services : ressources mises à disposition par un ordinateur

Une première remarque concerne les ressources mises à disposition. Celles-ci ne peuvent-être que
des ressources possédées par la machine serveur (ce qui est une évidence). Les ressources
potentiellement mises à disposition sont soit d’ordre physique :
- Espace de stockage (fichiers sur un disque dur ou sur un autre périphérique de masse)
- Temps de calcul (temps UC) + utilisation mémoire centrale (les deux étant liés)
- Liaisons à des périphériques ou à des interfaces locales (Imprimantes, accès distant…)
soit d’ordre logique :
- Applications spécifiques (bases de données, pages WEB…)
- Gestion de l’infrastructure informatique (authentification, gestion des licences...)

1
Dans le cas des ressources logiques (le plus fréquent maintenant), le service est plus complexe et va
utiliser les autres catégories de ressources (disque, UC, voire périphériques).

La deuxième remarque concerne la distinction que l'on peut faire entre les fonctions d'une machine
et la machine elle-même. En fait, la relation Client/Serveur est une relation entre fonctions et non
entre machines. En d'autres termes cela veut dire que plusieurs serveurs (en tant que fonctions)
peuvent être hébergés sur la même machine. Par exemple, une machine hébergeant un serveur WEB
peut aussi être serveur de messagerie, si elle possède les ressources suffisantes.
De même, le client et le serveur peuvent être sur la même machine; Un exemple habituel est le
fonctionnement de l'interface graphique sur une machine UNIX autonome : le client X (programme
qui envoie les commandes graphiques pour affichage) et le serveur X (programme qui va gérer
l'affichage sur l'écran à partir des commandes reçues) sont sur la même machine. Cet exemple peut
être d'ailleurs vu comme un paradoxe lorsque la machine qui affiche n'est pas la même que celle qui
envoie les commandes graphiques : le serveur X est alors la machine locale (celle qui affiche pour
l'utilisateur) et le client X, la machine distante (qui fait les traitements – elle est donc serveur pour
un autre service-).
De fait, un serveur pour une application peut-être client pour une autre ce qui va conduire à définir
des architectures plus complexes comme nous le verrons plus loin.

Dans le cas d'un ensemble de machines en réseau, les interactions Client/Serveur peuvent être vues
de manière différente suivant l'endroit où l'on se place.

Relation Client/Serveur (Vision côté serveur) :

On a un multiplexage de l’accès au serveur. Plusieurs clients ont un accès simultané à un seul
serveur, le serveur est spécialisé dans un service particulier.
Remarque : « accès simultané » signifie sessions de communication ouvertes avec plusieurs
machines simultanément (valable dans le cas ou le serveur est multi-tâches). Dans le cas d’un
serveur mono-processeur ou ne possédant qu’une carte réseau, il n’y a qu’une seule communication
physique à un instant déterminé.

2
Relation Client/Serveur (vision côté client) :
Dans le cas d'une machine cliente multi-tâches, il peut y avoir des accès simultanés à plusieurs
serveurs pour un client unique. Chaque serveur est toujours spécialisé dans un service mais le client
a besoin de plusieurs services pour mener à bien la tâche en cours (par exemple : messagerie avec
affichage de pages WEB intégrées).

Relation Client/Serveur (vision globale) :

En fait dans un système informatique complet, plusieurs clients et plusieurs serveurs cohabitent et
travaillent ensemble. On obtient alors une architecture plus complexe où chaque client pourra
accéder suivant ses besoins à chaque serveur :

On imagine facilement la complexité d'un tel système s'il fallait gérer chaque accès de manière
individuelle pour un ensemble de 100 machines et d'une dizaine de serveurs.
Pour être utilisable, l'informatique partagée va devoir être basée sur 2 aspects :
- la nécessité d’un réseau de communication pour assurer physiquement les échanges
- la nécessité de protocoles gérant les échanges Client/Serveur pour contrôler logiquement
ces échanges.

3
Dans ce dernier cas, chaque fonction spécifique nécessite la définition d'un protocole adapté. Cela
conduit forcément à une convergence des protocoles applicatifs sur un même support lors d'une
mise en œuvre par réseaux informatiques. Le point de convergence des protocoles applicatifs est
généralement la couche transport TCP/IP (surtout s'il y a communication entre sous-réseaux) ou
plus rarement la couche liaison (LLC+Ethernet) si on reste sur un même réseau local de type
industriel.

Comme nous l'avions évoqué précédemment, la relation Client/Serveur peut être plus complexe
avec des architectures où un serveur peut devenir client d’un autre serveur pour répondre à un client
: le serveur est spécialisé dans un service mais il a besoin pour le mettre en œuvre d’un autre
service :

On parle alors d'architecture à étages (tier en anglais), ou d'architectures N-tier. Ces architectures
peuvent paraître plus complexes avec l'utilisation de plusieurs protocoles (un par relation entre

4
machines), mais elles conduisent aussi à une mise en œuvre plus simple permettant des
modifications plus aisées, car chaque fonction peut être traitée séparément.

Une architecture fréquemment rencontrée est une architecture à 3 étages (3-tier) où les fonctions de
base : IHM (Interface Homme-Machine), Traitement et stockage (base de données) sont séparées
sur 3 serveurs. De ce fait, on peut changer l'interface homme-machine (fréquent sur les sites WEB
par exemple) sans changer le reste de l'application. De même, la base de données peut-être
complètement refondue pour pouvoir répondre à d'autres applications sans que le service initial ne
soit affecté de manière visible. Un point important de ces architectures concerne la sécurité : si le
réseau est constitué correctement, un client ne pourra pas réaliser directement des requêtes SQL sur
le serveur de base de données.
La représentation habituelle pour une application basée sur le protocole HTTP est la suivante :

Plusieurs remarques peuvent être faite :

- cette architecture à 3 niveaux ne possèdent que 2 serveurs, la fonction d'affichage est le rôle du
client (navigateur). Cette approche n'est pas générale, car c'est bien le serveur (WEB+PHP) qui
génère les ordres graphiques (HTML) le client n'est là que pour suivre directement les ordres. Quoi
qu'il en soit le client a un rôle de gestion d'interface homme-machine, mais un 4ème niveau celui de
la mise en forme des données pourrait être rajouté à cette architecture. Elle serait plus évidente si
l'application était basée sur un autre protocole que HTTP.

5
- La structure client/serveur WEB est un contre exemple parfait de l'architecture client/serveur X
(ou l'inverse !) : en effet dans un relation client/serveur X11, c'est le serveur qui affiche et le client
qui génère les ordres alors que dans une structure WEB c'est l'inverse, l'informatique s'éloigne
quelquefois (souvent ?) de la pure logique comme le montre cette phrase !

Lors de la mise en œuvre de cette architecture à 3 étages dans un réseau de type LAN des
problèmes de sécurité peuvent apparaître :

En effet, le client peut accéder directement par une autre application au serveur de base de données,
il n'y a pas d'impossibilité physique. Il faut alors prévoir d'introduire des contraintes au niveau des
équipements intermédiaires (VLAN...) si l'on veut empêcher cet accès.
Une autre évolution, liée à la sécurité, concerne l'authentification du client, cette dernière peut-être
gérée par un serveur spécifique (LDAP...) et constitue alors un niveau supplémentaire.

1.2.2 Durée de l’échange, connexion

Lors d'échanges entre client et serveur les données échangées peuvent être importantes en taille. Il
n'est pas rare que des pages WEB contenant des images dépassent les 100 Koctets où qu'un fichier à
transférer dépasse le Mo. Le bon fonctionnement de tels échanges nécessite une permanence dans le
temps de la relation client/serveur, c'est à dire un fonctionnement en mode connecté. De même pour
des raisons de sécurité, on peut aussi désirer une permanence à plus long terme (jusqu'à fermeture
du navigateur ou déconnexion volontaire de l'utilisateur).
Suivant les caractéristiques de l’application, la gestion de la connexion peut se faire sur des couches
différentes :
Transport (TCP : connexion standard)
Session (session utilisateur)
ou au niveau de l’application (cookies…)

1.2.3 Middleware
Le middleware (quelquefois traduit en français sous le terme Intergiciel) est un ensemble de
protocoles, logiciels permettant de réaliser les relations applications clients / serveurs.

D’un point de vue des communications le middleware se situe au niveau des couches
intermédiaires : Session, Présentation, Application

6
Mais il peut représenter un ensemble plus complet d'outils (API : Application Programming
Interface) permettant cet échange en facilitant le développement d’applications qui doivent
s’interfacer avec un type de serveur donné. Puisqu'il est situé au-dessus de la couche transport, mais
en dessous d'une application, il a un lien direct avec le Système d’exploitation. Toutefois ce terme
n'a pas une définition très précise comme peuvent l'avoir les fonctions des couches basses. En
particulier, son usage a évolué en fonction du temps et des catégories d'applications qu'il doit
supporter.

Il existe différents catégories de middleware relativement à la technologie mise en œuvre :

- Echange de messages via une File d’attente

il nécessite un formatage propriétaire des messages, du code spécifique côté client et
serveur, mais la mise en œuvre est simple et fiable.

- Appel de procédures distantes (RPC : Remote Procedure Call)

L'appel de fonctions distantes se fait comme dans un programme standard, il est
alors nécessaire de définir une interface des procédures standardisée (IDL : interface
definition language) : concernant les noms et les paramètres.

- Objets distribués (CORBA, DCOM...)

Il y a proposition de services par des objets distribués sur un réseau avec les mêmes
"avantages" que la programmation objet relativement à la programmation procédurale.

Exemple : couche RPC sous UNIX :

Programme Client Serveur

Callrpc()

Execute
request Call
service

Service
execute

Request
completes
Return
reply

Suite du
programme

Fonctionnement :
Appel CallRPC() identique à une fonction avec des paramètres mais la requête est transmise sur le
réseau. Cet appel distant bloque le thread jusqu’au retour de la réponse (ou time out).
La machine serveur exécute réellement la fonction et renvoie par le réseau le résultat du traitement
au thread en attente.
Celui-ci se débloque et poursuit son exécution.

7
Structures des couches intermédiaires :

Exemple 1 : Partage de fichiers sous Windows (avec l'usage de TCP/IP)

Application

Couche Application/Présentation SMB/CIFS

Couche « Session » NetBIOS
Couche d'interface NbT
Couche Transport TCP

IP

Couches basses

Exemple 2 : Partage de Fichiers sous UNIX

Application

Couche Application NFS (Network File System)

Couche Présentation XDR (eXchange Data Representation)

Couche « Session » RPC (Remote Procedure Call)
Couche Transport TCP
IP
Couches basses

Exemple 3 : Autres cas sous UNIX

Très souvent l’application descend jusqu’à la couche transport quand il y a utilisation directe de
l’API socket. Sous Windows, c’est souvent le cas si l’application vient du monde UNIX.

8
 Application

Couche Application... FTP

Couche Transport TCP

IP

Couches basses

Remarque : l'application est souvent découpée en fonctions liées aux couches OSI, mais cela
n’apparaît pas dans les PDU.

1.3 Classifications des serveurs (et des services)

1.3.1 Différents types de serveurs
Serveurs d’infrastructure
Serveurs proposant des services nécessaires au fonctionnement de l’infrastructure de
communication. Exemples : serveurs DNS, DHCP, WINS, LDAP, contrôleur de domaine

Serveurs de ressources
Serveurs proposant des services liés à l’usage direct d’une de ses ressources par le client pour le
même usage. Exemples : serveurs de fichiers, d’impression

Serveurs d’applications
Serveurs proposant l’exécution d’une application particulière à distance. Exemples : serveurs de
terminaux, serveur Telnet

Serveurs de communication
Serveurs proposant un partage de ses capacités de communications (cartes réseaux) vers l’extérieur.
Il a des fonctionnalités proche de celles d’un routeur. Exemples : serveurs d’accès distants (VPN).

Serveurs spécifiques
Serveurs multimédia, serveurs de base de données, serveurs d’entrepôt de données (Data
WareHouse)...

Serveurs de groupware
Services utilisant des informations formatées à destination d’un utilisateur humain. Exemples :
mail, gestion de documents…

Serveurs d’applications WEB

Serveurs de fichiers (HTML) dans sa version statique simple. Il y a eu une évolution vers un
partage des traitements (sur le client et sur le serveur) via des langages (scripts) pour avoir une
interactivité.

9
Usage presque généralisé comme une interface normalisée pour diverses applications : client à tout
faire (messagerie, gestion et configuration d’applications...)
Les applications WEB évoluent vers des interactions de plus en plus complexes.

1.3.2 Serveurs d'infrastructures

Serveurs DHCP
Utilité : attribution d’une adresse IP à un poste sans adresse fixe

Demande non ciblée (de type BroadCast : couche MAC et réseau) :

Plusieurs serveurs possibles (redondance), il faut donc définir un protocole (protocole DHCP), au
dessus de UDP. Les serveurs attribuent une adresse au poste via un bail (durée limitée), il doit donc
redemander une adresse périodiquement.
Comme les trames BroadCast sont non routées, il est nécessaire de définir un serveur relais si les
serveurs DHCP sont sur un autre sous-réseau. Le serveur DHCP relais va donc rediriger la demande
en interceptant les requêtes DHCP puis les envoyer vers un ou plusieurs serveurs DHCP connu par
le serveur relais avec une adresse fixe donc routable. Le chemin de retour repasse par le serveur
relais ou est direct pour un renouvellement car alors les trames ont des adresses IP unicast.

Serveurs DNS
Utilité : Résolution d’un nom littéral vers une adresse IP

10
Le protocole DNS est basée sur UDP ou TCP. Il met en oeuvre une recherche arborescente (par
zone) en travaillant sur une base de données répartie. Chaque domaine possède un serveur DNS de
zone locale qui définit la correspondance entre les noms des machines locales et leur adresse IP. Les
demandes remontent vers un serveur racine puis sont renvoyées vers le serveur de zone locale qui
donne l'information recherchée.

Serveurs d’annuaire LDAP

Utilité : Services d’authentification ou de recherche d’informations

Ce service permet entre autre une authentification centralisée, lorsque des clients veulent accéder à
différents services (serveurs). Le protocole LDAP sert souvent à une communications entre
serveurs. Les applications serveurs concernées par cette authentification doivent posséder un
module LDAP client pour aller interroger le serveur LDAP. C'est une architecture à plusieurs
niveaux.

11
1.3.3 Serveurs de ressources
Serveurs de fichiers
Utilité : partage de fichiers et centralisation du stockage.

C'est un service complexe car il est souvent transparent pour l’utilisateur, il est donc intégré dans le
système d’exploitation. Les protocoles mis en œuvre sont donc des protocoles spécifiques au SE
(on retrouve ici la notion de Middleware).

Pour Windows, ce service est basé sur CIF(SMB)/NetBIOS.

Pour UNIX, il est construit à partir des RPC et de NFS/XDR

Serveurs d’impression
Utilité : partage d'imprimantes et gestion centralisée des quotas

C'est aussi un service complexe car les périphériques sont considérés comme des fichiers dans les
systèmes d'exploitation.
Les services proposés sont par exemple : Spooler (désynchronisation de l'envoi et de l'impression),
contrôle de volume (taille), contrôle horaire...

1.3.4 Serveurs d'applications

12
Serveurs de terminaux
Utilité : travail à distance sur une autre machine

Dans ce cas, non seulement les données sont à distance, mais le code exécuté aussi. Le client n'est
en fait qu'un terminal de contrôle et de visualisation.
Console texte déportée : Telnet
Environnement graphique déporté : console à distance Windows, XWindows sous UNIX
Les problème de sécurité doivent être pris en compte : protocoles cryptés, accès restreint pour
certains comptes.
Le domaine des serveurs d'applications est un secteur en plein développement depuis quelques
années, où l'externalisation des ressources informatiques se développent rapidement dans les
entreprises (serveurs CITRIX, virtualisation…). Ce sont des technologies de plus en plus présentes..

1.3.5 Serveurs de communication : serveurs d’accès distant

Utilité : partage et contrôle d'un accès longue distance (Internet)

Les services sont comparables à ceux d'un routeur mais c'est une approche différente. Ce service
englobe d'autres fonctionnalités : authentification, cache
En général, ils ont moins de puissance qu'un routeur en terme de débit routé brut.

1.3.6 Serveurs de groupWare

Serveurs de Mail

13
Utilité : envoi, réception, stockage de messages

Même si le service global, met en œuvre un échange final de type Client/Client, des services
intermédiaires sont utilisés. Les serveurs fournissent donc les fonctions : Stockage temporaire,
Aiguillage (DNS), Renvoi...
Le service de messagerie est basé sur des protocoles asymétriques (l'envoi et la lecture des
messages ne se fait pas avec les mêmes protocoles :
Envoi : SMTP
Réception : POP, IMAP

Serveurs de base de données

Stockage de données, plus Possibilités de tri, recherche...

Langage SQL,...
Protocole encapsulant les requêtes et réponses

14
1.3.7 Autres.

Serveurs WEB

Initialement les serveurs WEB étaient uniquement des serveurs de pages HTML statiques, leur
fonction correspondait à un simple transfert de fichiers HTML. Maintenant, afin de permettre une
personnalisation des pages affichées, les serveurs WEB peuvent envoyer des pages HTML crées
dynamiquement (Calculs sur le serveur) ou contenant des scripts (fonctions) encapsulées (calculs
sur le client). On s'oriente de plus en plus vers des architectures plus complexes, où de nombreux
services sont apportés s'appuyant sur le protocole HTTP et les fonctionnalités des clients
(navigateurs). En fait, les protocoles applicatifs précédents (mail, transfert de fichiers...) sont
remplacés par le développement d'interfaces WEB, où chaque lien ou contrôle permet de mettre en
oeuvre une fonction, la complexité est reportée sur le serveur, au bénéfice d'un client générique
(exemple : WEBMail versus client de messagerie).

Transfert de fichiers

Ne pas mélanger avec serveurs de fichiers, ici les fichiers sont physiquement transférés (donc il en
existe 2 copies).
Ce sont des protocoles plus simples qui permettent une compatibilité inter-plateforme : FTP ; TFTP
et qui sont surtout utilisés à plus longue distance.

15
1.4 Lien Serveur - Système d’exploitation
1.4.1 Généralités
Les fonctionnalités serveur sont toujours supportés par un système d’exploitation. En effet, un
serveur utilise des ressources gérées par le SE : disque, mémoire, UC, périphériques.
Pour cela le SE met aussi à disposition des ressources logicielles : threads, sémaphores,
descripteurs, priorités…, ainsi que des outils de surveillance, de statistiques...

L'intégration des fonctionnalités serveur au sein d'un SE peut se faire suivant différentes approches
en fonction des caractéristiques initiales des SE. Actuellement, tous les SE serveur sont basés sur
des SE standard : UNIX/Linux, Windows

1.4.2 Classes de Systèmes d’exploitation serveurs:

Windows :
Evolution NT -> 2000 -> 2003 -> 2008 -> 2012, avec une approche basée sur des services intégrés.

UNIX :
UNIX propriétaires, Linux et dérivés
Le système d'exploitation standard possède un serveur de fichiers natif (NFS), les autres services
sont ajoutés comme des applications supplémentaires, plusieurs solutions peuvent alors être
choisies.

1.4.3 Applications serveurs de windows 2003

Serveurs DNS, DHCP, WINS
Contrôleur de domaine (Active directory…)
Serveurs de fichiers, d’impression
Serveurs d’applications (IIS, ASP, NET)
Serveurs de messagerie (Exchange Server 2003)
Serveurs multimedia par flux
Serveurs de terminaux
Serveurs d’accès distants (VPN)

1.4.4 Applications serveurs de UNIX/Linux

Serveurs de fichiers natifs (NFS)
Gestion des comptes natifs (NIS)
Serveurs DNS, DHCP, WINS
Serveurs d’applications : Apache...
Serveurs de messagerie (sendmail,...)
Serveurs de terminaux (protocole X11)
Serveurs d’accès distants
Serveur SAMBA (emulation windows), contrôleur de domaine

1.4.5 Part de marché

Pour les serveurs, le renouvellement est moins rapide que pour les postes clients (10 ans). Le choix
est fonction du type ou de la taille des entreprises. Historiquement, les serveurs de taille importante

16
fonctionnaient sous UNIX. Mais Microsoft s’est aussi positionné, depuis Windows Serveur 2003,
sur le marché des gros réseaux.
De manière synthétique, on évalue les parts de marché de manière équitable entre les 2 familles.
Mais ceci n’est qu’une évaluation car certains systèmes Linux ne sont pas déclarés (et non visible
s’ils n’ont pas d’interaction avec le Web). Une mesure peut-être réalisée sur les serveurs web
public.

Windows 2000, 2003, 2008... : 50%

UNIX/Linux : 50% (avec une prépondérance de Linux relativement aux UNIX propriétaires
(Solaris...)
Il existe aussi une offre importante de fabricants sur des systèmes Linux adaptés avec ajout de
services supplémentaires (Novell...). De plus avec la généralisation de la virtualisation, le nombre
de serveurs visibles a largement augmenté même s'ils ne correspondent pas à des machines
physiques différentes.

17
1.5 Questions concernant ce chapitre.
Les éléments de réponse sont en partie seulement dans le polycopié, l'usage de documents
complémentaires est conseillé (livres, Internet, RFC...). De plus, les réponses ne sont pas uniques et
donc aucune correction ne pourra être fournie...!

Question 1 :
Donner pour chaque ressource un ou plusieurs exemples de serveurs l'utilisant :
- Espace de stockage
- Temps UC (+ mémoire centrale)
- Liaisons à des périphériques (Imprimantes, accès distant…)

Question 2 :
Imaginer une architecture Client/Serveur 4 tier.
Dessiner un schéma de principe
Attribuer des fonctions cohérentes à chaque étage
Dessiner la mise en oeuvre réelle

Question 3 :
Comment est mis en place la permanence dans le temps de la relation client-serveur :
Au niveau de quelles couches OSI ?
A partir de quels éléments ?

Question 4 :
Dessiner les interactions qu'il peut y avoir entre les différents éléments d'un ordinateur en relation
client/serveur :
- Noyau du SE
- Périphériques
- Drivers
- Applications
- Middleware
- Logiciel de développement : API
- Autres... (nécessaires pour reliés les précédents)

Question 5 :
Donner des exemples de serveurs d'infrastructure
- Noms des Services
- Fonctions principales

Question 6 :
Donner des exemples de serveurs de ressources
- Noms des Services
- Fonctions principales

18
Question 7 :
Un Serveur d’applications c'est quoi ?
Exemples (aller voir sur le WEB)

Question 8 :
A quoi sert un serveur d’accès distant ?
Donner un schéma de fonctionnement

Question 9 :
Donner le parcours d'un mail envoyé par un utilisateur de la machine de gauche vers un utilisateur
de celle de droite.
Donner le parcours du même mail lu par un utilisateur de la machine de droite

Question 10 :
Donner la liste des systèmes d'exploitation serveur connus ainsi que les différentes versions
Si vous aviez à choisir un système serveur lequel prendriez-vous ?
Pourquoi, avantages/inconvénients

19