Principes du transfert fiable de données. Les réseaux - deuxième partie. Transfert fiable de données fonctionnement

Transcription

1 Principes du transfert fiable de données Les réseaux - deuxième partie Chapitre 1 : Protocoles Concept faisant partie du top-10 des concepts importants des réseaux! AbdelAli.ED-DBALI@univ-orleans.fr Département d Informatique - LIFO Université d Orléans Les caractéristiques des canaux non fiables détermine 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 1 / 110 c A. ED-DBALI (Université d Orléans) Réseaux II 2 / 110 Transfert fiable de données fonctionnement 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 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 3 / 110 c A. ED-DBALI (Université d Orléans) Réseaux II 4 / 110

2 rdt1.0 : transfert fiable sur un canal fiable rdt2.0 : canal avec erreurs (et sans perte) 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 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 5 / 110 c A. ED-DBALI (Université d Orléans) Réseaux II 6 / 110 rdt2.0 : spécification de l AEF rdt2.0 a un défaut néfaste! émetteur récepteur 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 7 / 110 c A. ED-DBALI (Université d Orléans) Réseaux II 8 / 110

3 rdt2.1 : l émetteur gère les ACK/NAKs altérés rdt2.1 : le récepteur gère les ACK/NAKs altérés c A. ED-DBALI (Université d Orléans) Réseaux II 9 / 110 c A. ED-DBALI (Université d Orléans) Réseaux II 10 / 110 rdt2.1 : discussion rdt2.2 : un protocole sans NAK é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 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 11 / 110 c A. ED-DBALI (Université d Orléans) Réseaux II 12 / 110

4 rdt2.2 : l émetteur rdt2.2 : le récepteur c A. ED-DBALI (Université d Orléans) Réseaux II 13 / 110 c A. ED-DBALI (Université d Orléans) Réseaux II 14 / 110 rdt3.0 : canal avec erreurs et pertes rdt3.0 : l émetteur 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 15 / 110 c A. ED-DBALI (Université d Orléans) Réseaux II 16 / 110

5 rdt3.0 en action rdt3.0 en action Echange sans perte Perte d un paquet Perte d acquittement timeout prématuré c A. ED-DBALI (Université d Orléans) Réseaux II 17 / 110 c A. ED-DBALI (Université d Orléans) Réseaux II 18 / 110 Performance de rdt3.0 rdt3.0 : stop-and-wait en action 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 = = ko toutes les 30 ms 33ko/s à transmettre via le lien 1Gbps les protocoles réseau limitent l utilisation des ressources physiques! Uémetteur = L/R RTT + L/R = = c A. ED-DBALI (Université d Orléans) Réseaux II 19 / 110 c A. ED-DBALI (Université d Orléans) Réseaux II 20 / 110

6 Protocoles pipelinés Pipelining : accroît le taux d utilisation 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 21 / 110 Uémetteur = 3 L/R RTT + L/R = = Améliore le taux d utilisation par un facteur de 3! c A. ED-DBALI (Université d Orléans) Réseaux II 22 / 110 Go-Back-N : protocole à fenêtre d émission GBN : ADF étendu de l émetteur É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 23 / 110 c A. ED-DBALI (Université d Orléans) Réseaux II 24 / 110

7 GBN : ADF étendu du récepteur GBN en action 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 25 / 110 c A. ED-DBALI (Université d Orléans) Réseaux II 26 / 110 Répétition sélective (Selective Repeat) Répétition sélective : fenêtres émetteur/récepteur 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 27 / 110 c A. ED-DBALI (Université d Orléans) Réseaux II 28 / 110

8 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é 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 29 / 110 c A. ED-DBALI (Université d Orléans) Réseaux II 30 / 110 Répétition sélective 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 31 / 110 c A. ED-DBALI (Université d Orléans) Réseaux II 32 / 110

9 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 TCP : Vue d ensemble 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 33 / 110 c A. ED-DBALI (Université d Orléans) Réseaux II 34 / 110 TCP structure segment 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 35 / 110 c A. ED-DBALI (Université d Orléans) Réseaux II 36 / 110

10 TCP : Round Trip Time et Timeout 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 RTTestimé = (1 α) RTTestimé + α EchantillonRTT l influence des échantillons passés décroît exponentiellement valeur typique pour α : c A. ED-DBALI (Université d Orléans) Réseaux II 37 / 110 c A. ED-DBALI (Université d Orléans) Réseaux II 38 / 110 RTT : exemple d estimation 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 39 / 110 c A. ED-DBALI (Université d Orléans) Réseaux II 40 / 110

11 TCP : transfert fiable de données TCP : événements de l émetteur 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 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 41 / 110 c A. ED-DBALI (Université d Orléans) Réseaux II 42 / 110 Émetteur TCP simplifié TCP : scénarios de retransmission Scénario perte ACK 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 43 / 110 c A. ED-DBALI (Université d Orléans) Réseaux II 44 / 110

