Services réseaux. Protocoles applicatifs. 4. La couche Application. Protocoles applicatifs. Protocoles applicatifs. Les principaux trafics

Transcription

1 Services réseaux Protocoles applicatifs Les principaux trafics 4. La couche Application Protocoles applicatifs Service DNS Web et HTTP Messagerie (SMTP, POP, IMAP) Transfert de fichiers (FTP, P2P) Voix sur IP Vidéo sur IP Administration et SNMP Stéphane Lohier Source Sandvine 1H 2015 ESIPE - IR1/IG1 La couche Application S. Lohier 2 Protocoles applicatifs Les principaux trafics Protocoles applicatifs Répartition du trafic par application Aux US, Netflix (VoD), YouTube et HTTP sont les applications dominantes du trafic large bande pour les accès fixes. Source Sandvine 1H 2015 ESIPE - IR1/IG1 La couche Application S. Lohier 3 ESIPE - IR1/IG1 La couche Application S. Lohier 4 1

2 Protocoles applicatifs Répartition du trafic par application Protocoles applicatifs Pics de trafic Pour les accès mobiles, les réseaux sociaux sont juste derrière la vidéo. 30 à 35% d augmentation du trafic Netflix le dimanche de la 1 ère diffusion de la saison 3 de House Of Cards ESIPE - IR1/IG1 La couche Application S. Lohier 5 ESIPE - IR1/IG1 La couche Application S. Lohier 6 Protocoles applicatifs Répartition du trafic sur Internet Protocoles applicatifs Localisation / modèle OSI Une projection pour les années à venir donne les tendances : Ø importance du RT Entertainment ; Ø Le web Browsing et le filesharing régressent, le tunneling progresse. Le protocole applicatif définit le dialogue au niveau 7 entre les deux entités communicantes. L application utilise les services de la couche TCP/IP. Client Serveur Navigateur web Couche TCP/IP Couche Liaison Protocole applicatif Protocole de gestion de la connexion Protocole de gestion de la liaison Serveur web Couche TCP/IP Couche Liaison Modem Internet Modem ESIPE - IR1/IG1 La couche Application S. Lohier 7 ESIPE - IR1/IG1 La couche Application S. Lohier 8 2

3 Protocoles applicatifs Rôle du protocole Protocoles applicatifs Côté développeur Les protocoles sont les règles de dialogue qui permettent de mettre en œuvre une application entre un client et un serveur. Par exemple, l application web est constitué : Ø de langages de description de pages statiques ou dynamiques : html, xhtml Ø de navigateurs web : Firefox, Opera, IE Ø de serveurs web : Apache, IIS Ø de protocoles de niveau applicatif : HTTP Une application en réseau implique : Ø 2 processus engagés sur 2 hôtes reliés par un réseau ; Ø des interfaces de connexion (socket) permettant de faire passer les messages vers la couche de transport ; Ø une infrastructure de transport (TCP ou UDP) permettant de transporter les messages lorsque la connexion est établie. Client Demande Réponse Serveur Un protocole applicatif (HTTP, SMTP, FTP ) définit : Ø la séquence de messages échangés entre client et serveur (quand et comment les processus client et serveur doivent envoyer des demandes ou des réponses) ; Ø le type de messages échangés (message de demande, de réponse, de confirmation ) ; Ø la syntaxe adoptée par les différents types de messages (les différents champs et leurs délimitations) ; Ø La sémantique des différents champs (le sens des informations qu ils contiennent). Contrôlé par le développeur Contrôlé par l OS Processus Socket Couche TCP/IP Protocole applicatif Protocole TCP/IP Internet Processus Socket Couche TCP/IP ESIPE - IR1/IG1 La couche Application S. Lohier 9 ESIPE - IR1/IG1 La couche Application S. Lohier 10 Protocoles applicatifs Besoins des applications Le service DNS RFC Principe L Internet n est pas conçu au départ pour offrir des garanties en termes de QoS (Qualité de Service) Certaines applications ont besoin de QoS : débit minimum, délai maximum, taux de pertes Les protocoles de niveau inférieur (TCP, IP, RTP ) devront donc être choisis en fonction des ces besoins : TCP pour retransmettre des paquets perdus, RTP pour garantir des délais Application Perte de données Débit Transfert de fichier Interdite Flexible Non Contrainte de temps Pour simplifier l identification, un service de résolution permettant d utiliser des noms symboliques de machines à la place des adresses IP est utilisé sur tous les réseaux TCP/IP. Pour circuler sur Internet, un paquet IP doit contenir l adresse IP de destination et non le nom associé. Il faut donc interroger ce service de résolution qui contient toutes les correspondances. La méthode la plus simple passe par l utilisation d un fichier ASCII (fichier /etc/hosts sous UNIX par exemple) sur la machine émettrice qui comprend des noms et les adresses IP correspondantes (méthode impossible pour de gros réseaux). Interdite Flexible Non web Interdite Flexible Non Messagerie instantanée Interdite Flexible Oui - faible Streaming Acceptable Audio : 10 kbit/s à 1 Mbit/s Vidéo : 100 kbit/s à 5 Mbit/s P2P Interdite Flexible Non Oui - forte Réseaux sociaux Interdite Flexible Oui - faible ESIPE - IR1/IG1 La couche Application S. Lohier 11 Pour Internet, la gestion des noms est centralisée sur des machines spécifiques (les serveurs de noms) à l aide d un service permettant une organisation hiérarchisée : le DNS (Domain Name Service). Ce service de nom de domaine travaille suivant une organisation arborescente en divisant le réseau global en un ensemble de domaines primaires, secondaires ESIPE - IR1/IG1 La couche Application S. Lohier 12 3

4 Le service DNS Arborescence Le service DNS Statistiques 1 Dans la structure arborescente sont définis des domaines racine (appelés TLD, pour Top Level Domains), rattachés à un nœud racine représenté par un point. Un nom complet d hôte ou FQDN (Fully Qualified Domaine Name) est constitué des domaines successifs séparés par un point. Racine Domaines de 1er niveau Domaines de 2ème niveau Domaines de 3ème niveau gtld (generic Top Level Domain) New gtld cctld (country code TLD) net com gov mil org int edu biz pro info museum coop us fr cn uk... microsoft gouv www support www education Importance Importance www Adresse IP Nom de machine Domaine de 3ème niveau FQDN TLD Domaine de 2ème niveau ESIPE - IR1/IG1 La couche Application S. Lohier 13 ESIPE - IR1/IG1 La couche Application S. Lohier 14 Le service DNS Statistiques 2 Le service DNS Carte des serveurs racine Il y a officiellement 13 serveurs de noms racine (de a.root-servers.net à m.rootservers.net) qui connaissent les serveurs de nom de premier niveau (.com,.fr ). Ces serveurs sont dupliqués et répartis dans le monde (plus de 300 serveurs physiques). La figure donne le nom du serveur (D, L ) ou le nombre de serveurs dans les régions plus denses (3 serveurs à Hawai : un G, un L et un J ). ESIPE - IR1/IG1 La couche Application S. Lohier 15 ESIPE - IR1/IG1 La couche Application S. Lohier 16 4

