1 Questions préliminaires :
2 Petits exercices :
3 Etude de cas : bâtiment C. Chappe
On considère l’aménagement du futur bâtiment « Télécommunication Services et Usages ». On occupe les 4 étages du bâtiment. Tous les ordinateurs sont reliés par Ethernet 10Mbits/s (principalement pour l’échange de données).
En période de pointe, chaque station gère 10 trames par seconde à transmettre.
S G a=0,015 a=0,020 a=0,025 a=0,030 a=0,035 a=0,040 0,100 0,099 0,099 0,099 0,099 0,099 0,099 0,126 0,124 0,124 0,124 0,124 0,123 0,123 0,158 0,154 0,154 0,154 0,154 0,154 0,154 0,200 0,192 0,192 0,191 0,191 0,191 0,191 0,251 0,237 0,237 0,236 0,236 0,236 0,235 0,316 0,290 0,289 0,289 0,288 0,288 0,288 0,398 0,350 0,349 0,348 0,347 0,346 0,346 0,501 0,415 0,414 0,412 0,411 0,410 0,409 0,631 0,482 0,480 0,478 0,477 0,475 0,473 0,794 0,546 0,544 0,541 0,539 0,537 0,534 1,00 0,603 0,600 0,597 0,594 0,591 0,588 1,26 0,650 0,647 0,643 0,639 0,635 0,631 1,59 0,687 0,683 0,678 0,673 0,668 0,663 2,00 0,716 0,711 0,705 0,699 0,693 0,687 2,51 0,741 0,734 0,727 0,720 0,713 0,705 3,16 0,763 0,756 0,747 0,739 0,730 0,721 3,98 0,787 0,777 0,768 0,758 0,747 0,736 5,01 0,810 0,799 0,787 0,775 0,762 0,749 6,31 0,832 0,819 0,805 0,790 0,774 0,758 7,94 0,851 0,836 0,819 0,801 0,781 0,760 10,0 0,866 0,848 0,827 0,804 0,779 0,752 12,6 0,876 0,854 0,828 0,799 0,766 0,730 15,8 0,882 0,854 0,821 0,782 0,737 0,688 20,0 0,882 0,845 0,800 0,747 0,684 0,615 25,1 0,874 0,825 0,761 0,684 0,595 0,500 31,6 0,857 0,786 0,692 0,580 0,459 0,343 39,8 0,824 0,716 0,576 0,424 0,285 0,178 50,1 0,762 0,596 0,405 0,240 0,128 0,064 63,1 0,652 0,415 0,212 0,093 0,038 0,015 79,4 0,474 0,210 0,074 0,023 0,007 0,002 100 0,254 0,069 0,016 0,004 0,001 0,000
Tableau A.1: Table donnant le débit utile normalisé S en fonction de G (charge offerte normalisée) pour différentes valeur de a.
Figure A.1: Sous sol
Figure A.2: Rez de chaussé
Figure A.3: Premier étage
Figure A.4: Deuxième étage
1 Désassemblage de trames IP/Ethernet
Un analyseur de réseau est connecté sur un LAN Ethernet et permet d’extraire le contenu des trames circulant sur celui-ci (le préambule, le SFD ainsi que le CRC et les octets de bourrage sont supprimés). Une capture du réseau donne les résultats suivants:
FF FF FF FF FF FF 08 00 20 02 45 9E 08 06 00 01 08 00 06 04 00 01 08 00 20 02 45 9E 81 68 FE 06 00 00 00 00 00 00 81 68 FE 05 08 00 20 02 45 9E 08 00 20 07 0B 94 08 06 00 01 08 00 06 04 00 02 08 00 20 07 0B 94 81 68 FE 05 08 00 20 02 45 9E 81 68 FE 06
2 IP: Encapsulation, ARP
On considère le réseau suivant composé de deux sous-réseaux Ethernet (1 et 2) raccordés par un routeur IP.
3 Fragmentation d’un datagramme IP
Un datagramme IP contenant 2000 octets de données est émis sur un réseau A de MTU=4096. En passant par un routeur R1, il atteint le réseau B de MTU=1024 octets. La structure du datagramme dans le réseau A est présentée ci-dessous :
4 Adresses Internet et subnetting
1 Commutation
L’équipement de la figure ?? est un commutateur dont les tables sont initialement vide.
2 Routage et Adressage
Une société dispose du réseau suivant sur son site. Son fournisseur d’accès Internet (FAI) lui fournit le préfixe 192.108.116.0/22.
L’ingénieur système décide de numéroter les équipements dans l’ordre croissant en commençant par la première adresse IP disponible sur le sous réseau et les interfaces des routeurs dans l’ordre décroissant en partant de la dernière adresse IP disponible sur le sous réseau.
Soit les stations SA, SB et SD situées respectivement sur les réseaux a, b et d.
Ce TD machine a pour but de vous familiariser avec les outils et les configurations du réseaux sur les machines du département.
1 Outils TCP/IP sous Linux
La syntaxe des commandes les plus utilisées pour l’administration de machines TCP/IP sous Linux sont indiquées ci-dessous. Un grand nombre de ces commandes est implanté dans d’autres OS comme Windows ou MacOS. Attention toutefois, les options ne sont pas forcément les mêmes ainsi que la présentation des résultats ! Bien entendu cette courte présentation ne saurait remplacer les pages du manuel (man) !
La plupart des outils nécessitent d’être administrateur des machines pour faire des modifications. Vous pouvez tout de même les utiliser pour consulter les configurations en tant qu’utilisateurs.
1.1 Outils en ligne de commande
Paramètrage des interfaces IP et affichage des différents paramètres nécessaires à une carte réseau : spécification de l’adresse IP, du masque, etc.
ifconfig eth0 @IP netmask masque [broadcast @broadcast]
Lorsqu’une interface est reconfigurée, n’oubliez pas de reconfigurer les routes qui empruntent cette interface !
ifconfig -a : affiche toutes les interfaces connues (même down).
Manipulation de la table de correspondance entre adresse physique (MAC) et adresse IP. Cette table est mise-à-jour par le protocole ARP. Listage de la table (sans résolution inverse des adresses IP) :
arp -na
Manipulation de la table de routage des datagrammes IP.
route
route add default gw @passerelle
route add -net réseau-distant netmask masque gw @passerelle
route del -net réseau-distant netmask masque gw @passerelle
Permet le listage de la table de routage des datagrammes IP et l’état du réseau.
Quelques options:
Effectue la conversion entre un nom de machine et une adresse IP. host peut également effectuer des recherches simples comme trouver les adresses des DNS ou bien encore les enregistrements MX (serveurs de mail) des domaines.
dig est un outils d’interrogation de DNS plus complet que host. Sa syntaxe est assez facile et est décrite dans les pages du manuel.
Envoi des paquets ICMP ECHO_REQUEST vers un système cible et réception d’un écho ECHO_REPLY retourné en réponse par le système cible. C’est donc un test élémentaire pour vérifier la bonne circulation des datagrammes IP dans un réseau.
ping @IP-hôte-distant
Quelques options :
Indique quels dont les routeurs traversés entre le système hôte d’origine et un système hôte destinataire dont on spécifié l’adresse IP. Peut servir de test pour la vérification de la bonne circulation des datagrammes IP dans un réseau :
traceroute @IP-hôte-distant
Affiche une trace (capture) des datagrammes IP qui entrent et sortent sur une interface de réseau.
tcpdump [options] expression
Cet outil n’est pas utilisé dans la salle de TP info mais sera disponible dans la salle de TP réseau.
Interface graphique de capture et de décodage de trames. Propose les mêmes fonctions que tcpdump mais avec une interface graphique qui permet de visualiser directement les différents protocoles utilisés. Cet outil n’est pas non plus installé dans les salles de TP info, il est par contre installé dans la salle de TP réseau.
1.2 Fichiers importants
La configuration des machines est en général stockée (sur les machines Unix) dans le répertoire /etc. Certains fichiers de ce répertoire concernent la configuration du réseau et sont standards:
Ces fichiers sont presque toujours présents sur une machine Unix (Linux, MacOS et même certaines versions de Windows). Des fichiers supplémentaires sont disponibles dans /etc/ pour indiquer les paramètres de configuration spécifiques à la machine. Ces fichiers de configurations sont spécifiques à la distribution Linux utilisée. Sur les distributions Debian, comme au département, le fichier principal de configuration est /etc/network/interfaces.
2 Présentation de l’outil Netperf
Cette fiche donne les fonctionnalités de base de l’outil de benchmark de performance réseau nommé netperf. Ce programme pemet de faire divers tests entre un PC client et un PC distant (aussi nommé serveur). Netperf est un outil client/serveur permettant d’injecter du trafic dans le réseau jusqu’à le saturer pour en mesurer les performances.
2.1 Architecture de netperf
Netperf suit une architecture très classique client/serveur et il y a deux exécutables : netperf et netserver. Quand netperf est exécuté, la première chose qu’il fait est d’établir une connexion TCP de contrôle vers le PC distant.
2.2 Installation
A priori netperf est installé sur les PC linux dans /home/Partage/enseignants/Reseau/3tc-NET/netperf/bin. Si ce n’est pas le cas vous pouvez positionner la variable NETHOME=/newpath/to/netperf/location/.
Il est possible d’exécuter netserver en standalone à la main sur le PC cible de votre choix : netserver -p <port number> et il s’exécutera et répondra aux requêtes sur le port que vous spécifiez (Si le port spécifié est différent du port standard veillez à le spécifier par la suite dans tous vos appels à netperf).
2.3 Netperf pour mesurer un taux de transfert
L’utilisation la plus courante est de vouloir mesurer le taux de transfert de donnée en block, i.e., un flux unidirectionnel et ceci revient à mesurer à quelle vitesse un système est capable d’envoyer des données vers un autre système.
Le test le plus simple est effectué par : /opt/netperf/netperf -H <remote host> qui va effectuer un test de 10 seconde. Les différentes options seront par défaut et la taille des buffers des sockets du PC client et du PC serveur distant sera celle du système par défaut. Netperf est livré avec divers script, notamment : tcp_stream_script et tcp_range_script. Si les tests des scripts ne sont pas suffisants il est possible d’appeler netperf avec un grand nombre d’options :
Un test de performance employant UDP est assez similaire à TCP. Une différence majeure est que la taille envoyée (send size) ne peut pas être plus grande que le plus petit buffer du PC client ou distant, i.e., si vous spécifiez l’option -m, la valeur doit être inférieure ou égale à la taille des buffer de socket spécifié par -s et -S. Le seconde remarque est que UDP n’étant pas le test par défaut, il faut préciser UDP_STREAM : /opt/netperf/netperf -H remotehost -t UDP_STREAM -- -m 1024
Il existe aussi un script livré avec netperf pour UDP : udp_stream_script.
Petite remarque triviale : UDP n’étant pas un protocole fiable, il est toujours bon d’examiner les résultats en émission et en réception.
2.4 Netperf pour mesurer des temps de requête/réponse
Netperf envoie des transactions d’une taille donné qui sont en fait une seule requête et uen seule réponse.
La commande /opt/netperf/netperf -H remotehost -t TCP_RR va employer une requête de taille 1 octet et une réponse de taille 1 octet. Il existe aussi des scripts pour ce type de mesure : tcp_rr_script. Les options sont :
Idem que pour TCp avec les mêmes options (sauf -D !). Vous pouvez employer la commande /opt/netperf/netperf -H remotehost -t UDP_RR et le script fournis est udp_rr_script.
3 Time
La commande time(1) permet de mesurer l’exécution d’un programme. On peut mesurer ainsi avec précision le temps que prend un transfert de données avec les différents protocoles. Exemple :
time ftp 192.168.31.100
4 Sock
Sock permet de générer du trafic UDP ou TCP entre un client et un serveur. L’aide est obtenue en tapant simplement sock sur la ligne de commande. A titre d’exemple voici la façon de générer un trafic UDP saturant une ligne.
serveur : sock -u -i -s @port client : sock -u -i -n 10240 @ip_serveur @port
5 Ftp
On peut automatiser un transfert ftp afin d’en mesurer le temps plus précisément : il faut définir un ficher de configuration /.netrc
Il faudra changer les droits en 600 sur ce fichier (chmod 600 .netrc) pour qu’il soit pris en compte par ftp. Exemple de fichier :
machine 192.168.1.100 login root password linadm macdef init put fichier bye <nl>
La première ligne permet d’automatiser la connexion à la machine 192.168.1.100. On définit, ensuite, une macro avec le nom spécial init qui sera exécutée dès la connection établie. Il ne faut pas oublier la ligne vide en fin de fichier, c’est elle qui marque la fin de la macro.
Ftp donne aussi un temps de transfert, qui sera forcément différent de celui donné par time. Il ne faut pas oublier que time mesure aussi l’établissement de la connexion, l’envoi des commandes ainsi que la clôture de la connexion.
6 Exercice 1
Les exercices qui sont à faire lors de ce TD sont principalement utilisés pour vous familiariser avec les outils de configuation des machines.
Dans les deux cas essayez de retrouver ces informations dans les fichiers de configuration ainsi qu’avec les commandes en ligne qui affichent l’état de la machine.
7 Exercice 2
Le réseau des salles TP est équipé en commutateurs Ethernet. Ces commutateurs permettent de limiter (éliminer) les collisions de trames.
Des scripts d’utilisation de netperf sont disponibles à l’emplacement suivant:
/home/Partage/enseignants/Reseau/3tc-NET/netperf/download/histogram
Ces scripts sont un peu compliqué mais en les lisant vous trouverez de nombreuses informations sur la façon de générer des tests avec netperf.
D’autres montages seront utilisables dans la salle de TP réseau en utilisant des concentrateurs Ethernet. Ces montages permettront de faire des mesures dans d’autres conditions d’utilisation.
1 Gestion de connexion
Le diagramme suivant reproduit le mécanisme d’établissement de connexion de TCP.
L’application qui demande la connexion envoie un segment TCP avec le bit SYN à 1 et le bit ACK à 0 pour initier la connexion. Le paquet envoyé indique également la taille de segment que la machine est prête à recevoir (initialisation de la fenêtre d’émission TCP du serveur) ainsi que le numéro de port de communication pour l’application cliente et le numéro de port de connexion pour atteindre le serveur.
Si aucune application n’a ouvert le port destination demandé la machine 2 renvoie un paquet avec le bit RST à 1 pour signifier le refus de connexion. Dans le cas favorable, le segment est passé à l’application qui choisit ou non d’autoriser la connexion. En cas d’autorisation le segment renvoyé comporte le bit SYN à 1, le bit ACK à 1 ainsi que la taille de segment accepté et les bon numéros d’acquittement.
Le troisième paquet est renvoyé par le client et sert à confirmer la mise en place de la connexion.
2 Politique de transmission
Les transmissions de données se font dans TCP en utilisant une fenêtre glissante pour temporiser et grouper les octets à envoyer dans le réseau. Si l’on ne fait pas attention, ce mécanisme peut s’avérer totalement inefficace. Considérons son fonctionnement normal: le destinataire annonce dans les acquittements la taille de données qu’il est prêt à recevoir (place libre dans la fenêtre). Ces données sont ensuite lues par l’application à un rythme/débit différent de celui du flux TCP entre les machines. Par exemple, si une machine possède une fenêtre de 4Ko et qu’elle reçoit un paquet de 2Ko, la taille renvoyée dans le segment d’acquittement pour la fenêtre sera de 2Ko. Si le prochain segment TCP arrive sans que l’application n’ait retiré de données alors le prochain acquittement aura une taille de fenêtre nulle. Lorque l’application retire des données, une indication de modification de la fenêtre est envoyée et TCP déplace la fenêtre du nombre d’octets lus vers la droite.
2.1 Algorithme de Nagle
Cet algorithme est une première modification du mécanisme envoi/acquittement
pour les cas où l’emetteur envoie les données octet par octet dans le flux
TCP. Ceci est particulièrement le cas dans les sessions intéractives type
Telnet/Ssh pour lesquelles les informations envoyées sont les caractères
tapés au clavier.
2.2 Algorithme de Clark (silly window)
Cet algorithme correspond au cas où l’emetteur envoie des segments de grande
taille mais où l’application ne lit les données qu’octet par octet sur la
machine destinatrice.
Le contrôle de congestion est assuré dans TCP par l’algorithme de démarrage lent (slow start) de Jacobson. Cet algorithme permet de savoir quelle est la taille de segment maximum qui peut être envoyé dans le réseau sans perte. Ceci est différent de la gestion de la fenêtre que l’on vient de voir (taille de buffer disponible dans une machine). Lorsque TCP choisit de créer un segment il doit prendre la taille minimum entre les deux valeurs (fenêtre annoncée et taille max de segment) pour être sûr de ne pas déborder la capacité de réception du destinataire (taille de la fenêtre) et de ne pas envoyer des paquets trop gros dans le réseau (taille de segment maximum).
S. Frénot, F. Le Mouël
Le World Wide Web repose essentiellement sur deux normes: HTML définissant le format de fichiers hypertexte et HTTP (http://www.w3.org/Protocols/rfc1945/rfc1945) définissant le protocole régissant le transfert de ces fichiers et la communication entre les clients (les navigateurs) et serveurs.
Le rôle du serveur Web est :
Une ressource peut se composer d’un ensemble de fichiers ou d’un exécutable accessible par un serveur Web, etc. Une ressource est identifiée par son type MIME (MultiPurpose Internet Mail Exchange).
1 Echanges avec un serveur web
Les serveurs Web utilisent le protocole HTTP (HyperText Transfert Protocol), le protocole définit le format des requêtes ainsi que le format des réponses. Les types de requêtes possibles sont :
En bref, une requête HTTP envoyée par le client est représentée en Figure 1. Une requête est constituée de 3 parties: une ligne de requête, des en-têtes, un corps. Le format d’une requête du client vers le serveur est :
<Type de Requête> Nom_de_la_ressource Version_protocole [paramètres_client] <saut de ligne>
Voici l’exemple donné pour un GET :
GET / HTTP/1.0
Host: localhost:8080
User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.7.3) Gecko/20041007 Debian/1.7.3-5
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: fr-fr
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: close
Pragma: no-cache
<---- Ligne vide obligatoire (CR LF seuls)
La ligne de requête, la seule obligatoire, est composée de 3 éléments séparés par des espaces: la méthode (GET, HEAD, POST ou PUT), la ressource sous forme de chemin absolu et la mention de version HTTP (HTTP/1.0).
La réponse se décompose en deux parties: un « emballage » qui identifie le type de la ressource renvoyée et la ressource elle même.
[Emballage http] Content-Type: text/html\n \n <---- Ligne vide obligatoire (CR LF seuls) <html> <body> Bonjour à tous </body> </html>
La ligne vide permet d’identifier la fin de l’emballage. Il est possible que le serveur renvoie plus d’information dans l’entête http (durée de vie du document, type de serveur ?). Une réponse type prend la forme donnée ci dessous:
HTTP/1.0 200 OK
Server: 3TC HTTP Server 1.0
Content-Type: text/html
<---- Ligne vide obligatoire (CR LF seuls)
<ressource>
La réponse est constituée de 3 parties: la ligne d’état, des en-têtes suivies d’un corps correspondant généralement à un fichier HTML, GIF, JPEG ou autre. Une ligne ne contenant qu’un CR LF sépare les en-têtes du corps.
La ligne d’état, seule obligatoire, est composée de trois éléments séparés par des espaces un identificateur de version HTTP (HTTP/1.0 dans notre cas), suivi d’un code de diagnostic, lui-même suivi d’un message de diagnostic correspondant (voir paragraphe 6.1.1. du RFC1945)
En cas d’erreur, le corps de réponse doit tout de même être constitué d’un document HTML valide expliquant l’erreur.
Pour simuler une connexion cliente sur un serveur Web, on peut faire
un telnet sur le port de connexion : telnet telecom.insa-lyon.fr 80 On
dialogue alors selon le protocole HTTP.
1 Configuration d’un serveur web
Afin de tester cet environnement, réalisez une page Web simple pour en faire votre page perso et testez-la à partir du serveur officiel. Il est également souhaité que vous testiez un script shell CGI simple sur votre page perso.
Q: Quelle est la page html la plus simple à tester ?
Q: Comment vérifier que le serveur fonctionne
lorsque l’on est connecté sur la machine serveur ?
Cette partie a pour objectif d’installer un serveur Web personnel
indépendamment d’un accès administrateur.
Installer un serveur Web (il ne s’agit que des fichiers de configuration et non pas de l’exécutable) sur votre compte de l’utilisateur.
cd ~ # revenir au répertoire racine
mkdir httpd # créer un répertoire quelconque
cd httpd # passer dans ce répertoire
tar zxvf /home/Partage/enseignants/Reseau/3tc-NET/http_conf.tar.gz
# décompacter l'archive
Editer les fichiers .conf afin d’adapter les paramètres donnés ci-dessous (ne pas hésiter à jeter un coup d’œil sur les autres paramètres ?)
Expliquez et adaptez ces directives à vos besoins.
Listen 8000 ServerRoot /home/<user> PidFile /home/<user>/httpd/lock/httpd.pid LockFile /home/<user>/httpd/lock/httpd.lock DocumentRoot /home/<user>/httpd/html ErrorLog /home/<user>/httpd/logs
User <user> Group <group> ServerAdmin <user_mail>
Votre <home_directory> est /home/<année>/<login> et
non pas /home/<login>.
Lancer le serveur avec la commande
/usr/sbin/apache2 -f ~<user>/httpd/conf/httpd2.conf
2 Pages dynamiques : CGI / PHP / Java
L’interface CGI permet au serveur de donner la main à un exécutable chargé de renvoyer la ressource au client. Le serveur web appelle donc un programme à chaque fois qu’on lui demande une ressource précise. L’exécution de ce programme génère le contenu qui sera renvoyé au client. Du point de vue du client il n’y a pas de différence avec un fichier qui aurait été fabriqué à l’avance et stocké sur le serveur web.
Pour programmer un script CGI n’importe quel langage sachant récupérer une entrée standard et sachant écrire sur une sortie standard peut être utilisé. Certains langages sont cependant plus adaptés que d’autres (Perl, par exemple) !
Un exemple de script shell pourrait ressembler à celui-ci:
#! /bin/sh
echo "Content-Type: text/html"
echo " " # ligne vide
echo "<html><body> "
echo bonjour $REMOTE_ADDR
echo "</body></html>"
Lorsqu’un client se connecte sur un serveur, celui-ci récupère du client l’adresse source, le type de client?, qu’il passe au script CGI sous la forme de variables d’environnements.
Lorsqu’une ressource est demandée par la méthode GET elle peut contenir des paramètres ajoutés à la fin du nom de la ressource. Le format de passage des paramètres est :
<a href= « toto.cgi?param1=toto¶m2=titi¶m3=25 »>afficher</a>
La zone paramètre est séparée de la zone ressource par un ? Les différents paramètres sont séparés par des &. Tous les paramètres sont encodés au format 7 bits (pas de caractères spéciaux). Lorsque le serveur Web reçoit une requête GET avec une ressource de type CGI il extrait la chaîne située après le & et crée une variable d’environnement QUERY_STRING qui est passée au script. A la charge du script de traiter les paramètres.
la séparation & entre les paramètres n’est qu’une convention. La QUERY_STRING contient la chaîne en brut.