INF4032 Réseaux Informatiques 2024-2025 PDF

Summary

Ce document présente un aperçu des réseaux informatiques. Il couvre les concepts fondamentaux tels que les couches de transport TCP/UDP, les protocoles d'application HTTP et DNS, ainsi que la programmations des réseaux et le routage dynamique et IPv6.

Full Transcript

INF4032 Réseaux Informatiques Bassem Haidar 2024-2025 INF4032 Réseaux Informatiques Introduction rappel, couche transport TCP/UDP, NAT. Couche Application HTTP, DNS. Programmation réseaux Routage dynamique, IPv6 B. HAIDAR –...

INF4032 Réseaux Informatiques Bassem Haidar 2024-2025 INF4032 Réseaux Informatiques Introduction rappel, couche transport TCP/UDP, NAT. Couche Application HTTP, DNS. Programmation réseaux Routage dynamique, IPv6 B. HAIDAR – INF4032 2 Introduction Rappel TCP - IP Chapter 01 - Part II Couche de Transport B. HAIDAR – INF4032 4 Services et protocoles de transport applicatio n fournir une communication transport network data link logique entre les processus physical d'application s'exécutant sur différents hôtes protocoles de transport exécutés dans les systèmes d'extrémité – côté envoi : divise les messages de l'application en segments, passe à la couche réseau – côté rcv : réassemble les applicatio segments en messages, passe à n la couche d'application transport network plusieurs protocoles de transport data link physical disponibles pour les applications – Internet : TCP et UDP B. HAIDAR – INF4032 5 Transport vs. network layer couche réseau : analogie : communication logique entre 12 enfants dans la maison d'Ann envoyant des lettres à 12 enfants les hôtes dans la maison de Bill : Couche de transport : la hôtes = maisons communication logique entre processus = enfants les processus messages d'application = lettres dans des enveloppes – repose sur des services de protocole de transport = Ann et couche réseau améliorés Bill qui démultiplexent leurs frères et sœurs en interne protocole de couche réseau = service postal B. HAIDAR – INF4032 6 Internet transport-layer protocols applicatio n livraison fiable et en ordre transport network data link (TCP) physical network network data link data link physical contrôle de la congestion physical network data link – contrôle de flux physical – configuration de la connexion network data link livraison non fiable et non physical network data link commandée : UDP network physical – « au mieux », Best-effort data link physical applicatio n network services non disponibles : data link physical transport network data link – garanties de retard physical – garanties de bande passante B. HAIDAR – INF4032 7 Comment fonctionne le démultiplexage l'hôte reçoit des datagrammes IP 32 bits – chaque datagramme a une source port # dest port # adresse IP source, une adresse IP de destination other header fields – chaque datagramme transporte un segment de couche transport – chaque segment a une source, application un numéro de port de data destination (payload) l'hôte utilise des adresses IP et des numéros de port pour diriger le segment vers le socket approprié TCP/UDP segment format B. HAIDAR – INF4032 8 UDP : en-tête de segment length, in bytes of Why is there a UDP? UDP segment, including header – no connection establishment (which can add delay) 32 bits – simple: no connection state at sender, receiver source port # dest port # – small header size length checksum – no congestion control: UDP can blast away as fast as desired application data (payload) B. HAIDAR – INF4032 UDP segment format 9 TCP: Overview RFCs: 793,1122,1323, 2018, 2581 données en duplex intégral : point à point: – flux de données bidirectionnel dans la même connexion – un expéditeur, un destinataire – MSS : taille maximale des flux d'octets fiable et segments Connexion orientée: ordonnée : – établissement de liaison – pas de « limites de message » (échange de msgs de contrôle) en pipeline : dans son état émetteur, récepteur avant l'échange de – contrôle de congestion et de données flux - taille de la fenêtre débit contrôlé, control de flux : – l'expéditeur ne submergera pas le destinataire B. HAIDAR – INF4032 10 Structure des segments TCP 32 bits URG: urgent data counting (generally not used) source port # dest port # by bytes sequence number of data ACK: ACK # valid acknowledgement number (not segments!) head not PSH: push data now len used UAP R S F receive window (generally not used) # bytes checksum Urg data pointer rcvr willing RST, SYN, FIN: to accept options (variable length) connection estab (setup, teardown commands) application Internet data checksum (variable length) (as in UDP) B. HAIDAR – INF4032 11 TCP seq. numbers, ACKs outgoing segment from sender Numéros de séquence : source port # dest port # sequence number – flux d'octets « nombre » du acknowledgement premier octet dans les données number rwnd checksum urg pointer du segment window size Acquittements : N – seq # du prochain octet attendu de l'autre côté sender sequence number space – ACK cumulé Q : comment le récepteur gère sent ACKed sent, not- usable not yet ACKed but not usable les segments dans le désordre (“in- yet sent flight”) – A: la spécification TCP ne dit incoming segment to sender pas, laisser a l'implémentation source port # dest port # sequence number acknowledgement number A rwnd B. HAIDAR – INF4032 checksum urg pointer 12 TCP seq. numbers, ACKs Host A Host B User types ‘C’ Seq=42, ACK=79, data = ‘C’ host ACKs receipt of ‘C’, echoes Seq=79, ACK=43, data = ‘C’ back ‘C’ host ACKs receipt of echoed ‘C’ Seq=43, ACK=80 simple telnet scenario B. HAIDAR – INF4032 13 Accepter d'établir une connexion TCP 3-way handshake client state server state LISTEN LISTEN choose init seq num, x send TCP SYN msg SYNSENT SYNbit=1, Seq=x choose init seq num, y send TCP SYNACK msg, acking SYN SYN RCVD SYNbit=1, Seq=y ACKbit=1; ACKnum=x+1 received SYNACK(x) ESTA indicates server is live; send ACK for SYNACK; B this segment may contain ACKbit=1, ACKnum=y+1 client-to-server data received ACK(y) indicates client is live ESTA B B. HAIDAR – INF4032 14 TCP : fermeture d'une connexion le client, le serveur ferment chacun leur côté de connexion – envoyer le segment TCP avec le bit FIN = 1 répondre à FIN reçu avec ACK – à la réception de FIN, ACK peut être combiné avec son propre FIN les échanges FIN simultanés peuvent être gérés B. HAIDAR – INF4032 15 TCP : fermeture d'une connexion client state server state ESTA ESTA B clientSocket.close() B FIN_WAIT_1 can no longer FINbit=1, seq=x send but can receive data CLOSE_WAIT ACKbit=1; ACKnum=x+1 can still FIN_WAIT_2 wait for server send data close LAST_ACK FINbit=1, seq=y TIMED_WAIT can no longer send data ACKbit=1; ACKnum=y+1 timed wait for 2*max CLOSED segment lifetime CLOSED B. HAIDAR – INF4032 16 B. HAIDAR – INF4032 17 Contrôle de flux TCP application l'application peut process supprimer des données de application Tampons de socket TCP …. socket TCP OS tampons récepteurs … plus lent que TCP le récepteur livre (l'expéditeur envoie) TCP code IP contrôle de flux code le récepteur contrôle l'expéditeur, afin que l'expéditeur ne déborde pas la mémoire tampon du destinataire en transmettant de l'expéditeur trop, trop vite B. HAIDAR – INF4032 receiver protocol stack 18 Contrôle de flux TCP to application process le récepteur "annonce" l'espace tampon libre en incluant la valeur rwnd dans l'en-tête TCP des RcvBuffer buffered data segments récepteur-expéditeur – Taille de RcvBuffer définie via les rwnd free buffer space options de socket (la valeur par défaut typique est de 4096 octets) – de nombreux systèmes d'exploitation ajustent automatiquement RcvBuffer TCP segment payloads l'expéditeur limite la quantité de receiver-side buffering données non acquittées (« en vol ») à la valeur rwnd du destinataire garantit que le tampon de réception receive window flow control: # bytes receiver willing to accept ne débordera pas B. HAIDAR – INF4032 19 TCP Flow Control – In practice Host A is sending a large Host A Host B Host B allocates a receive file to Host B over a TCP buffer to this connection (of connection size RcvBuffer) From time to time, the LastByteSent application process in B LastByteAcked reads from the buffer LastByteRead: # of the last byte read from the buffer by the application 𝐿𝑎𝑠𝑡𝐵𝑦𝑡𝑒𝑆𝑒𝑛𝑡 – 𝐿𝑎𝑠𝑡𝐵𝑦𝑡𝑒𝐴𝑐𝑘𝑒𝑑 ≤ 𝑟𝑤𝑛𝑑 process in B LastByteRcvd: # of the last byte arrived from the network and placed in receive buffer at B INF4032 20 Principes du contrôle de la congestion Congestion: de manière informelle : « trop de sources envoient trop de données trop rapidement pour que le réseau puisse les gérer » différent du contrôle de flux ! manifestation : – paquets perdus (débordement de tampon au niveau des routeurs) – longs délais (mise en file d'attente dans les tampons du routeur) un problème parmi les 10 premiers ! B. HAIDAR – INF4032 21 Contrôle de congestion TCP : augmentation additive, diminution multiplicative. ▪ approach: l'expéditeur augmente le taux de transmission (taille de la fenêtre), en recherchant la largeur de bande disponible, jusqu'à ce qu'une perte se produise. augmentation additive : augmentation du cwnd de 1 MSS à chaque RTT jusqu'à ce que la perte soit détectée. diminution multiplicative : réduction de moitié de la bande après une perte. additively increase window size … congestion window size …. until loss occurs (then cut window in half) cwnd: TCP sender AIMD saw tooth behavior: probing for bandwidth time Contrôle de congestion TCP Host A RTT Host B time NAT: Network address translation NAT: network address translation rest of local network Internet (e.g., home network) 10.0.0/24 10.0.0.1 10.0.0.4 10.0.0.2 138.76.29.7 10.0.0.3 ▪Tous les datagrammes Datagrammes avec la source ou la quittant le réseau local ont destination dans ce réseau ayant l'adresse la même et unique adresse 10.0.0.0/24 pour la source IP source NAT:138.76.29.7 destination (comme d'habitude) ▪ numéros de ports sources différents Network Layer: Data Plane 4-25 Plages d'adresses privées The private address blocks are: –10.0.0.0 to 10.255.255.255 (10.0.0.0 /8) –172.16.0.0 to 172.31.255.255 (172.16.0.0 /12) –192.168.0.0 to 192.168.255.255 (192.168.0.0 /16 NAT: network address translation Motivation : le réseau local utilise juste un adresse IP quand il communique avec l'extérieur : – pas besoin de demander au FAI tout un intervalle d'adresses officielles : une adresse IP est utilisée pour tous les périphériques – 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, «invisible» de l'extérieur (un plus de sécurité). 27 NAT: network address translation 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 pairs 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) 28 NAT: network address translation NAT translation table 1: host 10.0.0.1 2: le routeur NAT WAN side addr LAN side addr change l'adresse du envoi le datagramme à datagramme source 138.76.29.7, 5001 10.0.0.1, 3345 128.119.40.186, 80 de10.0.0.1, 3345 to …… …… 138.76.29.7, 5001, mets à jour la table S: 10.0.0.1, 3345 D: 128.119.40.186, 80 10.0.0.1 1 S: 138.76.29.7, 5001 2 D: 128.119.40.186, 80 10.0.0.4 10.0.0.2 138.76.29.7 S: 128.119.40.186, 80 D: 10.0.0.1, 3345 4 S: 128.119.40.186, 80 D: 138.76.29.7, 5001 3 10.0.0.3 4: le routeur NAT 3: la réponse arrive change l'adresse dest. à l'adresse dest: du datagramme 138.76.29.7, 5001 138.76.29.7, 5001 to 10.0.0.1, 3345 * Check out the online interactive exercises for more examples: http://gaia.cs.umass.edu/kurose_ross/interactive/ 29 NAT: network address translation 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 end-to-end 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 30 Références Computer Networking: A Top-Down Approach, 7th Edition, James F. Kurose, University of Massachusetts, Amherst Keith Ross Data Communications and Networking, 5th Edition, By Behrouz A. Forouzan Cisco Networking Academy Program, Introduction to Networks v7.0 (ITN) B. HAIDAR – INF4032 31

Use Quizgecko on...
Browser
Browser