5 Le service DNS Résolution locale ou en cache Le service DNS Résolution récursive Chaque serveur de noms DNS gère une ou plusieurs zones du réseau. Chacune des zones possède au moins un serveur de noms ayant la connaissance complète des adresses des machines de la zone. Côté client, chaque machine possède au moins l adresse d un serveur DNS (serveur primaire) et éventuellement l adresse d un second (serveur secondaire). Lorsqu une application (navigateur, client FTP, client mail ) à besoin de résoudre un nom symbolique en une adresse réseau, elle envoie une requête au résolveur local (processus spécifique sur la machine client pour l application DNS). Le résolveur local transmet au serveur de nom de la zone locale (serveur primaire). Si le nom est local ou en cache, le serveur primaire renvoie directement l adresse IP demandée. Résolution locale ou en cache Station big.business.com Serveur mail.business.com 3 Zone business.com Resolver 1 mail.business.com? a b Cache Serveur DNS primaire Autorité sur business.com c Internet Si le nom ne peut être résolu localement (zone distante ou nom absent du cache), le serveur primaire transmet à un serveur distant ayant autorité sur le domaine racine concerné (.fr,.com,.net ). La requête est ensuite relayée de manière récursive jusqu à atteindre le serveur DNS ayant autorité sur la zone demandée. L adresse IP de la machine est alors renvoyée. Si le serveur primaire ne connaît pas l adresse ayant autorité sur le domaine de premier niveau, il doit au préalable interroger un serveur racine. Les serveurs racine connaissent au moins les serveurs de noms pouvant résoudre le premier niveau (.fr,.com,.net ) Résolution récursive 1 Resolver DNS Serveur DNS primaire DNS Autorité sur la zone.fr DNS Autorité sur la zone gouv.fr DNS Autorité sur la zone education.gouv.fr ESIPE - IR1/IG1 La couche Application S. Lohier 17 ESIPE - IR1/IG1 La couche Application S. Lohier 18 Le service DNS Résolution itérative Le service DNS Résolution itérative et récursive Le protocole DNS autorise également l usage de recherches itératives. Les recherches itératives sont utilisées lorsque : Ø Le client demande l'utilisation de la récursivité, mais celle-ci est désactivée sur le serveur DNS ; Ø Le client ne demande pas l'utilisation de la récursivité. Lorsqu un serveur DNS n est pas en mesure de relayer la requête de manière récursive il transmet au serveur primaire l adresse du prochain serveur. Dans l exemple suivant, toutes les recherches sont de type itératives, c est le serveur primaire qui est chargé de toutes les requêtes. Résolution itérative 1 Resolver du DNS de gouv.fr du DNS de education.gouv.fr DNS DNS Autorité sur la zone.fr DNS Autorité sur la zone gouv.fr Dans certains cas, le serveur de nom de premier niveau, fortement sollicité, ne relaye pas les requêtes de manière récursive. Seule la requête vers le serveur de nom de premier niveau est itérative, les autres sont récursives. Résolution itérative et récursive 1 Resolver DNS Serveur DNS primaire du DNS de gouv.fr DNS Autorité sur la zone.fr DNS Autorité sur la zone gouv.fr Serveur DNS primaire DNS Autorité sur la zone education.gouv.fr DNS Autorité sur la zone education.gouv.fr ESIPE - IR1/IG1 La couche Application S. Lohier 19 ESIPE - IR1/IG1 La couche Application S. Lohier 20 5

6 Le service DNS Résolution itérative ou récursive? Le service DNS Le Round-Robin L'utilisation du mode récursif est limité aux cas qui résultent d'un accord négocié entre le client et le serveur. Cet accord est négocié par l'utilisation de deux bits particuliers dans les messages de requête et de réponse : Ø Le bit Ra (Recursion available) est marqué par le serveur dans toutes ses réponses si il accepte à priori de fournir le service récursif au client, que ce dernier l'ait demandé ou non (le bit Ra signale la disponibilité du service plutôt que son utilisation). Lorsqu'un service génère un trafic important, celui-ci peut faire appel à la technique du DNS Round- Robin (en français tourniquet). Le Round-Robin consiste à associer plusieurs adresses IP à un nom de domaine. Par exemple, les différentes versions de Wikipedia, comme fr.wikipedia.org sont associées à plusieurs adresses IP : , , , , et L'ordre dans lequel ces adresses sont renvoyées sera modifié d'une requête à la suivante. Une rotation circulaire entre ces différentes adresses permet ainsi de répartir la charge générée par ce trafic important entre les différentes machines ayant ces adresses IP. Il faut cependant nuancer cette répartition car elle n'a lieu qu'à la résolution du nom d'hôte et reste par la suite en cache sur les différents resolvers. Les très nombreux serveurs DNS Google fonctionnent également sur ce principe. Ø Le bit Rd (Recursion desired) indique dans les requêtes du client qu il souhaite utiliser le service récursif. Les clients peuvent demander le service récursif à n'importe quel serveur de noms, bien que ce service ne puisse leur être fourni que par les serveurs qui auront déjà marqué leur bit Ra, ou des serveurs qui auront donné leur accord pour ce service par une négociation propriétaire ou tout autre moyen hors du champ du protocole DNS. ESIPE - IR1/IG1 La couche Application S. Lohier 21 ESIPE - IR1/IG1 La couche Application S. Lohier 22 Le service DNS Enregistrements DNS Le service DNS Enregistrements DNS - Valeur du TTL La base de données des serveurs de noms est constituée "d'enregistrements de ressources" ou "Ressource Records" (RRs). Ces enregistrements sont répartis en classes. La seule classe d'enregistrement usuellement employée est la classe Internet (IN). À chaque nom de domaine est donc associé un RR. Il existe plusieurs types de RR : Ø A : Adress, correspondance nom -> adresse IP (le plus usuel) Ø NS : Name Server, serveur(s) de nom faisant autorité sur le domaine Ø CNAME : Canonical NAME, nom d origine (des alias peuvent exister) Ø SOA : Start Of Authority, nom officiel du domaine, nom du NS, et valeurs de temps et de rafraichissement pour le domaine Ø PTR : PoinTeR, correspondance adresse IP -> nom (résolution inverse) Ø MX : Mail exchange, indique le serveur de messagerie. Exemple de RR : TTL (Time To Live), permet de définir, en secondes et dans un intervalle qui va de 0 à , le délai maximum pendant lequel un enregistrement pourra être gardé en cache. Avec 86400, le cache sera vidé, et les fichiers relus, toutes les 24 heures. Le choix du TTL se fait en fonction du réseau : pour un réseau dont les IP des postes clients et de certains serveurs sont gérées par DHCP, il faudra une valeur pour le TTL faible, car nous ne sommes pas certains que les stations auront la même adresse IP si elles sont coupées puis relancées Si par contre sur le réseau les adresses IP sont fixes, la valeur du TTL peut être augmentée car il n'y aura pas de changement de configuration des machines du réseau. Une valeur basse engendre une occupation de la bande passante réseau qui peut être non négligeable mais permet au serveur DNS maître de délivrer des informations à jour, alors qu'une valeur haute n'occupe pas la bande passante mais les données sont plus anciennes donc pas forcément à jour. ESIPE - IR1/IG1 La couche Application S. Lohier 23 ESIPE - IR1/IG1 La couche Application S. Lohier 24 6

