Les réseaux - deuxième partie

Les réseaux - deuxième partie Chapitre 1 : Protocoles AbdelAli.ED-DBALI@univ-orleans.fr Département d Informatique - LIFO Université d Orléans c A. ED-DBALI (Université d Orléans) Réseaux II 1 / 113

1 Spécification de protocoles Exemples de spécifications TCP DHCP NAT 2 Les réseaux sans fil, WiFi, mobilité IP, Bluetooth,... c A. ED-DBALI (Université d Orléans) Réseaux II 2 / 113

Principes du transfert fiable de données Concept faisant partie du top-10 des concepts importants des réseaux! Les caractéristiques des canaux non fiables déterminent la complexité du protocole de transfert fiable des données (reliable data transfer : rdt) c A. ED-DBALI (Université d Orléans) Réseaux II 3 / 113

Transfert fiable de données fonctionnement rdt send() : appelée depuis le niveau au dessus (ex. par app.). Données transmises au niveau supérieur du récepteur udt send() : appelée par le protocole rdt pour transférer les paquets sur le canal non fiable rdt rcv() : appelée à l arrivée des paquets sur le canal du côté récepteur deliver data() : appelée par le protocole rdt pour délivrer les données au dessus c A. ED-DBALI (Université d Orléans) Réseaux II 4 / 113

Transfert fiable de données fonctionnement Nous allons : Développer incrémentalement les parties émetteur et récepteur du protocole rdt Utilisation des automates d états finis (AEF) pour spécifier l émetteur et le récepteur état : l état suivant est déterminé uniquement par un événement c A. ED-DBALI (Université d Orléans) Réseaux II 5 / 113

rdt1.0 : transfert fiable sur un canal fiable Le canal sous-jacent est parfaitement fiable pas d erreurs de bits pas de perte de paquets Un AEF pour chaque partie de l échange : L émetteur envoie des données dans le canal sous-jacent Le récepteur lit les données sur la sortie du canal c A. ED-DBALI (Université d Orléans) Réseaux II 6 / 113

rdt2.0 : canal avec erreurs (et sans perte) Le canal peut détériorer des bits du paquet rappel : checksum d UDP pour détecter les erreurs de bits la question : comment réparer ces erreurs? acquittements (ACK) : le récepteur dit explicitement à l émetteur que ce paquet a été reçu sans dommages acquittements négatifs (NAK) : le récepteur dit explicitement à l émetteur que le paquet contenait des erreurs L émetteur retransmet le paquet à la réception d un NAK Nouveaux mécanismes dans rdt2.0 : détection d erreurs retours du récepteur : messages (ACK,NAK) : récepteur émetteur c A. ED-DBALI (Université d Orléans) Réseaux II 7 / 113

rdt2.0 : spécification de l AEF émetteur récepteur c A. ED-DBALI (Université d Orléans) Réseaux II 8 / 113

rdt2.0 a un défaut néfaste! Que se passe-t-il si les ACK/NAK sont erronés? L émetteur ne sait pas ce qui se passe chez le récepteur! Ne peut pas retransmettre simplement : possibilité de duplication de paquets (retransmission de paquets reçus correctement) Gérer la duplication L émetteur ajoute des numéros de séquence à chaque paquet L émetteur retransmet le paquet courant si ACK/NAK altéré Le récepteur jette (ne délivre pas) le paquet dupliqué Stop and wait L émetteur émet un paquet Attend la réponse du récepteur c A. ED-DBALI (Université d Orléans) Réseaux II 9 / 113

rdt2.1 : l émetteur gère les ACK/NAKs altérés c A. ED-DBALI (Université d Orléans) Réseaux II 10 / 113

rdt2.1 : le récepteur gère les ACK/NAKs altérés c A. ED-DBALI (Université d Orléans) Réseaux II 11 / 113

rdt2.1 : discussion émetteur numéro de séquence ajouté au paquet deux numéros de séquence (0,1) suffisent. Pourquoi? doit vérifier si les ACK/NAK reçus sont altérés les états sont dupliqués : l état doit se rappeler si le num. du paquet courant est 0 ou 1 récepteur doit vérifier si le paquet reçu est une duplication l état indique si le paquet attendu a un num. de séq. 0 ou 1 Note : le récepteur ne sait pas si son dernier ACK/NAK a été reçu correctement par l émetteur c A. ED-DBALI (Université d Orléans) Réseaux II 12 / 113

rdt2.2 : un protocole sans NAK Même fonctionnalité que rdt2.1 mais n utilisant que des ACK Au lieu d un NAK, le récepteur envoie un ACK pour le paquet correctement reçu le récepteur doit inclure explicitement le numéro de séquence du paquet acquitté positivement (ACK) Chez l émetteur, un ACK dupliqué a la signification d un NAK : retransmettre le paquet courant c A. ED-DBALI (Université d Orléans) Réseaux II 13 / 113

rdt2.2 : l émetteur c A. ED-DBALI (Université d Orléans) Réseaux II 14 / 113

rdt2.2 : le récepteur c A. ED-DBALI (Université d Orléans) Réseaux II 15 / 113

rdt3.0 : canal avec erreurs et pertes Nouvelle supposition Le canal peut aussi perdre des paquets (données ou ACKs) Checksum, num. séq., ACKs, retransmissions peuvent aider mais ne suffisent pas Question : comment gérer les pertes? L émetteur attend jusqu à la perte ou l acquittement, puis retransmet Approche L émetteur attend pdt un temps raisonnable l arrivée d un ACK retransmet si pas de ACK reçu durant ce temps si le paquet (ou ACK) simplement retardé (non perdu) : retransmission duplication (sol. : num. séq.) requiert un minuteur c A. ED-DBALI (Université d Orléans) Réseaux II 16 / 113

rdt3.0 : l émetteur c A. ED-DBALI (Université d Orléans) Réseaux II 17 / 113

rdt3.0 en action Echange sans perte Perte d un paquet c A. ED-DBALI (Université d Orléans) Réseaux II 18 / 113

