Master Miage Réseau. La couche Application

La couche Application

2007-2008

Réseau

application

Application (réseau): processus répartis qui communiquent

 Tournent dans les hosts dans

“l’espace utilisateur”

 Échangent des messages pour

réaliser la fonction de l’application

 Ex : email, ftp, Web

Protocoles : couche Application

 Un “morceau” d’une application

 Définit les messages échangés par les appli. et les actions à réaliser

 Utilise les services de communication fournis par les protocoles de couche inférieure (TCP, UDP)

application transport

network data link

physical

application transport

network data link

physical application

transport network data link

physical

Applications réseau : terminologie

Processus: programme qui s’exécute sur un host

 Dans le même host, deux processus communiquent en utilisant les mécanismes

IPC (définis par le système d’exploitation)

InterProcess Communication

 Deux processus tournant dans des hosts différents communiquent via un

protocole de couche application

 Agent utilisateur (user agent): processus

s’interfaçant avec

l’utilisateur “en haut” et le réseau “en bas”

 Implante le protocole de couche application

 Web: navigateur

 E-mail: utilitaire de mail (Mozilla, Outlook, …)

 Flux audio/video: media player

Le paradigme Client-serveur

Une appli réseau a deux

morceaux: client et serveur application transport

network data link

physical

application transport

network data link

physical

Client:

 Initie le contact avec le serveur (“parle en 1er”)

 Demande un service

 Web: client implanté dans le navigateur; e-mail: dans

l’utilitaire de mail

request

reply

Serveur:

 Fournir les services demandés aux clients

 Ex : le serveur Web envoie la page Web demandée, le serveur de mail délivre le courrier

Le paradigme pair à pair (pi2pi)