7 Le service DNS Echanges DNS primaire / DNS secondaire Le service DNS Délégation de zone Pour chaque zone DNS, le serveur servant de référence est le DNS maître ou DNS primaire. Un ou plusieurs serveurs esclaves ou DNS secondaires peuvent être ajoutés pour la sécurité ou le transfert de charge. Les DNS esclave servant cette zone vont récupérer les informations du DNS maître. Cette récupération d'information est appelée transfert de zone. Seuls les DNS esclaves ont besoin d'être autorisés à effectuer cette opération. Lorsque des changements apparaissent sur une zone, il faut que tous les serveurs qui gèrent cette zone en soient informés. Les changements sont effectués sur le serveur maître, le plus souvent en éditant un fichier. Après avoir édité le fichier, l'administrateur signale au serveur qu'une mise à jour a été effectuée (reload de bind sur un serveur de type Linux par exemple) Les serveurs esclaves interrogent régulièrement le serveur maître pour savoir si les données ont changé depuis la dernière mise à jour. Ils utilisent un numéro constitué de la date au format américain: année, mois, jour; version du jour. Il est donc toujours incrémenté. Pour la mise à jour ils comparent le champ SERIAL du RR SOA de la zone donnée par le serveur maître contenant le numéro à celui qu'ils connaissent. Si ce numéro a augmenté, ils chargent les nouvelles données. Dans une arborescence de domaine dotée par exemple d un domaine parent et de deux sous-domaines, la solution la plus simple est de mettre en place un serveur DNS dans le domaine parent avec une zone DNS primaire. Pour faciliter la gestion et améliorer les performances, il peut être intéressant de mettre en place 3 serveur DNS : un dans le domaine parent et un dans chaque sous-domaine. Dans ce cas de figure, il faut créer des délégations de zones au niveau du serveur DNS appartenant au domaine parent. Une délégation permet d'autoriser un autre serveur DNS à contrôler une partie des enregistrements de la zone. ESIPE - IR1/IG1 La couche Application S. Lohier 25 ESIPE - IR1/IG1 La couche Application S. Lohier 26 Le service DNS Format des messages DNS Le service DNS Format des messages DNS Pour lire les différents RR, le protocole associé utilise le même format de message pour les demandes et les réponses. Le champ «identificateur» est positionné par le client et permet de faire correspondre les réponses aux demandes Identificateur Drapeaux Nombre de questions Nombre de réponses Les drapeaux donnent des indications supplémentaires sur le message (demande ou réponse, demande standard ou inverse, erreur de nom, récursivité disponible ). Nombre d enregistrements «autorité» Questions Réponses Autorité Nombre d enregistrements «information supplémentaire» Les 4 valeurs suivantes de 16 bits précisent le nombre de RR dans les 4 champs de longueurs variables qui terminent le message. Les champs «questions» et «réponses» précisent le type et le contenu de la demande ou de la réponse (résolution IP, nom demandé, adresse retournée ). Informations supplémentaires Les champs «autorité» et «informations supplémentaires» donnent éventuellement dans une réponse des indications sur les serveurs DNS ayant participé à la résolution. ESIPE - IR1/IG1 La couche Application S. Lohier 27 ESIPE - IR1/IG1 La couche Application S. Lohier 28 7

8 Le service DNS Analyse DNS Le service DNS Analyse DNS Les figures suivantes montrent un exemple de dialogue DNS relevé à l aide d un analyseur de protocoles. Pour la requête, seul le champ «queries» comporte un enregistrement, il contient le nom demandé. Le message de réponse comporte les quatre champs avec un enregistrement pour le champ «queries» et 2 enregistrements pour chacun les 3 autres champs. L adresse IP demandée est donnée dans l un des 2 enregistrements de réponse. Bit Ra = 1 Nombre et types d enregistrement trouvés Requête standard Question Réponse Nom canonique de Demande de résolution récursive (par défaut) Adresse IP de l alias Une seule question Argument de la requête RR demandé de type Address Class INternet Serveurs faisant autorité sur le domaine jsmp.net Adresse IP des serveurs faisant autorité ESIPE - IR1/IG1 La couche Application S. Lohier 29 ESIPE - IR1/IG1 La couche Application S. Lohier 30 Le service DNS Questions Le service DNS Questions (2) Voici le résultat d'une capture DNS sous Wireshark. : Voici le contenu du champ applicatif de la trame n 88 : Pour la première trame capturée (n 86), donnez la valeur : de l adresse IP du serveur DNS Ø de l adresse IP du client? Ø du champ protocole de l'en-tête IP? Ø du port source et du port client? Pourquoi le client exécute-t-il deux requêtes (trames 86 et 88)? Observez les champs flags de la requête. A quoi sert le bit nommé par Wireshark «Recursion desired : Do query recursively»? Quel est l'intérêt pour le client de faire travailler les serveurs en mode récursif? Observez le champ query de la requête : que signifient les champs TYPE et CLASS? ESIPE - IR1/IG1 La couche Application S. Lohier 31 ESIPE - IR1/IG1 La couche Application S. Lohier 32 8

9 Le service DNS Questions (3) Le service DNS Questions (4) On exécute trois fois de suite la commande : host Voici le résultat : root@woody:~# host is an alias for has address has address has address has address has address has address A quoi sert la commande? Pourquoi plusieurs adresses IP sont-elles renvoyées en réponse? root@woody:~# host is an alias for has address has address has address has address has address has address Pourquoi les adresses IP n'apparaissent-elles pas dans le même ordre dans les deux premières réponses? root@woody:~# host is an alias for has address has address has address has address has address has address ESIPE - IR1/IG1 La couche Application S. Lohier 33 Pourquoi la 3ème réponse est-elle différente des deux premières? ESIPE - IR1/IG1 La couche Application S. Lohier 34 Web et HTTP Hyperliens et URL Web et HTTP RFC 2616 Principe d HTTP HTTP (HyperText Transport Protocol) : protocole de communication entre le navigateur du client et les serveurs Web, basé sur le principe des liens hypertextes ou des hyperliens. Client + navigateur Page HTML Hyperliens Serveur Web Documents accessibles par un URL (Uniform Ressource Locator) : syntaxe : protocol://[user:password@]host[:port][/path][/document] Ø user : nom d utilisateur utilisé par certains protocoles (FTP ) Ø password : mot de passe pour user Ø host : nom complet d hôte FQDN ( Ø port : port sur lequel se connecter, la plupart des protocoles ont un port par défaut (80 pour HTTP ) Ø path : détail sur la façon d accéder à la ressource (/~lohier) Ø document : nom de la ressource (index.html, video.mpeg ) Fonction de base de HTTP : transfert de fichier (essentiellement au format HTML) localisé grâce à son URL entre client et un serveur Web. A partir de la version 1.0 : possibilité de transférer des messages avec des en-têtes décrivant le contenu du message en utilisant un codage de type MIME. La communication entre le navigateur et le serveur se fait en deux temps : Ø le navigateur effectue une requête HTTP ; Ø le serveur traite la requête puis envoie une réponse HTTP. Navigateur Client Requête HTTP GET Réponse HTTP Serveur web Décodage Décode Création des en-têtes Formatage des données Localisation du fichier ESIPE - IR1/IG1 La couche Application S. Lohier 35 ESIPE - IR1/IG1 La couche Application S. Lohier 36 9

