Chapitre 2 - Couche Application

Chapitre 2 Protocoles de la couche Application Programmation et Réseautique en génie logiciel (GTI/LOG100 )  Le contenu de cette présentation est basé sur le livre de Kurose et Ross et de la documentation y jointe : Computer Networking: A Top Down Approach, 6ème édition. Jim Kurose, Keith...

Chapitre 2 Protocoles de la couche Application Programmation et Réseautique en génie logiciel (GTI/LOG100 )  Le contenu de cette présentation est basé sur le livre de Kurose et Ross et de la documentation y jointe : Computer Networking: A Top Down Approach, 6ème édition. Jim Kurose, Keith Ross Addison-Wesley, Mars 2012, ISBN-13: 978-0132856201 Chapitre 2: la couche application Nos objectifs:  Comprendre le fonctionnement des protocoles les plus connus de la couche application  HTTP  FTP  SMTP / POP3 / IMAP  DNS  Conception et implémentation des protocoles des apps réseaux  Modèles de services de la couche transport  Le paradigme client-serveur  Le paradigme pair-à-pair (P2P) 2: la couche application 2 Chapitre 2: la couche application 1. Principes des apps réseaux 1. Architectures des apps 2. Interfaces de connexion (Socket) 3. Exigences des apps en termes de performance et de fiabilité 2. Web et HTTP 3. Protocole de transfert de fichier (FTP) 4. Courrier électronique (SMTP, POP3, IMAP) 5. Serveur de noms DNS 2: la couche application 3 Chapitre 2: la couche application 1. Principes des apps réseaux 1. Architectures des apps 2. Interfaces de connexion (Socket) 3. Exigences des apps en termes de performance et de fiabilité 2. Web et HTTP 3. Protocole de transfert de fichier (FTP) 4. Courrier électronique (SMTP, POP3, IMAP) 5. Serveur de noms DNS 2: la couche application 4 Quelques apps réseaux  e-mail  Voix sur IP (par ex.,  web skype)  messagerie instantanée  Réseaux sociaux  Accès à distance  …  Partage de fichiers P2P  …  Jeux multi-utilisateurs  …  Diffusion de vidéo clips (YouTube, Netflix) 2: la couche application 5 Créer une app réseau application transport réseau liaison physique Écrire des programmes qui  Roulent (run) sur des hôtes différents  communiquent à travers le réseau  Par exemple, un serveur web communique avec le fureteur Pas de besoin d’écrire du code pour les équipements du cœur du application transport réseau réseau liaison application  Les équipements du cœur de physique transport réseau réseau n’exécutent pas les liaison applications des utilisateurs physique  L’exécution des apps sur les hôte seulement facilite leur développement et accélère leur adoption 2: la couche application 6 Architectures des apps  Client-serveur  pair-à-pair (peer-to-peer - P2P) 2: la couche application 7  Architecture client-serveur serveur:  Hôte toujours actif  Adresse IP permanente  Centres de données pour la mise à l’échelle clients:  Communiquent avec le serveur client/serveur  Connectés d’une manière intermittente  Peuvent avoir des adresses IP dynamiques  Ne communiquent pas directement entre eux 2: la couche application 8 Architecture P2P pure peer-peer  Il n’y a pas de serveur qui est toujours actif  Les hôtes communiquent directement d’une façon arbitraire  Les hôtes “peers” demandent des services de la part des autres hôtes “peers”  Les hôtes sont connectés d’une manière intermittente et changent d’adresses IP Hautement extensible mais difficile à gérer 2: la couche application 9 Chapitre 2: la couche applications 1. Principes des apps réseaux 1. Architectures des apps 2. Interfaces de connexion (Socket) 3. Exigences des apps en termes de performance et de fiabilité 2. Web et HTTP 3. Protocole de transfert de fichier (FTP) 4. Courrier électronique (SMTP, POP3, IMAP) 5. Serveur de noms DNS 2: la couche application 10 Communication entre processus Processus: un programme Processus client: exécuté sur un hôte. processus qui initie la  Dans le même hôte, deux communication processus communiquent Processus serveur: avec communication interprocessus (définie par processus qui attend le système d’exploitation). d’être contacté  Processus dans différents hôtes communiquent en  Note : les applications avec échangeant des messages une architecture P2P ont des processus client et serveur 2: la couche application 11  Interface de connexion (Sockets)  Processus émet/reçoit des messages à travers son socket  Socket analogue à une porte  Processus d’émission met les messages à l’extérieur  Processus d’émission compte sur l’infrastructure transport de l’autre côté de la porte pour transférer les messages à la porte du côté réception Controlé par le programmeur application application socket de l’application processus processus Controlé par transport transport le système réseau réseau d’exploitation liaison Internet liaison physique physique 2: la couche application 12 Donner une adresse à un processus  Pour recevoir des messages,  L’identifiant comprend le processus doit avoir un l’adresse IP et le numéro de identifiant port associé au processus.  L’équipement hôte a une  Exemples de numéros de port: adresse IP unique 32-bit  serveur HTTP : 80  Q: est ce que l’adresse IP  serveur courriel SMTP: 25 suffit pour identifier le  Pour émettre des messages processus? HTTP au serveur  A: Non, plusieurs www.etsmtl.ca: processus peuvent rouler  Adresse IP: 142.137.250.114 sur le même hôte  Numéro de port: 80  Une connexion est définie par : adresses IP source et destination + numéros de port source et destination + protocole de transport (TCP ou UDP) 2: la couche application 13 Le protocole d’application définit  Le type des messages Protocoles ouverts: échangés,  définis dans des RFCs  Par ex., requête, réponse  Permettent l’interopérabilité  Le syntaxe du message :  Par ex., HTTP, SMTP  Quels sont les champs Protocoles Propriétaires: contenus dans le message & comment ils sont délimités  Par ex., Skype  La sémantique du message  Sens de l’information contenu dans les champs  Règles pour déterminer quand et comment les processus échangent des messages 2: la couche application 14 Chapitre 2: la couche applications 1. Principes des apps réseaux 1. Architectures des apps 2. Interfaces de connexion (Socket) 3. Exigences des apps en termes de performance et de fiabilité 2. Web et HTTP 3. Protocole de transfert de fichier (FTP) 4. Courrier électronique (SMTP, POP3, IMAP) 5. Serveur de noms DNS 2: la couche application 15  Quels sont les services de transport dont une app a besoin? Intégrité de données Débit  Il y a des applications exigeant  quelques apps (e.g., multimédia) une transmission fiable à 100% exigent un débit moyen pour  par ex., transfert de fichier être “effectives”  D’autres peuvent tolérer une  d’autres (“apps élastiques”) certaine perte utilisent le débit existant  par ex., audio Sécurité Timing  Encryptage, intégrité des  quelques apps exigent un données, … faible délai pour être efficaces  par ex., téléphonie Internet, jeux interactifs 2: la couche application 16  Les demandes en service transport pour des apps typiques Sensibilité au Application Perte débit temps transfert de fichier pas de perte élastique non e-mail pas de perte élastique non documents Web pas de perte élastique non audio/vidéo temps réel tolérant audio: 5kbps-1Mbps oui, 100’s msec vidéo:10kbps-5Mbps audio/vidéo stockés tolérant pareil oui, qq secs Jeux interactifs tolérant qq kbps oui, 100’s msec messagerie instantanée pas de perte élastique oui et non 2: la couche application 17 Les services des protocoles de transport de l’Internet service TCP : service UDP :  Un transfert de données  transport fiable : entre les processus client et serveur non fiable entre les processus client et  Contrôle du flux : l’émetteur serveur ne submergera pas le  Pas de: établissement de récepteur connexion, fiabilité,  Contrôle de congestion : contrôle de flux, contrôle réduire le débit de de congestion, transmission quand le synchronisation, débit réseau est surchargé minimal, ou sécurité  Ne fournit pas de : timing, garantie de débit minimal, Q: Pourquoi il y a UDP? sécurité  Orienté connexion : création d’une connexion entre les processus client et serveur 2: la couche application 18  apps Internet: application, protocoles de transport Protocole Protocole de Application d’application transport courriel SMTP [RFC 2821] TCP Accès terminal à distance Telnet [RFC 854] TCP Web HTTP [RFC 2616] TCP Transfert de fichiers FTP [RFC 959] TCP streaming multimédia HTTP (par ex., Youtube), TCP ou UDP RTP [RFC 1889] téléphonie Internet SIP, RTP, propriétaire (par ex., Skype) TCP ou UDP 2: la couche application 19 Chapitre 2: la couche applications 1. Principes des apps réseaux 1. Architectures des apps 2. Interfaces de connexion (Socket) 3. Exigences des apps en termes de performance et de fiabilité 2. Web et HTTP 3. Protocole de transfert de fichier (FTP) 4. Courrier électronique (SMTP, POP3, IMAP) 5. Serveur de noms DNS 2: la couche application 20  Web et HTTP Un peu de jargon  Une page Web contient des objets  Un objet peut être un fichier HTML, une image JPEG, une applet Java, un fichier audio,…  Une page web contient un fichier de base sous format HTML qui contient des références à des objets  Chaque objet a une adresse URL (Unique Resource Locator)  Exemple URL: www.someschool.edu/someDept/pic.gif Nom de l’hôte Nom du chemin 21 HTML: Hypertext Markup Language HTTP en bref HTTP : hypertext transfer protocol  Protocole de la couche application pour le Web  client/serveur utilisant HTTP :  Le client: fureteur qui PC exécutant le fureteur Firefox envoie des requêtes, reçoit les objets Web et les affiche  Le serveur: le serveur Web serveur envoie les objets Web hébergeant comme une réponse à une un serveur Web Apache requête iphone exécutant le fureteur Safari 2: la couche application 22 HTTP en bref utilise TCP: HTTP est “sans état”  Le client initie la connexion  Le serveur ne garde TCP (crée une socket) au aucune information sur les serveur, port 80 requêtes précédentes  Le serveur accepte la connexion TCP du client Les protocoles qui conservent  Les messages HTTP “l’état” sont complexes! échangés entre le fureteur  L’historique (état) doit (client HTTP) et le serveur être conservé web (serveur HTTP)  si un serveur/client tombe  Fermeture de la connexion en panne, leurs perceptions TCP de l“état” peuvent être inconsistantes et doivent être récupérées 2: la couche application 23  Connexions HTTP HTTP non persistant HTTP persistant  Un seul objet est envoyé  Plusieurs objets peuvent sur une connexion TCP. être envoyés sur une seule  Une connexion TCP pour connexion TCP entre le chaque objet client et le serveur. 2: la couche application 24  HTTP non persistant Supposons l’utilisateur demande la page Web suivante qui contient des références à 10 images jpeg : www.someSchool.edu/someDepartment/home.html 1a. Le client HTTP initie une connexion TCP vers le serveur HTTP (processus) à 1b. Le serveur HTTP à l’hôte www.someSchool.edu attend www.someSchool.edu on port 80 une connexion TCP au port 80. “accepte” la connexion, avise le client 2. Le client HTTP envoie un message de requête HTTP (contenant l’URL) dans une 3. Le serveur HTTP reçoit la socket de connexion TCP. requête, construit un message Le message indique que le de réponse contenant l’objet client veut l’objet demandé, et envoie le message someDepartment/home.html vers son socket temps 2: la couche application 25  HTTP non persistant (suite) 4. Le serveur HTTP ferme la connexion TCP. 5. Le client HTTP reçoit la réponse avec le fichier html, affiche html. Il Parcourt le fichier html, trouve 10 objets jpeg référencés temps 6. étapes 1-5 se répètent pour chacun des 10 objets jpeg 2: la couche application 26 HTTP non-persistant temps de réponse Définition du RTT (Round Trip Time): le temps nécessaire pour un petit paquet de faire un aller- retour entre le client et le Initier une serveur. connexion TCP temps de réponse : RTT  un RTT pour initier la Envoie de la requête connexion TCP du fichier  un RTT pour la requête HTTP RTT Temps de Transmission et les premiers octets de la fichier réponse HTTP reçu  Temps de transmission du fichier temps temps total = 2RTT+temps de transmission 2: la couche application 27 HTTP persistant Problèmes de HTTP Non- HTTP persistant persistant :  Le serveur laisse la  demande 2 RTTs par objet connexion ouverte après  Surchage le système l’envoie d’une réponse d’exploitation pour chaque  Les messages HTTP connexion TCP subséquents entre les  Les fureteurs souvent mêmes client/serveur sont ouvrent plusieurs connexions envoyés sur la même TCP en parallèle pour connexion télécharger les fichiers  Le client envoie des référencés requêtes dès qu’il trouve un objet référencé  Un RTT pour tous les objets référencés 2: la couche application 28  message de requête HTTP  Deux types de messages HTTP: requête, réponse  message de requête HTTP :  ASCII (format lisible par les humains) Ligne de requête (commandes GET, GET /somedir/page.html HTTP/1.1\r\n POST, HEAD) Host: www.someschool.edu \r\n User-agent: Mozilla/4.0\r\n Lignes de l’entête Connection: close\r\n Accept-language:fr\r\n \r\n Carriage return (extra carriage return, line feed) et line feed pour indiquer la fin du message 2: la couche application 29 message de requête HTTP: format général 2: la couche application 30 Envoie d’un formulaire d’entrée Méthode Post :  La page Web comprend souvent un formulaire  Les données saisies dans le formulaire sont envoyées au serveur dans le corps de l’entité Méthode GET :  Utilise la méthode GET  Les données du formulaire sont envoyées dans le champ URL de la requête : www.somesite.com/animalsearch?monkeys&banana 2: la couche application 31 Types de méthodes HTTP/1.0 HTTP/1.1  GET  GET, POST, HEAD  POST  PUT  HEAD  Uploader le fichier dans le corps à un chemin  Demande au serveur de spécifié dans le URL laisser les objets requis à l’extérieure de la  DELETE réponse  Effacer un fichier spécifié dans l’URL 2: la couche application 32  Message de réponse HTTP Ligne d’état (protocole, Code d’état, message d'état) HTTP/1.1 200 OK\r\n Connection close\r\n Date: Thu, 06 Aug 1998 12:00:15 GMT\r\n Server: Apache/1.3.0 (Unix)\r\n Lignes Last-Modified: Mon, 22 Jun 1998 2007 17:00:02 GMT\r\n d’entête Content-Length: 6821\r\n Content-Type: text/html\r\n \r\n data data data data data... données (Par ex., le fichier HTML requis) 2: la couche application 33 Codes d'état de réponse HTTP  Dans la première ligne de la réponse  Quelques exemples de codes: 200 OK  Requête réussie, objet requis viendra plus tard dans le msg 301 Moved Permanently  L’objet requis est déplacé, la nouvelle localisation est spécifiée plus tard dans le message (Location:) 400 Bad Request  La requête n’est pas comprise par le serveur 404 Not Found  Le document requis n’est pas sur ce serveur 505 HTTP Version Not Supported 2: la couche application 34  Essaie HTTP (côté client) pour toi 1. Telnet vers ton serveur Web favori : telnet www.etsmtl.ca 80 Ouvre une connexion TCP au port 80 (port du serveur HTTP par défault) à www.etsmtl.ca. Ce qui est écrit sera envoyé au port 80 à www.uqam.ca 2. Saisis une requête GET HTTP: GET / HTTP/1.1 En tapant cela (appuyer sur Host: www.etsmtl.ca return 2 fois), tu envoie ce minimum (mais complet) requête GET au serveur HTTP 3. Regarde la réponse envoyée par le serveur HTTP! 2: la couche application 35 Chapitre 2: la couche applications 1. Principes des apps réseaux 1. Architectures des apps 2. Interfaces de connexion (Socket) 3. Exigences des apps en termes de performance et de fiabilité 2. Web et HTTP 3. Protocole de transfert de fichier (FTP) 4. Courrier électronique (SMTP, POP3, IMAP) 5. Serveur de noms DNS 2: la couche application 36 FTP: protocole de transfert de fichiers FTP Transfert de fichier client Serveur Interface FTP FTP utilisateur utilisateur Système de Système fichier distant de fichier local  Transfert de fichier vers/de une machine distant  Modèle client/serveur Le client : initie le transfert (de ou vers une machine  distante)  Le serveur : machine distante  ftp: RFC 959  Le serveur ftp utilise le port 21 2: la couche application 37  FTP: sépare les connexions: contrôle, données 1. Le client FTP contacte le connexion de contrôle TCP, serveur FTP au port 21 à port serveur 21 travers TCP (connexion de contrôle) Connexion de données TCP, 2. Le client est authentifié sur la Client port serveur 20 Serveur connexion de contrôle FTP FTP 3. Le client parcours le répertoire de fichier distant  Connexion de contrôle: est utilisée en envoyant des commandes pour envoyer les commandes sur la connexion de contrôle. « Hors-bande » (out of band)  4. Quand le serveur reçoit une  Chaque fois que le serveur a à commande de transfert d’un transmettre un fichier, il ouvre une fichier, nouvelle connexion TCP appelée  il ouvre une 2ème connexion TCP connexion de données (appelée connexion données) avec le client pour transmettre  Le serveur FTP maintient “l’état”: le fichier répertoire actuel, authentification  Après le transfert du fichier, précédente le serveur ferme la connexion données. 38 Commandes et réponses FTP Ex. commandes: Ex. codes de retour  Envoyées en texte ASCII  Code d'état et message d’état sur la connexion de (comme en HTTP) contrôle  331 Username OK, password  USER username required  PASS password  125 data connection  LIST donne la liste des already open; transfer fichiers dans le répertoire starting actuel  425 Can’t open data  RETR filename demande connection un fichier (gets)  452 Error writing file  STOR filename stocke (puts) le fichier sur la machine à distance 2: la couche application 39 Chapitre 2: la couche applications 1. Principes des apps réseaux 1. Architectures des apps 2. Interfaces de connexion (Socket) 3. Exigences des apps en termes de performance et de fiabilité 2. Web et HTTP 3. Protocole de transfert de fichier (FTP) 4. Courrier électronique (SMTP, POP3, IMAP) 5. Serveur de noms DNS 2: la couche application 40  Système de messagerie file d’att. des messages sortants électronique Boite de courriel des utilisateurs user 3 composantes majeures: agent  Agent utilisateur (User agent) mail user server  Serveurs de courriel (mail server) agent  Simple Mail Transfer Protocol SMTP mail (SMTP) server user SMTP agent Agent utilisateur (User Agent)  “lecteur de courriel” SMTP mail user  Composer, éditer, lire les agent server courriel  Par ex., Outlook, Thunderbird user agent  Les messages entrants et user sortants sont stockés sur le agent serveur 2: la couche application 41 Système de messagerie électronique user agent Serveurs de courriels mail user (mail servers) server agent  Boite aux lettres contient les SMTP mail messages entrants pour l’usager server user  File d’attente des message pour les agent messages à envoyer SMTP  Protocole SMTP entre les serveurs SMTP user de courriels pour envoyer les mail agent messages server  client: le serveur qui envoient les user courriels agent  serveur: le serveur qui reçoit les courriels 2: la couche application 42 Système de messagerie électronique SMTP [RFC 5321]  Utilise le TCP pour transférer sans erreur les messages email du client au server, port 25  Transfert direct: du serveur d’émission vers le serveur de réception  Trois phases de transfert  handshaking (bonjour)  transfert des messages  fermeture  L’interaction commande/réponse (comme http et ftp)  commandes: texte ASCII  réponse: le code d'état et message d’état  Les messages doivent être en ASCII 7-bit 2: la couche application 43 Scénario: Alice envoie un message à Bob 1) Alice utilise UA pour 3) Le client SMTP dans le serveur composer le message “à” crepes.fr ouvre une connexion [email protected] TCP avec le serveur mail de Bob 4) Il envoie le message d’Alice sur la 2) l’agent de l’utilisateur d’Alice connexion TCP au serveur SMTP envoie un message à son résidant à hamburger.edu serveur mail crepes.fr 5) Le serveur mail de Bob place le le message est placé dans message dans la boite aux lettres une file d’attente et attend de Bob son tour pour être envoyé Maintenant, si Bob veut récupérer son message, il utilise son agent utilisateur pour se connecter à son serveur mail et récupérer le message 1 mail mail user user server server 2 agent agent 3 4 5 Serveur de courriels Serveur de courriels d’Alice de Bob hamburger.edu 44 crepes.fr  Exemple d’une interaction SMTP S: 220 hamburger.edu C: HELO crepes.fr S: 250 Hello crepes.fr, pleased to meet you C: MAIL FROM: S: 250 [email protected]... Sender ok C: RCPT TO: S: 250 [email protected]... Recipient ok C: DATA S: 354 Enter mail, end with "." on a line by itself C: Do you like ketchup? C: How about pickles? C:. S: 250 Message accepted for delivery C: QUIT S: 221 hamburger.edu closing connection S: Serveur C: Client 2: la couche application 45 Essayer une interaction SMTP  telnet servername 25  Vérifier la réponse du serveur : 220  Entrer les commandes HELO, MAIL FROM, RCPT TO, DATA, QUIT Ces commandes permettent d’envoyer un email sans utiliser un client Mail 2: la couche application 46  SMTP : Résumé  SMTP utilise des connexions Comparaison avec HTTP: persistantes  HTTP: pull protocol (tirez)  SMTP exige que le message  SMTP: push protocol (poussez) (entête & corps) soit en ASCII 7-bit  Les deux ont des interactions  Le serveur SMTP utilise basées sur commande/réponse en CRLF.CRLF pour déterminer ASCII, codes d'état la fin du message  HTTP : chaque objet est encapsulé dans son propre message de réponse  SMTP : plusieurs objets envoyés dans un message multi-parties CRLF: Carriage Return and Line Feed 2: la couche application 47 Le format du message Mail  SMTP: le protocole pour échanger des courriels entête  RFC 5322: le standard pour le ligne format texte du message: blanche  Lignes d’entête, par ex., To: From: corps Subject: Différentes des commandes SMTP !  corps le “message”, est en caractère ASCII seulement 2: la couche application 48  Format du message: extensions multimédia  MIME: extension mail pour les multimédia, RFC 2045, 2056  Des lignes additionnelles dans l’entête du message déclarent le type du contenu MIME From: [email protected] version MIME To: [email protected] Subject: Picture of yummy crepe. méthode utilisée pour MIME-Version: 1.0 encoder les données Content-Transfer-Encoding: base64 Content-Type: image/jpeg type de données multimédia, sous-type, base64 encoded data..... déclaration de paramètres...............................base64 encoded data données encodées 2: la couche application 49  Protocole d’accès Mail protocole SMTP SMTP d’accès aux courriels user user agent agent (par ex., POP, IMAP) Serveur mail Serveur mail d’émission de réception  SMTP est utilisé seulement pour livrer le courriel au serveur de réception  Protocoles d’accès aux courriels: récupérer les courriels à partir du serveur  POP : Post Office Protocol [RFC 1939] : autorisation d’accès et téléchargement des courriels  IMAP : Internet Mail Access Protocol [RFC 1730]: Plus d’options (plus complexe) incluant la manipulation des messages stockés sur le serveur  HTTP : gmail, Hotmail, Yahoo! Mail, etc. 2: la couche application 50 Le protocole POP3 S: +OK POP3 server ready C: user bob phase d’autorisation S: +OK  Les commandes client: C: pass hungry S: +OK user successfully logged  user: déclare le nom on  pass: mot de passe C: list  Les réponses du serveur S: 1 498  +OK S: 2 912  -ERR S:. C: retr 1 Phase de transaction, client: S:  list: liste les numéros des S:. messages C: dele 1  retr: récupérer le message C: retr 2 par numéro S:  dele: efface S:.  quit C: dele 2 C: quit S: +OK POP3 server signing off 2: la couche application 51  POP3 et IMAP Plus sur POP3 IMAP  L’exemple précédent utilise le  Garde tous les courriels dans la mode “télécharge et efface”. même place: le serveur  Bob ne peut pas relire les courriels  Permet à l’utilisateur d’organiser s’il change de client les messages en répertoires  “télécharge-et-garde”: des  IMAP garde l’état de l’utilisateur copies des courriels sur des à travers les sessions : clients différents  Les noms de répertoires et le  POP3 est sans état à travers mappage entre les IDs des les sessions messages et le nom du répertoire 2: la couche application 52 Chapitre 2: la couche applications 1. Principes des apps réseaux 1. Architectures des apps 2. Interfaces de connexion (Socket) 3. Exigences des apps en termes de performance et de fiabilité 2. Web et HTTP 3. Protocole de transfert de fichier (FTP) 4. Courrier électronique (SMTP, POP3, IMAP) 5. Serveur de noms DNS 2: la couche application 53  DNS: Domain Name System Humains : plusieurs identifiants :  NAS, nom, passeport hôtes Internet et routeurs :  Adresse IP (32 bit) – utilisée pour l’adressage des datagrammes  “nom”, par ex., www.yahoo.com – utilisé par les humains Q: comment faire la correspondance entre un nom et une adresse IP ?  Système de noms de domaines (Domain Name System) :  Base de données distribuée implémentée en hiérarchie de plusieurs serveurs de noms et qui maintiennent les correspondances : (nom de domaine –> adresse IP)  Protocole Domain Name Service (DNS) :  Les hôtes et routeurs doivent communiquer avec les serveurs de noms à travers le protocole DNS pour trouver la correspondance (nom, adresse IP)  Protocole de niveau application qui utilise soit TCP soit UDP au niveau transport Note : la résolution des noms de domaines est une fonction de base dans l’Internet, mais implémentée comme un protocole de niveau application 54  DNS Les services DNS Pourquoi ne pas centraliser  traduction du nom d’une le DNS? machine en une adresse IP  fragilité d’un site central  dénomination d’hôte unique  Nom canonique  volume de trafic  Alias  Une base de données  attribution d’un alias à un centralisée peut être située serveur de messagerie trop loin par rapport à  distribution de charge quelques utilisateurs  Plusieurs instances du même  maintenance serveur Web : plusieurs adresses IP pour le même nom Pas de mise à l’échelle! 55  Base de données répartie, hiérarchique Serveurs de noms « racine » … … Serveurs de domaine niveau supérieur Serveurs DNS com Serveurs DNS org Serveurs DNS edu (Top-Level Domain - TLD) : Serveurs serveur DNS serveur DNS serveur DNS serveur DNS serveur DNS autoritaires : umass.edu yahoo.com amazon.com pbs.org poly.edu Un client veut l’adresse IP de www.amazon.com : 1. Le client demande au serveur DNS racine de trouver le serveur DNS.com 2. Le client demande au serveur DNS.com de trouver le serveur DNS de amazon.com 3. Le client demande au serveur DNS de amazon.com de trouver l’adresse IP de www.amazon.com 2: la couche application 57 TLD et serveurs DNS autoritaires  Serveurs de noms autoritaires:  Serveur DNS appartenant à l’organisation, donne la correspondance nom-adresse IP pour les serveurs de l’organisation (par ex., Web, mail).  Peut être maintenu par une organisation ou par un fournisseur d’accès  Serveurs de domaines de niveau supérieur (Top-Level Domain servers – TLD servers):  responsable pour com, org, net, edu, … et tous les domaines de niveau supérieur des pays (par ex., ca, uk, fr).  Verisign Global Registry Services maintient les serveurs TLD pour.com  Educause pour les serveurs TLD.edu 2: la couche application 58  DNS: serveurs de nom « racine »  Contacté par le serveur de nom local qui ne peut pas trouver l’adresse IP qui correspond à un nom  Serveur de nom « racine » (root name server) :  Retourne l’adresse(s) de serveur(s) TLD responsable d’un domaine (edu, ca, fr…) c. Cogent, Herndon, VA (5 other sites) d. U Maryland College Park, MD k. RIPE London (17 other sites) h. ARL Aberdeen, MD j. Verisign, Dulles VA (69 other sites ) i. Netnod, Stockholm (37 other sites) e. NASA Mt View, CA m. WIDE Tokyo f. Internet Software C. (5 other sites) Palo Alto, CA (and 48 other sites) a. Verisign, Los Angeles CA 13 organisations de nom « racine » (5 other sites) b. USC-ISI Marina del Rey, CA dans le monde l. ICANN Los Angeles, CA (41 other sites) g. US DoD Columbus, OH (5 other sites) 2: la couche application 59  Serveur DNS local  N’appartient pas à la hiérarchie  Chaque FAI (FAI résidentiel, compagnie, université) en a un.  appelé aussi “serveur de noms par défaut”  Quand un hôte envoie une requête DNS, la demande est envoyée à son serveur DNS local  Il possède un cache local contenant les couples (nom, adresse IP) récemment demandés.  Il agit comme proxy, transfère les demandes dans la hiérarchie 2: la couche application 60 Exemple de résolution Serveur DNS racine d’un nom 2  Un hôte cis.poly.edu 3 Serveur DNS TLD de.edu souhaite l’adresse IP de 4 gaia.cs.umass.edu (umass: university of 5 Massachussetts) serveur DNS local dns.poly.edu 7 6 recherche itérative: 1 8  Le serveur DNS serveur DNS autoritaire contacté répond avec de l’université de Massachussetts le nom du serveur hôte dns.cs.umass.edu DNS à contacter : cis.poly.edu “je ne connais pas ce nom mais demande à ce serveur” gaia.cs.umass.edu 61 Exemple de résolution Serveur DNS racine d’un nom 2 3 recherche récursive: 7 6  Mettre le fardeau sur le Serveur serveur DNS contacté DNS TLD  grande charge sur les de.edu serveurs DNS racine? serveur DNS local dns.poly.edu 5 4 1 8 Serveur DNS autoritaire dns.cs.umass.edu Hôte cis.poly.edu gaia.cs.umass.edu 2: la couche application 62 DNS: le cache et les mises à jour  Lorsqu’un serveur DNS trouve l’adresse IP correspondante à un nom, il la place dans sa mémoire cache  Chaque entrée dans le cache est supprimée (disparaît) après un certain temps (TTL)  Les adresses des serveurs TLD sont typiquement stockées dans la mémoire cache du serveur DNS local Donc le serveur racine n’est pas fréquemment visité  Les mécanismes de mise à jour et de notification sont décrits dans le RFC 2136 2: la couche application 63