📕 Communication d’un logiciel sur un réseau
| L’icône rouge 📕 signifie que ce chapitre ne sera pas présenté en séance de CM, et sera donc entièrement à travailler en autonomie. Il est important de l’avoir lu et préparé avant la séance sur le chapitre suivant. |
| Ceci n’étant pas un cours de réseau, nous prenons ici certains raccourcis ! |
Un processus doit être capable de communiquer avec d’autres processus pour échanger des informations ou des requêtes. Ces autres processus peuvent soit se trouver dans un autre environnement (par exemple une autre machine physique), ou bien peuvent se trouver dans le même environnement.
Supposons qu’on souhaite les programmes jouets suivants :
-
Un premier programme Receiver qui une fois exécuté est un processus qui attend qu’on lui envoie des messages. À chaque fois qu’il reçoit un message, il l’affiche dans la console, puis répond
"Bien reçu"à l’expéditeur du message. -
Un second programme Sender qui une fois exécuté est un processus qui tente de se connecter à un processus issu du premier programme, puis s’il réussit, envoie le message
"Bonjour !", affiche la première réponse reçue, puis envoie"Au revoir", et affiche la seconde réponse reçue.
Comment concrètement faire pour que ces deux logiciels puissent communiquer entre eux ? Et comment permettre cela :
-
avec les deux processus dans le même environnement ? (par exemple la même machine)
-
avec les deux processus chacun dans un environnement différent ? (par exemple deux machines différentes)
Simplestblog représente un type classique de déploiement, à savoir un logiciel qui s’exécute sous la forme d’un serveur web, nom donné à un processus qui écoute sur un port réseau et qui s’attend à recevoir des connexions réalisées de la part de navigateurs web (Firefox, Chrome, etc.). Dans ce contexte, un navigateur web est donc un processus client que l’on appelle un client web. Lorsqu’un client web contacte un serveur web, ce dernier répond au client web avec une page HTML à afficher.
En outre, là aussi de manière assez classique, Simplestblog stocke ses données dans un système de gestion de base de données (SGBD) via un logiciel à part appelé MariaDB. Dans ce contexte, c’est Simplestblog qui joue le rôle de processus client qui se contacte au processus serveur du SGBD.
Ce déploiement aura donc besoin de deux types de communications inter-processus :
-
le processus qui exécute le serveur web aura besoin de communiquer avec le processus qui gère le SGBD,
-
le processus du serveur web devra recevoir des requêtes envoyées par les processus de navigateurs web (Firefox, Chrome, etc).
Si on reprend le schéma de déploiement vu juste précédemment, on a donc la situation suivante :
Il est également possible de partir sur un déploiement où le serveur web et le SGBD sont chacun dans un environnement différent. On obtient alors la situation alternative suivante :
1. Connecter des environnements via des réseaux informatiques
Un réseau informatique est un moyen par lequel plusieurs processus logiciels peuvent communiquer entre eux. On peut distinguer deux grandes catégories des réseaux :
-
Un réseau physique est un réseau qui connecte physiquement différentes machines − c’est-à-dire des environnements physiques − entre elles (ex. ordinateurs, serveurs, téléphones), que ce soit par des moyens filaires (câbles ethernet, switchs, etc.) ou sans-fil (WiFi). Cela permet à des processus logiciels exécutés sur des machines différentes de communiquer entre eux. On distingue généralement :
-
Un réseau local (en anglais local area network (LAN)) est un réseau physique qui relie entre eux différentes machines pour un objectif donné, et sur un périmètre donné. On peut trouver des réseaux locaux de tailles très diverses, que ce soit à l’échelle d’un foyer (la fameuse box internet crée un réseau local entre les quelques machines d’une maison) ou à l’échelle d’une entreprise ou d’une université (où une interconnexion de switchs et de routeurs permet de relier entre elles des dizaines, voire des centaines de machines).
-
Internet est le nom donné au réseau physique international qui relie une très large quantité de machines du monde entier entre elles. C’est en fait un immense réseau local, tellement grand qu’il en devient… global ! Un grand nombre de machines ne sont pas directement sur le réseau Internet, mais sont sur un réseau local possédant une passerelle qui fait le lien avec le réseau Internet (ex. ce que fait une box Internet).
-
-
Un réseau virtuel est un réseau qui n’a pas d’existence physique à proprement parler, et qui permet notamment de définir comment plusieurs processus peuvent communiquer entre eux au sein d’un même environnement. Un réseau virtuel particulier est le réseau de rebouclage (en anglais loopback), qui permet de connecter un environnement "à lui-même" qui permet à des processus de communiquer entre eux au sein de ce même environnement. Il existe toujours exactement un réseau de rebouclage pour chaque environnement.
| Attention, il existe dans la littérature le concept de Virtual LAN (VLAN), qui est distinct de ce que nous appelons dans le cours réseau virtuel. En très simplifié, un VLAN est une manière logicielle de créer de définir des règles par-dessus un ou plusieurs réseaux physiques afin pour définir de nouveaux réseaux locaux. Nous ne verrons pas de VLANs dans ce cours. |
| Nous verrons dans la suite du cours une nouvelle sorte de réseaux virtuels permettant de relier entre eux des conteneurs. |
2. Interfaces, adressages et nommages
Pour pouvoir se connecter à un réseau, un environnement doit posséder une interface réseau, qui comme un réseau peut être soit matérielle (ex. une carte ethernet ou une carte WiFi), soit virtuelle (ex. l’interface de rebouclage). Une interface réseau est connectée à un seul réseau informatique, mais un hôte peut posséder plusieurs interfaces réseau (et ainsi être connecté à plusieurs réseaux à la fois).
| Comme un environnement possède toujours un réseau de rebouclage qui lui est propre, il possède également toujours une interface de rebouclage pour se connecter à ce réseau interne. |
Dans un environnement Linux, la commande ip link permet de lister toutes les interfaces réseau disponibles (et également tout un tas d’informations que nous n’allons jamais utiliser).
$ ip linkExemple de résultat :
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp55s0u2u1i5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
link/ether 9c:eb:e8:53:46:2e brd ff:ff:ff:ff:ff:ff
altname enx9cebe853462e
3: wlo1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 56:98:85:62:56:20 brd ff:ff:ff:ff:ff:ff permaddr 18:cc:18:cb:b4:7f
altname wlp0s20f3
altname wlx18cc18cbb47fIci on peut voir que l’environnement possède :
-
Une interface réseau
lo, à savoir l’interface de rebouclage de l’environnement, -
Une interface réseau
enp55s0u2u1i5, qui correspond à la carte réseau ethernet de l’environnement, -
Une interface réseau
wlo1, qui correspond à la carte réseau WiFi de l’environnement.
Chaque environnement connecté au sein d’un réseau informatique est appelé un hôte (ou éventuellement nœud) de ce réseau.
Lorsqu’un hôte est connecté à un réseau à l’aide d’une de ses interfaces réseau, il se voit affecter une adresse IP, à savoir un identifiant unique pour cette interface sur le réseau considéré.
Dans ce cours, nous nous concentrerons sur les adresses IPv4 qui s’écrivent sous la forme XXX.XXX.XXX.XXX, où XXX est un nombre entre 0 et 255.
L’adresse IP d’un hôte sur son réseau de rebouclage est toujours 127.0.0.1.
Ainsi, si un premier processus veut contacter un second processus situé dans le même environnement, il peut contacter 127.0.0.1.
|
Dans un environnement Linux, la commande ip addr permet de lister toutes adresses IP de l’environnement (et également tout un tas d’informations que nous n’allons jamais utiliser).
$ ip addrExemple de résultat :
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6{nbsp}::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: enp55s0u2u1i5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 9c:eb:e8:53:46:2e brd ff:ff:ff:ff:ff:ff
altname enx9cebe853462e
inet 192.168.1.68/24 brd 192.168.1.255 scope global dynamic noprefixroute enp55s0u2u1i5
valid_lft 78254sec preferred_lft 78254sec
inet6 2a02:8428:805f:3601:4c3c:c1e9:d44f:9884/64 scope global dynamic noprefixroute
valid_lft 604677sec preferred_lft 604677sec
inet6 fe80::e611:d155:e230:bb5a/64 scope link noprefixroute
valid_lft forever preferred_lft forever
3: wlo1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 56:98:85:62:56:20 brd ff:ff:ff:ff:ff:ff permaddr 18:cc:18:cb:b4:7f
altname wlp0s20f3
altname wlx18cc18cbb47fIci on peut voir que l’environnement possède :
-
Pour l’interface
lo(interface de rebouclage), l’adresse IP127.0.0.1, -
Pour l’interface
enp55s0u2u1i5(carte réseau ethernet), l’adresse IP192.168.1.68, -
Pour l’interface
wlo1(carte réseau WiFi), aucune adresse IP.
Au sein d’un réseau informatique donné, en complément de son adresse IP, chaque hôte peut se voir attribuer un nom d’hôte (en anglais hostname), à savoir un identifiant unique sous une forme textuelle.
Un nom d’hôte est une chaîne de caractères ASCII (ce qui exclut les caractères accentués) contenant des lettres, des chiffres, des tirets - et des points ..
Au sein d’un réseau, chaque nom d’hôte correspond à exactement une adresse IP.
Sur un réseau de rebouclage, le nom d’hôte d’un environnement est toujours localhost (qui correspond donc à l’IP 127.0.0.1).
Ainsi, si un premier processus veut contacter un second processus situé dans le même environnement, il peut contacter localhost !
|
Comparé aux IPs, l’intérêt des noms d’hôte est double :
-
cela permet d’une part de ne pas directement manipuler les pénibles séquences de chiffres des adresses IP, difficiles à mémoriser et à différencier,
-
cela permet d’autre part de découpler le nom d’un hôte de son adresse IP, ce qui est très utile lorsque l’affectation d’une adresse IP est aléatoire, mais que le nom lui est affecté de manière constante.
| Un nom d’hôte est spécifique à un réseau informatique donné. Ainsi, lorsqu’un hôte est simultanément connecté à plusieurs réseaux informatiques, il pourra posséder plusieurs noms d’hôte, chaque nom d’hôte étant spécifique à un réseau. |
Dans un environnement Linux, la commande getent hosts permet :
-
de lister quelle est l’adresse IP associée à un nom d’hôte donné.
-
de lister quels sont les noms d’hôte associés à une adresse IP donnée,
Si on utilise ce deuxième mode dans le même environnement exemple que précédemment, on peut par exemple faire :
$ getent hosts 127.0.0.1donne pour résultat :
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4ce qui indique que quatre noms d’hôte existent pour 127.0.0.1, à savoir localhost (qui sera toujours associé à 127.0.0.1, quel que soit l’environnement !), localhost.localdomain, localhost4 et localhost4.localdomain4.
Autre exemple :
$ getent hosts 192.168.1.68donne pour résultat :
192.168.1.68 mohnstrudelce qui indique que seul le nom d’hôte mohnstrudel est associé à l’IP 192.168.1.68.
| Si chaque hôte possède un nom d’hôte, il n’est même plus nécessaire de directement connaître ou manipuler la moindre adresse IP. C’est ce que nous allons souvent faire dans ce cours ! |
Reprenons notre exemple jouet avec les logiciels Receiver et Sender.
Dans un premier schéma de déploiement, nous imaginions avoir les deux processus s’exécutant dans le même environnement. Cet environnement possède un réseau de rebouclage que les processus pourront utiliser :
Dans un second schéma de déploiement, nous imaginions avoir les deux processus dans des environnements séparés. Dans ce cas, un réseau local sera nécessaire pour leur communication :
Reprenons notre exemple Simplestblog.
Dans un premier schéma de déploiement, nous imaginions avoir le serveur web et le SGDB s’exécutant dans le même environnement. Cet environnement possède forcément un réseau de rebouclage que les processus pourront utiliser. Cependant, l’environnement utilisateur avec le navigateur web Firefox sera lui forcément dans un environnement à part. Dans ce cas, un réseau local sera nécessaire pour permettre au navigateur web de communiquer avec le serveur web :
Dans un second schéma de déploiement, nous imaginions avoir le serveur web et le SGDB s’exécutant chacun dans un environnement différent. Dans ce cas, un réseau local sera également nécessaire pour leur communication, et cela peut être le même réseau local que pour la liaison entre l’environnement utilisateur et celui du serveur web :
3. Communication entre processus à l’aide de ports réseaux
Revenons à notre problème initial : comment permettre à deux processus logiciels de communiquer entre eux ? Le principe parait simple : si un processus se trouve sur un réseau informatique, il peut ouvrir un canal de communication avec un hôte cible de ce réseau informatique, à condition de connaître son adresse IP ou son nom d’hôte.
Cependant, si plusieurs processus s’exécutent sur cet hôte cible, comment faire en sorte que le canal soit ouvert avec le bon processus ? Par exemple, si cet hôte cible possède à la fois un processus serveur web et un processus serveur de base de données, comment peut-on choisir de se connecter spécifiquement au processus serveur web ?
| Si on rephrase de manière plus "imagée" : imaginons que notre hôte cible soit un immeuble, que notre nom d’hôte soit l’adresse de l’immeuble, et que nos processus soient des appartements de cet immeuble. On souhaite envoyer une lettre à un appartement. Si on écrit sur cette lettre uniquement l’adresse de l’immeuble, sans nom ni numéro d’appartement, comment peut-elle atteindre le bon appartement ? |
Pour résoudre ce problème, il est nécessaire que chaque processus qui souhaite pouvoir recevoir des messages soit identifiable au sein de l’hôte dans lequel il s’exécute. Un tel identifiant s’appelle un port réseau, et prend la forme d’une valeur entière comprise entre 0 et 65536.
| Tout comme une adresse IP ou un nom d’hôte est spécifique à un réseau informatique donné, un port réseau est spécifique à un hôte donné. Par conséquent, le même numéro de port peut être utilisé par différents processus au sein du même réseau : étant donné deux hôtes X et Y au sein du même réseau informatique, il est possible d’affecter à un processus A le port réseau 777 dans l’environnement X, et à un processus B le port réseau 777 dans l’environnement Y. Même si par coïncidence le même numéro de port est utilisé, ce sont bien deux processus distincts dans deux environnements distincts : il n’y a pas d’ambiguïté. |
Ainsi, à l’aide d’un port réseau, la communication entre deux processus sur un réseau informatique se déroule généralement de la manière suivante :
-
Un premier processus dit serveur demande à son système d’exploitation de lui affecter un port réseau sur une interface réseau donnée (elle-même connectée à un réseau donné). Le système d’exploitation mémorise également que le processus serveur "écoute" sur ce port, c’est-à-dire est prêt à recevoir des requêtes avec ce port en destinataire.
-
Un second processus dit client souhaite contacter le premier processus. Pour cela, il se connecte auprès de l’environnement du processus serveur (à l’aide de son nom d’hôte ou de son adresse IP), et demande au système d’exploitation de ce dernier s’il peut se connecter à un port réseau de son choix. Si le port indiqué est bien celui sur lequel le processus serveur écoute, une connexion est établie, et les deux processus (serveur et client) peuvent communiquer entre eux de manière bidirectionnelle.
Pour résumer, un processus client souhaitant contacter un processus serveur sur un réseau a besoin d’une paire composée :
-
d’un identifiant de l’environnement de déploiement à contacter, à savoir soit son nom d’hôte, soit son adresse IP
-
d’un identifiant du processus à contacter au sein de la cible, à savoir son numéro de port.
On écrit très souvent une telle paire sous la forme <nom d’hôte>:<port> (par exemple serveurweb:80), ou <adresse IP>:<port> (par exemple 10.0.0.15:80).
| On notera que la création d’un canal de communication réseau est une opération asymétrique : il faut toujours qu’un premier processus serveur écoute sur un port, et qu’un second processus client se connecte ensuite à ce port. Ainsi, un processus qui n’écoute sur aucun port ne pourra communiquer avec d’autres processus que en se connectant à d’autres ports réseaux. |
| Un processus peut tout à fait agir simultanément comme serveur et comme client. |
Reprenons notre exemple jouet avec les logiciels Receiver et Sender.
Dans le premier schéma de déploiement où les deux processus s’exécutent dans le même environnement, le processus Receiver peut choisir d’écouter sur un port réseau de son choix − par exemple 7777 − sur l’interface réseau de rebouclage.
localhost)import socket
listening_address = 'localhost'
listening_port = 7777
server_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server_socket.bind((listening_address, listening_port))
server_socket.listen()
print("Listening on " + listening_address + ":" + str(listening_port))
conn, addr = server_socket.accept()
print("Connected from: " + str(addr))
while True:
data = conn.recv(1024).decode()
print(data)
response_data = "Message Received"
conn.send(response_data.encode())Le processus Sender peut alors se connecter à lui en contactant le nom d’hôte localhost sur le port 40, autrement écrit sous la forme localhost:7777.
localhost)import socket
target_host = 'localhost'
target_port = 7777
client_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
print("Connecting to " + target_host + ":" + str(target_port))
client_socket.connect((target_host, target_port))
print("Please type the message you wish to send:")
message = input(">> ")
while message.lower().strip() != "quit":
client_socket.send(message.encode())
data = client_socket.recv(1024).decode()
print("Response from server: " + str(data))
print("Please type the message you wish to send:")
message = input(">> ")
client_socket.close()
Dans le second schéma de déploiement où les deux processus s’exécutent dans des environnements séparés, le processus Receiver peut là aussi écouter sur un port 7777, mais sur l’interface réseau ethernet reliée au réseau local.
On sait que l’adresse IP de env1 sur le réseau local est 10.0.0.10.
10.0.0.10)import socket
listening_address = '10.0.0.10'
listening_port = 7777
… (suite identique au script présenté avant)Le processus Sender peut alors se connecter à lui en contactant le nom d’hôte env1 (qui correspond à 10.0.0.10) sur le port 7777, autrement écrit sous la forme env1:7777.
localhost)import socket
target_host = 'env1'
target_port = 7777
… (suite identique au script présenté avant)
Reprenons notre exemple Simplestblog.
Dans le premier schéma de déploiement où le serveur web et le SGDB s’exécutent dans le même environnement,
le processus MariaDB choisit d’écouter sur le port 3306 de l’interface de rebouclage.
Ainsi, le processus Simplestblog peut se connecter au processus MariaDB en se connectant à localhost:3306.
Ensuite le processus Simplestblog choisit lui d’écouter sur le port 5000 pour recevoir les connexions utilisateur⋅ices, mais sur l’interface réseau ethernet.
Ainsi, le processus Firefox situé dans un environnement utilisateur séparé, peut le contacter en se connectant à serveur:5000.
Dans un second schéma de déploiement, nous imaginions avoir le serveur web et le SGDB s’exécutant chacun dans un environnement différent. Dans ce cas, un réseau local sera également nécessaire pour leur communication, et cela peut être le même réseau local que pour la liaison entre l’environnement utilisateur et celui du serveur web :
Dans le second schéma de déploiement où le serveur web et le SGDB s’exécutent chacun dans un environnement différent,
le processus MariaDB choisit cette fois d’écouter sur le port 3306 de l’interface ethernet de son propre environnement.
Ainsi, le processus Simplestblog peut se connecter au processus MariaDB en se connectant à serveur2:3306.
Puis comme dans le premier schéma de déploiement, le processus Simplestblog écoute sur le port 5000 sur l’interface réseau ethernet, et ainsi, le processus Firefox peut le contacter en se connectant à serveur1:5000.
Depuis les premiers chapitres et le premier TP, nous avons vu comment le protocole SSH pouvait nous permettre de transférer des fichiers et de contrôler à distance des environnements de déploiement.
Or un accès SSH à un environnement distant se fait nécessairement par le réseau ! Voyons comment cela fonctionne avec les notions vues dans ce chapitre.
Supposons la situation suivante :
-
Un environnement de déploiement distant appelé
tatooineest connecté à un réseau ethernet filaire. Dans cet environnement, le logicielsshd(à ne pas confondre avecssh), à savoir un serveur SSH capable de recevoir des connexions SSH distantes, est en cours d’exécution. Ce processussshdécoute sur le port 22 de l’environnement. -
Notre poste de travail appelé
mycomputerest lui connecté au même réseau ethernet filaire que l’environnement de déploiement. Depuis ce poste de travail, on exécute l’outilsshen lui indiquant qu’on souhaite se connecter au nom d’hôtetatooine, avec le nom d’utilisateuranakin. On saisit donc la commande suivante :$ ssh anakin@tatooine -
Dès lors,
sshva ouvrir une communication avec le port 22 (port par défaut pour toute connexion SSH) ouvert par l’environnementtatooine, et rentrer ainsi en communication avec le processussshdqui écoutait sur ce port. Le connexion SSH est alors établie, et on peut commencer à contrôler l’environnementtatooineà distance.
En image :
