Protocoles UDP/TCP

TP Réseau - Protocoles UDP/TCP

I - Protocole UDP

UDP (User Datagram Protocol) est l’un des principaux protocoles de transmission de données sur Internet. Il fait partie de la quatrième couche (transport) du modèle OSI (Open System Interconnection). Il permet une transmission rapide et non contrôlée, ne nécessitant d’aucune connexion entre les 2. Il est donc appliqué pour des utilisations qui ne nécessitent pas une restitution totale des données (exemple : jeu vidéo en ligne, VoIP).

Durant cette séance, nous avons réalisé des transferts de données (grâce à de la programmation réseau) entre 2 cartes mères (Raspberry Pi Modèle 3B+) toutes deux connectées sur le même réseau (192.168.5.0). L’une sera l’hôte du serveur en python (192.168.5.1), et la seconde sera la machine client (192.168.5.11). Nous utiliserons Wireshark pour surveiller et capturer les échanges entre ces 2 machines afin de mieux comprendre ce mode de communication et se pencher sur le contenu des paquets.

Pour commencer le TP, on édite le fichier UDP/serveur.py (sur notre carte serveur) afin de préciser le couple IP/Port dans le but de lancer un handler udp dessus. Ce dernier nous permettra d’écouter toute connexion sur le serveur. On utilisera ici son adresse IP (192.168.5.1) et le port 9999. Puis on transfert le fichier UDP/client.py sur la carte client (scp) et on le modifie afin de pouvoir se connecter à la carte serveur sur le port que l’on vient d’ouvrir.

On exécute alors les fichiers serveur.py et client.py sur leurs cartes respectives, en mettant en paramètre sur le client le message que l’on souhaite envoyer. (Les résultats de Wireshark sont pour une taille de réception de 4000 octets (sock.recv(4000) et non 4 comme indiqué sur la photo).

[pic 1]

        On voit les messages envoyés par le client sur le terminal du serveur, et on reçoit une réponse du serveur indiquant le message reçu (réponse en majuscules). Nos 2 programmes fonctionnent bien à première vue. Cet échange de données a été capturé par Wireshark que nous avons lancé au préalable. On va alors voir ce que cette transmission a généré comme paquets sur le réseau.

[pic 2]

On a alors pour chaque échange de données réussi, l’apparition de 2 paquets UDP: le premier du client au serveur, et le second du serveur au client. (Les paquets DNS et ICMP sont dus à des tentatives de mise à jour de la carte client alors qu’elle n’est pas connectée à internet). On retrouve dans les entêtes de chaque paquet les adresses IP/Ports sources et destinations et, dans le corps du paquet, le message envoyé. Cette transmission est un exemple de transmission réussie, avec une machine connectée et possédant l’adresse IP de destination (et le port utilisé ouvert pour cet effet).

Nous allons ensuite voir trois autres cas:

• Envoi de données volumineuses,
• Capacité de réception inférieure à la taille des données reçues,
• Envoi de données avec serveur non lancé,

        Pour le 1er cas, on crée une boucle dans le fichier client qui incrémente les données à envoyer de 200 caractères à chaque itération. On lance ce dernier (avec le serveur lancé) et on observe le trafic réseau sur Wireshark.

[pic 3]

A partir du 8e envoi, on observe l’apparition de nouveaux paquets sous le protocole IPv4. En laissant le programme tourner un peu plus longtemps, on remarque que la taille maximale des paquets envoyés et reçus est d’environ 1500 octets. On peut lier ça au fait que le MTU (Maximum Transmission Unit) soit cappé sur les 2 cartes. En effet, on peut observer en lançant un ifconfig eth0 sur les 2 cartes que le MTU est fixé à 1500. Les données sont donc fragmentées, étiquetées et enfin envoyées. On voit bien dans les entêtes des paquets UDP l’ordre de lecture des données (voir photo ci-dessus, 2 fragments: l’un avec le numéro de séquence 170 et chargé de 1480 octets de données, et le second qui est le principal de séquence 171 et transportant 330 octets de données).

2e cas, on sait que l’on peut choisir le nombre d’octets de données que l’on souhaite utiliser en passant le passant en paramètre lorsque l’on souhaite lire les données reçues (Socket1.recv([taille en octets]). Nous avons choisi de limiter la réception de données à 4 octets. On remarque sur Wireshark que le client envoie bien le message qu’on lui indique, et renvoie celui-ci au client, qui ne lit que 4 octets. Et malgré le fait que le serveur refuse le reste des données liées à cet échange (après avoir reçu les 4 octets), le serveur continue quand même à envoyer des données sans être au courant que son interlocuteur ne reçoit pas la suite.

(Exemple: Client(“Test123”) => Serveur  / Serveur affiche “TEST123”

      Serveur(“TEST123”) => Client / Client affiche “TEST”)

        3e et dernier cas, on envoie un message au serveur (éteint) à partir de la carte client.On voit bien l’envoi d’un paquet à partir de la carte client sur Wireshark. On observe sur le terminal du client que rien ne s’affiche et que le fichier reste en cours d’exécution. En regardant mieux le code, on sait que les lignes contenant la fonction print viennent à la toute fin, donc on a une ligne qui n’est pas exécutée. On sait que le socket sur le client attend une réponse (sock.recv(X)), réponse qu’il ne recevra pas car le serveur n’est pas exécuté.

II - Protocole TCP

[pic 4]

        TCP (Transmission Control Protocol) est l’un des principaux protocoles de transmissions de données sur Internet. Il fait partie de la quatrième couche (transport) du modèle OSI (Open System Interconnection). C’est un protocole fiable et qui nécessite une connexion “vivante” (alive) entre les 2 machines communicantes. Pour cela il faut plusieurs requêtes afin de voir si la connexion est toujours vivante.

        Durant ce TP, nous avons utilisé comme ressources 2 programmes modèles en python – l’un pour le serveur et l’autre pour le client – et des « patterns » pour différentes situations de connexion en TCP.

...