Cours Réseaux. Chapitre 2 Couche applications

Transcription

1 Cours Réseaux Chapitre 2 Couche applications Université de Perpignan Page web du cours : Ouvrage de référence: Analyse Structurée des Réseaux, J. Kurose & K. Ross, Pearson Education, 2002

2 Plan du chapitre Principe de la couche application 2.2 Web et HTTP 2.3 FTP 2.4 (SMTP, POP3, IMAP) 2.5 DNS 2.6 Echange de fichier par P2P 2

3 Plan du chapitre Principe de la couche application Hiérarchie/Architecture des applications Notions de services 2.2 Web et HTTP 2.3 FTP 2.4 (SMTP, POP3, IMAP) 2.5 DNS 2.6 Echange de fichier par P2P 3

4 Quelques applications réseaux Téléphone sur IP Web Conférence vidéo à distance Méssagerie Instantanée Calcul massivement parallèle Login à distance Partage de fichier en P2P Jeux en réseau mutiutilisateurs video clips en streaming 4

5 Caractéristique des applications réseaux Une application réseau S'exécute sur différents terminaux Communique sur le réseau Par exemple: le serveur Web communique avec le navigateur applicatio transport network data link physical Hiérarchie Client-serveur (e.g., navigateurserveur web) Peer-to-peer (P2P) Hybride client-serveur et P2P applicatio transport network data link physical applicatio transport network data link physical 5

6 Architecture Client-serveur serveur: client: Un terminal toujours connecté et actif Adresse IP permanente Ferme de serveurs pour de grosse demande Communique avec le serveur Peut être connecté par intermittence Peut avoir une adresse IP dynamique Ne communique pas directement avec d'autres clients 6

7 Architecture purement P2P Des serveurs pas constamment actifs et connectés. N'importe quel couple de terminaux peuvent communiquer entre eux. Les pairs sont connectés par intermittence et peuvent changer d'adresse IP Exemple: Gnutella Hautement adaptable mais difficile à gérer et contrôler 7

8 Architecture hybride client-serveur et P2P Skype Application de téléphonie internet. Trouver des adresses d'autre participant: avec un ou plusieurs serveurs centraux. La connexion client-client est directe (ne passe pas par le serveur). Messagerie instantanée Tchat/clavardave entre deux utilisateurs est P2P. Détection/localisation de présence est centralisée: Les utilisateurs enregistrent leur adresse IP avec un serveur central lorsque il se connecte sur le réseau L'utilisateur contacte le serveur central pour trouver les adresses IP de ses connaissances/contacts 8

9 Communication de processus Processus: programme exécuté sur un terminal. Sur le même terminal, deux processus communiquent en utilisant une interface de communication définie par le système. Des processus sur différents terminaux communiquent en échangeant des messages. Processus client: processus qui démarre la communication Processus serveur: processus qui attend d'être contacté. Note: les applications P2P ont à la fois des processus clients et des processus serveurs 9

10 Sockets Les processus envoient et reçoivent des messages à travers une socket qui leur sont attachée. Une socket est analogue à une porte Le processus expéditeur pousse un message à travers une porte L'infrastructure de transport de l'autre côté de la porte amène le message jusqu'à la porte (socket) du message destinataire hôte ou serveur processus socket TCP avec tampons, variables contrôlé par le développeur de l'application contrôlé par le système Internet hôte ou serveur processus socket TCP avec tampons, variables 10

11 Adressage des processus Pour recevoir un message, le processus doit avoir un identifiant La machine hôte a une unique adresse IP sur 32 bits Q: est-ce que l'adresse IP de la machine hôte sur laquelle tourne le processus suffit pour identifier le processus? 11

12 Adressage des processus Pour recevoir un message, le processus doit avoir un identifiant La machine hôte a une unique adresse IP sur 32 bits Q: est-ce que l'adresse IP de la machine hôte sur laquelle tourne le processus suffit pour identifier le processus? Réponse: NON, beaucoup de processus s'exécute en même temps sur une même machine L'identifiant inclut à la fois adresse IP et numéro de port associé au processus sur la machine hôte. Exemple de numéro port: Serveur HTTP: 80 Serveur mail: 25 Pour envoyer des messages HTTP au serveur web gaia.cs.umass.edu : adresse IP: Numéro de port: 80 brièvement 12

13 La couche application définit Types de messages échangés, e.g., requête, réponse Syntaxe des messages: Quels champs dans les messages & comment les champs sont délimités Sémantiques des messages Signification de l'information dans les différents champs. Règles qui décrivent le moment et la façon dont les processus envoient et répondent aux messages Protocoles dans le domaine public: Définis dans les RFCs Permettent l'intéropérabilité e.g., HTTP, SMTP Protocoles propriétaires: e.g., KaZaA 13