Un terminal est pair car il peut être à la fois client et à la fois serveur (tt le monde est sur un pied d'égalité).

 Ex. Download de fichier tout en laissant dispo le téléchargement sur son terminal.

 Pour échange de fichiers

 Pour calculs (xtreme web)



Impose

 protocole commun d'échange des infos

 gestion des participants.



Ex.

 1999 Napster (info centralisé)

 2000 Gnutella (décentralisé)

 2002 bit torrent

(fractionnement fichiers)

De quel service de transport une application a-t-elle besoin ?

Perte de données

 Certaines appli (ex, audio) tolèrent des pertes

 D’autres (ex transfert fichiers) nécessitent un transfert fiable à 100%

Délai

 Certaines appli (ex,

téléphonie Internet, jeux interactifs) nécessitent des délais faibles pour être

efficaces

Bande passante

 Certaines appli (ex,

multimedia) nécessitent un montant minimum de BP pour être efficace

 D’autres (“appli

élastiques”) fonctionnent quelque soit la BP dont elles disposent (email, Web, transfert de

fichiers)

Besoins en services de transport des applications courantes

Application file transfer e-mail Web documents real-time audio/video stored audio/video interactive games financial apps

Data loss no loss no loss

loss-tolerant loss-tolerant loss-tolerant loss-tolerant no loss

Bandwidth elastic

elastic elastic

audio: 5Kb-1Mb video:10Kb-5Mb same as above few Kbps up elastic

Time Sensitive no

no no

yes, 100’s msec yes, few secs yes, 100’s msec yes and no

Les services

des protocoles de transport Internet

Service TCP:

 Orientée-connexion: connexion entre le client et le serveur

 Transport fiable entre processus émetteur et récepteur

 Contrôle de flux : l’émetteur n’engorge pas le récepteur

 Contrôle de congestion : étranglement de l’émetteur quand le réseau est

surchargé

 Ne fournit pas : garantie de délai, garantie d’un minimum de bande passante

Service UDP:

 Transfert de données non fiables entre processus émetteur et récepteur

 Ne fournit pas :

établissement de connexion, fiabilité, contrôle de flux, contrôle de congestion, garanties de délai et de bande passante

Pourquoi y a-t-il un UDP?

Protocoles de couche application

API: Application Programming Interface

 Définit l’interface entre l’application et les couches transport

 Ex : socket (prise)

 API Internet

 Deux processus communiquent en envoyant des données sur la

socket et en lisant les données de la socket

Comment un processus identifie-t-il l’autre

processus avec lequel il veut communiquer ?

 adresse IP de l’host sur lequel tourne l’autre

processus

 “numéro de port” - permet à l’host récepteur de

déterminer à quel

processus local le message doit être délivré

… plus de détails plus tard

Le Web: le protocole http

http: HyperText Transfer Protocol

 Protocole de couche application de l’application WWW

 Modèle client/serveur

 client: navigateur qui demande, reçoit et affiche des objets Web (fichier html, image

JPEG, GIF, applet java, …). Le navigateur est aussi le user

agent

 serveur: serveur Web qui envoie les objets en réponse aux requêtes

 http1.0: RFC 1945

 http1.1: RFC 2616

PC avec IE

Serveur exécutant un serveur Web

Apache Mac avec

Netscape Navigator

http re

quest

http request http resp

onse

http r

esponse

Le protocole http : plus de détails

http: service de transport TCP

 Le client initie une connexion TCP (crée une socket) vers le serveur, en utilisant le n° de port 80

 Le serveur accepte les connexions TCP du client

 Les messages http (APDU) sont

échangés entre le navigateur (client http) et le serveur Web (serveur http)

 La connexion TCP est fermée

http est “stateless”

 Le serveur ne maintient aucune information sur les requêtes des clients

Les protocoles qui maintiennent un état sont complexes !

 Historique (état) à maintenir

 Si le serveur/client tombe, leurs états respectifs

peuvent être incohérents, et doivent être réconciliés

aparté

Un exemple http

Soit un utilisateur qui saisit l’URL

www.someSchool.edu/someDepartment/home.index 1a. Le client http initie la connexion

TCP to serveur http (processus) sur la machine www.someSchool.edu. Le

port 80 est le numéro par défaut de ce serveur http (ce processus).

2. Le client http envoie un

request message http (contenant l’URL) sur la socket TCP

1b. Le serveur http de la machine www.someSchool.edu est en

attente sur la connexion TCP au port 80. Il accepte la

connexion, et notifie le client

3. Le serveur http reçoit le message, forme le response message contenant l’objet demandé

(someDepartment/home.index), émet le message sur la socket

temps

(contient du texte, et des références à 10

images jpeg )

Suite de l’exemple http

5. Le client http reçoit le msg de réponse contenant le fichier html, affiche le html. En parsant le fichier html, il trouve les 10 références

d’objets JPEG (liens)

6. Les étapes 1 à 5 sont répétées pour chaque objet JPEG

4. Le serveur http ferme la connexion TCP

temps

Connexion non persistante

Combien de connexions TCP sont-elles nécessaires ?

Connexions non-persistantes, persistantes

Non-persistante

 http/1.0: le server parse la requête, répond, ferme la connexion TCP

 Combien de RTTs pour aller chercher l’objet requis ?

 La plupart des navigateurs ouvrent des connexions

parallèles multiples

Persistante (keep alive)

 Par défaut pour http/1.1

 Sur la même connexion TCP : le serveur parse la requête, répond, parse la nvlle requête,…

 Il fermera la connexion après son inutilisation durant un certain

temps (configurable)

 Avec pipeline : Le client envoie une requête dès qu’il rencontre une

référence

 Sans pipeline : possible, pas le

mode par défaut de 1.1. Le client envoie une requête après avoir

reçu la réponse de la requête précédente

Non-persistante (close)

 http/1.0: le serveur parse la requête, répond, ferme la connexion TCP

 2

 La connexion TCP

 La requête/transfert d’objet

 La plupart des navigateurs ouvrent des connexions

parallèles multiples

Combien de RTT pour la page web précédente ?

Format des messages http : request

 Deux types de messages http : request, response

 Le message http de request :

 ASCII (format lisible)

GET /somedir/page.html HTTP/1.1 Host: www.someschool.edu

Connection:close

User-agent: Mozilla/4.0 Accept-language:fr

(extra carriage return, line feed) request line

3 champs

Header lines Carriage return,

line feed indicates end

of message

URL requise Méthode

(HEAD, POST,

GET) Version du protocole

Non persistante Netscape

En-tête HTTP (1.1)

requêtes



Méthodes

 GET Pour demander une ressource est sans effet sur la ressource.

 HEAD Ne demande que des informations sur la ressource, sans demander la ressource.

 POST Utilisée lorsqu'une requête modifie la ressource.

 OPTIONS Permet d'obtenir les options de communication d'une ressource ou du serveur en général.

 CONNECT Permet d'utiliser un proxy comme un tunnel de communication.

 TRACE Demande au serveur de retourner ce qu'il a reçu. But test et diagnostic sur la connexion.

En-tête HTTP 1.1

Options des Requêtes



Host



Referer



User-Agent



Connection



Accept types



Accept-Charset



Accept-Language

Format des messages http : response

HTTP/1.1 200 OK

Date: Thu, 06 Aug 1998 12:00:15 GMT Server: Apache/1.3.0 (Unix)

Accept-Ranges: bytes Content-Language: fr Content-Length: 6821 Content-Type: text/html

ETag: "ab010-2adf-3d202062”

Last-Modified: Mon, 22 Jun 1998 ……

data data data data data ...

status line (3 champs)

header lines

Data

(ex : Fichier html demandé)

Version du protocole Status code status phrase

En-tête HTTP (1.1):

 Le chiffre des centaines représente une classe de réponses.

 1xx Information

 2xx Succès

 3xx Redirection

 4xx Erreur du client

 5xx Erreur du serveur



Exemples 

200 OK Requête réussie, l’objet demandé est dans le message

301 Moved Permanently L’objet demandé a été déplacé, sa nouvelle localisation figure dans ce message (Location:)

400 Bad Request

 Message de requête non compris par le serveur

404 Not Found

 Doument demandé non trouvé sur le serveur

505 HTTP Version Not Supported

En-tête réponses HTTP (1.1)

Options



Date Moment auquel le message est généré.



Server Modèle du serveur HTTP qui répond à la requête.



Content-Length Taille en octets de la ressource.



Content-Type type MIME de la ressource.



Expires date après laquellle la ressource devrait être considérée obsolète



Last-Modified Date de dernière modification de la

ressource.

Interaction utilisateur-serveur : authentification

Authentification : contrôle d’accès au contenu du serveur

 Autorisation : généralt nom, mot de passe

 Sans état : le client doit présenter son autorisation à chaque requête

 authorization: ligne d’entête à chaque requête

 Si pas authorization: le

serveur refuse l’accès, et utilise le message de status code 401

WWW authenticate:

client serveur

usual http request msg 401: authorization req.

WWW authenticate:

usual http request msg + Authorization: <cred>

usual http response msg

usual http request msg + Authorization: <cred>

usual http response msg time

Cookies : gardien d’état

 Le serveur génère un n°

d’identification, qu’il mémorise et qu’il utilise pour :

 L’authentification

 Le stockage des préférences de l’utilisateur

 Le serveur envoie le

“cookie” au client dans un message response

Set-cookie: 1678453

 Le client présente le cookie dans ses requêtes futures

cookie: 1678453

client serveur

usual http request msg usual http response +

Set-cookie: #

usual http request msg

cookie: #

usual http response msg

usual http request msg

cookie: #

usual http response msg

cookie- specific

action

cookie- specific

action

GET conditionnel : cache côté client

 But : Ne pas envoyer l’objet si le client a une version à jour dans son cache

 Client: spécifie la date de la version cachée dans la requête http

If-modified-since: <date>

 Serveur : la réponse ne contient pas d’objet si la version cachée est à jour :

HTTP/1.0 304 Not Modified

client serveur

http request msg

If-modified-since:

<date>

http response

HTTP/1.0 304 Not Modified

objet modifiénon

http request msg

If-modified-since:

<date>

http response

HTTP/1.1 200 OK

<data>

objet modifié

Cache Web (serveur proxy)

 L’utilisateur utilise un

navigateur : le Web accède au cache web

 Le client envoie toutes les requêtes http au cache web

 L’objet est dans le cache:

le cache l’envoie

 Sinon le cache demande l’objet au serveur

d’origine, puis l’envoie au client

But : satisfaire la reqûete client sans invoquer le serveur d’origine

client

Proxy server

client

http req uest

http request http r

esponse

http r

esponse

http request http re

sponse

origin server origin server

Pourquoi les caches Web ?

Hypothèse : le cache est

“proche” du client (par ex., dans le même réseau)

 Réduction des temps de réponse (la réponse vient

plus vite puisqu’elle vient de moins loin)

 Réduction du trafic sur le réseau

 Pas de génération de trafic pour aller chercher la réponse sur un site éloigné

Quelle différence de temps

origin servers

public Internet

institutional

network 10 Mbps LAN

1.5 Mbps access link

institutional cache

HEAD http://www.inria.fr/index.fr.html

 Quel est l’effet de cette commande (sous linux) ?

 Quel est le type et la version du serveur HTTP distant ? Quel type de connexion supporte-t-il ?

 Connectez vous avec un telnet à l'inria (sur le port 80) et tapez la requête HTTP équivalent à cette commande.

 Modifiez la requête pour avoir l'ensemble des données de la page

 Télécharger une image contenue dans cette page

 Modifiez le champs Accept-langage:en.Le texte est-il en anglais ? (et en remplaçant fr par en dans URI)

Exercices II

 Même chose avec Nanterre ?

telnet www.u-paris10.fr 80 GET ? HTTP/1.1

Host: www.u-paris10.fr Connection:close

 Essayez de vous connecter en remplaçant www.u-paris10.fr par ksup.u-paris10.fr dans le telnet

 Essayez de vous connecter en remplaçant également dans le host

 Identifiez vous le cookie ?

Exercices III

L'URL est : http://www.blabla.fr/unfichier.html

 Quel est le terminal (host) ?

 Quel est le chemin du fichier ?

Donner la version de votre requete HTTP (contenu GET et Host)

 Vérifier avec

http://guilde.jeunes-chercheurs.org/Guilde/index.html

Et si vous essayiez d'aller à (avec votre navigateur)

http://postes.smai.emath.fr/2002/index.php

 Avec telnet

Quel va devoir être votre réponse ? Authorization: BASIC 

d2VibWFzdGVyOnpycW1d2VibWFzdGVyOnpycW1  qui est encodage (en base 64) de login:mdp

Les « sessions » WEB



Définition Session :

Connexion d'une durée indéfinie (bornée) entre un utilisateur et un correspondant (généralement un serveur).

Elle nécessite l'échange de messages entre les deux parties



Principe d'une session :

 Permet de conserver des informations sur un

internaute tout au long de sa visite sur un site. Pour lui donner l'impression d'une seule connexion.



Contraintes d'une session

 Identifier l'utilisateur alors que http est «stateless»

 Associer à l'utilisateur certaines valeurs

 Associer à l'utilisateur espace mémoire (2^nd temps)

Les « sessions » WEB



Identification de la connexion

 Dans les cookies.

 Dans l'URL (présente sous la forme session=xxx).

 Dans l'URL (forme variable précise gérée par utilisateur).



Sauvegarde des infos

 Dans la base de données du site (ou fichier) pour associer des informations à cette session. Info rémanentes.

 Dans l'espace mémoire associé à la session.



Passage des valeurs

 Par les URI (?valeur)

 La session (valables tout le temps)

Authentification

(au niveau application)



Gérée par le serveur (au niveau http)

 htaccess avec serveur Apache

Mot de passe, Adresse IP

 Contrôle l'accès à la page elle-même

 Aucun fichier html renvoyé si mauvaise identification



Gérée par la session (au niveau html)

 Fichier html renvoyé

 Contrôle d'accès à partir d'une page web

 Gestion par l'application

Htaccess



Redirections des pages d'erreurs



URL rewritting



“Réécriture” des Index des répertoires



Restriction d'accès pour un répertoire et son arborescence

 2 fichiers

Gestion des authentification : .htaccess

Gestion des mots de passe : .htpasswd



Syntaxe du .htaccess (pour authentification)

 En tête

 Authentification par login

 Authentification par @IP ou par domaine

.htaccess

(Restriction d'accès par nom)

 En tête :

AuthType Basic

- Authentification de type basique les mots de passe circulent en clair sur le réseau (encodés en base64)

AuthUserFile /chemin/absolu/sur/serveur/.htpasswd - N.B. Le nom .htpasswd peut être changé

AuthName ''Le message mis pour l'utilisateur''

 Activation service (autorisation nécessaire pour methode get et post)

<LIMIT GET POST> 

require valid­user

</LIMIT>



Fichier mots de passe

.htaccess

(Restriction d'accès par domaine)

 Interdiction (autorisation) totale

deny from all (allow from all)

 Interdiction @ IP (Autorisation plage @ IP)

deny from 192.168.1.2 (allow from 192.168.2)

 Interdiction (autorisation) domaine

deny from microsoft.com (allow from .fr)

 Ordre sur les traitements

order deny allow Traite d'abord refus puis autorisations

 L'appliquer aux méthodes GET & POST (avec balise limit)

 Appliquer à un fichier

balise <file nom> encapsulant config. des restrictions

 Modification des accès pour sous répertoire

Nouveau fichier htaccess pour tout le sous rep.

FTP: File Transfer Protocol

 Transfère des fichiers d’un/vers un hôte distant

 Modèle client/serveur

 client: côté qui initie le transfert (de/vers le distant)

 serveur: hôte distant

 ftp: RFC 959

 serveur ftp : port 21

file transfer FTP server userFTP

interface

clientFTP

Système de fichiers local

Système de fichiers distant utilisateur

sur host

ftp: connexions séparées pour le contrôle et les data

 Le client ftp contacte le serveur ftp sur le port 21, en spécifiant TCP comme protocole de transport

 Deux connexions TCP parallèles sont ouvertes :

 Contrôle : échange des

commandes et réponses entre le client et le serveur

“contrôle hors bande”

 Données : fichier de données du/vers le serveur

 Le serveur ftp maintient un “état”: le répertoire courant, l’authentification lors de la connexion

clientFTP FTP

server

TCP control connection port 21

TCP data connection port 20

Les commandes ftp sont envoyées comme du texte ASCII sur le canal de contrôle



Que font les commandes suivantes ?

 open, user, pwd, cd, lcd, get, recv, mget, put, send, mput, status

 Un peu d'aide :

Sur miage03, lancer le client ftp miage03$ftp

help : liste des commandes ftp>? nom-commande



Ouvrir une connexion avec ftp.lip6.fr en login anonyme : rapatrier le rapport LIP6 le plus récent (/lip6/reports/……

…….)



Ftp sécurisé (sftp) le lip6 accepte-t-il le ftp sécurisé ?



Quelles commandes sont disponible avec le sftp

Courrier électronique

Trois composants majeurs :

 user agents

 Serveurs de mail

 SMTP : Simple Mail Transfer Protocol

User Agent

 Appelé parfois “mail reader”

 Composer, éditer, lire les messages

 Ex de user agent GUI : Eudora, Outlook, Netscape Messenger

 Ex de user agent non GUI : elm, mail, pine

 Les messages sortants et entrants sont stockés sur le serveur

user mailbox outgoing message queue

servermail

agentuser

agentuser

agentuser servermail

agentuser agentuser

servermail

agentuser

SMTP SMTP SMTP

Les serveurs de mail

Trois éléments

 Les mailbox qui contiennent les

messages entrants (encore non lus) des utilisateurs

 La file des messages sortants (qui doivent être expédiés)

 Le protocole SMTP entre serveurs de mail pour envoyer les messages

 Modèle client/serveur

 Sur le serveur de mail S, le client SMTP s’occupe de

l’expédition du mail

 Sur le même serveur de mail S, le serveur SMTP s’occupe de la réception du mail

servermail

agentuser

agentuser

agentuser servermail

agentuser agentuser

servermail

agentuser

SMTP SMTP SMTP

Courrier électronique : smtp [RFC 821]

 Utilise tcp pour transférer de façon fiable un message d’un client vers un serveur, port 25

 Transfert direct : du serveur émetteur vers le serveur récepteur

 Trois phases de transfert

 Ouverture

 Transfert de messages

 Fermeture

 Interaction de forme commande/réponse

 Commandes : texte ASCII

HELO, MAIL, FROM, RCPT TO, DATA, QUIT

 Réponses : status code et phrase

 Les messages doivent être en ASCII 7-bits

Analyse des interactions smtp

S: 220 miage03.miage.u-paris10.fr ESMTP Sendmail ...

C: HELO miage03.miage.u-paris10.fr

S: 250 ... Hello miage03…, pleased to meet you

C: MAIL FROM: <[email protected]>

S: 250 [email protected]... Sender ok C: RCPT TO: <[email protected]>

S: 250 user1@miage03.miage.u-paris10.fr... Recipient ok

C: DATA

S: 354 Enter mail, end with "." on a line by itself C: Je simule un user agent qui dialogue avec le MTA C: .

S: 250 Message accepted for delivery C: QUIT

S: 221 miage03.miage.u-paris10.fr closing connection

Ouverture

(handshaking)

fermeture transfert

Comparaison smtp - http

 Échange d’informations

 Connexions persistantes

 Interactions de type commande/réponse et status codes en ASCII

smtp

 Mode push

 l’utilisateur envoie de

l’information et la connexion TCP est ouverte par l’émetteur de l’information

 Messages (entête & corps) en ASCII 7-bits

 Qq strings non permises dans les msg (CRLF.CRLF)

http

 Mode pull

 l’utilisateur retire de

l’information et la connexion TCP est ouverte par le

récepteur de l’information

(Dans le champs “Data”)

RFC 821: standard smtp

RFC 822: standard du format des messages texte

 Format des lignes d’entête construites par le user agent

 To:

 From:

 Subject:

différent des commandes . smtp!

pas le même TO, FROM

 Format du corps du message

 Caractères ASCII

Entête

Corps

Ligne de blanc

!

É, è, â, ç et autres

?

Les extensions multimédia

 MIME: Multimedia Mail Extension, RFC 2045, 2056

 Règles d’encodage des données non-ASCII 7 bits

 Des lignes supplémentaires dans l’entête du message déclarent le contenu de type MIME

From: [email protected] To: [email protected]

Subject: Picture of yummy crepe.

MIME-Version: 1.0

Content-Transfer-Encoding: base64 Content-Type: image/jpeg

base64 encoded data ...

...

...base64 encoded data

Nature du contenu méthode utilisée pour coder les données (base64, quoted-printable

encoding, …) Version MIME

Données codées

Les types MIME

Content-Type: type/subtype; parameters

Texte

 Exemples de sous-types : plain, html

Image

 Exemples de sous-types : jpeg, gif

Audio

 Exemples de sous-types : basic (8-bit mu-law encoded), 32kadpcm (32 kbps coding)

Vidéo

 Exemples de sous-types : mpeg, quicktime

Application

 Autres données qui doivent être traitées par un user agent avant d’être “lisibles”

 Exemples de sous-types : msword, octet-stream

Multipart

 Différents types de contenus

 Délimiteurs pour les différencier

Exemple de type Multipart

From: [email protected] To: [email protected]

Subject: Picture of yummy crepe.

MIME-Version: 1.0

Content-Type: multipart/mixed; boundary=98766789 --98766789

Content-Transfer-Encoding: quoted-printable Content-Type: text/plain

Dear Bob,

Please find a picture of a crepe.

--98766789

Content-Transfer-Encoding: base64 Content-Type: image/jpeg

base64 encoded data ...

...

...base64 encoded data --98766789--

typesous-type délimiteur

1er objet : texte

2ème objet : image

Protocoles d’accès mail

 SMTP: livraison/stockage au serveur récepteur

 Protocole d’accès mail : pour le retrait du mail

 POP: Post Office Protocol [RFC 1939]

Autorisation (agent<->serveur) et retrait

 IMAP: Internet Mail Access Protocol [RFC 1730]

Plus de caractéristiques (plus complexe)

Manipulation de messages stockés sur le serveur^.

agentuser

Serveur SMTP émetteur agentuser

SMTP SMTP POP3 ou IMAP

Serveur SMTP récepteur

Retrait uniquement chargemen, t en SMTP

POP3 (RFC 1939)

 Connexion TCP user agent - serveur sur le port 110

Phase d’autorisation

 Commandes du client :

 user: déclare le nom

 pass: password

 Réponses du serveur

 +OK

 -ERR

Phase de transaction, client:

 list: liste les n° de messages

 retr: recherche de message par n°

 dele: delete

 quit

C: list S: 1 498 S: 2 912 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

S: +OK POP3 server ready C: user alice

S: +OK

C: pass hungry

S: +OK user successfully logged on

HTTP et SMTP



HTTP: Hotmail , Yahoo! Mail, etc



L’utilisateur peut organiser sa

hiérarchie de classeurs sur le serveur (~ IMAP)

agentuser

Serveur SMTP émetteur agentuser

HTTP SMTP HTTP

Serveur SMTP récepteur

Retrait

&

chargemen t en HTTP

L'en-tête

(à analyser)

From - Wed Dec 07 15:07:55 2005 X-UIDL: 1094468282.5273

X-Mozilla-Status: 0003

X-Mozilla-Status2: 00000000 Return-Path: < @yahoo.fr>

Received: from hermes.u-paris10.fr ([unix socket]) by hermes.u-paris10.fr (Cyrus v2.2.10) with LMTPA;

Wed, 07 Dec 2005 15:06:17 +0100 X-Sieve: CMU Sieve 2.2

Received: from localhost (hermes [127.0.0.1]) by hermes.u-paris10.fr (Postfix) with ESMTP id 547C0283DD for <[email protected]>;

Wed, 7 Dec 2005 15:06:16 +0100 (CET)

Received: from web26915.mail.ukl.yahoo.com (web26915.mail.ukl.yahoo.com [217.146.177.82]) by hermes.u-paris10.fr (Postfix) with SMTP id 1BB6628456 for <[email protected]>;

Wed, 7 Dec 2005 15:05:47 +0100 (CET)

Received: from [195.101.108.232] by web26915.mail.ukl.yahoo.com via HTTP; Wed, 07 Dec 2005 14:59:06 CET



Sur miage03, envoyer un mail sur miage03 en mode verbose

miage03%mail -v [email protected]

Après le “subject” taper sur “Entree”

puis saisir message à la fin du message Ctrl D Consultation /var/mail/user1



Ce qui s’affiche suite à la saisie de votre message est l’échange entre le client SMTP et le serveur SMTP (théoriquement)



Refaire la manipulation avec

telnet miage03.miage.u­paris10.fr 25

1) Classiquement

2) Changeant return path 3) Réécrire l'en tête.