rdt3.0 en action suite Perte d acquittement timeout prématuré c A. ED-DBALI (Université d Orléans) Réseaux II 19 / 113

Performance de rdt3.0 rdt3.0 fonctionne avec une performance médiocre Exemple : lien à 1 Gbps, t prop =15 ms, taille paquet : 1Ko T trans = L (taille paquet en bits) = 8kb/paquet R (taux de transmission en bps) 10 9 b/s = 8µs Uémetteur : taux d utilisation (fraction du temps ou l émetteur est actif) Uémetteur = L/R RTT + L/R = 0.008 30.008 = 0.00027 1ko toutes les 30 ms 33ko/s à transmettre via le lien 1Gbps les protocoles réseau limitent l utilisation des ressources physiques! c A. ED-DBALI (Université d Orléans) Réseaux II 20 / 113

rdt3.0 : stop-and-wait en action Uémetteur = L/R RTT + L/R = 0.008 30.008 = 0.00027 c A. ED-DBALI (Université d Orléans) Réseaux II 21 / 113

Protocoles pipelinés Pipelining L émetteur émet plusieurs paquets, en-vol, sans attendre l acquittement du premier paquet l intervalle des num. de séq. doit grandir bufferisation au niveau de l émetteur et/ou récepteur Deux formes de protocoles pipelinés génériques : Go-Back-N (protocole à fenêtre d émission ou d anticipation) Selective Repeat (à retransmission sélective) c A. ED-DBALI (Université d Orléans) Réseaux II 22 / 113

Pipelining : accroît le taux d utilisation Uémetteur = 3 L/R RTT + L/R = 0.024 30.008 = 0.008 Améliore le taux d utilisation par un facteur de 3! c A. ED-DBALI (Université d Orléans) Réseaux II 23 / 113

Go-Back-N : protocole à fenêtre d émission Émetteur Num. séq. prend k-bit dans l entête des paquets La fenêtre permet jusqu à N paquets consécutifs non acquittés ACK(n) : acquitte tous les paquets jusqu au num. de séq. n inclus (ACK cumulatif) peut duper les ACK dupliqués (voir récepteur) timer pour chaque paquet en vol timeout(n) : retransmet pqt n et tous les pqts de la fenêtre de num de séq plus grand que n c A. ED-DBALI (Université d Orléans) Réseaux II 24 / 113

GBN : ADF étendu de l émetteur c A. ED-DBALI (Université d Orléans) Réseaux II 25 / 113

GBN : ADF étendu du récepteur ACK-uniquement : envoyer tjrs ACK pour les paquets reçus avec le plus grand num. de séq. dans l ordre Peut générer des ACK dupliqués A besoin de se rappeler uniquement le num de séq attendu (expectedseqnum) Paquet désordonné : Jeter (ne pas bufferiser) pas de buffer chez le récepteur! Re-ACK les pqts avec le plus grand num. de séq. dans l ordre c A. ED-DBALI (Université d Orléans) Réseaux II 26 / 113

GBN en action c A. ED-DBALI (Université d Orléans) Réseaux II 27 / 113

Répétition sélective (Selective Repeat) Le récepteur acquitte individuellement tous les paquets reçus correctement Bufferise les paquets, au besoin, pour les transmettre à la couche application L émetteur renvoie uniquement les paquets pour lesquels il n a pas reçu de ACK L émetteur minute chaque paquet non acquitté Fenêtre d émetteur N num. séq. consécutifs Limite les num. séq. des paquets émis et non acquittés c A. ED-DBALI (Université d Orléans) Réseaux II 28 / 113

Répétition sélective : fenêtres émetteur/récepteur c A. ED-DBALI (Université d Orléans) Réseaux II 29 / 113

Répétition sélective Emetteur Données depuis application : si prochain num. séq. dispo. dans fenêtre, envoyer pqt timeout(n) : renvoyer pqt n, redémarrer minuteur ACK(n) dans [sendbase,sendbase+n] : marquer le pqt n comme reçu si n le + petit pqt non acquitté, avancer fenêtre base au prochain num. séq. non acquitté c A. ED-DBALI (Université d Orléans) Réseaux II 30 / 113

Répétition sélective Récepteur pqt n dans [rcvbase, rcvbase + N 1] envoyer ACK(n) pas dans l ordre : bufferiser dans l ordre : acheminer (acheminer aussi les pqts bufferisés et ordonnés), avancer fenêtre au prochain pqt non reçu pqt n dans [rcvbase N, rcvbase 1] ACK(n) autrement : ignorer c A. ED-DBALI (Université d Orléans) Réseaux II 31 / 113

Répétition sélective c A. ED-DBALI (Université d Orléans) Réseaux II 32 / 113

Répétition sélective Dilemme Exemple : num. séq : 0, 1, 2, 3 taille fenêtre=3 le récepteur ne voit aucune différence entre les deux scénarios! livre incorrectement des données dupliquées comme nouvelles dans (a) Q : quelle relation entre num. séq. et taille fenêtre? c A. ED-DBALI (Université d Orléans) Réseaux II 33 / 113

TCP : Vue d ensemble RFCs : 793, 1122, 1323, 2018, 2581 point-à-point un émetteur, un récepteur transfert fiable, ordonné pas de messages sur la touche pipelining contrôle de flux et de congestion, positionnement de la taille de la fenêtre d émission buffers d émission et de réception c A. ED-DBALI (Université d Orléans) Réseaux II 34 / 113

TCP : Vue d ensemble suite données en full duplex flot de données bi-directionel dans la même connexion MSS : maximum segment size mode connecté initialisation de la connexion (échange de msgs de contrôle) avant l échange de données flux controlé émetteur ne peut submerger le récepteur c A. ED-DBALI (Université d Orléans) Réseaux II 35 / 113

TCP structure segment c A. ED-DBALI (Université d Orléans) Réseaux II 36 / 113