14 Quel service de transport une application a-telle besoin? Perte de données Quelques applications (e.g., audio) peuvent tolérer quelques pertes. D'autres applications (e.g., transfert de fichier, telnet) nécessite un transfert de données 100% fiable. Timing Quelques applications (e.g., téléphonie internet, jeux réseaux) ont besoin d'un faible délai pour bien fonctionner. Bande passante Quelques applications (e.g., multimédia) ont besoin d'un minimum de bande passante pour bien fonctionner. D'autres applications ( applications élastiques ) fonctionnent avec n'importent quelle bande passante. 14

15 Services nécessaires à une application Applications Perte de données Débit Sensibilité au temps Transfert de fichiers Pages Web audio/vidéo temps réel audio/vidéo enregistrés jeux interactifs App. financières Interdite Interdite Acceptable Acceptable Acceptable Acceptable Interdite Flexible Flexible Flexible audio: 5Kb-1Mb vidéo:10kb-5mb Idem qq - 10 Kb/s Flexible non non non oui, ~100 msec oui, qq secs oui, 100 s msec oui et non

16 Service des protocoles de transport Service TCP: orienté-connexion: initialisation par poignée de main nécessaire a l'établissement de la connexion transport fiable entre le processus expéditeur et le processus destinataire Contrôle du flux: l'expéditeur ne sur-envoie pas des données. Contrôle congestion: ralentissement des envois si le réseau est surcharge. Ne garantit pas: un délai, ni un minimum de bande passante. Service UDP: Transfert de données non fiable Ne fournit pas: de connexion, fiabilité, contrôle de flux, contrôle de congestion, temps ou bande passante. Q: Pourquoi s'embêter? Pourquoi UDP existe-t-il? 16

17 Applications internet: application et protocoles de transport Application Accès distant (ssh) Web transfert de fichier streaming multimédia téléphonie internet Protocole de la couche application SMTP [RFC 2821] Telnet [RFC 854] HTTP [RFC 2616] FTP [RFC 959] propriétaire (e.g. RealNetworks) propriétaire (e.g., Vonage,Dialpad) Protocole de transport utilisé TCP TCP TCP TCP TCP or UDP typiquement UDP 17

18 Plan du chapitre Principe de la couche application 2.2 Web et HTTP 2.3 FTP 2.4 (SMTP, POP3, IMAP) 2.5 DNS 2.6 Echange de fichier par P2P 18

19 Web et HTTP D'abord un peu de jargon Une page web consiste en objets Un objet peut être un fichier HTML, une image JPEG, une applet Java, un fichier audio, Une page web consiste en un fichier HTML principal qui inclut la référence à différents objets Chaque objet est adressable par une URL Exemple d'url: Nom de l'hôte Chemin du fichier 19

20 Généralité sur HTTP HTTP: hypertext transfer protocol C'est un protocole de la couche application Modèle client/serveur client: le navigateur qui fait des requêtes, reçoit et affiche des objets web. serveur: le serveur Web envoie des objets en réponse à des requêtes HTTP 1.0: RFC 1945 HTTP 1.1: RFC 2068 PC sur lequel tourne firefox Mac sur lequel tourne safari Requête HTTP Réponse HTTP réponse HTTP Serveur sur lequel tourne le serveur web Apache 20

21 Généralité sur HTTP (suite) Utilise TCP: Le client démarre une connexion TCP (création de socket) avec le serveur, port 80 Le serveur accepte la connexion TCP du client Des messages HTTP (messages de la couche application) sont échangés entre le navigateur (HTTP client) et le serveur Web (HTTP serveur) La connexion TCP est fermée HTTP est sans état Le serveur ne maintient aucune information concernant les requêtes du client Les protocoles qui maintiennent des états sont complexes! À côté historique récente (état) doit être maintenu Si le serveur ou le client crashes, leur états en mémoire peuvent être endommage et doivent être rafistoles. 21

22 Connexions HTTP HTTP Non-persistant Au plus un objet est envoyé sur la connexion TCP. HTTP/1.0 utilise une connexion non persistante HTTP Persistant Des objets multiples peuvent être envoyés sur une même connexion TCP entre un client et un serveur. HTTP/1.1 utilisent la connexion persistante par défaut. 22