10 Web et HTTP Connexion TCP non persistante Web et HTTP Connexion TCP persistante avec pipelining Dans la version HTTP 1.0, les connexions ne sont pas persistantes par défaut (option keep-alive possible). Le traitement des requêtes est donc séquentiel : le client établit une nouvelle connexion TCP avec le serveur pour chaque objet (page, image, etc.) demandé et attend le résultat avant de pouvoir poursuivre avec la requête suivante. Port Ouverture d'une connexion TCP GET/HTTP HTTP paramètres...corps du document Suite du document Fermeture de la connexion TCP Ouverture d'une nouvelle connexion TCP Port 80 Port 1026 Port 80 GET/HTTP /pompe.gif HTTP paramètres...image Fermeture de la connexion TCP ESIPE - IR1/IG1 La couche Application S. Lohier 37 Dans la version HTTP 1.1, la connexion est persistante par défaut. Tous les éléments de la page correspondant au même URL de base, sont chargés sur la même connexion TCP, ce qui permet d économiser du trafic sur le réseau, des ressources mémoire et du temps CPU. La technique du pipelining est de plus utilisée pour accélérer les transferts : plusieurs requêtes sont envoyées à la suite sans attendre les réponses des précédentes. Le client doit indiquer qu'il souhaite fermer la connexion persistante avec le message Connection close. Port Ouverture d'une connexion TCP GET/HTTP GET/HTTP /pompe.gif HTTP paramètres...fichier HTTP paramètres...image Fermeture de la connexion TCP Port 80 ESIPE - IR1/IG1 La couche Application S. Lohier 38 Web et HTTP Connexion TCP persistantes et parallèles Web et HTTP Requête HTTP Pour accélérer encore les transferts de pages comportant beaucoup d éléments, plusieurs connexion TCP persistantes peuvent être ouvertes en parallèle pour un même URL de base. Cette possibilité initiée par le client peut être personnalisée suivant le navigateur (options User-Agent et Accept). Il est nécessaire dans ce cas de trouver un équilibre : plusieurs connexions en parallèle accélère le transfert de la page mais utilisent du temps pour les établir et des ressources pour les maintenir (Firefox propose 15 connexion parallèle par défaut). Syntaxe d une requête HTTP : METHODE URL VERSION EN-TETE : Valeur EN-TETE : Valeur Ligne vide CORPS DE LA REQUETE La ligne de requête comprend 3 éléments séparés par un espace : Ø La méthode (GET, HEAD, POST ) ; Ø L'URL ; Ø La version du protocole utilisé par le client (actuellement HTTP/1.1). Les champs d'en-tête : ensemble de lignes facultatives permettant de donner des informations supplémentaires sur la requête et/ou le client (navigateur, OS...). Le corps de la requête : ensemble de lignes optionnel devant être séparé des lignes précédentes par une ligne vide (par exemple pour un envoi de données par la méthode POST lors de l utilisation de formulaire). ESIPE - IR1/IG1 La couche Application S. Lohier 39 ESIPE - IR1/IG1 La couche Application S. Lohier 40 10

11 Web et HTTP La méthode GET : requête Web et HTTP La méthode GET : requête La méthode GET permet de récupérer une ressource localisée par un URL. Pour HTTP 1.1, l URL est passé dans le champ d en-tête «Host» qui devient obligatoire. GET HTTP/1.0\r\n Accept: application/vnd.ms-excel, application/msword Accept-Language: fr\r\n Accept-Encoding: gzip, deflate\r\n User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv: ) Firefox/3.6.13\r\n Host: Proxy-Connection: Keep-Alive\r\n \r\n GET / HTTP/1.1\r\n Host: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv: ) Gecko/ Firefox/3.6.13\r\n Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8\r\n Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3\r\n Accept-Encoding: gzip,deflate\r\n Accept-Charset: ISO ,utf-8;q=0.7,*;q=0.7\r\n Keep-Alive: 300\r\n Connection: keep-alive\r\n Cookie: PersoHome=d:4&nVer:1.2; PersoModRecherche=Cd:acc_search_sld1&nVer:1.2; \r\n \r\n ESIPE - IR1/IG1 La couche Application S. Lohier 41 Description de quelques en-têtes de requête : Nom de l'en-tête Accept Accept-Charset Accept-Encoding Accept-Language Content-Type Date User-Agent Host Connection Keep-Alive Description Type de contenu accepté par le navigateur (par exemple text/html). Jeu de caractères attendu par le navigateur. Codage de données accepté par le navigateur. Langage attendu par le navigateur (anglais par défaut). Type de contenu du corps de la requête (par exemple text/html). Date de début de transfert des données. Chaîne donnant des informations sur le client : nom et version du navigateur, de l OS URL demandé. Permet à l émetteur de spécifier les options utilisées pour cette connexion : keep-alive, close En cas de connexions persistantes : spécifie la durée ou le nombre maximum de requêtes multiples sur la même connexion TCP/IP. ESIPE - IR1/IG1 La couche Application S. Lohier 42 Web et HTTP Réponse HTTP Web et HTTP La méthode GET : réponse Syntaxe d une réponse HTTP : VERSION-HTTP CODE INDICATION EN-TETE : Valeur EN-TETE : Valeur Ligne vide CORPS DE LA REPONSE L état de la réponse comprend 3 éléments : Ø version HTTP ; Ø un code d'état décrivant le résultat (200 pour un acquittement, 404 ) ; Ø Une chaîne de caractère donnant une indication sur le résultat (OK, Not Found ) Les champs d'en-tête : ensemble de lignes facultatives permettant de donner des informations supplémentaires sur la réponse (type du serveur, version de MIME ) Le corps de la réponse qui contient les données HTTP au format html; php. ESIPE - IR1/IG1 La couche Application S. Lohier 43 Les en-têtes sont fonction du type de réponse. HTTP/ OK\r\n Date: Thu, 13 Sep :59:46 GMT\r\n Server: Apache/ (Unix) mod_ssl/ OpenSSL/0.9.7c\r\n Last-Modified: Mon, 03 Sep :52:39 GMT\r\n ETag: "51007b-146c-a5c6d3c0"\r\n Accept-Ranges: bytes\r\n Content-Length: 5228 Keep-Alive: timeout=15, max=99\r\n Connection: Keep-Alive\r\n Content-Type: text/html\r\n Content-Language: fr\r\n \r\n <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"\r\n " <html xmlns=" <!-- DW6 -->\r\n <head>\r\n HTTP/ Not Found\r\n Date: Thu, 13 Sep :49:41 GMT\r\n Server: Apache/ (Unix) (Red-Hat/Linux)\r\n Connection: close\r\n Transfer-Encoding: chunked\r\n Content-Type: text/html; charset=iso \r\n \r\n ESIPE - IR1/IG1 La couche Application S. Lohier 44 11