TCP : num. de séq. et de ACKs num. séq. : num. du premier octet du seg. de données dans le flux des octets ACKs : num. de séq du prochain octet attendu ACK cumulatif Q : comment le récepteur traite les segments hors séquence? R : la spéc de TCP ne dit rien : implementation dependent telnet : scénario simple c A. ED-DBALI (Université d Orléans) Réseaux II 37 / 113

TCP : Round Trip Time et Timeout Comment TCP initialise la valeur de timeout? Plus grand que RTT... mais RTT varie Trop petit : timeout prématuré (retransmissions inutiles) Trop grand : retarde la réaction à la perte d un segment Comment estimer RTT? EchantillonRTT : temps mesuré depuis la transmission d un segment jusqu à la réception du ACK en ignorant les retransmissions EchantillonRTT varie lisser l estimation de RTT moyenne de plusieurs mesures récentes pas seulement l EchantillonRTT courant c A. ED-DBALI (Université d Orléans) Réseaux II 38 / 113

TCP : Round Trip Time et Timeout suite RTTestimé = (1 α) RTTestimé + α EchantillonRTT l influence des échantillons passés décroît exponentiellement valeur typique pour α : 0.125 c A. ED-DBALI (Université d Orléans) Réseaux II 39 / 113

RTT : exemple d estimation c A. ED-DBALI (Université d Orléans) Réseaux II 40 / 113

TCP : Round Trip Time et Timeout Calcul du timeout RTTestimé plus une marge de sécurité Grande variation de RTTestimé grande marge de sécurité Estimer d abord de combien dévie EchantillonRTT par rapport au RTTestimé : DevRTT = (1 β) DevRTT + β EchantillonRTT RTTestimé Valeur typique de β : 0.25 L intevalle de timeout : IntervalleTimeout = RTTestimé + 4 DevRTT c A. ED-DBALI (Université d Orléans) Réseaux II 41 / 113

TCP : transfert fiable de données TCP implémente un service de TFD au dessus du service non fiable de IP Pipelining des segments ACKs cumulatifs TCP utilise un seul minuteur pour les retransmissions Retransmissions déclenchées par Evénement de minuterie ACKs dupliqués Pour simplifier, l émetteur TCP Ignorer ACKs dupliqués Ignorer le contrôle de flux, le contrôle de congestion c A. ED-DBALI (Université d Orléans) Réseaux II 42 / 113

TCP : événements de l émetteur Données reçues depuis la couche appli. Création segment avec un num. de séq. Num. de séq. = numéro du premier octet du flux de données dans le segment Démarrer le minuteur si ce n est déjà fait (minuteur sur le dernier seg. non acquitté) Intervalle de timeout : Variable IntervalleTimeOut timeout retransmettre le segment qui a causé le timeout redémarrer le minuteur Ack reçu Si acquittement reçu sur des segments non acquittés prendre acte des acquittements démarrer le minuteur si des segments restent en suspend c A. ED-DBALI (Université d Orléans) Réseaux II 43 / 113

Émetteur TCP simplifié NumSeqSuiv = NumSeqInitial DebutFenetre = NumSeqInitial pour toujours { switch(evenmt) évènement: données reçus depuis application - créer segment TCP avec num. séq. NumSeqSuiv - si (minuteur ne tourne pas) démarrer minuteur - passer le segment à IP - NumSeqSuiv = NumSeqSuiv + taille(données) évènement: minuteur atteint le timeout - retransmettre le segment non encore acquitté et ayant le plus petit num. de séq. - démarrer minuteur évènement: ACK reçu, avec le champ num. ACK = y - si (y > DebutFenetre) { DebutFenetre = y si (il y a des segments non encore acquittés) démarrer minuteur } } /* fin pour */ c A. ED-DBALI (Université d Orléans) Réseaux II 44 / 113

TCP : scénarios de retransmission Scénario perte ACK c A. ED-DBALI (Université d Orléans) Réseaux II 45 / 113

TCP : scénarios de retransmission suite Scénario timeout prématuré c A. ED-DBALI (Université d Orléans) Réseaux II 46 / 113

TCP : scénarios de retransmission suite Scénario ACK cumulatif c A. ED-DBALI (Université d Orléans) Réseaux II 47 / 113

TCP : génération de ACK RFC 1122, RFC 2581 Evénement récepteur Arrivée d 1 seg. dans l ordre avec num. séq. attendu. Ttes données jusqu au num. séq. ACKées Arrivée d 1 seg. dans l ordre avec num. séq. attendu. Un autre seg. a le ACK en suspend Arrivée d un seg. hors séq. (plus grand que num. séq. attendu) Trou détecté Arrivée d un segment remplissant partiellement ou totalement le trou Action récepteur TCP Retarder le ACK : Attendre 500ms l arrivée du prochain seg. Si pas de prochain seg., envoyer ACK Envoyer immédiatement un seul ACK cumulatif : ACKer plusieurs segments arrivés dans l ordre Envoyer immédiatement un ACK dupliqué indiquant le num. séq. du prochain octet attendu Envoyer immédiatement un ACK disant que le segment doit commencer à la borne inférieure du nouveau trou c A. ED-DBALI (Université d Orléans) Réseaux II 48 / 113

Retransmission Rapide L intervalle timeout souvent relativement long long retard avant retransmission du paquet perdu Détecter segments perdus via les ACKs dupliqués L expéditeur envoie souvent beaucoup de segments en rafale Si segment perdu, il y aura probablement beaucoup de ACKs dupliqués Si l émetteur reçoit 3 ACKs pour la même donnée, il suppose que le segment après les données ACKées est perdu : retransmission rapide : renvoyer le segment avant expiration du minuteur c A. ED-DBALI (Université d Orléans) Réseaux II 49 / 113

Algorithme de retransmission rapide évènement: ACK reçu, avec le champ ACK qui vaut y - si (y > DebutFenetre) { DebutFenetre = y si (il y a des segments non encore acquittés) démarrer le minuteur } sinon { incrémenter le compteur des ACKs dupliqués reçus pour y si (compteur des ACKs dupliqués reçus pour y = 3) { retransmette le segment avec y comme num. de séq. } } c A. ED-DBALI (Université d Orléans) Réseaux II 50 / 113

