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

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

Master 1 SIGLIS

Ingénierie des réseauxStéphane Tallard

Chapitre 2 – La Couche Application

Master 1 SIGLIS

Ingénérie des réseaux 2

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”


Plan du Chapitre

Master 1 SIGLIS

2.1 Principes des applications réseau2.2. Web et HTTP 2.3 FTP 2.4 Courrier électronique

SMTP, POP3, IMAP 2.5 DNS2.7. Programmation Socket avec TCP 2.8 Programmation Socket avec UDP


Les objectifs du cours

Master 1 SIGLIS

• 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


Quelques applications réseau

Master 1 SIGLIS

• E-mail

• 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)


Pour créer une application réseau

Master 1 SIGLIS

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.


Chapitre 2 : La couche Application

Master 1 SIGLIS




Architectures applicatives

Master 1 SIGLIS

• Client – Serveur • Peer-to-Peer (P2P) • Hybride Client Serveur / P2P


Architecture Client Serveur

Master 1 SIGLIS

• 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.


Architecture P2P

Master 1 SIGLIS

• Les systèmes finaux communiquent directement

• Les pairs sont connectées par intermittence et peuvent changer d’adresse IP

• Exemple : Gnutella


Hybride client serveur /P2P

Master 1 SIGLIS

• 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.


Les processus communiquent

Master 1 SIGLIS

• 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.


Les sockets

Master 1 SIGLIS

• 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


Identifier les processus

Master 1 SIGLIS

• 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

• Pour recevoir les messages, les processus doivent avoir un identifiant


• 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

• Pour recevoir les messages, les processus doivent avoir un identifiant


• 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 : 194.167.156.236

• Numéro de port : 80


Un protocole de la couche application définit

Master 1 SIGLIS

• 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.


Exigences sur les services de transport

Master 1 SIGLIS

• 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


Exigences sur les services de transport

Master 1 SIGLIS

Application Perte de données Bande passante Sensible au temps

Transfert de fichier Pas de perte élastique Non

E-mail Pas de perte élastique Non

Documents Web Pas de perte élastique Non

Audio-video temps réel

Tolérant à la perte Audio : 5kbps-1Mbps. Vidéo 10kbps – 5Mbps.

Oui, ~ 100 ms

Audio-vidéo stocké Tolérant à la perte Audio : 5kbps-1Mbps. Vidéo 10kbps – 5Mbps.

Oui, quelques secondes

Jeux interactifs Tolérant à la perte Quelques Kbs Oui, ~ 100 ms

Messagerie instantanée

Pas de perte élastique Oui et non


Les services de protocoles de transport Internet

Master 1 SIGLIS

• 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 ?


Applications Internet: protocole application et protocole transport

Master 1 SIGLIS

Application Protocole Couche Application

Protocole couche transport sous jacent

e-mail SMTP TCP

Accès terminal distant Telnet TCP

Web HTTP TCP

Transfert de fichier FTP TCP

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


Un texte ici

Master 1 SIGLIS




Web et HTTP

Master 1 SIGLIS

• 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:

www.uneentreprise.com/unservice/pic.gif

Nom de l’hôte Chemin


Le protocole HTTP

Master 1 SIGLIS

• 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 HTTPRéponse HTTP

Req

uête

HTT

P

Rép

onse

HTT

P

PC + Navigateur

Web

Mac + Navigateur Web

Serveur + Serveur Web (Apache, Tomcat, …)


Le protocole HTTP

Master 1 SIGLIS

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


Connexions HTTP

Master 1 SIGLIS

HTTP non persistant

• Un objet au plus est envoyé sur une connexion TCP

• HTTP/1.0 utilise de l’HTTP non persistant

HTTP persistant

• 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 non persistant

Master 1 SIGLIS

L’utilisateur entre : http://www.univ-pau.fr

1a. Le navigateur initie une connexion TCP au serveur HTTP www.univ-pau.fr.

2. Le client HTTP envoie une requête HTTP (contenant l’url www.univ-pau.fr) 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 www.univ-pau.fr 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

tem

ps

http://www.univ-pau.fr/




Http non persistant : Evaluation du temps de réponse