12 Web et HTTP La méthode GET : réponse Web et HTTP La méthode GET : réponse Description de quelques en-têtes de réponse : Le code de réponse est constitué de trois chiffres : le premier indique la classe d état (réussite, redirection, erreur) et les suivants la nature exacte de l'erreur. Nom de l'en-tête Content-Encoding Content-Language Content-Length Content-Type Server Date Last-Modified Transfer-Encoding Forwarded Location Description Type de codage du corps de la réponse Type de langage du corps de la réponse Longueur du corps de la réponse Type de contenu du corps de la réponse (par exemple text/html) Caractéristiques du serveur ayant envoyé la réponse Date de début de transfert des données Date de la dernière modification de la ressource Spécifie un encodage particulier des données transférées Utilisé par les machines intermédiaires entre le navigateur et le serveur Redirection vers une nouvelle URL associée au document 20x Réussite Bon déroulement de la transaction 200 OK La requête a été accomplie correctement 201 CREATED 202 ACCEPTED 203 PARTIAL INFORMATION Elle suit une commande POST, elle indique la réussite, le corps du reste du document est sensé indiquer l URL auquel le document nouvellement créé devrait se trouver. La requête a été acceptée, mais la procédure qui suit n'a pas été accomplie Lorsque ce code est reçu en réponse à une commande GET, la réponse n'est pas complète. 204 NO RESPONSE Le serveur a reçu la requête mais il n'y a pas d'information a renvoyer 30x Redirection La ressource n'est plus à l'emplacement indiqué 301 MOVED Les données demandées ont été transférées a une nouvelle adresse 302 FOUND 303 METHOD 304 NOT MODIFIED Les données demandées sont à une nouvelle URL, mais ont cependant peut-être été déplacées depuis... Cela implique que le client doit essayer une nouvelle adresse, en essayant de préférence une autre méthode que GET Lorsque le client a effectué une commande GET conditionnelle (en demandant si le document a été modifié depuis la dernière fois) et que le document n'a pas été modifié. ESIPE - IR1/IG1 La couche Application S. Lohier 45 ESIPE - IR1/IG1 La couche Application S. Lohier 46 Web et HTTP La méthode GET : réponse Web et HTTP La méthode HEAD 40x Erreur dûe au client Requête incorrecte 400 BAD REQUEST Syntaxe de la requête mal formulée ou impossible à satisfaire 401 UNAUTHORIZED 402 PAYMENT REQUIRED Le paramètre du message donne les spécifications des formes d'autorisation acceptables. Le client doit reformuler sa demande avec les bonnes données de paiement 403 FORBIDDEN L'accès à la ressource est interdit 404 NOT FOUND Classique! Le serveur n'a rien trouvé à l'adresse spécifiée. 50x Erreur due au serveur Erreur interne du serveur 500 INTERNAL ERROR Le serveur a rencontré une condition inattendue qui l'a empêché de donner suite à la demande 501 NOT IMPLEMENTED Le serveur ne supporte pas le service demandé. 502 SERVICE TEMPORARILY OVERLOADED 503 GATEWAY TIMEOUT Le serveur ne peut pas répondre pour l'instant, le trafic est trop dense. La réponse du serveur a été trop longue vis à vis du temps pendant lequel la passerelle était préparée à l'attendre. ESIPE - IR1/IG1 La couche Application S. Lohier 47 Similaire à la méthode GET mais ne demande que l en tête du message et non le corps (page html). Utilisé par exemple pour vérifier l existence d une ressource en cache ou la date de dernière modification d'un fichier Exemple : Requête Réponse HEAD / HTTP/1.1\r\n Host: HTTP/ OK Date: Thu, 13 Sep :08:06 GMT Server: Apache/ (Debian GNU/Linux) mod_jk2/2.0.4 PHP/ mod_ssl/ OpenSSL/0.9.7e Last-Modified: Mon, 10 Sep :02:27 GMT X-Powered-By: PHP/ Content-Length: 79 Connection: close Content-Type: text/html ESIPE - IR1/IG1 La couche Application S. Lohier 48 12

13 Web et HTTP La méthode POST Web et HTTP HTTP 1.1 et les autres méthodes Permet au client d'envoyer des données au serveur, par exemple le contenu d'un formulaire renseigné par l'utilisateur. Syntaxe de la requête : POST URL VERSION EN-TETE : Valeur EN-TETE : Valeur Ligne vide name1=value1&name2=value2 Après traitement sur le serveur (authentification, recherche dans une base de données ) par un script (PHP, ASP, CGI ), les informations sont renvoyées comme pour la méthode GET. Exemple : POST /index.php HTTP/1.1\r\n Host: jungle.net\r\n username=tarzan%40jungle.net&password=jane&logon=log+on Réponse Requête HTTP/ OK\r\n Date: Thu, 13 Sep :11:47 GMT\r\n Server: Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.7a PHP/5.2.3\r\n <!DOCTYPE HTML PUBLIC '-//W3C//DTD HTML 4.01//EN'\n ' <head>\n ESIPE - IR1/IG1 La couche Application S. Lohier 49 En plus des 3 méthodes de base (GET, HEAD et POST), la version 1.1 propose 5 méthodes supplémentaires : Ø Ø Ø Ø Ø OPTIONS : permet d'interroger le serveur sur les options disponibles pour obtenir la ressource. TRACE : méthode de contrôle. Demande au serveur de renvoyer dans le corps de sa réponse la requête telle qu'elle a été reçue avec les différentes en-têtes ajoutées. CONNECT : permet de demander au proxy de relayer une requête sur certains ports, typiquement 443 (HTTPS). PUT : permet d'envoyer au serveur un document à enregistrer à l'uri spécifiée. (c est directement le serveur qui traite le document envoyé, et non pas un script comme pour la méthode POST). DELETE : efface la ressource spécifiée. Ces deux dernières méthodes sont introduites pour permettre une mise à jour des sites distants via HTTP. PUT /data/lohier/text/liste.txt HTTP/1.1 Host: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv: ) Gecko/ Firefox/3.0.9 Content-Type: Text/plain Content-Length: 44 ESIPE - IR1/IG1 La couche Application S. Lohier 50 Web et HTTP RFC 2045 MIME Web et HTTP Les cookies MIME (Multipurpose Internet Mail Extension) est un standard qui étend le format de données des courriels pour supporter des textes en différents codage de caractères autres que l'ascii, des contenus non textuels et des contenus multiples. HTTP utilise aussi MIME pour décrire les différents types de données qu'il doit manipuler. La ligne Content type est une description MIME des données transférées. Ø Par exemple : text/html indique que les données sont de type texte, sous type HTML. Lorsque le navigateur reconnaît ce type texte, il sait qu'il doit interpréter les données comme du code HTML (idem pour un player mpeg ). Autres types : Ø text : html, plain, xml Ø image : gif, jpeg... Ø audio : mp3, wav... Ø video : avi, mpeg... Dans HTTP, le dialogue Client-Serveur est sans état ou state-less : le serveur ne stocke aucune information relative à une transaction. Le système des cookies inventé par Netscape et normalisé dans HTTP1.1 permet d'établir des transactions avec état. Un cookie est une information envoyée par le serveur, stockée coté client et renvoyée par le client lors d une nouvelle connexion. Applications courantes : Ø mémorisation de la navigation du client pour une exploitation commerciale ; Ø prise de commandes en ligne via un serveur web : les libellés des différents articles sont stockés en local sur le client. ESIPE - IR1/IG1 La couche Application S. Lohier 51 ESIPE - IR1/IG1 La couche Application S. Lohier 52 13