TCP : Contrôle de flux Le côté récepteur d une connexion TCP gère un buffer : Les processus (côté applis) peuvent être lents à lire dans le buffer Contrôle de flux L émetteur ne doit pas faire déborder le buffer du récepteur trop rapidement Service correspondance de vitesse (speed-matching) : faire correspondre le taux d envoi des segments avec le taux d absorption des données par les applis c A. ED-DBALI (Université d Orléans) Réseaux II 51 / 113

Contrôle de flux : comment ça marche? Supposons que le récepteur abandonne les segments arrivés hors séquence Espace disponible dans le buffer = FenêtreRcpt = BufferRcpt - [DernierOctetReçu - DernierOctetLu] Le récepteur montre l espace disponible en mettant la valeur de FenêtreRcpt dans les segments L émetteur limite les données non acquittées à FenêtreRcpt Garantie du non débordement du buffer du récepteur c A. ED-DBALI (Université d Orléans) Réseaux II 52 / 113

TCP : Gestion de la connexion Rappel : L émetteur et le récepteur TCP établissent une connexion avant d échanger les segments de données Initialisation des variables TCP : numéros de séquence buffers, infos de contrôle de flux (ex. FenêtreRcpt) Client : l initiateur de la connexion JAVA : Socket Soc Clt = new Socket("poste","port") C : Soc Clt = socket(af INET,SOCK STREAM,0)) Serveur : contacté par le client JAVA : Socket SCon = SocketEcoute.accept() C : SCon = accept(socketecoute,(struct sockaddr*) &clt skaddr, &addrlen)) c A. ED-DBALI (Université d Orléans) Réseaux II 53 / 113

Connexion en trois étapes Etape 1 Le poste client envoie au serveur le segment SYN TCP specifie le numéro de séquence initial pas de données Etape 2 Le poste serveur reçoit SYN, répond avec le segment SYNACK le serveur alloue les buffers le serveur specifie son numéro de séquence initial Etape 3 Le client reçoit SYNACK, répond avec le segment ACK, qui peut contenir des données c A. ED-DBALI (Université d Orléans) Réseaux II 54 / 113

TCP : Gestion de connexion suite c A. ED-DBALI (Université d Orléans) Réseaux II 55 / 113

TCP : Gestion de connexion suite Fin de connexion le client ferme la socket : Java : SokClt.close() C : close(sokclt) Etape 1 : client envoie au serveur le segment de contrôle TCP FIN Etape 2 : serveur reçoit FIN, répond avec ACK, ferme la connexion et envoie FIN c A. ED-DBALI (Université d Orléans) Réseaux II 56 / 113

TCP : Gestion de connexion suite Etape 3 : client reçoit FIN, répond avec ACK Entre dans une attente temporelle (au cas où le ACK se perde) : Connexion fermée Etape 4 : serveur, reçoit ACK : Connexion fermée c A. ED-DBALI (Université d Orléans) Réseaux II 57 / 113

TCP : Gestion de connexion Cycle de vie du client TCP c A. ED-DBALI (Université d Orléans) Réseaux II 58 / 113

TCP : Gestion de connexion Cycle de vie du serveur TCP c A. ED-DBALI (Université d Orléans) Réseaux II 59 / 113

Principes du contrôle de congestion Congestion Informellement : beaucoup de sources envoyant beaucoup de données, trop rapidement, que le réseau doit traiter Pas de lien avec le contrôle de flux! Manifestations paquets perdus (débordement des buffers des routeurs) retards importants (mise en file d attente dans les buffers des routeurs) top-10 des problèmes réseau! c A. ED-DBALI (Université d Orléans) Réseaux II 60 / 113

Approches autour du contrôle de congestion Contrôle de congestion par les systèmes terminaux Pas de feedback du réseau La congestion déduite par les observations des systèmes terminaux : perte, retard Approche adoptée par TCP Contrôle de congestion assisté par le réseau Les routeurs fournissent un feedback aux systèmes terminaux Un bit indiquant la congestion (SNA, DECbit, TCP/IP ECN, ATM) L émetteur se doit d émettre à un certain taux c A. ED-DBALI (Université d Orléans) Réseaux II 61 / 113

Étude de cas Contrôle de congestion dans ATM (Asynchronous Transfer Mode) ABR ABR (Available Bit Rate) service élastique Si le chemin de l émetteur est sous-chargé L émetteur doit utiliser la bande passante disponible Si le chemin de l émetteur est surchargé L émetteur ne peut travailler qu avec le taux minimum garanti c A. ED-DBALI (Université d Orléans) Réseaux II 62 / 113

Étude de cas Contrôle de congestion dans ATM ABR Cellules RM (Resource Management) Envoyées par l émetteur, entremêlées avec les données Les bits dans une cellule RM positionnés par les switchs (network-assisted) bit NI : No Increase (pas d augmentation de taux : congestion douce) bit CI : Congestion Indication Les cellules RM renvoyées intactes par le récepteur à l émetteur c A. ED-DBALI (Université d Orléans) Réseaux II 63 / 113

Étude de cas Contrôle de congestion dans ATM ABR ER (Explicit Rate) : champ de deux octets dans la cellule RM Le commutateur encombré peut baisser la valeur de ER dans la cellule Taux d émission = taux minimum supportable dans le chemin Bit EFCI (Explicit Forward Congestion Indication) dans les cellules données : mis à 1 dans le commutateur encombré Si la cellule donnée précédant la cellule RM a le bit EFCI positionné, l émetteur positionne le bit CI dans la cellule RM retournée c A. ED-DBALI (Université d Orléans) Réseaux II 64 / 113