Configuration Mailer agent

Ouvrir Thunderbird



Faites Fichier -> Nouveau -> Compte



Créez le avec des valeurs bidon



Que signifient dans paramètres de comptes les champs :

 Nom

 Adresse electronique

 Nom (serveur sortant)

 Nom (serveur entrant)



Quels va être le serveur SMTP à remplir

DNS: Domain Name System

Humains: bcp d’identifications:

 N° sécu, nom, passeport, CI

Hosts & routeurs Internet :

 Adresse IP (32 bit) - utilisée pour adresser les datagrammes

 “nom”, (hostname) ex,

miage03.miage.u-paris10.fr - utilisé par les humains

Annuaire Internet :

Correspondance adresse IP et nom ?

Domain Name System

 Une BD distributée implantée en une hiérarchie de plusieurs

serveurs de noms

 Un protocole d’application qui

utilise UDP sur le port 53: host, routeurs, serveurs de nom

communiquent pour la résolution de noms (= traduction

adresse/nom et nom/adresse)

 À noter: fonction intrinsèque à Internet (core Internet), implantée en protocole

d’application

 Complexité au bord réseau (network’s “edge”)

Les serveurs DNS (serveurs de noms)

 Aucun serveur ne possède tous les mappings nom-@IP Serveur de noms local

 Chaque ISP, compagnie a un serveur de noms local (default)

 Un host interroge tjs en 1er le serveur de noms local

