Ingénierie des réseaux - Chapitre 2 : La Couche Application

Ingénierie des réseaux - Chapitre 2 : La Couche Application
Master 1 SIGLIS Ingénierie des réseaux Stéphane Tallard Chapitre 2 – La Couche Application Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Présentation du cours Ce cours s’appuie sur le cours réseau donnée à l’ University of California, Los Angeles (UCLA) par Deborah Estrin et Roozbeh Mottagi; lui-même basé sur « Computer Networking: A Top Down Approach , 5th edition par Jim Kurose, Keith Ross” Ingénérie des réseaux

Plan du Chapitre 2.1 Principes des applications réseau 2.2. Web et HTTP 2.3 FTP 2.4 Courrier électronique  SMTP, POP3, IMAP 2.5 DNS 2.7. Programmation Socket avec TCP 2.8 Programmation Socket avec UDP Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Les objectifs du cours Aspects conceptuels et internes des protocoles des applications réseau modèles de services de la couche transport paradigme client serveur paradigme peer-to-peer Apprendre sur les protocoles en examinant des protocoles populaires de la couche application HTTP FTP SMTP / POP3 / IMAP DNS Programmer une application réseau La bibliothèque des Sockets Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Quelques applications réseau Web Messagerie instantanée Remote login Partage de fichiers P2P Jeux en réseau multiutilisateurs Streaming vidéo Voix sur IP Conférence Vidéo en temps réel Grid computing (calcul distribué sur un réseau d’ordinateurs) Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Pour créer une application réseau Il faut écrire des programmes qui: fonctionnent sur différents systèmes communiquent à travers le réseau Ex : Les serveurs Web communiquent avec des navigateurs Une application réseau ce sont : une application qui tourne sur une machine qui émet une application qui tourne sur une machine qui reçoit des applications dans le cœur du réseau qui ne sont pas vues par l’utilisateur final. Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

 2.1 Principes des applications réseau 2.2. Web et HTTP 2.3 FTP 2.4 Courrier électronique  SMTP, POP3, IMAP 2.5 DNS 2.7. Programmation Socket avec TCP 2.8 Programmation Socket avec UDP Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Architectures applicatives Client – Serveur Peer-to-Peer (P2P) Hybride Client Serveur / P2P Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Architecture Client Serveur Le serveur Toujours sur un hôte Adresse IP permanente Des fermes de serveurs pour répondre à la charge (scaling) Les clients Communiquent avec le serveur Peuvent être connectés par intermittence Peuvent avoir une adresse IP dynamique Ne communiquent pas entre eux. Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Architecture P2P Les systèmes finaux communiquent directement Les pairs sont connectées par intermittence et peuvent changer d’adresse IP Exemple : Gnutella Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Hybride client serveur /P2P Skype Application P2P de voix sur IP Une serveur centralisé est utilisé pour stocker et rechercher les adresses des utilisateurs Il y a une connexion directe entre les clients et pas à travers un serveur Le flux de communication met en jeu les utilisateurs du réseau Messagerie instantanée Discussion entre deux utilisateurs en P2P Un service centralisé détecte la présence des utilisateurs et leur localisation Au moment de la connexion l’adresse IP des utilisateurs est enregistrée Les utilisateurs contactent le serveur central pour trouver les adresses IP des amis. Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Les processus communiquent Processus : se sont des programmes qui tournent sur un hôte Sur un même hôte, les processus communiquent en utilisant les services de communication inter processus définis par l’OS. Sur des hôtes différents, les hôtes communiquent en échangeant des messages. Le processus client initie la communication Le processus serveur attend qu’on le contacte Note: les applications P2P ont des processus client et des processus serveur. Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Les sockets Socket = Connecteur réseau Les processus reçoivent /envoient des messages à travers la couche réseau La socket est une interface sur les services transport définis par l’OS: Quand il émet le processus utilise les services de transport définis par l’OS La couche de transport de l’OS convoie le message vers l’OS du processus recevant. L’API permet : Le choix du protocole de transport Le paramétrage de la communication Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Identifier les processus Pour recevoir les messages, mes processus doivent avoir un identifiant Un hôte doit avoir une adresse IP 32-bits unique Question: est ce que l’adresse de l’hôte sur lequel tourne le processus suffit à identifier le processus ? Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Identifier les processus Pour recevoir les messages, les processus doivent avoir un identifiant Un hôte doit avoir une adresse IP 32-bits unique Question: est ce que l’adresse de l’hôte sur lequel tourne le processus suffit à identifier le processus ? Réponse : Non plusieurs processus peuvent tourner sur le même hôte Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Identifier les processus Pour recevoir les messages, les processus doivent avoir un identifiant Un hôte doit avoir une adresse IP 32-bits unique Question: est-ce que l’adresse de l’hôte sur lequel tourne le processus suffit à identifier le processus ? Réponse: Non plusieurs processus peuvent tourner sur le même hôte Les identifiants réseau contiennent non seulement l’adresse IP mais aussi le numéro de port Le port désigne le processus destinataire Exemple de numéros de port: Serveur HTTP: 80 Serveur de mail : 25 Pour envoyer un message HTTP au serveur portail.univ- pau.fr : Adresse IP : Numéro de port : 80 Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Un protocole de la couche application définit Le type des messages échangés Ex: requête, réponse La syntaxe des messages Les champs contenus dans les messages La façon dont les champs sont délimités La sémantique des messages La signification des informations dans les champs Les règles qui décrivent quand et comment les processus envoient et répondent aux messages Les protocoles du domaine public: Sont définis dans des RFCs (Request For Comments) Permettent l’interopérabilité Ex: HTTP, SMTP Il existe des protocoles propriétaires : Ex: Skype. Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Exigences sur les services de transport Perte de données Des applications (ex: audio) peuvent tolérer des pertes Des applications (ex: transfert de fichier, telnet) ont besoin d’un transfert de données 100% fiable Bande passante: Des application demandent un minimun de bande passante (ex: téléphonie internet). Des applications (applications « élastiques ») font avec la bande passante disponible (ex: courrier électronique). Performance Des applications (ex: téléphonie internet, jeux interactifs ) demandent des temps de réponse corrects Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Exigences sur les services de transport Application Perte de données Bande passante Sensible au temps Transfert de fichier Pas de perte élastique Non Documents Web Audio-video temps réel Tolérant à la perte Audio : 5kbps-1Mbps. Vidéo 10kbps – 5Mbps. Oui, ~ 100 ms Audio-vidéo stocké Oui, quelques secondes Jeux interactifs Quelques Kbs Messagerie instantanée Oui et non Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Les services de protocoles de transport Internet Service TCP Orienté connexion : un négociation est requise entre les processus client et les processus serveur Transport fiable entre les processus émetteur et récepteur Contrôle de flux: l’émetteur ne doit pas submerger le receveur Contrôle de congestion: l’émetteur doit ralentir lorsque le réseau est chargé Ne garantit pas : ni la performance, ni un minimum de bande passante. Service UDP Transfert de données non fiable entre l’émetteur et le récepteur Ne fournit pas: négociation, fiabilité, contrôle de flux, performance, bande passante Question: à quoi sert UDP ? Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Applications Internet: protocole application et protocole transport Application Protocole Couche Application Protocole couche transport sous jacent SMTP TCP Accès terminal distant Telnet Web HTTP Transfert de fichier FTP Streaming multimédia Propriétaire (ex : Realnetworks) TCP ou UDP Téléphonie Internet Propriétaire (Realnetworks) (ex : Vonage, Dialpad) Typiquement UDP Réponse: UDP est principalement utilisé pour le streaming Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Un texte ici 2.1 Principes des applications réseau 2.2. Web et HTTP 2.3 FTP 2.4 Courrier électronique  SMTP, POP3, IMAP 2.5 DNS 2.7. Programmation Socket avec TCP 2.8 Programmation Socket avec UDP  Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Web et HTTP Du vocabulaire: Une page Web contient des objets Des objets peuvent être des fichiers HTML , des images JPEG, des applet Java, des fichiers audio Des pages Web sont constitués d’un fichier HTML de base qui peut référencer plusieurs autres objets Chaque objet est adressable via une URL Exemple: Chemin Nom de l’hôte Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Le protocole HTTP HTTP : Hypertext Transfert Protocol C’est le protocole de la couche application du Web Conçu sur le modèle du client serveur Le client : le navigateur qui envoie des requêtes, reçoit et affiche des objets Web. Le serveur : Le serveur Web envoie des objets en réponse à des requêtes. Requête HTTP Réponse HTTP PC + Navigateur Web Serveur + Serveur Web (Apache, Tomcat, …) Réponse HTTP Requête HTTP Mac + Navigateur Web Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Le protocole HTTP HTTP utilise TCP Le client initie une connexion TCP (création d’une socket) sur le serveur, port 80 Le serveur accepte une connexion TCP du client Des messages HTTP sont échangés entre le navigateur (client HTTP) et le serveur Web (server HTTPP) La connexion TCP est fermée HTTP est « stateless » Le contenu des requêtes passées est perdu C’est au serveur de maintenir l’ état de l’interaction Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Connexions HTTP HTTP non persistant HTTP persistant Un objet au plus est envoyé sur une connexion TCP Plusieurs objets peuvent être envoyés sur une connexion unique entre le client et le serveur HTTP/1/1 utilise des connexions persistantes par défaut. HTTP/1.0 utilise de l’HTTP non persistant Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Http non persistant L’utilisateur entre : 1a. Le navigateur initie une connexion TCP au serveur HTTP 2. Le client HTTP envoie une requête HTTP (contenant l’url dans la socket de connexion TCP). 5. Le client HTTP reçoit le message de réponse contenant le fichier HTML et affiche l’HTML. En analysant le fichier html, il trouve 10 objets jpeg référencés. 6. Les étapes 1 à 5 sont répétées pour chacun des 10 objets jpeg. 1b. Le serveur HTTP est en attente de la connexion TCP sur le port 80. Le serveur accepte la connexion, et notifie le client . 3. Le serveur HTTP reçoit le message de requête, forme le message de réponse contenant l’objet demandé (un fichier html) et renvoie le message dans sa socket. 4. Le serveur ferme la connexion TCP temps Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Http non persistant : Evaluation du temps de réponse RTT (Round Trip Time): Le temps entre l’envoi d’une requête et l’arrivée de la réponse. Initialisation de la connexion TCP Le temps de réponse: Un RTT pour initier la connexion TCP Un RTT pour transférer le fichier Html Le temps de transmission du fichier Total = 2RTT + temps de transmission RTT Demande du fichier HTML RTT Temps de transmission du fichier Fichier reçu Temps Temps Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Inconvénient du HTTP non persistant Pour une pages qui référence n objets il faut initier n+1 connexions (1 fois pour le fichier html lui-même, n fois pour chaque objet) Le serveur doit réserver puis libérer une zone mémoire à chaque connexion L’initiation de la connexion est coûteuse en temps    Les navigateurs ouvrent des connexions TCP en parallèle pour télécharger les n objets. Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