Contrôle de congestion dans TCP Contrôle end-end (pas d assistance réseau) L émetteur limite la transmission : DernierOctetEnvoyé DernierOctetAck CongWin Autrement dit : taux = CongWin RTT CongWin est dynamique, fonction de la percéption de la congestion de réseau c A. ED-DBALI (Université d Orléans) Réseaux II 65 / 113

Contrôle de congestion dans TCP suite Comment l émetteur perçoit la congestion? évnmt de perte = timeout ou 3 ACKs dupliqués émetteur TCP réduit le taux (donc CongWin) après une perte Trois mécanismes AIMD (Additive-Increase, Muliplicative-Decrease) démarrage lent (slow start) conservateur après les timeouts c A. ED-DBALI (Université d Orléans) Réseaux II 66 / 113

TCP : AIMD Diminution Multiplicative Diviser CongWin par 2 à chaque perte Augmentation Additive Augmenter CongWin d 1 MSS (Maximum Segment Size) chaque RTT en l absence de perte c A. ED-DBALI (Université d Orléans) Réseaux II 67 / 113

TCP : Démarrage lent Au début de la connexion : CongWin = 1 MSS Exemple : MSS = 500 octets et RTT = 200 msec Taux initial = 20 ko/s La bande passante disponible peut être MSS/RTT On souhaite atteindre rapidement un taux respectable Au début de la connexion Augmenter exponentiellement le taux (de transfert) jusqu au premier événement de perte c A. ED-DBALI (Université d Orléans) Réseaux II 68 / 113

TCP : Démarrage lent suite Au début de la connexion Augmenter exponentiellement le taux (de transfert) jusqu au premier événement de perte : Doubler CongWin à chaque RTT : à chaque réception d un ACK En résumé : le taux initial est faible mais croit exponentiellement c A. ED-DBALI (Université d Orléans) Réseaux II 69 / 113

TCP : Démarrage lent raffinement Après 3 ACKs dup. : CongWin est divisé par 2 puis la fenêtre grandit linéairement Après un timeout : CongWin remise à 1 MSS puis la fenêtre grandit exponentiellement jusqu au à un seuil, puis grandit linéairement Philosophie 3 ACKs dup. indiquent que le réseau est capable d acheminer quelques segments timeout avant les 3 ACKs dup. est plus alarmant c A. ED-DBALI (Université d Orléans) Réseaux II 70 / 113

TCP : Démarrage lent raffinement Q : Quand est ce que la croissance exponentielle devient linéaire? R : Quand CongWin devient la moitié de sa valeur avant le timeout Implémentation Variable Seuil si événement perte alors Seuil := (CongWin juste avant l événement perte) / 2 c A. ED-DBALI (Université d Orléans) Réseaux II 71 / 113

TCP : Contrôle de congestion résumé Quand CongWin < Seuil, émetteur dans sa phase démarrage lent, fenêtre grandit exponentiellement. Quand CongWin > Seuil, émetteur dans la phase congestion évitable, fenêtre grandit linéairement. Quand un triple ACK dupliqué se produit, Seuil mis à CongWin/2 et CongWin mise à Seuil. Quand timeout se produit, Seuil mis à CongWin/2 et CongWin mise à 1 MSS. c A. ED-DBALI (Université d Orléans) Réseaux II 72 / 113

DHCP Dynamic Host Configuration Protocol - RFC 2131 But Permet à un poste client d obtenir dynamiquement sa configuration IP (quand il rejoint le réseau) à partir d un serveur Peut renouveler le bail d une adresse en cours d utilisation Permet la réutilisation des adresses (prendre l adresse uniquement quand connecté) Support pour utilisateurs mobiles qui veulent rejoindre le réseau c A. ED-DBALI (Université d Orléans) Réseaux II 73 / 113

DHCP - Architecture c A. ED-DBALI (Université d Orléans) Réseaux II 74 / 113

DHCP - Mécanismes d allocation d adresses Trois mécanismes d allocation L allocation automatique DHCP assigne une adresse IP permanente à un client. Le client reçoit une configuration sans limite de bail (plus besoin de renouveller durant l utilisation) L allocation dynamique DHCP assigne une adresse IP à un client pour une durée déterminée ou jusqu à ce que le client renonce à son adresse). L allocation manuelle une adresse IP est assignée par l administrateur réseau, et DHCP est simplement utilisé pour convoyer les adresses désignées jusqu au client Un réseau spécifique utilisera un ou plusieurs de ces mécanismes Dépend de la stratégie de l administrateur réseau c A. ED-DBALI (Université d Orléans) Réseaux II 75 / 113

Allocation dynamique Les avantages Le client reçoit une configuration pour une durée determinée (qu on appelle le bail) Le seul des 3 mécanismes qui réutilise automatiquement une adresse qui n est plus utilisée par un client Utile pour assigner une adresse à un client qui se connectera au réseau de manière temporaire Particulièrement utile pour partager une liste limitée d adresses IP entre un groupe de clients qui ne nécessitent pas une adresse permanente. c A. ED-DBALI (Université d Orléans) Réseaux II 76 / 113

Allocation manuelle La machine reçoit une adresse fixe. Le serveur reconnait le client avec son adresse MAC. Le fichier de config du serveur fait l association entre l adresse MAC et l adresse fixe. Les avantages Permet à DHCP d être utilisé pour éliminer les processus enclins à l erreur de configuration manuelle de machines avec une adresse IP Utile dans le cas où le contrôle d accès à des services est basé sur l adresse IP du demandeur c A. ED-DBALI (Université d Orléans) Réseaux II 77 / 113

Paramètres de configuration Plusieurs paramètres peuvent être offerts par le serveur DHCP ; mais tous ne sont pas obligatoires Un client et un serveur peuvent négocier seulement les paramètres demandés par le client ou spécifiques à un sous réseau Après configuration via DHCP, un client devrait communiquer normalement avec son entourage (et Internet) Le minimum syndical est l adesse IP et le masque de réseau DHCP ne demande pas d inscription des clients nouvellement configurés avec le Service de noms de domaine (DNS) DHCP non utilisé pour la configuration des routeurs c A. ED-DBALI (Université d Orléans) Réseaux II 78 / 113