Master 1 SIGLIS

RTT (Round Trip Time): Le temps entre l’envoi d’une requête et l’arrivée de la réponse.

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

Initialisation de la connexion TCP

Demande du fichier HTML

Fichier reçu

RTT

RTT

Tem

ps

de t

ransm

issi

on

du

fich

ier

Temps Temps


Inconvénient du HTTP non persistant

Master 1 SIGLIS

• 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.


HTTP Persistant

Master 1 SIGLIS

• 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

• Les clients envoient une nouvelle requête seulement quand la réponse précédente a été reçue

HTTP persistant avec pipelining

• 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é


Visualisation du trafic pour charger une page avec Firebug

Master 1 SIGLIS

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)

Le code retour

L’adresse du serveur

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

Nombre total de requêtes

Taille totale des objets

Durée totale


Message de requête HTTP

Master 1 SIGLIS

• Deux types de message HTTP : request, response

• Le message de requête HTTP est en ASCII

GET /somedir/page.html HTTP/1.1

HOST : www.univ-pau.fr

User-agent : Mozilla /6.0

Connection : keep-alive

Accept-language : fr

Type de la requête : ici GET

CR LF indique la fin de la ligne

Ligne d’entête



Message de réponse HTTP

Master 1 SIGLIS

Ligne de statut

Lignes d’entêtes

Données : ici le fichier html demandé


Message de requête HTTP: forme générale

Master 1 SIGLIS

Note: sp = space

Dans le cas d’une request, permet d’uploader un fichier.


Visualiser l’échange avec Firebug (1)

Master 1 SIGLIS

Affichage des entêtes

Que reconnaissez vous ?


Visualiser l’échange avec Firebug (2)

Master 1 SIGLIS

Visualisation des données


Les différents types de méthode

Master 1 SIGLIS

HTTP/1.0

• GET

• POST : pour les formes html

• HEAD

• Demander au serveur de renvoyer uniquement l’entête

HTTP/1.1

• GET, POST, HEAD

• PUT

• Upload d’un fichier

• DELETE

• Détruire un fichier spécifié dans le field URL


Les codes de status HTTP

Master 1 SIGLIS

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


Jouons un peu avec www.univ-pau.fr

Master 1 SIGLIS

Ouvre une connexion TCP sur le port 80 (serveur HTTP par défaut). Tout ce qui est tapé est envoyé à www.univ-pau.fr 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.



Caches Web (serveur proxy)

Master 1 SIGLIS

Objectif : répondre à la requête du client sans accéder au serveur initial

client

client

Serveur Proxy

Serveur

Serveur

Serveur

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

Req

uête

HTT

P

Rép

onse

HTT

P

Requête HTTP

Réponse HTTP

Requête HTTP

Réponse HTTP

Requête HTTP

Réponse HTTP

Requête HTTPRéponse HTTP


Stratégie d’optimisation: une étude de cas

Master 1 SIGLIS

Hypothèses

• Taille moyenne des objets : 100000 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

Internet public

Serveurs Initiaux

Liaison 1,5 Mbps

Réseau local à 10Mbs

c.f. ch 1 p.35

2s


Stratégie d’optimisation: mise à niveau matérielle

Master 1 SIGLIS

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)


= 2s + millisecondes + millisecondes

Mais la mise à niveau est souvent coûteuse

Liaison 10 Mbps

Internet public

Serveurs Initiaux


2s


Stratégie d’optimisation: Installation d’un cache

Master 1 SIGLIS

Internet public

Serveurs Initiaux


Ajout 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)


Liaison 1,5 Mbps

Avec cache

Sans cache

Délai internet 0s 2s

Délai liaison accès

0s 0.01

Délai LAN 0.01 0.01

Délai moyen : (0.4 * 0.01s) + (0.6 * 2.02s)Mais l’installation est beaucoup moins chère que la mise à niveau d’une liaison à 10 Mgbs

2s


Get Conditional (1)

Master 1 SIGLIS

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".

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

Get Conditionnel (2)

Master 1 SIGLIS

Client

Reponse httpHTTP/1.0

304 Not Modified