12 TCP : scénarios de retransmission Scénario timeout prématuré TCP : scénarios de retransmission Scénario ACK cumulatif c A. ED-DBALI (Université d Orléans) Réseaux II 45 / 110 c A. ED-DBALI (Université d Orléans) Réseaux II 46 / 110 TCP : génération de ACK RFC 1122, RFC 2581 Retransmission Rapide 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 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 47 / 110 c A. ED-DBALI (Université d Orléans) Réseaux II 48 / 110

13 Algorithme de retransmission rapide 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 é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 49 / 110 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 50 / 110 Contrôle de flux : comment ça marche? TCP : Gestion de la connexion 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 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 51 / 110 c A. ED-DBALI (Université d Orléans) Réseaux II 52 / 110

14 Connexion en trois étapes TCP : Gestion de connexion 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 53 / 110 c A. ED-DBALI (Université d Orléans) Réseaux II 54 / 110 TCP : Gestion de connexion TCP : Gestion de connexion 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 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 55 / 110 c A. ED-DBALI (Université d Orléans) Réseaux II 56 / 110

15 TCP : Gestion de connexion Cycle de vie du client TCP TCP : Gestion de connexion Cycle de vie du serveur TCP c A. ED-DBALI (Université d Orléans) Réseaux II 57 / 110 c A. ED-DBALI (Université d Orléans) Réseaux II 58 / 110 Principes du contrôle de congestion Approches autour 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! 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 59 / 110 c A. ED-DBALI (Université d Orléans) Réseaux II 60 / 110

16 Étude de cas Contrôle de congestion dans ATM (Asynchronous Transfer Mode) ABR Étude de cas Contrôle de congestion dans ATM 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 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 61 / 110 c A. ED-DBALI (Université d Orléans) Réseaux II 62 / 110 Étude de cas Contrôle de congestion dans ATM ABR Contrôle de congestion dans TCP Contrôle end-end (pas d assistance réseau) L émetteur limite la transmission : DernierOctetEnvoyé DernierOctetAck CongWin 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 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 63 / 110 c A. ED-DBALI (Université d Orléans) Réseaux II 64 / 110

17 Contrôle de congestion dans TCP 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 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 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 65 / 110 c A. ED-DBALI (Université d Orléans) Réseaux II 66 / 110 TCP : Démarrage lent 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 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 67 / 110 c A. ED-DBALI (Université d Orléans) Réseaux II 68 / 110

18 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 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 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 69 / 110 c A. ED-DBALI (Université d Orléans) Réseaux II 70 / 110 TCP : Contrôle de congestion résumé DHCP Dynamic Host Configuration Protocol - RFC 2131 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. 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 71 / 110 c A. ED-DBALI (Université d Orléans) Réseaux II 72 / 110

19 DHCP - Architecture DHCP - Mécanismes d allocation d adresses Trois mécanismes d allocation L allocation automatique DHCP assigne une adresse IP permanente à un client 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 73 / 110 c A. ED-DBALI (Université d Orléans) Réseaux II 74 / 110 Allocation dynamique Allocation manuelle Les avantages 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. 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 75 / 110 c A. ED-DBALI (Université d Orléans) Réseaux II 76 / 110

20 Paramètres de configuration Exigeances 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 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 77 / 110 c A. ED-DBALI (Université d Orléans) Réseaux II 78 / 110 Objectifs DHCP - vue d ensemble 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 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 79 / 110 c A. ED-DBALI (Université d Orléans) Réseaux II 80 / 110

21 Format des messages DHCP - Sénario de configuration c A. ED-DBALI (Université d Orléans) Réseaux II 81 / 110 c A. ED-DBALI (Université d Orléans) Réseaux II 82 / 110 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) 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 83 / 110 c A. ED-DBALI (Université d Orléans) Réseaux II 84 / 110

22 Expiration du bail et réacquisition Configuration du client Etablissement 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) 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 85 / 110 c A. ED-DBALI (Université d Orléans) Réseaux II 86 / 110 Configuration du client Consultation Capture trame DHCP Discover Sous Linux : fichier /var/lib/dhcp/dhclient.leases lease { interface "eth0" ; fixed-address ; option subnet-mask ; option dhcp-lease-time ; option routers ; option dhcp-message-type 5 ; option dhcp-server-identifier ; option domain-name-servers , ; option domain-name "free.fr" ; renew /2/2 08 :02 :16 ; rebind /2/7 04 :40 :44 ; expire /2/8 10 :40 :44 ; } Sous windows : commande ipconfig /all 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: , Dst Addr: 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: 0x e... c A. ED-DBALI (Université d Orléans) Réseaux II 87 / 110 c A. ED-DBALI (Université d Orléans) Réseaux II 88 / 110