Exigeances DHCP ne devrait pas exiger un serveur sur chaque sous réseau Travailler au travers des routeurs ou via l intervention des agents relais (meilleure adaptabilité et économie) Des serveurs DHCP peuvent se chevaucher (fiabilité et performances) Un client DHCP doit être préparé pour recevoir des réponses multiples à une demande de paramètres de configuration Coexistence avec des machines statiques et non participantes c A. ED-DBALI (Université d Orléans) Réseaux II 79 / 113

Objectifs Garantir l unicité simultanée d attribution des adresses réseau Retenir une configuration DHCP d un client malgré un redémarrage du client DHCP ou du serveur Un client DHCP devra, à chaque fois que cela est possible, se voir assigner les mêmes paramètres de configuration (ex : même adresse réseau) en réponse à chaque demande Supporter les allocations fixes ou permanentes des paramètres de configuration à des clients particuliers c A. ED-DBALI (Université d Orléans) Réseaux II 80 / 113

DHCP - vue d ensemble DHCPDISCOVER Client broadcast : localiser les serveurs disponibles DHCPOFFER Serveur Client : Répondre au DHCPDISCOVER avec les paramètres de configuration DHCPREQUEST Client Serveur(s) : soit demander les paramètres à un serveur (décline implicitement les offres de tous les autres) confirmer la validité des adresses précédemment allouées (ex : un redémarrage système) étendre le bail sur une adresse réseau en particulier DHCPACK Serveur Client : paramètres de configuration dont l adresse IP déjà attribuée c A. ED-DBALI (Université d Orléans) Réseaux II 81 / 113

Format des messages c A. ED-DBALI (Université d Orléans) Réseaux II 82 / 113

DHCP - Sénario de configuration c A. ED-DBALI (Université d Orléans) Réseaux II 83 / 113

Autres messages DHCPNAK Serveur Client : notion d un client pour les adresses réseau incorrectes (ex : client déplacé sur un nouveau sous réseau) le bail du client a expiré DHCPDECLINE Client Serveur : indique que l adresse réseau est déjà utilisée DHCPRELEASE Client Serveur : libére l adresse réseau et annule le bail DHCPINFORM Client Serveur : demande seulement les paramètres de configuration locaux (le client possède déjà une adresse réseau attribuée de manière externe) c A. ED-DBALI (Université d Orléans) Réseaux II 84 / 113

Clients DHCP Etats de transition Légende des transitions 1 -/envoi DHCPDISCOVER 2 Select. offre/envoi DHCPREQUEST 3 DHCPACK/enregistre bail ;tempos T1, T2 4 DHCPNAK/Rejet offre 5 DHCPOFFER/Collecte réponses 6 DHCPACK (rejeté)/envoi DHCPDECLINE 7 DHCPOFFER/Rejet 8 T 1 expire/envoi DHCPREQUEST pour location serveur 9 DHCPNAK, bail expiré/arrêt réseau 10 DHCPNAK/Arrêt réseau 11 -/envoi DHCPREQUEST 12 DHCPNAK/Redémarrage 13 T 2 expire/diffusion DHCPREQUEST 14 DHCPOFFER, DHCPACK, DHCPNAK/Rejet c A. ED-DBALI (Université d Orléans) Réseaux II 85 / 113

Expiration du bail et réacquisition Rôle des temporisateurs T 1 et T 2 Temps auxquels le client essaie d étendre son bail T 1 état Renouvellement et envoi DHCPREQUEST au serveur T 2 état Réaffectation et envoi DHCPREQUEST à un serveur (diffusion) T 1 plus récent que T 2 plus récent que expiration bail Valeurs de T 1 et T 2 T 1 aléatoirement autour de (0.5 durée bail) T 2 aléatoirement autour de (0.875 durée bail) c A. ED-DBALI (Université d Orléans) Réseaux II 86 / 113

Configuration du client Etablissement Sous linux : Choisir DHCP dans la fenêtre de config du réseau... ou Fichier /etc/sysconfig/network-scripts/ifcfg-eth i (i numéro interface) devant contenir au moins les lignes : DEVICE="eth0" BOOTPROTO="dhcp" IPADDR="" NETMASK="" ONBOOT="yes" Sous windows : Cocher obtenir automatiquement une adresse IP sous propriétés TCP/IP c A. ED-DBALI (Université d Orléans) Réseaux II 87 / 113

Configuration du client Consultation Sous Linux : fichier /var/lib/dhcp/dhclient.leases lease { interface "eth0"; fixed-address 192.168.0.2; option subnet-mask 255.255.255.0; option dhcp-lease-time 864000; option routers 192.168.0.254; option dhcp-message-type 5; option dhcp-server-identifier 192.168.0.254; option domain-name-servers 212.27.54.252,213.228.0.212; option domain-name "free.fr"; renew 4 2006/2/2 08:02:16; rebind 2 2006/2/7 04:40:44; expire 3 2006/2/8 10:40:44; } Sous windows : commande ipconfig /all c A. ED-DBALI (Université d Orléans) Réseaux II 88 / 113

Capture trame DHCP Discover Ethernet II, Src: 00:20:18:b9:49:37, Dst: ff:ff:ff:ff:ff:ff Destination: ff:ff:ff:ff:ff:ff (Broadcast)... Internet Protocol, Src Addr: 0.0.0.0, Dst Addr: 255.255.255.255... User Datagram Protocol, Src Port: bootpc (68), Dst Port: bootps (67)... Bootstrap Protocol Message type: Boot Request (1) Hardware type: Ethernet Hardware address length: 6 Hops: 0 Transaction ID: 0x6719436e... c A. ED-DBALI (Université d Orléans) Réseaux II 89 / 113

