07-cours
7
pages
Français
Documents
Le téléchargement nécessite un accès à la bibliothèque YouScribe Tout savoir sur nos offres
7
pages
Français
Documents
Le téléchargement nécessite un accès à la bibliothèque YouScribe Tout savoir sur nos offres
RéseauxCouche RéseauE. JeandelRésumé des épisodes précédents– Couche réseau :– Transmission précise de données entre deux machines– Non fiableCouche transport– Transmission de données entre deuxprocessus– Fiable ou non1 MultiplexageProblématique– La couche réseau permet la transmission entre deux machines– Deux processus différents sur la machineA veulent parler à un deux processussur la machineB.– La couche réseau ne permet pas de les distinguerSolution– Ports– Adresses de transport– Sur16 bits.– Communication identifiée par un quadruplet(Adresse Réseau A, Port A, Adresse Réseau B, Port B)– Triplet du point de vue de chacun des participantsRécapitulatif– Si la machine A veut parler à la machineB sur le portb, elle doit d’abord choisirun porta– Comment NAT peut-il fonctionner ?– PAT (Port Address Translation)1UDP– Ajoute les ports à IP, et c’est tout– Encapsulé dans IP16 16 16 16Port Source Port Destination Longueur CRC DonnéesChecksum : parité sur 16 bits de UDP+un header IP2 TCPProblématique– UDP ne suffit pas– Aucune garantie que les paquets arrivent, ni qu’ils arrivent dans l’ordre– Besoin de transfert fiableTCP– Protocole connecté– A la création, on alloue des structures de chaque côté pour s’occuper spécifique-ment de la connexion– Fiable– Contrôle de la congestionL’unité de base en TCP s’appelle lesegment MSS : Max Segment Size2.1 FiabilitéTransfert fiable– TCP utilise une variante de GoBackN– Contrôle au niveau ...
Voir
RÉseaux Couche RÉseau E. Jeandel
RÉsumÉ des Épisodes prÉcÉdents – CoucherÉseau : – TransmissionprÉcise de donnÉes entre deux machines – Nonfiable
Couche transport – Transmissionde donnÉes entre deuxprocessus – Fiableou non
1 Multiplexage ProblÉmatique – Lacouche rÉseau permet la transmission entre deux machines – Deuxprocessus diffÉrents sur la machineAveulent parler À un deux processus sur la machineB. – Lacouche rÉseau ne permet pas de les distinguer
Solution –Ports –∼Adresses de transport – Sur16bits. – CommunicationidentifiÉe par un quadruplet (Adresse RÉseau A, Port A, Adresse RÉseau B, Port B) – Tripletdu point de vue de chacun des participants
RÉcapitulatif – Sila machine A veut parler À la machineBsur le portb, elle doit d’abord choisir un porta – CommentNAT peut-il fonctionner ? – PAT(Port Address Translation)
1
UDP – Ajouteles ports À IP, et c’est tout – EncapsulÉdans IP 16 1616 16 Port SourcePort DestinationLongueur CRC DonnÉes Checksum : paritÉ sur 16 bits de UDP+un header IP
2 TCP ProblÉmatique – UDPne suffit pas – Aucunegarantie que les paquets arrivent, ni qu’ils arrivent dans l’ordre – Besoinde transfert fiable
TCP – ProtocoleconnectÉ – Ala crÉation, on alloue des structures de chaque cÔtÉ pour s’occuper spÉcifique-ment de la connexion – Fiable – ContrÔlede la congestion L’unitÉ de base en TCP s’appelle lesegmentMSS : Max Segment Size
2.1 FiabilitÉ Transfert fiable – TCPutilise une variante de GoBackN – ContrÔleau niveau desbitset non pas des segments – ACKn: j’ai tout reÇu jusqu’aun-iÈme bit non compris – Pasde NACK
Transfert fiable – PremiernumÉro choisi alÉatoirement et envoyÉ au correspondant lors de l’Éta-blissement de la connexion – “empche”de hacker une connexion TCP – NumÉrossur 32 bits Optimisations – Optimisation:fast retransmitdensi 3 ACKn. – Piggybacking(Delayed ACK) – Attendre200ms avant de rÉenvoyer un ACK, au cas oÙ il y aurait une rÉponse sur laquelle on peut se greffer – Siun deuxiÈme paquet arrive, envoyer le ACK – EnrÉgime “permanent”, seulement un paquet sur deux sera acquittÉ
2
Timeout – Commentestimer le timeout avant de rÉenvoyer ? – Estimationdu temps AR (ERTT : estimated round-trip time) – ERT T:=αERT T+ (1−α)RT T – RTT: temps AR du dernier paquet acquittÉ –0.8≤α≤0.9 – Commentfixer le timer ?
T IM ER:=ERT T+ 4Deviation
Deviation:=αDeviation+ (1−α)|RT T−ERT T|
2.2 ContrÔlede flux ContrÔle de flux – Chacundes deux participants a un buffer de rÉception – PrÉvenirque le buffer est presque plein –BprÉvientAqu’il lui restepbits disponibles dans son buffer À chaque message qu’il envoie –Adoit s’arranger pour que DernierBitEnvoye−DernierBitAcquitte≤p
ProblÈme (v1) –Benvoie un message comme quoip= 0 – Quese passe-t-il ? – Solution:Aenvoie des paquets de1bit queBacquitte. –PersistenceTimer
ProblÈme (v2) –Best beaucoup plus lent queA – EnrÉgime “permanent”, chaque segment fera un seul octet –Silly Window Syndrome
Solution au SWS (CÔtÉ destinataire) – Attendrequepredevienne suffisament grand – Parexemple taille max d’un segment ou la moitiÉ de la taille totale – Quefaire en attendant ? – Nepas envoyer de ACK – Envoyerdes ACK avecp= 0
3
ProblÈme cÔtÉ Émetteur (v3 tinygram) Eviter les petits paquets niveau Émetteur (Algorithme de Nagle) – Sibeaucoup de donnÉes (plus que MSS), les envoyer – S’ily a des donnÉes non acquittÉes, attendre – Sinonenvoyer Attention – Peuttre indÉsirable (mouvement de la souris) – Conflitavec le Delayed ACK – Peuttre dÉsactivÉ (TCP_NODELAY)
Exemple – Lataille maximum d’un segment pour une pile rÉseau OSX est de 1448 octets. – A,sous OSX, envoie 100000 octets À B puis attend le OK de B – Battend les 100000 octets et envoie un OK À A. Questions : – SousOSX, le programme va considÉrablement plus vite pour envoyer 102000 octets que 100000. Pourquoi ? – SousWindows qui a un segment max de 1460 octets, le programme va plus vite que sous OSX pour 100000 octets, mais moins vite pour 102000. . .
2.3 QualitÉde service ProblÉmatique – ContrÔlerla congestion – Essentiellementau niveau des routeurs qu’on ne contrÔle pas – Quelquesinfos par ICMP (globales !), mais aussi dans TCP lui mme (par connexion)
Exemple –AetBreliÉs par un routeur au monde extÉrieur – Routeurparfait (buffers infinis, temps de traitement nul) – Cablesde dÉbitD – Comportementdu systÈme en fonction du dÉbit moyenddeAet deB?
Exemple – DÉbitsortant :min(d, D/2)par connexion – DÉlai(temps moyen avant rÉception) :∼1/(D−2d) – Dansla rÉalitÉ, gros dÉlai→rÉÉmission des paquets..
Exemple (v2) – Mmeexemple – RÉÉmissiondes paquets→delais encore plus grands – Nombrede paquets transfÉrÉs de plus en plus petit – Lerouteur surchargÉ l’est encore plus. . .
4
Congestion (ProblÈmes) DÈs que le dÉbit est trop ÉlevÉ – DÉlaisimportants – Retransmissionde segments dans la file d’attente d’un routeur – PaquetsdupliquÉs envoyÉs par le routeur – Lespaquets abandonnÉes par le routeur correspondent À du trafic gáchÉ
S’en occuper – Quidoit s’en occuper ? – CoucherÉseau (tous les participants, routeurs compris) – Couchetransport (uniquement les extrmitÉs) – ChoixTCP/IP : Dans la couche transport
S’en occuper Comment s’en occuper – PrÉvenirplutÔt que guÉrir – CommentcontrÔler le dÉbit dans TCP ? – Enchangeant la taille de la fentre. . .
Congestion dans TCP : AIMD (Additive Increase - Multiplicative Decrease) Point de vue : les pertes de paquets viennent uniquement des files d’attente dans les routeurs – Fentrede congestion de tailleF – Seuilλde congestion. – SiλF < – AudÉbut, taille de la fentre de 2 MSS (slow start) – Achaque ACK, on augmente de 1 MSS – Augmentationexponentielle – SiF≥λ – Augmentationde 1MSS tous lesFACK – AugmentationlinÉaire – Siperte de paquet (timeout) : –λ=F /2 – Lafentre passe À 1 MSS
ConsÉquences ConsÉquence pour l’utilisateur – Acause duslow start, il vaut mieux une connexion pour transfÉrer deux fichiers que deux connexions consÉcutives. – Sansoublier les coÛts de connexion. . . – Exemple: HTTP – Keep-Alive – Pipelining
5
Routeurs –nmachines derriÈre un routeur – StratÉgiedu routeur : supprimer les nouveaux paquets quand la file est pleine – ProblÈme: quand la file d’attente est pleine,toutesles connexions vont tre per-tubÉes et redÉmarrer
RED (Random Early Detection/Drop/Discard) – Filed’attente du routeur sÉparÉe en deux “moitiÉs” – Onremplit la premiÈre partie – Sila premiÈre partie est pleine, on accepte dans la file d’attente un nouveau paquet IP qu’avec probabilitÉp – Bienchoisirp
2.4 Connexion 2.4.1 CrÉation ProblÉmatique – DÉbuteret terminer la connexion – DifficultÉen gÉnÉral, dans un modÈle asynchrone avec pertes, de se synchroniser – ProblÈmedes gÉnÉraux byzantins
CrÉation de la connexion – VÉrifierque les deux parties veulent communiquer – Allouerles buffers et autres structures – Semettre d’accord sur les numÉros de sÉquence
CrÉation de la connexion – PaquetSY Nx: je commence À numÉroter Àx MÉthode informelle SY Nx A−−−−→B ACK x+1 A←−−−−−−B SY Ny A←−−−−B ACK y+1 A−−−−−−→B DAT Ax+1 A−−−−−−−→B DAT Ax+2 A−−−−−−−→B DAT Ax+3 A−−−−−−−→B DAT Ax+4 A−−−−−−−→B
6
CrÉation de la connexion On peut faire SYN+ACK en mme temps. SY Nx A−−−−→B SY Ny,ACK x+1 A←−−−−−−−−−−−B ACK y+1 A−−−−−−→B Three-way handshake. – EnpratiqueApeut envoyer des donnÉes dans le troisiÈme paquet.
CrÉation simultanÉe SY Nx A−−−−→B SY Ny A←−−−−B SY Nx,ACK y+1 A−−−−−−−−−−−→B SY Ny,ACK x+1 A←−−−−−−−−−−−B Ne marche pas en pratique..
2.4.2 Fermeture Fermeture de la connexion – PrÉvenirqu’on a plus rien À envoyer – LibÉrerles ressources allouÉes – Attention,l’autre partenaire peut avoir quelque chose À envoyer
Fermeture
F IN A−−−→B ACK A←−−−B F IN A←−−−B ACK A−−−→B – Lesdeux segments envoyÉs parBne peuvent pas toujours tre confondus – Timeoutpour Éviter les problÈmes.
7