23 HTTP par l'exemple Un utilisateur entre l'adresse suivante : (contient du texte et une référence vers 1 image jpeg) time 1a. le client http commence une connexion TCP avec le serveur http à l'adresse port le client http envoie une requête http avec l'url dans la socket TCP 5. le client reçoit le message contenant le fichier html, l'analyse et envoie une requête pour l'image (répétition des étape 1 à 5) 1b. Le serveur http ww.univ-perp.fr est à l'écoute d'une connexion TCP sur le port 80. Il envoie un accusé de connexion au client. 3. Le serveur HTTP reçoit la requête, forme une réponse contenant l'objet demandé (intranet/index.html) et l'envoie dans la socket. 4. Le serveur HTTP ferme la socket

24 HTTP non-persistant: temps de réponse Définition de RTT: temps pour un paquet pour aller du client au serveut et de revenir au client. (RTT=Round Trip Time) Temps de réponse: Un RTT pour initialiser la connexion TCP un RTT pour une requête HTTP et l'arrivée des premiers bits de la réponse HTTP du serveur Temps de transmission du fichier total = 2RTT+temps de transmission Initiation de la connexion TCP RTT requête d'un fichier RTT Fichier reçu Temps de transmission du fichier temps temps 24

25 HTTP persistant Problème du HTTP non-persistant: nécessite 2 RTTs par objet Temps d'initialisation pour chaque connexion TCP. Les navigateurs ouvrent souvent des connexions TCP en parallèle pour récupérer des objets référencés. HTTP Persistant Le serveur laisse la connexion ouverte après avoir envoyé une réponse. Les messages HTTP qui suivent entre les mêmes client et serveur sont envoyés sur cette connexion déjà ouverte. Persistant sans pipeline: client envoie une nouvelle requête seulement lorsque les précédentes réponses ont été reçues. Ca coûte donc un RTT pour chaque objet référence. Persistant avec pipeline: Par défaut dans HTTP/1.1 client envoie des requêtes des qu'il rencontre un objet référence. Le coût est réduit a un RTT pour la totalité des objets références. 25

26 Format des messages HTTP Messages de demande http : ligne de requête (Commandes GET, POST, HEAD) lignes d'en-têtes GET /intranet/page.html HTTP/1.0 Host: User-agent: Mozilla/4.0 Accept: text/html, image/gif,image/jpeg Accept-language:fr Retour chariot, fin de message

27 Message de requête HTTP: format général CR=Cariage Return LF = Line Feed CR+LF consiste en un retour à la ligne 27

28 Entrée de formulaire d'upload Méthode Post: Page Web souvent inclus des formulaires Les entrées dans le formulaire sont envoyées au serveur dans l' entité body. Méthode URL: Utilise la méthode GET Les entrées du formulaires sont envoyés dans le champs URL de la requête GET (séparé par? puis &) 28

29 Les différents types de méthode HTTP HTTP/1.0 GET POST HEAD Demande au serveur de ne pas inclure dans la réponse les objets de la requête. HTTP/1.1 GET, POST, HEAD PUT Envoie un fichier dans l'entité body au chemin spécifier dans l'url de la requête DELETE Détruit un fichier spécifié dans l'url de la requête. 29

30 Format d'une réponse HTTP Message de réponse HTTP : ligne d'état (version http, code d'état, message d'état) lignes d'en-têtes HTTP/ OK Date: Thu, 14 Aug :00:15 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Jun Content-Length: 6821 Content-Type: text/html données, par ex. le fichier html demandé data data data data data... Autre message possible : HTTP/ Moved permanently HTTP/ Bad request HTTP/ Not found HTTP/ HTTP Version not supported

31 Code de status des réponses HTTP Dans la première ligne du serveur-> réponse au message du client. Quelques échantillons de code: 200 OK requête réussie, l'objet requis se trouve plus loin dans ce message. 301 Moved Permanently L'objet requis a été déplacé, nouvelle location spécifiée plus tard dans ce message (Location:) 400 Bad Request La requête du message n'est pas comprise par le serveur. 404 Not Found Le document demandé n'a pas été trouvé sur ce serveur 505 HTTP Version Not Supported 31

32 Etat utilisateur-serveur: cookies Beaucoup des plus importants serveurs Web utilisent les cookies Quatre composants: 1) entête d'un cookie message réponse HTTP. 2) l'entête de cookie dans la requête HTTP. 3) le fichier cookie est sauvegardé sur la machine de l'utilisateur et est géré par le navigateur de l'utilisateur. 4) base de donnée sur le serveur Web du site. Exemple: Suzane accède à Internet a partir du même PC. Elle visite un site de commerce en ligne spécifique pour la première fois. Quand la requête HTTP arrive au site, le site crée un ID unique et crée une entrée dans base de donnée pour l'identifiant 32