Capture trame DHCP Discover suite Bootstrap Protocol Client IP address: 0.0.0.0 (0.0.0.0) Your (client) IP address: 0.0.0.0 (0.0.0.0) Next server IP address: 0.0.0.0 (0.0.0.0) Relay agent IP address: 0.0.0.0 (0.0.0.0) Client hardware address: 00:08:74:3B:7B:B8 Server host name not given Boot file name not given Actuellement, le client ne dispose d aucune configuration c A. ED-DBALI (Université d Orléans) Réseaux II 90 / 113

Capture trame DHCP Discover suite Options demandées Magic cookie: (OK) Option 53: DHCP Message Type = DHCP Discover Option 61: Client identifier Hardware type: Ethernet Client hardware address: 00:08:74:3B:7B:B8 1. Option 50: Requested IP Address = 192.168.0.2 Option 12: Host Name = "pcd-eddbali" Option 55: Parameter Request List 1 = Subnet Mask 15 = Domain Name 3 = Router 6 = Domain Name Server 31 = Perform Router Discover 33 = Static Route End Option 1. Le client souhaite récupérer la même IP qu il avait autrefois c A. ED-DBALI (Université d Orléans) Réseaux II 91 / 113

Capture trame DHCP Offer Partie BOOTP de la capture Bootstrap Protocol Message type: Boot Reply (2) Hardware type: Ethernet Hardware address length: 6 Hops: 0 Transaction ID: 0x6719436e Seconds elapsed: 0 Bootp flags: 0x0000 (Unicast) 0............ = Broadcast flag: Unicast.000 0000 0000 0000 = Reserved flags: 0x0000 Client IP address: 0.0.0.0 (0.0.0.0) 1. Your (client) IP address: 192.168.0.2 (192.168.0.2) 2. Next server IP address: 192.168.0.254 (192.168.0.254) 3. Relay agent IP address: 0.0.0.0 (0.0.0.0) 1. Confirmation de l IP du client 2. IP du serveur DHCP qui répond 3. Il n y a pas d agent de relais DHCP c A. ED-DBALI (Université d Orléans) Réseaux II 92 / 113

Capture trame DHCP Offer suite Option de configuration offertes... Client hardware address: 00:08:74:3B:7B:B8 Server host name not given Boot file name not given Magic cookie: (OK) Option 53: DHCP Message Type = DHCP Offer Option 54: Server Identifier = 192.168.0.254 Option 51: IP Address Lease Time = 1 hour Option 1: Subnet Mask = 255.255.255.0 Option 15: Domain Name = "free.fr" Option 3: Router = 192.168.0.254 Option 6: Domain Name Server = 212.27.54.252,213.228.0.212 End Option c A. ED-DBALI (Université d Orléans) Réseaux II 93 / 113

Capture trame DHCP Request Bootstrap Protocol Message type: Boot Request (1)... Option 53: DHCP Message Type = DHCP Request Option 61: Client identifier Hardware type: Ethernet Client hardware address: 00:08:74:3B:7B:B8 Option 50: Requested IP Address = 192.168.0.2 Option 54: Server Identifier = 192.168.0.254 Option 12: Host Name = "pcd-eddbali"... Capture similaire à DHCP Discover Différence : Option 54 (le client demande à un serveur précis) c A. ED-DBALI (Université d Orléans) Réseaux II 94 / 113

Configuration d un serveur DHCP Exemple Fichier de configuartion : /etc/dhcpd.conf Quelques directives de configuration ignore client-updates; update-static-leases on; ddns-domainname "cloche.ici"; max-lease-time 3600; default-lease-time 3600; Quelques options globales option domain-name-servers 192.168.0.254; option subnet-mask 255.255.255.0; option routers 192.168.0.254; c A. ED-DBALI (Université d Orléans) Réseaux II 95 / 113