14 Web et HTTP Les cookies : mise en place Web et HTTP Les cookies : envoi par le client En tête spécifique introduit dans la réponse du serveur : Set-Cookie: Nom=Valeur; expires=date; path=chemin; domain=domaine; secure. Set-Cookie comporte 5 champs : Ø Le premier permet d'envoyer au client une valeur associée à un identifiant afin que ces informations soient stockées en local, sous forme d'une chaîne de caractères. Ø expires permet d'indiquer la date d'expiration du cookie, une date d'expiration passée permet à un serveur d'effacer un cookie, Ø Domain spécifie le nom de domaine d'application du cookie. La valeur du cookie ne sera envoyée qu'aux serveurs appartenant au domaine précisé. Si le domaine n'est pas spécifié, la valeur par défaut est l'adresse DNS de la machine ayant généré le cookie. Ø path est utilisé pour désigner un sous-ensemble de ressources auxquelles le cookie est accessible. Si le champ Domain est renseigné, on concatène la valeur de ce champ à celle du path. Exemple : si path=/doc, alors les ressources /doc/index.html, /documents/ toc.html, etc. recevrons le cookie, à condition bien sûr que la valeur éventuelle du champ Domain corresponde à la machine considérée. Ø Secure est utilisé pour que le cookie ne soit envoyé que si la transmission s'effectue via une version sécurisée de type HTTPS. Les cookies stockés sur le client sont ensuite communiqués au serveur lors des nouvelles requêtes. Avant d'envoyer une nouvelle requête vers l URL, le navigateur parcourt la liste des cookies qu'il possède. S'il y a occurrence entre l'url de la ressource contenue dans la requête et les différents champs définissant le domaine d'application d'un cookie, la valeur de celui-ci est inséré dans la requête. Si plusieurs cookies sont applicables, le client les renvoie sur une ligne suivant la syntaxe : Cookie: Nom1=valeur1; Nom2=valeur2;... ESIPE - IR1/IG1 La couche Application S. Lohier 53 ESIPE - IR1/IG1 La couche Application S. Lohier 54 Web et HTTP Les cookies : exemple Web et HTTP Exemple d analyse HTTP (1) Requête GET La première trame correspond à une demande d images au format png suite à une demande de page à partir du navigateur du client. Les en-têtes (Accept ) prennent un place importante parmi les données HTTP. Réponse Set-Cookie : PUB=malvista; path=/ Client + navigateur Cookie Requête GET Cookie : PUB=malvista Réponse Traitement Set-Cookie : PUB=doutenet; path=/ Serveur Web Requête GET Cookie : PUB=malvista; PUB=doutenet ESIPE - IR1/IG1 La couche Application S. Lohier 55 ESIPE - IR1/IG1 La couche Application S. Lohier 56 14

15 Web et HTTP Exemple d analyse HTTP (2) Web et HTTP Logiciels pour server web La deuxième trame contient la réponse (état, en-tête ). La connexion est fermée ensuite. Apache est depuis plusieurs années le logiciel serveur HTTP le plus utilisé (source Netcraft). ESIPE - IR1/IG1 La couche Application S. Lohier 57 ESIPE - IR1/IG1 La couche Application S. Lohier 58 Web et HTTP Questions Web et HTTP Questions (2) On a réalisé la capture suivante : Par quelle machine a été émise cette trame? Quel est le numéro de port serveur? Le numéro de port client? Ethernet II, Src: Dell_0d:84:96 (5c:26:0a:0d:84:96), Dst: Netgear_df:fb:74 (00:2 6:f2:df:fb:74) Internet Protocol, Src: ( ), Dst: ( ) Transmission Control Protocol, Src Port: (54503), Dst Port: http (80), Seq : 1, Ack: 1, Len: 901 Hypertext Transfer Protocol GET / HTTP/1.1\r\n Host: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; fr; rv: ) Gecko/ Ubuntu/10.10 (maverick) Firefox/3.6.12\r\n If-Non-Match: "31bfe-9de-362eef8b" Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n Accept-Charset: ISO ,utf-8;q=0.7,*;q=0.7\r\n Keep-Alive: 115\r\n Connection: keep-alive\r\n Quelle est la méthode HTTP utilisée? A quoi sert-elle? Quelle est la fonction des champs Host, User-Agent, Accept, Accept-charset. Que représente la valeur après le champ If-None-Match? Les connexions sont-elles persistantes ou non par défaut dans HTTP1.0? Dans HTTP1.1? A quoi sert le champ Keep-Alive dans la requête? ESIPE - IR1/IG1 La couche Application S. Lohier 59 ESIPE - IR1/IG1 La couche Application S. Lohier 60 15