33 Cookies: garder l' état (cont.) Fichier Cookie ebay: 8734 client Requête http normale Réponse http normale + Set-cookie: #12345 serveur serveur crée un ID 1678 pour l'utilisateur entrée dans la base de données Fichier cookie amazon: 1678 ebay: 8734 Une semaine + tard: Fichier cookie amazon: 1678 ebay: 8734 Requête http normale cookie: #12345 Réponse http normale Requête http normale cookie: #12345 Réponse http normale Action spécifique à ce cookie Action spécifique à ce cookie accès accès 33

34 Cookies (cont.) Quesque peut comporter un cookie: Autorisation Cadis d'achat Recommandations L'état d'une session (Web ) Cookies et vie privée Les cookies permettent aux sites d'apprendre beaucoup de l'utilisateur. Vous pouvez fournir votre nom et aux sites Comment garder un état : Protocole aux deux bouts: maintient l'état expéditeur/destinataire lors des transactions multiples cookies: messages HTTP contenant l'état 34

35 Web caches (serveurs proxy) But: satisfaire les requêtes clients sans faire intervenir le serveur d'origine Le navigateur de l'utilisateur : accède au Web via un cache Le navigateur envoie toute requête HTTP au web cache (ou proxy) Si l'objet est en cache: le proxy retourne cet objet Autrement le proxy transmet la requête au serveur d'origine et fait passer la réponse au navigateur client client Requête HTTP Réponse HTTP Réponse HTTP Serveur proxy Requête HTTP Serveur d'origine Serveur d'origine 35

36 Web proxy (cont.) Le proxy agit à la fois comme un serveur et un client. Typiquement il est installé par un ISP (université, entreprise ou un ISP résidentiel) Pourquoi utilise-t-on des proxy? Réduit le temps de réponse pour une requête client. Réduit le trafic sur la liaison d'accès à une institution. Internet est rempli de caches: cela permet aux fournisseurs de contenu pauvre de délivrer rapidement le contenu (mais l'échange de fichier P2P le fait aussi) 36

37 Exemple de cache Web Hypothèses Taille moyenne d'un objet = 100,000 bits Taux de requête moyen des navigateurs de l'institution vers les serveurs d'origine = 15/sec Délai du routeur institutionnel vers un serveur d'origine et retour au routeur est de = 2 sec Conséquences utilisation du LAN = 15% =(15 requêtes/s * 100 kb) / 100 Mbps utilisation de la liaison d'accès = 100% =(15 requêtes/s * 100 kb) / 1.5 Mbps => occasionne un long délai délai total = délai Internet + délai d' accès délai + délai du LAN = 2 sec + minutes + millisecondes réseau institutionnel Internet public Lien d'accès de 1.5 Mbps 10 Mbps LAN Serveurs d'origine cache institutionnel 37

38 Exemple de cache Web (cont.) Solution possible Accroître la bande passante à 10 Mbps Conséquences utilisation du LAN = 15% utilisation de la liaison d'accès = 15% Délai total = internet délai + délai d'accès + délai sur le LAN = 2 sec + msecs + msecs Souvent une solution coûteuse réseau institutionnel Internet public Lien d'accès de 10 Mbps 10 Mbps LAN Serveurs d'origine 38

39 Exemple de cache Web (cont.) Installer un proxy suppose taux de réussite 0.4 Conséquence 40% des requêtes seront satisfaites presque immédiatement 60% des requêtes satisfaites par les serveurs d'origine utilisation de la liaison d'accès au LAN réduite a 60%, il en resulte un délai négligeable (c'est a dire 10 msec) Délai moyen total = délai Internet + délai d'accès + délai LAN =. 6*(2.01) secs +.4*millisecondes < 1.4 secs réseau institutionnel Internet public liaison d'accès de 1.5 Mbps 10 Mbps LAN Serveurs d'origine cache institutionnel 39

40 GET Conditionnel But: ne pas envoyer d'objet si le proxy a une version en cache a jour cache: spécifier la date de mise a jour de la copie en cache dans la requête HTTP If-modified-since: <date> serveur: la réponse contient aucun objet si la copie en cache est à jour: HTTP/ Not Modified cache Msg de requête HTTP If-modified-since: <date> Réponse HTTP HTTP/ Not Modified Msg de requête HTTP If-modified-since: <date> serveur objet non modifié objet modifié Réponse HTTP HTTP/ OK <data> 40

41 Plan du chapitre Principe de la couche application 2.2 Web et HTTP 2.3 FTP 2.4 (SMTP, POP3, IMAP) 2.5 DNS 2.6 Echange de fichier par P2P 41

42 FTP: le protocole de transfert de fichier interface utilisateur FTP FTP client Transfert de fichier Serveur FTP utilisateur sur l'hôte Fichier système local Fichier système éloigné transfert fichier vers/de terminal éloigné Modèle client/serveur Client: côté qui initie le transfert (soit vers/provenant de l'hôte éloigné) serveur: hôte éloigné ftp: RFC 959 ftp serveur: port 21 42

