Architectures d'applications réseaux

Avant de commencer le codage logiciel, vous devez disposer d'un plan architectural général pour votre application. Gardez à l'esprit que l'architecture d'une application est nettement différente de l'architecture du réseau (par exemple, l'architecture Internet à cinq couches). Du point de vue du développeur d'applications, l'architecture du réseau est fixe et fournit un ensemble spécifique de services aux applications. L'architecture de l'application, quant à elle, est conçue par le développeur de l'application et dicte la manière dont l'application est structurée sur les différents systèmes d'extrémité. En choisissant l'architecture d'application, un développeur d'application s'appuiera probablement sur l'un des deux paradigmes architecturaux prédominants utilisés dans les applications de réseau modernes : l'architecture client-serveur ou l'architecture peer-to-peer (P2P).

L’architecture traditionnelle est appelée le paradigme client-serveur. C'était le paradigme le plus populaire jusqu'à il y a quelques années. Dans ce paradigme, le fournisseur de services est un programme d'application, appelé serveur ; il s'exécute en continu, attendant qu'un autre programme d'application, appelé client, établisse une connexion via Internet et demande un service. Certains serveurs peuvent normalement fournir un type de service spécifique, mais de nombreux clients demandent un service à l'un de ces serveurs. Le serveur doit s'exécuter en permanence ; le client est lancé lorsque le client a besoin de recevoir un service.

Le paradigme client-serveur est similaire à certains services disponibles hors Internet. Par exemple, un centre d’appels dans n'importe quelle zone peut être considéré comme un serveur ; un abonné qui appelle et demande l’aide peut être considéré comme un client. Le centre d’appels doit être prêt et disponible à tout moment ; l'abonné peut appeler le centre pendant une courte période lorsqu’il a besoin du service fourni par le centre d’appels.

Un problème avec ce paradigme est que la concentration de la charge de communication repose sur l'épaule du serveur, ce qui signifie que le serveur doit être un ordinateur puissant. Même un ordinateur puissant peut être submergé si un grand nombre de clients essaient de se connecter au serveur en même temps.

Un autre problème est qu'il devrait y avoir un fournisseur de services prêt à accepter le coût et à créer un serveur puissant pour un service spécifique, ce qui signifie que le service doit toujours rapporter un certain type de revenu au serveur afin d'encourager un tel arrangement.

Plusieurs services traditionnels utilisent encore ce paradigme, notamment le World Wide Web (WWW) et son véhicule HyperText Transfer Protocol (HTTP), le protocole de transfert de fichiers (FTP), le shell sécurisé (SSH), le courrier électronique, etc.

Dans une architecture P2P, le recours à des serveurs dédiés dans des centres de données est minime (voire inexistant). Au lieu de cela, l'application exploite la communication directe entre des paires d'hôtes connectés par intermittence, appelés pairs(peers). Les pairs n'appartiennent pas au fournisseur de services, mais sont plutôt des ordinateurs de bureau et des ordinateurs portables contrôlés par les utilisateurs, la plupart des pairs résidant dans des maisons, des universités et des bureaux.

Comme les pairs communiquent sans passer par un serveur dédié, l'architecture est appelée peer-to-peer. Un exemple d'application P2P populaire est l'application de partage de fichiers BitTorrent.

L'une des caractéristiques les plus convaincantes des architectures P2P est leur auto-évolutivité. Par exemple, dans une application de partage de fichiers P2P, bien que chaque pair génère une charge de travail en demandant des fichiers, chaque pair ajoute également une capacité de service au système en distribuant des fichiers aux autres pairs. Les architectures P2P sont également rentables, car elles ne nécessitent normalement pas d'infrastructure de serveur ni de bande passante importante (contrairement aux conceptions client-serveur avec centres de données). Cependant, les applications P2P sont confrontées à des problèmes de sécurité, de performance et de fiabilité en raison de leur structure hautement décentralisée.

Une application peut choisir d'utiliser un mélange des deux architectures en combinant les avantages des deux. Par exemple, une communication client-serveur à faible charge peut être utilisée pour trouver l'adresse d’un pair (peer)qui peut offrir un service. Lorsque l'adresse du pair est trouvée, le service réel peut être reçu de pair en utilisant l’architecture peer-to-peer.