HTTP persistant sans pipelining HTTP persistant avec pipelining
Optimisation: le server laisse la connexion ouverte après avoir envoyé la réponse La connexion est réutilisée pour les messages HTTP envoyés depuis/vers le même client. On gagne les temps d’initiation de la connexion On diminue le trafic réseau On diminue la charge HTTP persistant sans pipelining HTTP persistant avec pipelining Les clients envoient une nouvelle requête seulement quand la réponse précédente a été reçue C’est le mode par défaut en HTTP/1.1 Le client envoie des requêtes aussitôt qu’il rencontre un objet référencé Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Visualisation du trafic pour charger une page avec Firebug Firebug est un plugin Firefox qui permet (entre autres) de voir l’activité du browser Les requêtes envoyées et leur type (ici des GET) La taille de l’objet L’adresse IP du serveur et le port Les requêtes envoyées: on voit que les requêtes sont envoyées en parallèle : on est en HTTP 1.1 Le code retour L’adresse du serveur Nombre total de requêtes Taille totale des objets Durée totale Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Message de requête HTTP Deux types de message HTTP : request, response Le message de requête HTTP est en ASCII Type de la requête : ici GET GET /somedir/page.html HTTP/1.1 HOST : User-agent : Mozilla /6.0 Connection : keep-alive Accept-language : fr Ligne d’entête CR LF indique la fin de la ligne Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Message de réponse HTTP Ligne de statut Lignes d’entêtes Données : ici le fichier html demandé Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Message de requête HTTP: forme générale Dans le cas d’une request, permet d’uploader un fichier. Note: sp = space Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Visualiser l’échange avec Firebug (1) Affichage des entêtes Que reconnaissez vous ? Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Visualiser l’échange avec Firebug (2) Visualisation des données Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Les différents types de méthode HTTP/1.1 GET, POST, HEAD PUT Upload d’un fichier DELETE Détruire un fichier spécifié dans le field URL HTTP/1.0 GET POST : pour les formes html HEAD Demander au serveur de renvoyer uniquement l’entête Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Les codes de status HTTP Le code de statut est dans la première ligne de la réponse. Quelques codes : 200 OK Requête traitée avec succès 301 Moved Permanently Document déplacé de façon permanente 400 Bad Request La syntaxe de la requête est erronée 404 Not Found Ressource non trouvée 505 HTTP Version not supported Version HTTP non gérée par le serveur Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Jouons un peu avec Ouvre une connexion TCP sur le port 80 (serveur HTTP par défaut). Tout ce qui est tapé est envoyé à sur le port 80 Il s’agit d’une requête HTTP valide. Terminez là en tapant deux fois sur entrée. Faites le et regardez le message de réponse envoyé par le server HTTP. Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Exemple: L’architecture réseau de Wikipedia
Caches Web (serveur proxy) Objectif : répondre à la requête du client sans accéder au serveur initial Requête HTTP Réponse HTTP Ferme de serveurs Web Exemple: L’architecture réseau de Wikipedia Les objets html (fichiers html, Images, …) sont hébergés sur des serveurs Web Des serveurs proxy, optimisés pour la gestion du cache, stockent les fichiers qu’ils voient passer Quand un poste client demande un objet, le proxy serveur regarde si il possède l’objet, si oui il le renvoie Si non il envoie la requête à la ferme de serveurs. On tente d’éviter d’accéder à la ferme de serveurs client Requête HTTP Réponse HTTP Serveur Requête HTTP Réponse HTTP Requête HTTP Réponse HTTP Serveur Requête HTTP Réponse HTTP Serveur Proxy  client Serveur  Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Stratégie d’optimisation: une étude de cas
Hypothèses Taille moyenne des objets : bits Fréquence moyenne des requêtes http des navigateurs clients vers les serveurs web = 15req/s Temps d’accès du routeur institutionnel à un des serveurs Web et retour vers le routeur : 2s Conséquences Utilisation du LAN = 15% (15 req/s * 100Kb/req)/(10Mbps) Utilisation du lien d’accès = 100 % (15 req/s * 100Kb/req) / 1,5 M) Délai total = Délai Internet + Délai du lien d’accès + Délai sur le LAN = 2s + minutes + milliseconds Serveurs Initiaux Internet public 2s Liaison 1,5 Mbps Réseau local à 10Mbs  c.f. ch 1 p.35    Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Stratégie d’optimisation: mise à niveau matérielle
Une solution pour améliorer les performances Augmenter la bande passante sur la liaison d’accès : 1,5 Mbps  10 Mbps Conséquences Utilisation du LAN = 15% (15 req/s * 100Kb/req)/(10Mbps) Utilisation du lien d’accès = 15 % (15 req/s * 100Kb/req) / 10 Mbps) Délai total = Délai Internet + Délai du lien d’accès + Délai sur le LAN = 2s + millisecondes + millisecondes Mais la mise à niveau est souvent coûteuse Internet public Serveurs Initiaux Réseau local à 10Mbs 2s Liaison 10 Mbps     Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Stratégie d’optimisation: Installation d’un cache Hypothèse le taux de requête qui peuvent être satisfaites par le cache est de 0.4 Si l’activité est < 0.8, le temps de transfert est de 0.01s. Conséquences 40 % des requêtes peuvent être satisfaites presque instantanément 60 % des requêtes satisfaites par les serveurs initiaux Utilisation de la liaison d’accès est réduite à 60% : (15 req/s * 0.6 * 100Kb/req) / 1,5 M) Délai total = Délai Internet + Délai du lien d’accès + Délai sur le LAN Internet public Serveurs Initiaux Réseau local à 10Mbs 2s Liaison 1,5 Mbps Avec cache Sans cache Délai internet 0s 2s Délai liaison accès 0.01 Délai LAN Ajout d’un cache  Mais l’installation est beaucoup moins chère que la mise à niveau d’une liaison à 10 Mgbs Délai moyen : (0.4 * 0.01s) + (0.6 * 2.02s) Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Get Conditional (1) Objectif : ne pas renvoyer l’objet si le cache contient une version récente On se sert du cache local: le navigateur maintient un cache d’objets Le server n’insère pas l’objet dans la réponse si la copie est à jour : Les objets sont stockés dans le cache avec leur date de dernière modification (contenue dans l'entête ligne "Last-modified") Lorsque le navigateur voit passer une demande pour cet objet stocké dans le cache il envoie une requête "if-modified-since" avec la date stockée Si l'objet a été modifié le serveur renvoie l'objet Si l'objet n'a pas été modifié le serveur renvoie un code retour "not modified". Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Get Conditionnel (2) Client Cache Server Vérifier si sample.html est dans le cache client Réponse : non L’utilisateur clique sur le lien sample.html GET /sample.html HTTP/1.1 Host: example.com HTTP/1.x 200 OK Via: The-proxy-name Content-Length: Expires: Tue, 27 Dec :25:11 GMT Date: Tue, 27 Dec :25:11 GMT Cache-Control: max-age= Last-Modified: Wed, 01 Sep :24:52 GMT Etag: “4135cda4″ + <Data> Génération Stockage dans le cache local Affichage GET /sample.html HTTP/1.1 Host: example.com If-Modified-Since: Wed, 01 Sep :24:52 GMT If-None-Match: “4135cda4″ sample.html Recherche dans le cache local: on a l’objet en cache Comparaison des dates Reponse http HTTP/1.0 304 Not Modified L’objet en cache est il toujours valide ?Réponse : Oui, l’objet est valide Lecture dans le cache local Affichage Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

2.1 Principes des applications réseau 2.2. Web et HTTP 2.3 FTP 2.4 Courrier électronique  SMTP, POP3, IMAP 2.5 DNS 2.7. Programmation Socket avec TCP 2.8 Programmation Socket avec UDP  Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

FTP : File Transfert Protocol Transfert de fichier FTP Server  FTP Client FTP User Interface Système de fichier distant Système de fichier local Transfert de fichier de/vers hôte distant Modèle client/server Client : côté qui initie le transfert Serveur : hôte distant Il existe des clients FTP gratuits ex: Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

FTP: connexions de données et de contrôle
Serveur FTP Connexion de contrôle TCP port 21 Connexion de données TCP port 21 Client FTP Le client FTP contacte le serveur FTP sur le port 21. TCP est le protocole de transport utilisé. Le client est autorisé à ouvrir une connexion de contrôle. Le client utilise la connexion de contrôle pour naviguer dans les répertoires du serveur FTP. Quand le serveur reçoit une commande de transfert de fichier, le serveur ouvre une seconde connexion TCP Après avoir transféré le fichier, le serveur ferme la connexion de données. Le serveur ouvrira une autre connexion de données pour transférer un autre fichier Le serveur maintient un « état »: le répertoire courant qu’il est associe à l’utilisateur. Lorsque cet utilisateur se reconnectera, il sera placé dans ce répertoire : on évitera toutes les commandes de changement de répertoire. Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

FTP : commande et réponses Commandes FTP : elles sont envoyées en ascii sur le canal de contrôle Authentification USER <username> PASS <password> Navigation dans le répertoires de la machine distante LIST retourne une liste de fichiers CWD <Repertoire> change de répertoire Transfert de fichier RETR <filename> rapatrie le fichier vers le client STOR <filename> envoie un fichier vers le serveur Exemples de codes de retour 331 Username OK password required 125 data connection already open; transfert starting 425 Can’t open data connection 452 Error writing file Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

FTP : exemple de dialogue Statut : Résolution de l'adresse de ftp.xxxxx.com Réponse : seconds (measured here), Kbytes per second Statut : Connexion à zzzzz.yyyyy.xxxx.www:21... Statut : Transfert de fichier réussi, 1 001 178 octets transférés en 6 secondes Statut : Connexion établie, attente du message d'accueil... Réponse : Welcome to Pure-FTPd [privsep] [TLS] Réponse : 220-You are user number 2 of 50 allowed. Réponse : 220-Local time is now 08:41. Server port: 21. Réponse : 220-This is a private system - No anonymous login Réponse : 220-IPv6 connections are also welcome on this server. Réponse : 220 You will be disconnected after 15 minutes of inactivity. Commande : USER Réponse : 331 User OK. Password required Commande : PASS ******* Réponse : 230 OK. Current restricted directory is / Commande : SYST Réponse : 215 UNIX Type: L8 Statut : Connecté Statut : Récupération du contenu du dossier... Commande : PWD Réponse : 257 "/" is your current location Commande : TYPE I Réponse : 200 TYPE is now 8-bit binary Commande : PASV Réponse : 227 Entering Passive Mode (50,61,246,101,12,125) Commande : MLSD Réponse : 150 Accepted data connection Réponse : 226-Options: -a -l Réponse : matches total Statut : Contenu du dossier affiché avec succès Commande : RETR xxxxrar Réponse : 150-Accepted data connection Réponse : kbytes to download Réponse : 226-File successfully transferred Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Courrier électronique
Trois composant majeurs Agents utilisateur Serveur de mail SMTP : Simple Mail Transfer Protocol Agent Utilisateur lecteur de mail Composition, édition, lecture de messages Eudora, Outlook, Mozilla Thunderbird les messages entrants et sortants sont stockés sur le serveur Serveur de mail Agent Utilisateur S er ve ur d e m ail SMTP Queue des messages sortants Boite aux lettres utilisateur Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Serveurs de mail Serveurs de mail
Les boîtes aux lettres contiennent les messages entrants pour l’utilisateur Les queues de message contiennent les messages sortants en attente d’envoi Le protocole SMTP est utilisé pour envoyer les messages entre serveurs de mail. Le protocole SMTP une partie client qui envoie des messages une partie serveur qui reçoit des messages Serveur de mail Agent Utilisateur S er ve ur d e m ail SMTP Queue des messages sortants Boite aux lettres utilisateur Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

SMTP [RFC 2821] Utilise TCP pour transférer de manière fiable les messages du client au serveur sur le port 25 Le transfert est direct : du server envoyeur au serveur recevant Trois phases de transfert : serrage de main (« handshaking ») Transfert de messages Fermeture Interaction commande/réponse Commandes : texte Ascii Réponse : code de statut et phrase Les messages doivent être en ASCII 7-bits Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Scénario : Alice envoie un message à Bob Alice utilise un agent utilisateur pour composer un message à Alice envoie le message à son serveur de mail : le message est placé dans la queue des messages Le client SMTP ouvre une connexion TCP avec le serveur de mail de Bob. Le client SMTP envoie le message d’Alice au dessus de la connexion TCP Le serveur de mail de Bob place le message dans la boite de Bob. Bob utilise l’agent utilisateur pour lire le message. S er ve ur d e m ail  Serveur de mail Serveur de mail    Agent Utilisateur Agent Utilisateur   Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Exemple d’une interaction SMTP S : serveur C : Client Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

SMTP SMTP utilise des connexions persistantes : il utilise la même connexion pour envoyer plusieurs fichiers SMTP requiert que les messages (entête et corps) soient en ASCII 7-bits. SMTP utilise CRLF-CRLF pour déterminer la fin du message Comparaison avec HTTP: HTTP : pull - Le client demande au serveur SMTP : push - Le serveur envoie les messages au client Les deux ont des commandes et des réponses libellées en ASCII Les deux utilisent des codes de statut HTTP : chaque objet est encapsulé dans son propre message de réponse SMTP : plusieurs objets peuvent être envoyés dans un message multipart. Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Format des messages électroniques SMTP : protocole pour échanger les s RFC 822 : standard pour les messages texte lignes d’entête To: From: Subject: Ce ne sont pas des commandes SMTP Corps Le message contient uniquement des caractères ASCII Entête Ligne vide Corps Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Format des message électroniques: extensions multimédia MIME: Multimédia Mail Extension, RFC 2045, 2056 des lignes additionnelles dans l’entête du message déclarent les type du contenu MIME Version MIME Méthode utilisée pour encoder les données Type et sous type de la donnée multimédia Données encodées Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Protocoles d’accès aux mails Protocoles d’accès Serveur de mail de l’envoyeur Serveur de mail du destinataire SMTP SMTP Agent Utilisateur Agent Utilisateur SMTP : livraison/stockage sur le serveur du receveur Protocoles d’accès aux mails : transfert depuis le serveur POP: Post Office Protocol [RFC 1939] autorisation (agent < -- > serveur ) et téléchargement IMAP: Internet Mail access Protocol [RFC 1730] davantage de fonctionnalités manipulations de messages stockés sur le serveur HTTP : gmail, Yahoo!Mail, etc… Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Protocole POP3 Phase d’autorisation commandes client user : déclare le nom de l’utilisateur pass : mot de passe Réponses du serveur +OK -ERR Phase de transaction, client list liste les numéros de message retr : transfère les messages par numéro dele : destruction Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

POP3 et IMAP IMAP laisse tous les messages en un seul endroit : le serveur Permet à l’utilisateur d’organiser ses messages en dossiers IMAP conserve l’état de l’utilisateur à travers les sessions: conservation de noms des dossiers conservation des correspondances entre les identifiants de messages et les noms de dossiers Davantage d’informations sur POP3 L’exemple précédent utilise le mode « download et delete » Bob ne peut pas relire ses mail si il change de client Le mode « download-and-keep » : copie les message sur des clients différents Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

DNS: Domain Name System Les gens : des tas d’identifiants Réponse: Domain Name System (DNS) N°= sécurité sociale, nom, passeport, … Base de données distribuée Implémentée en une hiérarchie de plusieurs serveurs de nom Pour les hôtes et les routeurs Internet: Un protocole de la couche application les adresses IP sont utilisées pour convoyer les datagrammes les hôtes, les routeurs, les serveurs de nom doivent communiquer pour résoudre les noms (traduction adresse/nom) les noms sont utilisés par les humains ex: Note: c’est une fonction du cœur d’Internet implémentée comme un protocole de la couche application Question: Comment mapper les adresses IP et les noms ? Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

DNS: Domain Name System Pourquoi ne pas centraliser le DNS ? introduit un point de défaillance généralisée: en cas d’erreur le réseau est paralysé volume du trafic distance au lieu d’installation Maintenance: comment réaliser les habituelles opérations de maintenance (mise à jour système, remplacement de périphériques …) Les services DNS traduction du nom d’hôte vers l’adresse IP alias de nom : ex relay1.west-coast.enterprise.com -> {enterprise.com , Alias de serveurs de mail au lieu distribution de la charge pour les fermes de serveur un nom canonique est associé à un ensemble d’adresse IP Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

DNS: Une base de données distribuée et hiérarchique Génériques Pays Serveurs DNS Racine Serveurs DNS com Serveurs DNS yahoo Serveurs DNS amazon Serveurs DNS edu Serveurs DNS gov Serveurs DNS org Serveurs DNS net Serveurs DNS fr Serveurs DNS us  Serveurs Top Level Domain (TLD) Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

DNS: Les serveurs de nom racine ils sont contactés par le serveur de nom local lorsqu’il ne peut pas résoudre un nom Le serveur de nom racine contacte le serveur de nom autoritatif si la correspondance n’est pas trouvée obtient la correspondance retourne la correspondance au serveur de nom local IL y a 13 serveurs de nom racine Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Les serveurs autoritatifs et les serveurs TLD (Top-level domain) Les serveurs de noms autoritatifs: tous les hôtes sont enregistrés dans une serveur de nom autoritatif Les serveur de nom racine savent trouver pour un nom, soit la correspondance soit le serveur de nom autoritatif qui va trouver la correspondance. Le serveurs de nom TLD gèrent les domaines génériques com , org, net ,edu, etc , et les nom des pays uk, fr, can jp , … Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Exemple de résolution: surf.eurocom.fr recherche gaia.cs.umass.edu Serveur de nom racine Les requêtes sont itérées : Si le serveur connait le nom, il répond par la correspondance sinon il répond par l’adresse d’un serveur dont il pense qu’il a la réponse   TLD DNS Server (xx.xx.xx.xx)   Serveur de nom local dns.eurocom.fr 1: gaia.cs.umass.edu ? 2:Quel est le serveur TLD pour edu ? 3: le serveur pour edu est xx.xx.xx.xx 4: Quel est le serveur autoritatif pour gaia.cs.umass.edu ? 5: Le serveur autoritatif pour gaia.cs.umass.edu est yy.yy.yy.yy 6: gaia.cs.umass.edu ? 7: zz.zz.zz.zz  Serveur autoritatif dns.cs.umass.edu (yy.yy.yy.yy)    surf.eurocom.fr gaia.cs.umass.edu (zz.zz.zz.zz) Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

DNS: Cacher et mettre à jour les enregistrements Lorsqu’un serveur a appris une correspondance, il la cache les entrées du cache disparaissent après un certain temps (time out) Les serveurs TLD sont typiquement cachés dans les serveurs de nom locaux c’est pourquoi les serveurs de nom racine ne sont pas souvent visités. Les mécanismes de mise à jour et de notification sont conçus par l’IETF RFC 2136 Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Enregistrements DNS DNS : une base de données distribuée stockant des enregistrements de ressource (RR) RR (name,value, type, ttl) Type = A Type = CNAME name est une nom d’hôte Name est une nom d’alias pour un nom canonique (nom réel) Value est adresse IP est vraiment servereast.backup2.ibm.co m Type = NS name est un domain (ex foo.com) Value est le nom d’hôte du serveur de nom autoritatif pour ce domaine value est le nom canonique Type = MX value est le nom du serveur de mail associé à name Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Protocoles et messages DNS Le protocole DNS est constitué de messages de requêtes, tous ayant des entêtes de message. Identification de la requête sur 16 bit La réponse reprend l’identification Le serveur peut alors rapprocher une réponse d’une requête envoyée Des flags query or reply recursivité désirée récursivité disponible la réponse est autoritative Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Protocoles et messages DNS Description du nom et du type pour une requête Les RRs trouvés en réponse à une requête Les enregistrements trouvés pour les serveurs autoritatifs Information additionnelle     Master 1 SIGLIS Ingénierie des réseaux - Chapitre 2 : La Couche Application

Ingénierie des réseaux - Chapitre 2 : La Couche Application

Présentations similaires

Présentation au sujet: "Ingénierie des réseaux - Chapitre 2 : La Couche Application"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back

Entrer

S'autoriser via un réseau social:

Ingénierie des réseaux - Chapitre 2 : La Couche Application

Présentations similaires

Présentation au sujet: "Ingénierie des réseaux - Chapitre 2 : La Couche Application"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back