43 FTP: connexion de contrôle et connexions de données séparées Le client FTP contacte le serveur FTP serveur au port 21, spécifie TCP comme protocole de transfert Le client obtient l'autorisation sur le contrôle de connexion Le client se déplace dans arborescence de fichier sur le serveur distant en envoyant des commandes a travers la connexion TCP. Quand le serveur reçoit une commande de transfert de fichier, le serveur ouvre une seconde connexion TCP Après avoir envoyé le fichier le serveur ferme la connexion de données. FTP client Connexion TCP de contrôle sur le port 21 Connexion de données TCP sur le port 20 FTP serveur Serveur ouvre une autre connexion TCP de données pour transferer un autre fichier. Connexion de contrôle: out of band FTP serveur maintient un état : répertoire, et précédente authentification 43

44 Commandes FTP, réponses Echatillons de commandes: Envoyer sous forme de texte ASCII sur le canal de contrôle USER username PASS password LIST renvoie la liste du fichier dans le répertoire courant RETR filename récupérer un fichier STOR filename enregistre (puts) un fichier sur l'hôte lointain Echantillons de codes réponses status code et phrase (comme dans HTTP) 331 Username OK, password required 125 data connexion already open; transfer starting 425 Can t open data connexion 452 Error writing file 44

45 Plan du chapitre Principe de la couche application 2.2 Web et HTTP 2.3 FTP 2.4 (SMTP, POP3, IMAP) 2.5 DNS 2.6 Echange de fichier par P2P 45

46 Mail électronique File de messages sortant Trois composants majeurs: Agents utilisateurs serveurs mails simple mail transfer protocol: SMTP mail server Agent utilisateur Boite mail utilisateur Agent utilisateur Agent utilisateur (Maileur) Aussi dénommé comme liseur de mail SMTP SMTP Server mail Compose, édite, lit les messages électroniques e.g., Eudora, Outlook, elm, thunderbird messages entrant et sortant stocké sur serveur Serveur mail SMTP Agent utilisateur Agent utilisateur Agent utilisateur 46

47 Courrier électronique: serveurs mail Serveur de mails Boite mail contient le message entrant de l'utilisateur File de messages sortant (attendant d'être envoyé) Protocole SMTP entre les serveurs mail pour envoyer les messages client: envoyer un message au serveur serveur: recevoir un mail SMTP mail server mail server user agent SMTP SMTP mail server user agent user agent user agent user agent user agent 47

48 Mail électronique: SMTP [RFC 2821] utilise TCP pour avoir un transfert d' fiable du client au serveur, port 25 transfert direct: serveur envoyeur au serveur receveur trois phases de transfert Poignée de main (salutation) transfert de messages Fermeture de la connexion commandes/réponse en interaction Commandes: en texte ASCII réponse: status code et phrase messages doivent être en 7-bit ASCII 48

49 Scénario: Alice envoie un message à Bob 1) Alice utilise une application pour composer ses messages to : bob@someschool.edu 2) L'application envoie le message a son serveur mail; le message est placé dans une file de message 3) Le coté client du serveur mail d'alice ouvre une connexion TCP avec le serveur mail de Bob utilisateur 4) SMTP client envoie le message d'alice sur la connexion TCP. 5) Le serveur mail de Bob place le message dans la boite mail de Bob 6) Bob utilise son application préférée pour lire le message SMTP SMTP POP3 ou IMAP utilisateur serveur de mail de l'expéditeur serveur de mail du destinataire 49

50 Echantillon 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 Sender ok C: RCPT TO: S: 250 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 connexion 50

51 SMTP: derniers mots SMTP utilise une connexion persistante. SMTP nécessite des messages (entête & corps) d'être codé en 7-bit ASCII Le serveur SMTP utilise CRLF.CRLF pour déterminer la fin du message. Comparaison avec HTTP: HTTP: pull SMTP: push Les deux ont des commandes/réponse interaction et codes de status codés en ASCII HTTP: chaque objet encapsulé dans son propre message réponse. SMTP: des objets multiple envoyé dans un message regroupant tous les objets. 51