Serveur de noms autorité

 Chaque host a son @IP et nom enregistrés sur un tel serveur

 Gnlt : serveur de noms local

 Fait la traduction nom/@ pour cet host

Serveur de noms racine Pourquoi le DNS n’est-il pas

centralisé ?

 Un seul point de panne

 Maintenance

 Volume du trafic

 Accès distant à une BD centralisée

Ne résiste pas à l’échelle!

Serveur racine (Root name servers)



Contacté par le serveur de noms local qui ne peut pas faire une résolution



Contacte le serveur de noms d’autorité s’il ne sait pas faire la résolution

 Le serveur d’autorité est censé avoir l’information exacte puisqu’un host est tjs enregistré auprès d’un tel serveur



Récupère la réponse et la transmet au serveur local



Questions : http://www.root­servers.org/

 Combien y a-t-il de root servers ?

 Où sont-ils ?

Serveur racine (Root name servers)

b USC-ISI Marina del Rey, CA l ICANN Marina del Rey, CA e NASA Mt View, CA

f Internet Software C. Palo Alto, CA

i NORDUnet Stockholm k RIPE London

m WIDE Tokyo a NSI Herndon, VA

c PSInet Herndon, VA

d U Maryland College Park, MD g DISA Vienna, VA

h ARL Aberdeen, MD j NSI (TBD) Herndon, VA