Configuration d un serveur DHCP Exemple - suite Un seul sous réseau subnet 192.168.0.0 netmask 255.255.255.0 { Adresses dynamiques pour les invités range 192.168.0.64 192.168.0.127; Les clients habituels en IP fixe host pcd-eddbali { hardware ethernet 00:08:74:3B:7B:B8; fixed-address 192.168.0.2; } host pc-home { hardware ethernet 05:00:34:F4:0A:9C; fixed-address 192.168.0.3; } c A. ED-DBALI (Université d Orléans) Réseaux II 96 / 113

NAT : Network Address Translation Motivation Le réseau local utilise juste une (ou quelques) adresse(s) IP quand il communique avec l extérieur Pas besoin de demander au FAI tout un intervalle d adresses officielles pour couvrir tous les périphériques Retarde le problème de pénurie des adresses IP On peut changer les adresses des périphériques dans le réseau local sans en avertir le reste du monde On peut changer de FAI sans bouleverser l adressage au sein du réseau local Les périphériques du réseau local non explicitement adressables, invisibles de l extérieur (un plus de sécurité). c A. ED-DBALI (Université d Orléans) Réseaux II 97 / 113

Espaces d adressage Rappel Les classes d adresses IP Classe Intervalle d adresses utilisables Classe A 1.0.0.0-127.255.255.255 Classe B 128.0.0.0-191.255.255.255 Classe C 192.0.0.0-223.255.255.255 c A. ED-DBALI (Université d Orléans) Réseaux II 98 / 113

Espaces d adressage privé Une classification plus fine Classe Intervalle d adresses privées Intervalles d adresses publiques Classe A 10.0.0.0-10.255.255.255 1.0.0.0-9.255.255.255 11.0.0.0-126.255.255.255 Classe B 172.16.0.0-172.31.255.255 128.0.0.0-172.15.255.255 172.32.0.0-191.255.255.255 Classe C 192.168.0.0-192.168.255.255 192.0.0.0-192.167.255.255 192.169.0.0-223.255.255.255 c A. ED-DBALI (Université d Orléans) Réseaux II 99 / 113

Adresse privée Sans traduction d adresse 10.0.0.0 réseau privé Datagramme 10.0.0.1 80.128.25.30 : arrive à destination Renvoi de réponse de 80.128.25.30 10.0.0.1 10.0.0.0 réseau non routé dans l internet datagramme jamais arrivé à 10.0.0.1! c A. ED-DBALI (Université d Orléans) Réseaux II 100 / 113

NAT Statique Datagrammes sortants : remplacer l adresse IP source de tout datagramme sortant par une adresse IP officielle... les clients/serveurs distants répondront en utilisant l adresse IP officielle du NAT comme adresse de destination Datagrammes entrants : remplacer l adresse IP officielle du NAT dans les champs dest. de tous les datagrammes entrants, par l adresse IP source privée c A. ED-DBALI (Université d Orléans) Réseaux II 101 / 113

NAT Statique Inconvénients Dans l exemple, on a simplement fait une association entre une adresse privée et une adresse publique : 10.0.0.1 138.76.29.8 Certes, l association adresse privée adresse publique a pu rendre une machine privée accessible sur Internet. Mais cela oblige à avoir une adresse publique par adresse privée ne règle donc pas le problème de pénurie d adresses IP c A. ED-DBALI (Université d Orléans) Réseaux II 102 / 113

NAT Statique Inconvénients Problème ARP Datagramme M 1 vers x.y.z.t Datagramme NATé dans R 1 (10.0.0.1 138.76.29.8) R 2 route normalement vers x.y.z.t Datagramme x.y.z.t vers 138.76.29.8 R 2 cherche l adresse MAC de 138.76.29.8 : ARP (pas de réponse) c A. ED-DBALI (Université d Orléans) Réseaux II 103 / 113

NAT Statique Inconvénients Proxy ARP R 1 répond aux requêtes ARP sur ses adresses NAT (138.76.29.8 et les autres) en plus de sa propre adresse (138.76.29.7). Ou : ajouter des entrées statiques dans la table ARP de R 2. Exemple : arp -s 138.76.29.8 @MAC R 1 ajouter une route statique pour chaque adresse NAT. Exemple : route add -host 138.76.29.8 netmask 255.255.255.255 gw 138.76.29.7 c A. ED-DBALI (Université d Orléans) Réseaux II 104 / 113

NAT Dynamique ou encore : IP masquerading Implémentation : le routeur NAT doit : Datagrammes sortants : remplacer (adresse IP, num. port) de tout datagramme sortant par (adresse IP NAT, nouv. num. de port)... les clients/serveurs distants répondront en utilisant (adresse IP NAT, le nouv. num. de port) comme adresse de destination Se rappeler (dans la table de traduction NAT ) toutes les paires de traduction (adresse IP source, num. port) vers (adresse IP NAT, nouv. num. port) Datagrammes entrants : remplacer (adresse NAT IP, nouv. num. port) dans les champs dest. de tous les datagrammes entrants, par (adresse IP source, num. port) correspondant (couples stockés dans la table NAT) c A. ED-DBALI (Université d Orléans) Réseaux II 105 / 113

NAT Dynamique 1 Le poste 10.0.0.1 envoie le datagramme à 128.119.40.186 sur le port 80 2 Le routeur NAT change l adresse du datagramme source de 10.0.0.1 (port 3345) à 138.76.29.7 (port 5001) et met à jour la table 3 La réponse arrive à l adresse dest. : 138.76.29.7 (port 5001) 4 Le routeur NAT traduit 138.76.29.7 (port 5001) en 10.0.0.1 (port 3345) c A. ED-DBALI (Université d Orléans) Réseaux II 106 / 113

NAT Dynamique suite Champ numéro de port 16-bit 60 000 connexions simultanées avec une seule adresse officielle! NAT controversé Les routeurs doivent travailler uniquement au niveau de la couche 3 Viole l argument bout-en-bout La possibilité NAT doit être prise en compte par les développeurs des applis. ex : applications P2P La pénurie des adresses doit être résolue grâce à l IPv6 c A. ED-DBALI (Université d Orléans) Réseaux II 107 / 113

Inconvénients du NAT dynamique Initialisation de l échange La machine peut reçevoir des datagrammes si c est elle qui débute l échange (NAT intercepte en sortie le datagramme pour le marquer et se rappeler de la source) Ne permet pas à un serveur d être accessible c A. ED-DBALI (Université d Orléans) Réseaux II 108 / 113

Inconvénients du NAT dynamique suite Problème de protocoles sans ports (ICMP) ICMP : protocole de la couche réseau (pas de port de la couche transport) Implémenter autrement le NAT dynamique Remplacer les ports TCP/UDP dans les traductions d adresses par l identifiant ICMP présent dans l en-tête du message Intervenir également sur le message pour la pertinence des erreurs véhiculées c A. ED-DBALI (Université d Orléans) Réseaux II 109 / 113

Inconvénients du NAT dynamique suite Problème FTP Deux connexions parallèles (contrôle + transfert effectif) Deux modes de fonctionnement : actif et passif Mode passif : les deux connexions initialisées de l intérieur Mode actif : la connexion de contrôle est initialisée de l intérieur (par le client) puis les connexions de transfert sont initialisées de l extérieur (par le serveur FTP) Solution : Proxy FTP c A. ED-DBALI (Université d Orléans) Réseaux II 110 / 113

NAT : dynamique ou statique? Les deux! Si on a à la fois : des serveurs qui doivent être visibles de l extérieur (initialisation de la communication depuis l extérieur) et d autres machines qui ne demandent qu à se connecter à Internet Economie des adresses pour les adresses NATées dynamiquement Service possible sur les adresses NATées statiquement c A. ED-DBALI (Université d Orléans) Réseaux II 111 / 113

Une seule adresse officielle! Que faire? Port Forwarding Rediriger le datagramme vers une machine précise en fonction du port destination du datagramme Le client C envoie sa requête FTP vers la seule adresse officielle 138.76.29.7 sur le port 21 Le routeur NAT R redirige automatiquement la requête au seul serveur FTP du réseau interne : 10.0.0.1 c A. ED-DBALI (Université d Orléans) Réseaux II 112 / 113