TP Introduction aux Réseaux Analyse pratique de l'architecture du réseau du DGEI

Transcription

1 BOUVOT Simon LOPEZ Rémi 3IMACS D TP Introduction aux Réseaux Analyse pratique de l'architecture du réseau du DGEI 13 Janvier 2012 Professeur : Mr Diop

2 Partie 1 : Utilisation du programme tsock Question 1 : En utilisant le protocole UDP : Afin de faire communiquer les 2 terminaux, on émule une autre machine sur le terminal puits (geitp111 09) et on envoie des paquets depuis la source (geitp111 08). Sur la machine puits :./tsock p u 9000 Sur la machine source :./tsock s u n 1000 geitp On envoie sur le puits 1000 paquets. SOURCE: Envoi n 997 ( 30) [ 997vvvvvvvvvvvvvvvvvvvvvvvvv] SOURCE: Envoi n 998 ( 30) [ 998wwwwwwwwwwwwwwwwwwwwwwwww] SOURCE: Envoi n 999 ( 30) [ 999xxxxxxxxxxxxxxxxxxxxxxxxx] SOURCE: Envoi n 1000 ( 30) [ 1000yyyyyyyyyyyyyyyyyyyyyyyyy] PUITS: Reception n 997 ( 30) [ 997vvvvvvvvvvvvvvvvvvvvvvvvv] PUITS: Reception n 998 ( 30) [ 998wwwwwwwwwwwwwwwwwwwwwwwww] PUITS: Reception n 999 ( 30) [ 999xxxxxxxxxxxxxxxxxxxxxxxxx] PUITS: Reception n 1000 ( 30) [ 1000yyyyyyyyyyyyyyyyyyyyyyyyy] Constatation : On n'observe pas de déséquencement car les 2 machines sont reliées directement. Les données à échanger suivent toutes le même chemin. Aucune perte n'est remarquée. Cependant, pour des machines non directement reliées, le service UDP ne garantie ni l'ordre, ni la fiabilité. En UDP, on pourrait perdre des paquets si par exemple apparaît : Une erreur de bit (ce qui pourrait arriver dans notre cas, cependant, c'est très peu fréquent) Une surcharge des routeurs (ou noeuds intermédiaires) se produit MAIS ici, pas de routeur Une surcharge au niveau du récepteur (mais que si on a un nombre de paquet important En utilisant le protocole TCP : On enlève dans cette partie u car le protocole utilisé par défaut est TCP. On envoie toujours 1000 paquets. Sur la machine puits :

3 ./tsock u 9000 Sur la machine source :./tsock s n 1000 geitp SOURCE: Envoi n 997 ( 30) [ 997vvvvvvvvvvvvvvvvvvvvvvvvv] SOURCE: Envoi n 998 ( 30) [ 998wwwwwwwwwwwwwwwwwwwwwwwww] SOURCE: Envoi n 999 ( 30) [ 999xxxxxxxxxxxxxxxxxxxxxxxxx] SOURCE: Envoi n 1000 ( 30) [ 1000yyyyyyyyyyyyyyyyyyyyyyyyy] PUITS: Reception n 997 ( 30) [ 997vvvvvvvvvvvvvvvvvvvvvvvvv] PUITS: Reception n 998 ( 30) [ 998wwwwwwwwwwwwwwwwwwwwwwwww] PUITS: Reception n 999 ( 30) [ 999xxxxxxxxxxxxxxxxxxxxxxxxx] PUITS: Reception n 1000 ( 30) [ 1000yyyyyyyyyyyyyyyyyyyyyyyyy] On n'observe pas de pertes de paquet ni de déséquencement. En effet, TCP garantie Ordre et Fiabilité des données envoyées (TCP est un service avec connexion ; cependant, ce n'est pas l'argument principal ici). Expérimentation : On va tout d'abord se placer en UDP et augmenter le nombre de paquets envoyés (10000 au lieu de 1000). SOURCE: Envoi n 9995 ( 30) [ 9995ttttttttttttttttttttttttt] SOURCE: Envoi n 9996 ( 30) [ 9996uuuuuuuuuuuuuuuuuuuuuuuuu] SOURCE: Envoi n 9997 ( 30) [ 9997vvvvvvvvvvvvvvvvvvvvvvvvv] SOURCE: Envoi n 9998 ( 30) [ 9998wwwwwwwwwwwwwwwwwwwwwwwww] SOURCE: Envoi n 9999 ( 30) [ 9999xxxxxxxxxxxxxxxxxxxxxxxxx] SOURCE: Envoi n ( 30) [10000yyyyyyyyyyyyyyyyyyyyyyyyy] PUITS: Reception n 8974 ( 30) [ 9996uuuuuuuuuuuuuuuuuuuuuuuuu] PUITS: Reception n 8975 ( 30) [ 9997vvvvvvvvvvvvvvvvvvvvvvvvv] PUITS: Reception n 8976 ( 30) [ 9998wwwwwwwwwwwwwwwwwwwwwwwww] PUITS: Reception n 8977 ( 30) [ 9999xxxxxxxxxxxxxxxxxxxxxxxxx] PUITS: Reception n 8978 ( 30) [10000yyyyyyyyyyyyyyyyyyyyyyyyy] On remarque qu'il y a : = 1022pertes. Maintenant, on modifie la taille du buffer (pour la réception) : 500 (toujours en UDP)/./tsock s u n geitp

4 On observe un certain nombre de pertes dues à la saturation du buffer de réception. Dans l'exemple ci dessous : SOURCE: Envoi n 9998 ( 30) [ 9998wwwwwwwwwwwwwwwwwwwwwwwww] SOURCE: Envoi n 9999 ( 30) [ 9999xxxxxxxxxxxxxxxxxxxxxxxxx] SOURCE: Envoi n ( 30) [10000yyyyyyyyyyyyyyyyyyyyyyyyy] PUITS: Reception n 1342 ( 30) [ 9972vvvvvvvvvvvvvvvvvvvvvvvvv] PUITS: Reception n 1343 ( 30) [ 9973wwwwwwwwwwwwwwwwwwwwwwwww] PUITS: Reception n 1344 ( 30) [ 9974xxxxxxxxxxxxxxxxxxxxxxxxx] PUITS: Reception n 1345 ( 30) [ 9999xxxxxxxxxxxxxxxxxxxxxxxxx] PUITS: Reception n 1346 ( 30) [10000yyyyyyyyyyyyyyyyyyyyyyyyy] Il y a beaucoup de pertes comme prévoyait la théorie. Au niveau du récepteur, on peut avoir des pertes à cause de trop nombreuses fragmentations (couche IP) du message envoyé. Question 2 : On utilise le protocole TCP. On lance tsock source avant le tsock puits. SOURCE: connect: Connection refused TCP est un service avec connexion, donc si le récepteur n'est pas opérationnel, il n'envoie pas le message. On utilise le protocole UDP. On lance tsock source avant le tsock puits. SOURCE: Envoi n 9998 ( 30) [ 9998wwwwwwwwwwwwwwwwwwwwwwwww] SOURCE: Envoi n 9999 ( 30) [ 9999xxxxxxxxxxxxxxxxxxxxxxxxx] SOURCE: Envoi n ( 30) [10000yyyyyyyyyyyyyyyyyyyyyyyyy] PUITS: Reception n 5564 ( 30) [ 9998wwwwwwwwwwwwwwwwwwwwwwwww] PUITS: Reception n 5565 ( 30) [ 9999xxxxxxxxxxxxxxxxxxxxxxxxx] PUITS: Reception n 5566 ( 30) [10000yyyyyyyyyyyyyyyyyyyyyyyyy] Les paquets sont envoyés sans préoccupation de l'état du récepteur. Le puits reçoit qu'à partir du moment où il est apte à recevoir par la commande :./tsock p u 9000, ce qui fait qu'il ne reçoit pas les premiers paquets envoyés. Les messages perdus sont supprimés au niveau de la couche transport du puits. Le comportement est acceptable car c'est un service sans garantie de QoS.

5 Partie 2 : Utilisation du programme tcpdump Question 3 : On se connecte à la machine 1 avec l'utilisateur tcpdump : ssh tcpdump@geitp Puits :./tsock p 9000 PUITS: lg_buf_appli=30, port=9000, nb_buf_appli=infini, TP= tcp PUITS: socket PUITS: connexion accepte avec Source :./tsock s geitp SOURCE: lg_buf_appli=30, port=9000, nb_buf_appli=10, TP= tcp > geitp SOURCE: socket SOURCE: connect sudo tcpdump port 9000 tcpdump: verbose output suppressed, use v or vv for full protocol decode listening on eth0, link type EN10MB (Ethernet), capture size 96 bytes Le terminal tcpdump est opérationnel : listening on eth0 Lorsqu'on utilise le protocole UDP on observe seulement les trames envoyés : 15:59: IP geitp insa toulouse.fr > geitp insa toulouse.fr.9000: UDP, length 30 15:59: IP geitp insa toulouse.fr > geitp insa toulouse.fr.9000: UDP, length 30 Il n'y a pas de requête qui est faite par la source pour savoir si le puits est bien connecté, le protocole UDP est donc bien un protocole sans connexion. Alors que lorsqu'on utilise le protocole TCP on observe un établissement de connexion avant l'envoi des trames : 16:01: IP geitp insa toulouse.fr > geitp insa toulouse.fr.9000: Flags [.], ack 2, win 92, options [nop,nop,ts val ecr ], length 0 16:01: IP geitp insa toulouse.fr > geitp insa toulouse.fr.9000: Flags [.], ack 2, win 92, options [nop,nop,ts val ecr ], length 0 La source et le puits communiquent, ils s'envoient des requêtes pour demander la connexion et pour donner l'accord pour cette demande. Le protocole TCP est donc un protocole avec connexion.

6 Les différentes phases que l'on observe quand on utilise le protocole TCP sont : CONNEXION Flags [S] : demande de connexion de la source Flags [S.] : accord du puits et demande de connexion du puits Flags [.] : accord de la source TRANSFERT Flags [P.] : envoi des paquets Flags [FP.] : envoi du dernier paquet et demande de fermeture de connexion de la source Flags [.] : acquittement des paquets par le puits FERMETURE CONNEXION Flags [F.] : accord du puits sur la fermeture de connexion et demande de fermeture de connexion Flags [.] ; accord de la source sur la demande de fermeture de connexion En réduisant la taille du buffer de réception on met en évidence le fait que le protocole TCP ne préserve pas la frontière des messages tels qu'ils ont été soumis en émission : SOURCE: Envoi n 970 ( 30) [ 970ttttttttttttttttttttttttt] SOURCE: Envoi n 971 ( 30) [ 971uuuuuuuuuuuuuuuuuuuuuuuuu] SOURCE: Envoi n 972 ( 30) [ 972vvvvvvvvvvvvvvvvvvvvvvvvv] PUITS: Reception n 970 ( 30) [cccccccccccccccccc 954ddddddd] PUITS: Reception n 971 ( 30) [dddddddddddddddddd 955eeeeeee] PUITS: Reception n 972 ( 30) [eeeeeeeeeeeeeeeeee 956fffffff] Question 4 : On utilise la commande : sudo tcpdump xx port :28: IP geitp insa toulouse.fr > geitp insa toulouse.fr.9000: Flags [.], ack 2, win 92, options [nop,nop,ts val ecr ], length 0 0x0000: 001a d2 001a 926e e x0010: ca5 0a01 050c 0a01 0x0020: a77 8b31 7c31 248b x0030: 005c c9bd a 001f f8f x0040: 3b61 Traitement de la trame Comme indiqué dans l'annexe, on détermine ethernet de la machine puit (destinataire) : ethernet de la machine source : 00:1a:92:6e:e4:82

7 Le protocole est : 06, c'est bien IP de la source : 0a01 050c en héxadécimal, en décimal : IP destination : 0a en héxadécimal, en décimal On vérifie l'exactitude de IP grâce à la commande ifconfig. Le numéro de port utilisé par le puits : 2328 (en héxa) = 9000 en décimal le port utilisé (9000) a été spécifié dès le début du TP. Le numéro de port utilisé par la source : 9062 le port source est choisi aléatoirement Question 5 : Le transfert en mode broadcast envoie l'information à un ensemble de machine. Son contraire est la diffusion unicast. On entre dans le terminal (tcpdump) : tcpdump@geitp102 01:~$ sudo tcpdump xx broadcast 16:48: IP gme1 034.insa toulouse.fr.1025 > : UDP, length 40 0x0000: ffff ffff ffff x0010: 0044 b6eb b 0a ffff 0x0020: ffff b d b7a 535a 0x0030: 514b e c54 417a 4e41 0x0040: a x0050: 5541 On détermine l'adresse broadcast du réseau physique : Conclusion A travers ce TP nous avons pu cerner les différences entres les protocoles de la couche réseau UDP et TCP dans des applications de transfert de paquet. On a pu confirmer les apprentissages du cours : UDP est un protocole sans connexion, c'est à dire qu'il n'a pas besoin d'être «connecté» à la destination pour pouvoir envoyer. On a remarqué qu'il n'avait aucune exigence de Qos. Contrairement à ce dernier, le protocole TCP se décline en 3 phases : Connexion, Transfert et Fermeture de la connexion ; ce qui lui confère des qualités de service (fiabilité, pas de déséquencement).