13 serveurs root

Un exemple simple

L’host miage03.miage.u-

paris10.fr veut l’@ IP de www.wia.org

1. Il contacte son serveur DNS local 2. Le serveur DNS local contacte le

serveur root, si nécessaire 3. Le serveur root contacte le

serveur d’autorité, si nécessaire

host

miage03.miage.u-paris10.fr www.wia.org

serveur root

serveur d’autorité

serveur DNS local 1

2 3 4

5

6

Exemple DNS plus réaliste

Le serveur root

 Ne connaît pas les

serveurs d’autorité de tous les hosts !

 Connaît un serveur intermédiaire : qui

contacter pour trouver le serveur d’autorité

Requêtes “récursives”

 Le serveur DNS A envoie une demande au serveur DNS B qui la prend en

charge, et interroge C, qui à son tour prend la

requête en charge etc. La réponse reviendra à A

host

miage03.miage.u-paris.fr

1

2 3

4 5

6

serveur intermédiaire (C)

7

8

serveur DNS local (A)

serveur root (B)

serveur d’autorité (D)

www.wia.org

Requêtes itératives vs requêtes récursives

Reqête récursive

 C’est le serveur

contacté qui fait la résolution, pas le serveur demandeur

 Quid de la charge ?

Requête itérative

 Le serveur contacté (B) renvoie le nom du