16 La messagerie de base La messagerie de base Le service (Electronic Mail) permet d échanger des messages et des fichiers. Il nécessite : Ø pour l expéditeur et le destinataire, un client de messagerie et un logiciel client ou MUA (Mail user Agent, ex : Outlook, Thunderbird ) ; Ø un serveur de messagerie expéditeur et un logiciel serveur pour le transfert ou MTA (Mail Transfert Agent, ex : Sendmail, Postfix, Exchange ) ; Ø un serveur de messagerie destinataire intégrant une boîte au lettres (BAL) pour chaque client, un MTA pour le transfert entre serveurs et un logiciel serveur pour la délivrance des messages ou MDA (Mail Delivery Agent, ex : Sendmail, Postfix, Exchange ) ; Ø des protocoles d échange (SMTP, POP3, IMAP ). Client expéditeur asterix@laudanum.fr MUA Protocole SMTP Serveur de messagerie mail.laudanum.fr MTA Spool SMTP Internet Serveur de messagerie mail.babaorum.fr MTA MDA Client destinataire obelix@babaorum.fr MUA Protocole POP3 Un message est envoyé à l aide du MUA situé sur le client expéditeur. Il est reçu par l intermédiaire du MTA sur le serveur local du client et stocké dans une file d attente (spool) avec tous les autres messages des autres expéditeurs du domaine. Le MTA du serveur d expédition transfère ensuite le message stocké vers le serveur de messagerie correspondant au domaine du destinataire. La file d attente du serveur expéditeur est ainsi traitée avec une politique du type FIFO (First In First Out), le temps d attente pour un message donné est donc fonction du volume de messages qui transitent sur le serveur de messagerie du domaine. Le MTA destinataire vérifie ensuite que le destinataire de l existe bien pour le nom de domaine qu il a en charge. Il s appuie pour cela sur une base de données contenant tous les comptes mail existant. Si le destinataire n existe pas, le MTA renvoie un message d erreur à l émetteur du mail. Si l adresse de destination est reconnue dans le domaine, le message atterrit finalement dans la boîte aux lettres du destinataire en attente de lecture grâce au MDA du serveur de destination. Le message peut rester stocké sur le serveur et être lu à distance (fonctionnement en mode online) ou être déplacé vers la station du client et effacé du serveur (mode offline). SMTP BAL (mailbox) Obelix ESIPE - IR1/IG1 La couche Application S. Lohier 61 ESIPE - IR1/IG1 La couche Application S. Lohier 62 La messagerie de base La messagerie Webmail Pour le courrier sortant, c'est-à-dire pour expédier un message de MUA vers MTA ou pour échanger les messages entre deux serveurs de messagerie (MTA vers MTA), le protocole SMTP (Simple Mail Transfer Protocol) est utilisé. Pour le courrier entrant, c'est-à-dire pour récupérer et lire leur courrier (MDA vers MUA), les stations utilisent : Ø le protocole POP (Post Office Protocol), ou IMAP, qui est orienté vers un fonctionnement en mode offline et permet notamment de vérifier l identité du client voulant lire le courrier d une boîte aux lettres Ø le protocole IMAP (Internet Mail Access Protocol) destiné à la lecture interactive des messages via une interface web. Le standard MIME (RFC1521) reprend le standard simple de codage ASCII (RFC 822) mais en structurant le corps du message et en définissant des règles de codage pour le corps du message et les fichiers joints : Ø un codage base64 pour les messages binaires (groupes de 24 bits segmentés en 6 bits et ASCII légal : A pour 0, B pour 1 ) ; Ø un codage QP (Quoted Printable) pour les messages texte : codage ASCII sur 7 bits et une séquence spécifique composé du signe égal et de la valeur du caractère pour les codes supérieurs à 127 (Ex : St=E9phane); Ø un codage spécifique lié à l application (son, vidéo ). Le cœur du serveur webmail est un module logiciel d interfaçage entre les serveurs SMTP/IMAP et le navigateur du client. Ce logiciel, souvent écrit en PHP, code les messages en HTML et JavaScript, afin de les rendre compatibles avec les langages interprétés par les navigateurs. Les messages étant stockés et rangés sur le serveur de messagerie, un serveur webmail s interface plus naturellement avec un serveur IMAP pour le courrier entrant mais le protocole POP3 est également possible. Les paramètres de session navigateur-serveur sont stockés dans une base de données (MySQL par exemple). Cette solution ne nécessite pas de configuration, ni d installation sur les postes clients. La page de gestion des messages reçus et d émission des messages est fournie par le serveur webmail lors de la connexion du client au serveur. Internet Serveur SMTP Serveur IMAP/ POP3 Serveur webmail Serveur de messagerie Echanges HTTP Réseau local Client avec navigateur ESIPE - IR1/IG1 La couche Application S. Lohier 63 ESIPE - IR1/IG1 La couche Application S. Lohier 64 16

17 La messagerie Listes et forums La messagerie Chat Les listes de diffusions (mailing lists) permettent d envoyer un même courrier à plusieurs personnes en utilisant une adresse commune de liste. Les destinataires doivent être abonnés à la liste, celle-ci est gérée sur un serveur de liste (Sympa, Listserv ) qui comprend les commandes d abonnement, de désabonnement, de consultation d archives Les forums permettent également de regrouper des abonnés appartenant à une même communauté ou intéressés par un même sujet. Contrairement aux listes de diffusion pour lesquelles un seul courrier est envoyé vers plusieurs destinataires, les messages des forums sont stockés sur un serveur et consultés ou enrichis lorsque l utilisateur le souhaite. Messagerie instantanée. Chaque utilisateur peut dialoguer à tout moment avec tous les contacts qu il a référencé au préalable, si ceux-ci sont en ligne... Systèmes client serveur. Deux familles : Ø Protocoles de communication ouvert : XMPP (Jabber), IRC, SIP ; Ø Protocoles propriétaires : Windows messenger, AIM, ICQ, Skype, Yahoo Les protocoles propriétaires enferment des groupes d utilisateur au sein d un réseau fermé par la technologie : le contraire des protocoles historiques comme HTTP ou SMTP qui permettent l échange d information avec le monde entier. ESIPE - IR1/IG1 La couche Application S. Lohier 65 ESIPE - IR1/IG1 La couche Application S. Lohier 66 La messagerie Relais ouverts ou fermés La messagerie RFC 2821 Le protocole SMTP (1) Une relai SMTP ouvert est configuré pour transférer tous les messages, pas seulement ceux provenant ou à destination d utilisateurs connus du domaine. Avec l arrivée massive de spam et de vers, cette configuration par défaut est généralement évitée aujourd hui. Suivant le niveau de restriction, un relai fermé est configuré pour accepter seulement : Ø Les messages provenant d IP locales vers des boites locales ; Ø Les messages provenant d IP locales vers des boites non locales ; Ø Les messages provenant d IP non locales vers des boites locales ; Ø Les messages de clients authentifiés et autorisés. SMTP (Simple Mail Transport Protocol) est le protocole courant de gestion du courrier électronique sur Internet. C est un protocole point à point : Ø communication entre le client expéditeur et son serveur de messagerie ; Ø communication entre 2 serveurs de messagerie : celui de l expéditeur et celui du destinataire. Ces serveurs sont chargés du stockage dans les BAL et du transport du courrier, ils doivent acheminer régulièrement les messages stockés vers les destinations mentionnées dans les champs adresse. SMTP est conçu au départ pour des systèmes reliés en permanence. Un utilisateur connecté de façon intermittente (Dial up) via le RTC utilisera SMTP pour le courrier sortant, et un protocole tel POP3 pour le courrier entrant. ESIPE - IR1/IG1 La couche Application S. Lohier 67 ESIPE - IR1/IG1 La couche Application S. Lohier 68 17

