Comme je l'ai dit plus haut, le réseau est un sujet bien trop vaste pour que je le présente en un unique chapitre. On va s'attacher ici à comprendre comment faire communiquer deux applications, qui peuvent être sur la même machine mais aussi sur des machines distantes. Dans ce cas, elles se connectent grâce au réseau local ou à Internet.
Il existe plusieurs protocoles de communication en réseau. Si vous voulez, c'est un peu comme la communication orale : pour que les échanges se passent correctement, les deux (ou plus) parties en présence doivent parler la même langue. Nous allons ici parler du protocole
TCP .
Le protocole TCP
L'acronyme de ce protocole signifie
Transmission Control Protocol, soit « protocole de contrôle de transmission ». Concrètement, il permet de connecter deux applications et de leur faire échanger des informations.
Ce protocole est dit « orienté connexion », c'est-à-dire que les applications sont connectées pour communiquer et que l'on peut être sûr, quand on envoie une information au travers du réseau, qu'elle a bien été réceptionnée par l'autre application. Si la connexion est rompue pour une raison quelconque, les applications doivent rétablir la connexion pour communiquer de nouveau.
Cela vous paraît peut-être évident mais le protocole UDP (User Datagram Protocol), par exemple, envoie des informations au travers du réseau sans se soucier de savoir si elles seront bien réceptionnées par la cible. Ce protocole n'est pas connecté, une application envoie quelque chose au travers du réseau en spécifiant une cible. Il suffit alors de prier très fort pour que le message soit réceptionné correctement !
Plus sérieusement, ce type de protocole est utile si vous avez besoin de faire transiter beaucoup d'informations au travers du réseau mais qu'une petite perte occasionnelle d'informations n'est pas très handicapante. On trouve ce type de protocole dans des jeux graphiques en réseau, le serveur envoyant très fréquemment des informations au client pour qu'il actualise sa fenêtre. Cela fait beaucoup à transmettre mais ce n'est pas dramatique s'il y a une petite perte d'informations de temps à autre puisque, quelques millisecondes plus tard, le serveur renverra de nouveau les informations.
En attendant, c'est le protocole TCP qui nous intéresse. Il est un peu plus lent que le protocole UDP mais plus sûr et, pour la quantité d'informations que nous allons transmettre, il est préférable d'être sûr des informations transmises plutôt que de la vitesse de transmission.
Clients et serveur
Dans l'architecture que nous allons voir dans ce chapitre, on trouve en général un serveur et plusieurs clients. Le serveur, c'est une machine qui va traiter les requêtes du client.
Si vous accédez par exemple à OpenClassrooms, c'est parce que votre navigateur, faisant office de client, se connecte au serveur d'OpenClassrooms. Il lui envoie un message en lui demandant la page que vous souhaitez afficher et le serveur d'OpenClassrooms, dans sa grande bonté, envoie la page demandée au client.
Cette architecture est très fréquente, même si ce n'est pas la seule envisageable.
Dans les exemples que nous allons voir, nous allons créer deux applications : l'application serveur et l'application client. Le serveur écoute donc en attendant des connexions et les clients se connectent au serveur.
Les différentes étapes
Nos applications vont fonctionner selon un schéma assez similaire. Voici dans l'ordre les étapes du client et du serveur. Les étapes sont très simplifiées, la plupart des serveurs peuvent communiquer avec plusieurs clients mais nous ne verrons pas cela tout de suite.
Le serveur :
1. attend une connexion de la part du client ;
2. accepte la connexion quand le client se connecte ;
3. échange des informations avec le client ;
4. ferme la connexion.
Le client :
1. se connecte au serveur ;
2. échange des informations avec le serveur ;
3. ferme la connexion.
Comme on l'a vu, le serveur peut dialoguer avec plusieurs clients : c'est tout l'intérêt. Si le serveur d'OpenClassrooms ne pouvait dialoguer qu'avec un seul client à la fois, il faudrait attendre votre tour, peut-être assez longtemps, avant d'avoir accès à vos pages. Et, sans serveur pouvant dialoguer avec plusieurs clients, les jeux en réseau ou les logiciels de messagerie instantanée seraient bien plus complexes.
Établir une connexion
Pour que le client se connecte au serveur, il nous faut deux informations :
Le nom d'hôte (host name en anglais), qui identifie une machine sur Internet ou sur un réseau local. Les noms d'hôtes permettent de représenter des adresses IP de façon plus claire (on a un nom comme google.fr , plus facile à retenir que l'adresse IP correspondante
74.125.224.84 ).
Un numéro de port, qui est souvent propre au type d'information que l'on va échanger. Si on demande une connexion web, le navigateur va en général interroger le port 80 si c'est en http ou le port 443 si c'est en connexion sécurisée ( https ). Le numéro de port est compris entre 0 et 65535 (il y en a donc un certain nombre !) et les numéros entre 0 et 1023 sont réservés par le système. On peut les utiliser, mais ce n'est pas une très bonne idée.
Pour résumer, quand votre navigateur tente d'accéder à OpenClassrooms, il établit une connexion avec le serveur dont le nom d'hôte est
fr.openclassrooms.com sur le port
80 . Dans ce chapitre, nous allons plus volontiers travailler avec des noms d'hôtes qu'avec des adresses IP.
Les sockets
Comme on va le voir, les sockets sont des objets qui permettent d'ouvrir une connexion avec une machine locale ou distante et d'échanger avec elle.
Ces objets sont définis dans le module
socket et nous allons maintenant voir comment ils fonctionnent.
Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !
Commençons donc, dans la joie et la bonne humeur, par importer notre module
socket .
Nous allons d'abord créer notre serveur puis, en parallèle, un client. Nous allons faire communiquer les deux. Pour l'instant, nous nous occupons du serveur.
Construire notre socket
Nous allons pour cela faire appel au constructeur socket . Dans le cas d'une connexion TCP, il prend les deux paramètres suivants, dans l'ordre :
socket.AF_INET : la famille d'adresses, ici ce sont des adresses Internet ;
socket.SOCK_STREAM : le type du socket, SOCK_STREAM pour le protocole TCP.
Connecter le socket
Ensuite, nous connectons notre socket. Pour une connexion serveur, qui va attendre des connexions de clients, on utilise la méthode bind . Elle prend un paramètre : le tuple
(nom_hote, port) .
Oui mais, pour que notre serveur écoute sur un port, il faut le configurer en conséquence. Donc, dans notre cas, le nom de l'hôte sera vide et le port sera celui que vous voulez, entre 1024 et 65535.
Faire écouter notre socket
Bien. Notre socket est prêt à écouter sur le port 12800 mais il n'écoute pas encore. On va avant tout lui préciser le nombre maximum de connexions qu'il peut recevoir sur ce port sans les accepter. On utilise pour cela la méthode
listen . On lui passe généralement 5 en paramètre.
Non. Cela veut dire que si 5 clients se connectent et que le serveur n'accepte aucune de ces connexions, aucun autre client ne pourra se connecter. Mais généralement, très peu de temps après que le client ait demandé la connexion, le serveur l'accepte. Vous pouvez donc avoir bien plus de clients connectés, ne vous en faites pas.
Accepter une connexion venant du client
Enfin, dernière étape, on va accepter une connexion. Aucune connexion ne s'est encore présentée mais la méthode
accept que nous allons utiliser va bloquer le programme tant qu'aucun client ne s'est connecté.
Il est important de noter que la méthode
accept renvoie deux informations :
le socket connecté qui vient de se créer, celui qui va nous permettre de dialoguer avec notre client tout juste connecté ;
un tuple représentant l'adresse IP et le port de connexion du client.
Non car votre client, en ouvrant une connexion, passe par un port dit « de sortie » qui va être choisi par le système parmi les ports disponibles. Pour schématiser, quand un client se connecte à un serveur, il emprunte un port (une forme de porte, si vous voulez) puis établit la connexion sur le port du serveur. Il y a donc deux ports dans notre histoire mais celui qu'utilise le client pour ouvrir sa connexion ne va pas nous intéresser.
Cette méthode, comme vous le voyez, bloque le programme. Elle attend qu'un client se connecte. Laissons cette fenêtre Python ouverte et, à présent, ouvrons-en une nouvelle pour construire notre client.
Création du client
Commencez par construire votre socket de la même façon :
Connecter le client
Pour se connecter à un serveur, on va utiliser la méthode connect . Elle prend en paramètre un tuple, comme bind , contenant le nom d'hôte et le numéro du port identifiant le serveur auquel on veut se connecter.
Le numéro du port sur lequel on veut se connecter, vous le connaissez : c'est
12800 . Vu que nos deux applications Python sont sur la même machine, le nom d'hôte va être localhost (c'est-à-dire la machine locale).
Et voilà, notre serveur et notre client sont connectés !
Si vous retournez dans la console Python abritant le serveur, vous pouvez constater que la méthode accept ne bloque plus, puisqu'elle vient d'accepter la connexion demandée par le client. Vous pouvez donc de nouveau saisir du code côté serveur :
La première information, c'est l'adresse IP du client. Ici, elle vaut 127.0.0.1 c'est-à-dire l'IP de l'ordinateur local. Dites-vous que l'hôte localhost redirige vers l'IP 127.0.0.1 .
Le second est le port de sortie du client, qui ne nous intéresse pas ici.
Faire communiquer nos sockets
Bon, maintenant, comment faire communiquer nos sockets ? Eh bien, en utilisant les méthodes send pour envoyer et recv pour recevoir.
Donc côté serveur :
La méthode send vous renvoie le nombre de caractères envoyés.
Maintenant, côté client, on va réceptionner le message que l'on vient d'envoyer. La méthode recv prend en paramètre le nombre de caractères à lire. Généralement, on lui passe la valeur
1024 . Si le message est plus grand que 1024 caractères, on récupérera le reste après.
Dans la fenêtre Python côté client, donc :
Magique, non ? Vraiment pas ? Songez que ce petit mécanisme peut servir à faire communiquer des applications entre elles non seulement sur la machine locale, mais aussi sur des machines distantes et reliées par Internet.
Le client peut également envoyer des informations au serveur et le serveur peut les réceptionner, tout cela grâce aux méthodes send et recv que nous venons de voir.
Fermer la connexion
Pour fermer la connexion, il faut appeler la méthode close de notre socket.
Côté serveur :
Et côté client :
Voilà ! Je vais récapituler en vous présentant dans l'ordre un petit serveur et un client que nous pouvons utiliser. Et pour finir, je vous montrerai une façon d'optimiser un peu notre serveur en lui permettant de gérer plusieurs clients à la fois.
Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !
Brève présentation du réseau
Les sockets
Commentaires