52 Format d'un SMTP: protocole pour echanger des courriels. RFC 822: format standard pour des messages textes: Lignes d'entete, e.g., To: From: Subject: différent d'une commande SMTP! Corps LE message, caractère en ASCII uniquement. entete corps ligne blanche 52

53 Format de messages: extensions multimédias MIME: multimédia mail extension, RFC 2045, 2056 Ligne additionnelle dans une entête de msg déclare un contenu de type MIME. Version MIME méthode utilisée pour encoder les données Donnée multimédia déclaration de type, sous-type et paramètre From: To: Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data base64 encoded data Donnée encodée 53

54 Potocoles d'accès aux s utilisateur SMTP SMTP protocole d'accès utilisateur Serveur mail de l'expéditeur Serveur mail du destinataire SMTP: livraison/stockage sur le serveur du destinataire. Protocole d'accès aux courriels: récupération sur le serveur POP: Post Office Protocol [RFC 1939] autorisation (utilisateur <-->serveur) et download IMAP: Internet Mail Access Protocol [RFC 1730] Plus de possibilité (mais aussi plus compliqué) manipulation de message stocker sur le serveur HTTP: Hotmail, Yahoo! Mail, etc. 54

55 Protocole POP3 Phase d'autorisation Commandes client: user: déclare nom utilisateur pass: password Réponses serveur +OK -ERR phase de transaction, client: list: lister les numéros de message retr: récupérer les messages par leur numéro dele: supprimer quit S: +OK POP3 server ready C: user bob S: +OK C: pass hungry S: +OK user successfully logged on C: list S: S: S:. C: retr 1 S: <message 1 contents> S:. C: dele 1 C: retr 2 S: <message 1 contents> S:. C: dele 2 C: quit S: +OK POP3 server signing off 55

56 POP3 (cont.) et IMAP Plus à propos de POP3 Les exemples précendants utilisent un mode télécharger et supprimer. Bob ne peut pas relire un e- mail si il change de terminal. Télécharger-et-garder : copies de messages sur différent clients POP3 est sans état à travers les différentes sessions IMAP Garder tous les messages a une seule place: le serveur Permet aux utilisateur d'organiser les messages dans des répertoires IMAP conserve un état utilisateur à travers les différentes sessions: Noms de répertoires et correspondance entre message Ids et nom de répertoire. 56

57 Plan du chapitre Principe de la couche application 2.2 Web et HTTP 2.3 FTP 2.4 (SMTP, POP3, IMAP) 2.5 DNS 2.6 Echange de fichier par P2P 57

58 DNS: Domain Name System Personnes: essentiellement des identifiants: Numéro de sécurité sociale, nom, passeport nb Terminaux internet, routeurs: Adresses IP (32 bit) utilisées pour adresser les datagrammes nom, e.g., ww.yahoo.com utilisé par les humains Q: Comment faire correspondre adresses IP et les noms? Domain Name System: Base de données distribuée et implémentée en hiérarchie sur de nombreux serveurs de noms Protocole de la couche application hôte, routeurs, serveurs de nom pour communiquer et résoudre les noms (correspondance adresse/nom) note: DNS est au coeur d'internet, même si implémenté en tant que protocole de la couche application compléxité aux extrémités du réseau 58

59 DNS Services DNS conversion d'adresse IP Alias de terminaux Nom canonique et alias. Alias de serveur de mail Chargement de distribution Réplique de serveur Web: ensemble d'adresses IP pour un nom canonique. Pourquoi ne pas centraliser le DNS? Un point de défaillance Volume de trafic Base de données centralisée et éloignée Problème de maintenance 59

60 Base de donnée hiérarchique et distribuée Racine des serveurs DNS serveurs DNS com Serveurs DNS org Serveurs DNS edu serveurs DNS yahoo.com serveurs DNS amazon.com serveurs DNS pbs.org serveurs DNS poly.edu serveurs DNS umass.edu Client veut l'ip pour 1 ere approx: Client demande au serveur racine de trouver le serveur DNS com Client demande au serveur DNS com de lui fournir le serveur DNS amazon.com Client demande au serveur DNS amazon.com de lui fournir l'adresse IP de 60