18 La messagerie Protocole SMTP (2) La messagerie Format SMTP Le protocole SMTP spécifie : Client expéditeur asterix@laudanum.fr MUA SMTP MTA Serveur de messagerie expéditeur mail.laudanum.fr Spool SMTP Serveur de messagerie destinataire mail.babaorum.fr MTA Ø le format des adresses des utilisateurs suivant une notation Internet classique faisant figurer le nom de l utilisateur suivi du nom de domaine (asterix@babaorum.fr) ; Ø les champs des courriers (from, to ) ; Ø les possibilités d'envoi groupé : ü Le champ CC pour Carbone Copy ou Copie Conforme permet d envoyer le même message à plusieurs personnes, tous les noms des destinataires apparaîtront en clair dans le champ to ; ü Le champ BCC (Blinde Carbone Copy) ou CCI (Copie Conforme Invisible) permet de masquer le nom des autres destinataires dans le champ to ; From: asterix@laudanum.fr To: obelix@babaorum.fr Cc: panoramix@petitbonum.fr ; Subject: Ce soir Date: Fri, 28 May :48: RV à 23h sur FaceBook Asterix Internet la gestion des heures ; le codage utilisé pour le message et les fichiers joints («attachés») : Ø texte pur codé en ASCII 7 (RFC 822) ou 8 bits pour une prise en compte des caractères accentués ; Ø standard MIME pour du texte formaté, des images ou du son. ESIPE - IR1/IG1 La couche Application S. Lohier 69 ESIPE - IR1/IG1 La couche Application S. Lohier 70 La messagerie Format des messages SMTP La messagerie Commandes SMTP Le tableau suivant donne les principaux champs d en-tête RFC 822 liés au transport du message (to, from ) et ses caractéristiques (date, sujet ). Une fois formatés, les messages sont envoyés en utilisant les commandes SMTP : Ø commandes d envoi constituées de quatre lettres ; Ø commandes de réponse du serveur constituées d un code sur trois chiffres suivi d un message texte. ESIPE - IR1/IG1 La couche Application S. Lohier 71 ESIPE - IR1/IG1 La couche Application S. Lohier 72 18

19 La messagerie Dialogue SMTP La messagerie Exemple d analyse SMTP (1) Les 3 phases classiques de dialogue se retrouvent au niveau SMTP : Ø établissement de la connexion au niveau SMTP et identification de la source et de la destination ; Ø envoi du message avec les différents en-tête RFC 822 et RFC 1521 ; Ø libération de la connexion. La requête de connexion est envoyée par le client SMTP par une commande HELO ou EHLO pour ESMTP (Extended SMTP). 220 xyz.com ready (serveur prêt) Client boy@abc.com Outlook HELO abc.com (courrier de abc.com) 250 xyz.com (serveur OK) MAIL FROM : boy@abc.com 250 MAIL FROM OK RCPT TO : girl@xyz.com 250 RCPT TO OK DATA (envoi du message...) 354 Start mail input ; end with. Serveur SMTP xyz.com Le serveur répond par le code de contrôle 250 (OK) suivi d un message identifiant le serveur de mail. La connexion au niveau SMTP est réalisée. From... (corps du message) From: boy@abc.com To: girl@xyz.com... MIME... (corps du message) Mail accepted QUIT 221 xyz.com closing ESIPE - IR1/IG1 La couche Application S. Lohier 73 ESIPE - IR1/IG1 La couche Application S. Lohier 74 La messagerie Exemple d analyse SMTP (2) La messagerie Exemple d analyse SMTP (3) Suivent les commandes «MAIL FROM» et «RCPT To» précisant l expéditeur et le destinataire le message est transmis au serveur avec les différents en-têtes et suivant les formats RFC 822 et RFC ESIPE - IR1/IG1 La couche Application S. Lohier 75 ESIPE - IR1/IG1 La couche Application S. Lohier 76 19

20 La messagerie Authentification SMTP La messagerie RFC 1939 Protocole POP3 Pas défaut, l authentification n est pas utilisée sur SMTP. Si le serveur l accepte, le client peut cependant la demander (bien souvent, les FAI bloquent l'utilisation anonyme de leurs serveurs mails pour éviter le spam). Deux types d authentifications sont possibles : Ø Le type AUTH PLAIN utilise une authentification login/password, avec les deux valeurs sur la même ligne (\0login\0password) encodées en Base64. Ø Le type AUTH LOGIN utilise une authentification login/password, avec les deux valeurs successives encodées en Base64. Exemples open smtp.laposte.net mwinf8407.laposte.net ESMTP ehlo localhost 250-mwinf8407.laposte.net 250-AUTH PLAIN LOGIN 250-8BITMIME Le serveur autorise les 2 types auth plain 334 Login/password encodé AHBhdWwAMTIz plain authentication successfull Le client demande une authentification «plain» Le client demande une authentification «login» auth login 334 VXNlcm5hbWU6 Login encodé cgf1ba== 334 UGFzc3dvcmQ6 MTIz Password encodé 235 plain authentication successfull ESIPE - IR1/IG1 La couche Application S. Lohier 77 Après vérification de l adresse de destination et transfert par le MDA du message de la file d attente vers la BAL concernée, le client de messagerie ou MUA peut venir relever son courrier en utilisant le protocole POP3 (Post Office Protocol version 3). SMTP Internet Serveur de messagerie destinataire mail.babaorum.fr MTA Client destinataire obelix@babaorum.fr Requête MDA MUA POP3 BAL (mailbox) Obelix Message(s) ESIPE - IR1/IG1 La couche Application S. Lohier 78 La messagerie RFC 1939 Protocole POP3 La messagerie Commandes POP3 Le protocole POP qui, comme son nom l indique, a été conçu pour récupérer le courrier sur une machine distante pour un utilisateur non connecté en permanence, gère : Ø l authentification, c est-à-dire la vérification du nom et du mot de passe ; Ø la réception, suite à une requête, des courriers et fichiers attachés à partir du serveur de messagerie ; Ø la réception de messages d erreur ou d acquittement. Les commandes POP3 (RFC 1939) reprennent la syntaxe sur 4 lettres de SMTP. Les réponses du serveur sont transmises sous forme d une chaîne de caractères sont de deux types : +OK et ERR suivi d un texte. L'envoi de messages n'est pas supporté par le protocole POP3 de base. Il n'est pas sécurisé au niveau de la confidentialité dans la mesure où les messages sont stockés «en clair» sur le serveur de courrier. Par ailleurs, il est nécessaire de télécharger l intégralité du courrier sur la station avant la lecture, sans possibilité de manipuler directement les messages sur le serveur. Le protocole IMAP (Interactive Mail Access Protocol) est une alternative à POP3. Il permet d accéder aux messages sans les télécharger et d effectuer des recherches de courrier selon critères. ESIPE - IR1/IG1 La couche Application S. Lohier 79 ESIPE - IR1/IG1 La couche Application S. Lohier 80 20