prochain serveur à

contacter (C), et c’est le serveur demandeur (A) qui s’en charge (donc A contacte C)

On peut mixer les 2

 Cf schéma miage03.miage.u-paris.fr^host

www.wia.org

serveur root (B)

serveur DNS local (A) 1

2 3 4

5 6

serveur d’autorité (D) serveur intermédiaire (C)

7

8

Requête itérative

Cache DNS



Optimiser les applications

 Les applications (ftp, smtp, http) utilisent le DNS pour la résolution de noms

Ex : mail to : [email protected] ou http://webdev.u-paris10.fr

 Le temps de réponse de l’appli est augmenté du temps de résolution (interrogations successives de serveurs)



Quand un serveur connaît une résolution (après avoir interrogé les autres serveurs), il la stocke dans un cache (mémoire locale)



Une entrée du cache est supprimée après timeout ttl



Lors d’une demande de résolution, le serveur DNS

commence par regarder son cache

Enregistrements DNS

DNS: BD distribuée stockant des “resource records” (RR)

 Type=NS

 name est le domaine (ex u- paris10.fr)

 value est l’@ IP serveur d’autorité pour ce domaine

format d’un RR : (name, value, type,ttl)

 Type=A

 name est le hostname

 value est l’@ IP

 Type=CNAME

 name est l’alias pour le nom