Cache ServerVérifier si sample.html est dans le cache client

Réponse : non

GET /sample.html HTTP/1.1Host: example.com

HTTP/1.x 200 OKVia: The-proxy-nameContent-Length: 32859Expires: Tue, 27 Dec 2005 11:25:11 GMTDate: Tue, 27 Dec 2005 05:25:11 GMTCache-Control: max-age=21600Last-Modified: Wed, 01 Sep 2004 13:24:52 GMTEtag: “4135cda4″ + <Data>

Affichage

Génération

L’utilisateur clique sur le lien sample.html

Stockage dans le cache local

sample.htmlGET /sample.html HTTP/1.1Host: example.comIf-Modified-Since: Wed, 01 Sep 2004 13:24:52 GMTIf-None-Match: “4135cda4″

Comparaison des dates

Recherche dans le cache local: on a l’objet en cache

Affichage

L’objet en cache est il toujours valide ?Réponse : Oui, l’objet est valide

Lecture dans le cache local



Master 1 SIGLIS




FTP : File Transfert Protocol

Master 1 SIGLIS

FTP ClientFTP User Interface

FTP Server

Transfert de fichier

Système de fichier local

Système de fichier distant

•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:


FTP: connexions de données et de contrôle

Master 1 SIGLIS

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.


FTP : commande et réponses

Master 1 SIGLIS

• 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


FTP : exemple de dialogue

Master 1 SIGLIS

Statut : Résolution de l'adresse de ftp.xxxxx.comStatut : Connexion à zzzzz.yyyyy.xxxx.www:21...Statut : Connexion établie, attente du message d'accueil...Réponse : 220---------- 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 loginRéponse : 220-IPv6 connections are also welcome on this server.Réponse : 220 You will be disconnected after 15 minutes of inactivity.Commande : USER [email protected]éponse : 331 User [email protected] OK. Password requiredCommande : PASS *******Réponse : 230 OK. Current restricted directory is /Commande : SYSTRéponse : 215 UNIX Type: L8Statut : ConnectéStatut : Récupération du contenu du dossier...Commande : PWDRéponse : 257 "/" is your current locationCommande : TYPE IRéponse : 200 TYPE is now 8-bit binaryCommande : PASVRéponse : 227 Entering Passive Mode (50,61,246,101,12,125)Commande : MLSDRéponse : 150 Accepted data connectionRéponse : 226-Options: -a -l Réponse : 226 6 matches totalStatut : Contenu du dossier affiché avec succèsCommande : RETR xxxxrarRéponse : 150-Accepted data connectionRéponse : 150 977.7 kbytes to downloadRéponse : 226-File successfully transferredRéponse : 226 5.798 seconds (measured here), 168.64 Kbytes per second

Statut : Transfert de fichier réussi, 1 001 178 octets transférés en 6 secondes



Master 1 SIGLIS




Courrier électronique

Master 1 SIGLIS

• 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

Agent Utilisateur

Agent Utilisateur

Serveur de mail

Agent Utilisateur

Serveur de mail

Serveur de mail

Agent Utilisateur

Agent Utilisateur

SMTP

SMTP

Queue des messages sortants

Boite aux lettres utilisateur

SM

TP


Serveurs de mail

Master 1 SIGLIS

• 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

Agent Utilisateur

Agent Utilisateur

Serveur de mail

Agent Utilisateur

Serveur de mail

Serveur de mail

Agent Utilisateur

Agent Utilisateur

SMTP

SMTP

Queue des messages sortants

Boite aux lettres utilisateur

SM

TP


SMTP [RFC 2821]

Master 1 SIGLIS

• 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


Scénario : Alice envoie un message à Bob

Master 1 SIGLIS

1. Alice utilise un agent utilisateur pour composer un message à [email protected]

2. Alice envoie le message à son serveur de mail : le message est placé dans la queue des messages

3. Le client SMTP ouvre une connexion TCP avec le serveur de mail de Bob.

4. Le client SMTP envoie le message d’Alice au dessus de la connexion TCP

5. Le serveur de mail de Bob place le message dans la boite de Bob.

6. Bob utilise l’agent utilisateur pour lire le message.

