BOUVOT Simon CALVIGNAC Raphaël TP Introduction aux Réseaux Analyse pratique de l'architecture du réseau du DGEI 29 Mars 2011 Professeur : Slim Abdellatif 1/9
Première partie : Utilisation du programme tsock Question 1 : PARTIE EN TCP Lorsqu'on envoie cette ligne de commande : Réception (à gauche) : bouvot@geitp102 15:~$ /gei/tsock/tsock linux p 15001 On se met en mode «réception» Envoi (à droite) : bouvot@geitp102 16:/gei/tsock$ /gei/tsock/tsock linux s n1000 geitp102 15 15001 On envoie avec la même configuration en précisant, en plus, le nombre de paquet ( n1000 : 1000 paquets) 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). 2/9
PARTIE EN UDP Lorsqu'on envoie cette ligne de commande : Réception : bouvot@geitp102 15:~$ /gei/tsock/tsock linux p u 15001 On se met en mode «réception», à noter qu'on précise «u» pour UDP On a : PUITS: lg_buf_appli=30, port=15001, nb_buf_appli=infini, TP= udp PUITS: socket Ce qui veut dire que le récepteur est apte à recevoir. Envoi : bouvot@geitp102 16:/gei/tsock$ /gei/tsock/tsock linux s u n1000 geitp102 15 15001 Nombre de paquet : 1000 ( n1000 : 1000 paquets) 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 Une surcharge au niveau du récepteur Exemple : On change la taille du buffer (réception) : (500) bouvot@geitp102 15:~$ /gei/tsock/tsock linux p u t500 15001 PUITS: lg_buf_appli=30, port=15001, nb_buf_appli=infini, lg_buf_tp=500, TP= udp PUITS: socket PUITS: setsockopt: rcvbuf OK PUITS: rcvbuf Lorsqu'on réduit la taille du buffer, on observe un certain nombre de pertes dues à la saturation du buffer de réception. Dans l'exemple ci dessus, il y a une perte de 120 paquets sur les 10000 envoyés. 3/9
Au niveau du récepteur, on peut avoir des pertes à cause de trop nombreuses fragmentations (couche IP) du message envoyé. Exemple : En rajoutant l'option l25000 à la ligne de commande source, on observe de nombreuses pertes. Question 2 : TCP est un service avec connexion, donc si le récepteur n'est pas opérationnel, il n'envoie pas le message. Alors qu'en UDP (sans connexion), on envoie sans connaître l'état du récepteur. Les données sont envoyées dans tous les cas. Lorsque le récepteur est activé, celui ci commence la réception au niveau où en est l'envoie de données. On voit bien que le message est reçu lorsque l'on active le récepteur : ici on commence à recevoir à partir du paquet 2419. 4/9
Deuxième partie : Utilisation du programme tcpdump Question 3 : On va se connecter sur la machine 01 de la salle avec l utilisateur tcpdump. ssh tcpdump@geitp102 01 On lance : sudo tcpdump 15001 (15001 correspond au numéro de port utilisé) Ce qui nous donne : //tcpdump@geitp102 01:~$ sudo tcpdump port 15001 tcpdump: verbose output suppressed, use v or vv for full protocol decode listening on eth0, link type EN10MB (Ethernet), capture size 96 bytes Le récepteur est prêt (listening on eth0) PARTIE EN UDP Au niveau de la source, on envoie la ligne de commande suivante : bouvot@geitp102 16:/gei/tsock$ /gei/tsock/tsock linux s u n25 geitp102 15 15001 Après quoi on observe, sur le poste 1: 5/9
On observe que les données sont envoyées sans avoir activé le récepteur. Ce qui nous convint sur le fait qu'udp est véritablement un service sans connexion. UDP est : Un service sans connexion (au niveau de la couche APPLICATION) : les applications doivent accepter pour se mettre d'accord à communiquer Un protocole sans connexion ( au niveau de la couche TRANSPORT) : les entités protocolaires doivent se synchroniser avant de communiquer PARTIE EN TCP On envoie sans activer le récepteur. Voilà ce qu'on observe sur le réseau (par l'intermédiaire de «l'analyseur de réseau»). 17:36:03.644357 IP geitp102 16.insa toulouse.fr.34691 > geitp102 15.insa toulouse.fr.15001: Flags [S], seq 3762871048, win 5840, options [mss 1460,sackOK,TS val 1777012 ecr 0,nop,wscale 6], length 0 17:36:03.644482 IP geitp102 15.insa toulouse.fr.15001 > geitp102 16.insa toulouse.fr.34691: Flags [R.], seq 0, ack 3762871049, win 0, length 0 Cela nous confirme que le protocole TCP est avec connexion. Lorsqu'on active le récepteur, les paquets sont envoyés, on observe sur le poste 1 : 6/9
Explication du code : L'émetteur informe le récepteur (geitp102 16 vers geitp102 15) qu'il lui envoie des données et précise la valeur à laquelle il commence. 17:40:39.196182 IP geitp102 16.insa toulouse.fr.41888 > geitp102 15.insa toulouse.fr.15001: Flags [S], seq 3795259457, win 5840, options [mss 1460,sackOK,TS val 1845901 ecr0,nop,wscale 6], length 0 C'est un SYN : Il y a une demande de synchronisation. Le récepteur lui répond que «oui, c'est possible» et qu'il peut également lui en envoyer (il précise la valeur à laquelle il commence). 17:40:39.196307 IP geitp102 15.insa toulouse.fr.15001 > geitp102 16.insa toulouse.fr.41888: Flags [S.], seq 4091034238, ack 3795259458, win 5792, options [mss 1460,sackOK,TS val 3160763 ecr 1845901,nop,wscale 6], length 0 C'est un SYNACK : Il y a accord de cette synchronisation et en demande une dans le sens inverse. L'émetteur renvoie un accord de synchronisation. 17:40:39.196429 IP geitp102 16.insa toulouse.fr.41888 > geitp102 15.insa toulouse.fr.15001: Flags [.], ack 1, win 92, options [nop,nop,ts val 1845901 ecr 3160763], length 0 C'est un ACK. Les 3 points ci dessus constituent la phase d'établissement de la connexion entre les 2 postes. On observe ensuite le message transmis Dernièrement, on voit un ACK correspondant à la fin du transfert de données. Conclusion : Les protocoles TCP et UDP sont bidirectionnels. Les échanges peuvent se faire dans les 2 sens. On peut aussi noter que le protocole TCP ne préserve pas les délimitations du message côté récepteur. Il voit l'information comme une suite de bit et ne s'intéresse pas aux limites du message en elles mêmes. Contrairement, le protocole UDP préserve bien entendu les délimitations. 7/9
Question 4 : On tape dans le terminal : sudo tcpdump xx port «port» où «port» désigne le n de port utilisé par le puit On relève sur le code ci dessus : L'adresse MAC du destinataire Ce sont les 6 premiers octets : 00.1A.92.03.F8.FB L'adresse MAC de la source Les 6 octets suivants : 00.1A.92.06.87.BE Le type Les 2 octets suivant : 08.00 Le paquet IP Le 13ème octet représente le début de l'adresse IP source, on peut alors déterminer l'adresse IP de la source : 0A.01.05.80. On la traduit en décimal pour qu'elle soit sous forme conventionnelle : 10.1.5.128. L'adresse IP du destinataire est lue à la suite, ce qui nous donne sous forme conventionnelle : 10.1.5.75. Le champ protocole C'est le 10ème octet du paquet IP : 06. Le type utilisé est TCP, ce qui est confirmé par le nombre 6. Si on avait été en protocole UDP, cet octet aurait valu 17 (en décimal). Le numéro de port utilisé par la source et par le puit Le port utilisé par la source est inscrit à la suite de l'adresse IP (sur 2 octets) : d2d3 ce qui correspond en décimal à 53971 8/9
Le port utilisé par le puit est : 3a99 ce qui donne 15001 (en décimal), ce qu'on avait choisi lors de la demande de dialogue. 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 On détermine l'adresse broadcast du réseau physique : 255.255.255.255. (FF.FF.FF.FF). 9/9