“canonique” (réel)

www.wia.org est en réalité

exchange.wia.org

 value est le nom canonique

 Type=MX

 value est le nom d’un serveur de mail dont l’alias est name

Durée de vie dans le

serveur

Les messages du protocole DNS (DNS-PDU)

Protocole DNS : messages de requête et réponse, dans le même format de message

Entête de message

Identification : n° sur 16 bits pour la requête, la réponse utilise le même n°

Drapeaux (flags)

 1 bit : req. (0) ou rép. (1)

 1 bit : si récursion voulue

 1 bit : si récursion disponible

 1 bit : si réponse vient de serveur d’autorité

Autres champs d’entête : nb d’occurrences des 4 types de champs “data”

Les messages du protocole DNS (DNS-PDU)

Le nom recherché et le type de question posée sur ce nom Les RRs fournis en réponse aux questions Les RRs provenant de

serveurs d’autorité

Information complémentaire

L’espace des noms



Nom : miage03.miage.u-paris10.fr

 se lit de droite à gauche : fr puis u-paris10 puis miage puis miage03



Hiérarchie de domaines

 fr est le nom de domaine

 u-paris10 est le nom de sous-domaine du domaine fr

 Un domaine est partitionné en sous-domaines, eux-mêmes partitionnés en sous-domaines etc