61 DNS: serveur de nom racine Contacté par des serveurs de nom local qui ne peuvent pas résoudre un nom Le serveur de nom racine: Contacte le serveur de nom qui fait autorité si la correspondance n'est pas connue Obtient la correspondance Renvoie la correspondance au serveur de nom local a Verisign, Dulles, VA c Cogent, Herndon, VA (also Los Angeles) d U Maryland College Park, MD g US DoD Vienna, VA h ARL Aberdeen, MD j Verisign, ( 11 locations) k RIPE London (also Amsterdam, Frankfurt) i Autonomica, Stockholm (plus 3 other locations) e NASA Mt View, CA f Internet Software C. Palo Alto, CA (and 17 other locations) m WIDE Tokyo b USC-ISI Marina del Rey, CA l ICANN Los Angeles, CA 13 serveurs de nom racine à travers le monde 61

62 TLD and Serveurs faisant autorité Serveurs Top-level domain (TLD) : responsable de com, org, net, edu, etc, et tous les domaines nationaux (uk, fr, ca, jp,...). La companie Network solutions maintient les serveurs pour le TLD com L'institution Educause maintient les serveurs pour le TLD edu Serveur DNS faisant autorité: organisation des serveurs DNS, procure un nom d'hôte qui fait autorité pour la correspondance de l'ip pour les serveurs de l'organisation (e.g., Web et mail). Peut être maintenu par l'organisation ou un fournisseur de service. 62

63 Découpage en zone Le système DNS permet de diviser l espace des noms en zones : Ces zones stockent des informations relatives à un ou plusieurs domaines. Avant tout, une zone est une base de données de stockage contenant des enregistrements RR (Resource Records) concernant un nom de domaine DNS. Si un sous-domaine est créé, il peut être géré par la zone du domaine parent ou par une zone qui lui est propre. 63

64 Découpage en zone : principe de réplication DNS A chaque zone, correspond un serveur DNS principal (unique) : Il a le droit de lecture-écriture sur les données originales de la zone. Il sert de point de mise à jour de la zone. Serveurs secondaires : Ils contiennent une réplique dans son intégralité de la base de données du serveur principal. Les données sont en lecture seule (les modifications sont faites d'abord sur le serveur principal) Ils assurent l équilibrage de la charge et la tolérance aux pannes. 64

65 Serveur de nom locaux N'appartient pas strictement à la hiérarchie Chaque ISP (ISP résidentiel, de compagnie, ou d'université) en a un. Aussi appelé serveur de nom par défaut Quand un terminal envoie une requête DNS cette requête est envoyé au serveur DNS local par défaut. C'est une sorte de serveur DNS proxy, qui transmet la requête à la hiérarchie s'il ne connaît pas la réponse à la requête. 65

66 Exemple : requête itérative Un hôte cis.poly.edu veut une adresse IP pour gaia.cs.umass.edu 2 root DNS server 3 4 Serveur DNS TLD edu Serveur DNS local dns.poly.edu Hote faisant la requête cis.poly.edu Serveur faisant autorité dns.cs.umass.edu gaia.cs.umass.edu 66

67 Requêtes recursives Requêtes récursives: Fait passer le fardeau de la résolution d'un nom au serveur de nom contacté Chargement coûteux? Requête itérative: Le serveur contacte/répond à l'hôte en lui donnant l'adresse Serveur DNS local dns.poly.edu du serveur a contacter Je ne connais pas ce nom, mais demander a un tel lui il saura mieux que moi Hôte faisant la requête cis.poly.edu 7 Serveur DNS racine Serveur DNS TLD 4 Serveur faisant authorite dns.cs.umass.edu gaia.cs.umass.edu 67

68 DNS: mise en cache et mise a jour des enregistrements Une fois qu'un serveur de nom connaît une correspondance il le met dans en mémoire (il le met en cache) Des entrées caches disparaissent après un certain temps. Les serveurs TLD sont généralement mis en cache dans les serveur de nom locaux Donc les serveurs racines ne sont pas souvent visités Mécanisme de mise a jour/notification dessiné par IETF RFC

69 Enregistrement DNS DNS: BD distribue enregistre des resource records (RR) RR format: (name, value, type, ttl) Type=A name est un nom d'hôte Value est une adresse IP Type=NS name est domaine (e.g. foo.com) value est un nom d'hôte de serveur de nom faisant autorité pour ce domaine Type=CNAME name est un nom d'alias pour quelque nom canonique (les vrais noms) est en fait servereast.backup2.ibm.com value est un nom canonique Type=MX value est un nom de serveur de mail associé avec name 69

70 Protocole DNS, messages Protocole DNS : messages requête et réponse, tous les deux sous le même format de message Entête du msg identifiant: 16 bit # pour la requête, la réponse utilise le meme # flags: Requête ou réponse Recursion souhaitée recursion disponible réponse qui fait autorité 70