Agent Utilisateur

Serveur de mail

Serveur de mail Serveur de mail

Agent Utilisateur

mailto:[email protected]


Exemple d’une interaction SMTP

Master 1 SIGLIS

S : serveur

C : Client


SMTP

Master 1 SIGLIS

• 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.


Format des messages électroniques

Master 1 SIGLIS

• SMTP : protocole pour échanger les emails

• 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

Corps

Ligne vide


Format des message électroniques: extensions multimédia

Master 1 SIGLIS

• 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


Protocoles d’accès aux mails

Master 1 SIGLIS

Agent Utilisateur

Serveur de mail de l’envoyeur

Serveur de mail du destinataire

Agent Utilisateur

SMTP SMTPProtocoles d’accès

• 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…


Protocole POP3

Master 1 SIGLIS

•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


POP3 et IMAP

Master 1 SIGLIS

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

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



Master 1 SIGLIS




DNS: Domain Name System

Master 1 SIGLIS

• Les gens : des tas d’identifiants

• N°= sécurité sociale, nom, passeport, …

• Pour les hôtes et les routeurs Internet:

• les adresses IP sont utilisées pour convoyer les datagrammes

• les noms sont utilisés par les humains ex: www.yahoo.com

Question: Comment mapper les adresses IP et les noms ?

Réponse: Domain Name System (DNS)

• Base de données distribuée

• Implémentée en une hiérarchie de plusieurs serveurs de nom

• Un protocole de la couche application

• les hôtes, les routeurs, les serveurs de nom doivent communiquer pour résoudre les noms (traduction adresse/nom)

• Note: c’est une fonction du cœur d’Internet implémentée comme un protocole de la couche application

http://www.yahoo.com/


DNS: Domain Name System

Master 1 SIGLIS

Les services DNS

• traduction du nom d’hôte vers l’adresse IP

• alias de nom : ex relay1.west-coast.enterprise.com -> {enterprise.com , www.enterprise.com}

• Alias de serveurs de [email protected] au lieu [email protected]

• distribution de la charge

• pour les fermes de serveur un nom canonique est associé à un ensemble d’adresse IP

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 …)

http://www.enterprise.com/

mailto:[email protected]


DNS: Une base de données distribuée et hiérarchique

Master 1 SIGLIS

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

www.univ-pau.fr

Serveurs DNS us

Génériques Pays

Serveurs Top Level Domain (TLD)


DNS: Les serveurs de nom racine

Master 1 SIGLIS

• 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


Les serveurs autoritatifs et les serveurs TLD (Top-level domain)

Master 1 SIGLIS

•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 , …


Exemple de résolution: surf.eurocom.fr recherche gaia.cs.umass.edu

Master 1 SIGLIS

surf.eurocom.fr

Serveur de nom local dns.eurocom.fr

Serveur de nom racine

TLD DNS Server (xx.xx.xx.xx)

gaia.cs.umass.edu

(zz.zz.zz.zz)

• 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

Serveur autoritatif

dns.cs.umass.edu

(yy.yy.yy.yy)

•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


DNS: Cacher et mettre à jour les enregistrements

Master 1 SIGLIS

• 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


Enregistrements DNS

Master 1 SIGLIS

•DNS : une base de données distribuée stockant des enregistrements de ressource (RR)

RR (name,value, type, ttl)

•Type = A

• name est une nom d’hôte

• Value est adresse IP

•Type = NS

• name est un domain (ex foo.com)

• Value est le nom d’hôte du serveur de nom autoritatif pour ce domaine

• Type = CNAME

• Name est une nom d’alias pour un nom canonique (nom réel)

• www.ibm.com est vraiment servereast.backup2.ibm.com

• value est le nom canonique

• Type = MX

• value est le nom du serveur de mail associé à name

http://www.imbm.com/


Protocoles et messages DNS

Master 1 SIGLIS

•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


Protocoles et messages DNS

Master 1 SIGLIS

1. Description du nom et du type pour une requête

2. Les RRs trouvés en réponse à une requête

3. Les enregistrements trouvés pour les serveurs autoritatifs

4. Information additionnelle