700 domaines « top-level » en 2 groupes : générique et pays

 Les visualiser : http://www.iana.org/domain-names.htm

L’arborescence des noms

ar pa

co m

ed u

go

v int mi

l

ne t

or

g ae .. fr ..

Racine non nommée

no ao tu c ho

st 2

host2.tuc.noao.edu

u- pa ris 10mi ag e0 3

miage03.miage.u-paris10.fr Domaines

de top niveau

Domaines de 2ème niveau

Domaines génériques Domaines

géographiques

Domaine spécifique pour obtenir des noms à partir d ’@

La gestion des noms de domaines



Qui gère les noms de domaine ?



Qui décide des noms de domaine ?



Où enregistrer un nom de domaine ?

 Affectation d’un nom de domaine top-level et 2ème niveau par l’ICANN qui délègue, par ex, pour .fr, à l’AFNIC

http://www.afnic.asso.fr

 Les noms de domaines (autres que top-level) sont sous la responsabilité du site demandeur

Relation domaine - serveur DNS



Chaque élément de l’arborescence (domaine, sous- domaine, …, host) a un RR associé



L’arborescence des noms est divisée en zones

 1 serveur d’autorité par zone (serveur primaire)

 Par sécurité, redondance des serveurs DNS, donc

plusieurs serveurs pour une zone (serveurs secondaires)

 Un serveur secondaire d’une zone peut se trouver dans une autre zone



Toute machine avec accès Internet n’est pas forcément enregistrée dans le DNS

 Ex : miage03

 Conséquence : nom inconnu du monde extérieur