71 Protocole DNS, messages Nom, type champs pour une requête RRs dans la réponse à la requête enregistrements pour les serveurs faisant autorité Infos additionnelles et utile qui peuvent être utilisées 71

72 Insérer des enregistrements dans DNS Exemple: une startup Network Utopia vient d'être crée Enregistrer le nom networkuptopia.com auprès d'un enregistreur ou registrar (e.g., Network Solutions) On doit fournir au registrar des noms et adresses IP des serveurs faisant autorité (primaire et secondaire) Le registrar insèrent alors deux RRs dans le serveur TLD de com (networkutopia.com, dns1.networkutopia.com, NS) (dns1.networkutopia.com, , A) Mettre aussi le serveur avec un enregistrement de Type A pour et de type MX pour networkutopia.com 72

73 Plan du chapitre Principe de la couche application 2.2 Web et HTTP 2.3 FTP 2.4 (SMTP, POP3, IMAP) 2.5 DNS 2.6 Echange de fichier par P2P 73

74 Partage de fichier par P2P Exemple Alice lance une application P2P sur son PC portable Le PC est connecte par intermittence sur internet; et il a une nouvelle adresse IP pour chaque connexion Elle fait une recherche pour Hey Jude Application renvoie les autres pairs qui ont une copie de Hey Jude. Alice choisit un des pairs, e.g., Bob. Le fichier est copié du PC de Bob au portable d'alice via HTTP. Quand Alice télécharge le fichier, d'autres utilisateurs récupèrent des fichiers sur le PC d'alice. Alice (son PC) est donc à la fois client Web et un éphemère serveur Web. Tous les pairs sont serveurs = hautement ajustable! 74

75 P2P: avec annuaire centralisé La structure originelle de Napster 1) quand un pair se connecte, il informe le serveur central de: centralized directory server 1 1 Bob peers Son adresse IP Ses fichiers partages 2) Alice fait une requête pour Hey Jude ) Alice demande alors le fichier à Bob Alice 75

76 P2P: problèmes liès à un annuaire centralisé Un point de défaillance Goulot d'étranglement qui peut affecter la performance Pose des problèmes de Copyright Le fichier de transfert est décentralisé, mais l'annuaire des contenus est hautement centralisé 76

77 P2P par avalanche de demande: Gnutella Entièrement distribue Pas de serveur central Protocole de domaine public Beaucoup de clients Gnutella implementent ce protocole Structure en graphe Les noeuds sont les pairs Arrête entre un pair X un pair Y s'il y a une connexion TCP entre eux Attention une arrête n'est pas une liaison physique Un pair sera en général connecté avec 10 pairs voisins (dans le graphe) 77

78 Protocole de Gnutella Le requêtes sont envoyées sur les connexions TCP ouvertes Les pairs font passer ce message de requête a leurs voisins Lorsqu'un pair a une touche il l'envoie par le chemin inverse requête touche Transfert du fichier via HTTP Requête Touche Adaptabilité: une avalanche de demande limitée 78

79 Gnutella: entrée dans le graphe 1. Un pair X pour rejoindre Gnutella doit trouver un autre pair Gnutella: utilise alors une liste de candidat/représentant de Gnutella 2. X tente de façon répétée d'ouvrir une connexion TCP avec des pairs sur la liste jusqu'à ce qu'une connexion s'ouvre avec un pair Y 3. X envoie une message Ping à Y; Y renvoie le message Ping à ses voisins. 4. Tous les pairs recevant le message Ping message répondent avec un message Pong. 5. X reçoit beaucoup de messages Pong. Il peut alors ouvrir des connexions TCP supplémentaire. 79

80 Exploiter l'hétérogeneité: KaZaA Chaque pair est soit un chef de groupe soit assigné à un chef de groupe (pair enfant). connexion TCP entre les pairs et les chefs de groupe. connexions TCP entre certains couples de chef de groupe. Le chef de groupe recherche les contenus auprès de tous ses enfants. o r d i n a r y p e e r g r o u p - l e a d e r p e e r n e i g h o r i n g r e l a t i o n s h i p s i n o v e r l a y n e t w o r k 80

81 KaZaA: Requête Chaque fichier a un haché/empreinte associé ainsiqu'une description Le client envoie des mots clefs a tous ses chefs de groupes. Un chef de groupe répond avec des touches: Pour chaque touche: metadonnée, haché, addresse IP Si un chef de groupe fait passer la requête à d'autres chefs de groupe ils répondent avec des touches. Le client sélectionne alors ses fichiers pour le téléchargement Requête HTTP utilisant un haché comme identifiant est envoyé au pair détenant le fichier desiré 81