Services des fournisseurs de services Internet

Module 7 Discovery 2 version 4.1 - Page 1 sur 51 Services des fournisseurs de services Internet 1 Présentation des services des fournisseurs de services Internet 1.1 Besoins du client Une fois la connexion établie avec le FAI, l entreprise ou le client doit décider quels services du FAI lui seront utiles. Les FAI servent plusieurs marchés. Le marché de la consommation est composé de personnes achetant des produits et services pour leur usage personnel. Le marché des entreprises est composé de sociétés multinationales. Entre ces deux pôles existent des marchés plus étroits, tels que ceux des petites et moyennes entreprises ou des organisations à but non lucratif de plus grande envergure. Chacun de ces clients a des besoins propres. Les exigences sans cesse croissantes des clients et les marchés de plus en plus compétitifs obligent les fournisseurs d accès à offrir de nouveaux services. Ces services permettent aux FAI d augmenter leurs revenus et de se distinguer de la concurrence. Courriel, hébergement de site Web, transmission multimédia en continu, téléphonie sur IP et transfert de fichiers sont des services importants que les FAI peuvent proposer à tous leurs clients. Ces services sont sensibles pour le marché des particuliers et des PME qui ne possèdent pas l expertise nécessaire pour les gérer eux-mêmes.

Module 7 Discovery 2 version 4.1 - Page 2 sur 51 De nombreuses organisations, de grande et petite taille, trouvent coûteuse la course à la technologie ou préfèrent consacrer leurs ressources à d autres aspects de leur activité. Les FAI offrent des services gérés qui permettent à ces organisations d accéder aux technologies et applications réseau de pointe sans avoir à effectuer d importants investissements en équipement et en support technique. Lorsqu une entreprise souscrit à un service géré, le fournisseur de services gère l équipement et les applications réseau conformément aux termes d un accord de niveau de service (ANS). Certains services gérés sont également hébergés, ce qui signifie que le fournisseur de services héberge les applications sur son site et non celui du client. Ci-après trois scénarios qui décrivent différentes relations entre FAI et client : Scénario 1 - le client possède et gère ses équipements et services réseau. Ces clients n ont besoin que d une connexion Internet fiable de la part du FAI. Scénario 2 - le FAI fournit la connexion Internet. Le FAI possède et gère l équipement réseau installé sur le site du client. Les responsabilités du FAI comprennent la configuration, la maintenance et l administration de l équipement pour le compte du client. Le client est responsable de la surveillance de l état du réseau et des applications et reçoit des rapports réguliers sur les performances du réseau. Scénario 3 - le client possède son équipement réseau, mais les applications sur lesquelles reposent ses activités sont hébergées par le FAI. Les serveurs qui exécutent

Module 7 Discovery 2 version 4.1 - Page 3 sur 51 les applications sont installés chez le FAI. Ces serveurs peuvent appartenir au client ou au FAI, mais c est le FAI qui est chargé de la maintenance des serveurs et des applications. Les serveurs sont normalement conservés dans des batteries de serveurs au centre d exploitation du réseau du FAI pour être connectés au réseau du FAI via un commutateur à haut débit. 1.2 Fiabilité et disponibilité La création de nouveaux services est une épreuve délicate. Les FAI doivent non seulement comprendre les souhaits de leurs clients, mais ils doivent avoir la capacité et les ressources nécessaires pour fournir ces services. À mesure que les applications professionnelles et Internet deviennent plus complexes, un nombre toujours plus important de clients de FAI s appuie sur les services fournis ou gérés par le FAI.

Module 7 Discovery 2 version 4.1 - Page 4 sur 51 Les FAI fournissent des services à leurs clients pour un prix et un niveau de service garanti, définis dans l accord de niveau de service. Pour répondre à cette attente, les offres de service des FAI doivent être fiables et disponibles. Fiabilité La fiabilité peut se mesurer de deux manières : intervalle moyen entre les défaillances (MTBF) et durée moyenne de rétablissement (MTTR). Les fabricants d équipements spécifient le MTBF déterminé lors de tests effectués dans le cadre de la fabrication. La mesure de la robustesse de l équipement est la tolérance aux pannes. Plus l intervalle moyen entre les défaillances est long, plus la tolérance aux pannes est élevée. La durée moyenne de rétablissement est établie par les accords de garantie ou de service. En cas de défaillance matérielle entraînant une interruption du réseau ou du service, la capacité du FAI à se conformer aux conditions du contrat de niveau de service est affectée. Pour se prémunir contre ce désagrément, un FAI peut se procurer des accords de services onéreux pour ses matériels les plus critiques afin de garantir une intervention rapide du fabricant ou du revendeur. Un FAI peut également choisir de se procurer ses équipements en double et de disposer de pièces sur site. Disponibilité La disponibilité se mesure normalement en pourcentage du temps d accessibilité d une ressource. Un pourcentage de disponibilité parfait serait de 100 %, signifiant que le système ne connaît aucune défaillance et n est jamais inaccessible. Traditionnellement, on attend que les services téléphoniques fonctionnent 99,999 % du temps. C est ce que l on appelle le standard de disponibilité des cinq 9. Avec ce standard, seul un pourcentage infime, (0,001 %), d interruption du service est toléré. À mesure que les FAI offrent des services d entreprise de plus en plus sensibles, tels que la téléphonie sur IP, ou des capacités de transactions

Module 7 Discovery 2 version 4.1 - Page 5 sur 51 commerciales de vente au détail de grand volume, ceux-ci doivent être à la hauteur des attentes les plus élevées des clients. Les FAI garantissent l accessibilité en doublant les périphériques et serveurs réseau à l aide de technologies conçues pour le maintien de la disponibilité. Dans les configurations redondantes, lorsqu un périphérique cesse de fonctionner, l autre prend automatiquement le relais. 2 Protocoles prenant en charge les services des fournisseurs de services Internet 2.1 Tour d horizon des protocoles TCP/IP Aujourd hui, les clients des FAI se servent de leur téléphone portable comme téléviseur, de leur ordinateur comme téléphone et de leur téléviseur comme console de jeux interactive dotée de différentes options de divertissement. À mesure que les services réseau se sophistiquent, les FAI doivent tenir compte de ces préférences utilisateur. Le développement de réseaux IP convergents permet à tous ces services d être livrés par le biais d un réseau commun. Pour assurer le support technique des nombreuses applications TCP/IP destinées aux utilisateurs finaux, il est important que le personnel du support technique du FAI soit familiarisé avec le fonctionnement des protocoles TCP/IP.

Module 7 Discovery 2 version 4.1 - Page 6 sur 51 Les serveurs des FAI doivent être capables de prendre en charge de nombreuses applications pour de nombreux clients différents. Pour ce faire, ils doivent utiliser les fonctions fournies par les deux protocoles de transport TCP/IP, TCP et UDP. Les applications hébergées courantes, telles que les comptes de mise en œuvre de serveurs Web et de messagerie, dépendent également de protocoles TCP/IP sous-jacents pour la fiabilité de leur livraison. De plus, tous les services IP s appuient sur des serveurs de noms de domaine (DNS), hébergés par les FAI, pour assurer le lien entre la structure d adressage IP et les URL que les clients utilisent pour y accéder. Clients et serveurs utilisent des standards et des protocoles IP spécifiques lors de l échange d informations. Les protocoles TCP/IP peuvent être représentés à l aide d un modèle à quatre couches. Nombre des services clés proposés aux clients FAI s appuient sur des protocoles qui résident dans les couches transport et application du modèle TCP/IP. Protocoles de couche application Les protocoles de couche application spécifient les informations de format et de contrôle nécessaires à un grand nombre de fonctions courantes de communication via Internet. Voici certains de ces protocoles : le protocole DNS (Domain Name System) est utilisé pour convertir les adresses Internet en adresses IP. Le protocole HTTP (HyperText Transfer Protocol) est utilisé pour transférer les fichiers qui constituent les pages du Web. Le protocole SMTP (Simple Mail Transfer Protocol) permet l utilisation de services de messagerie électronique. Le protocole Telnet, protocole d émulation de terminal, est utilisé pour permettre un accès distant aux serveurs et aux périphériques réseau. Le protocole FTP (File Transfer Protocol) est utilisé pour le transfert de fichiers entre les réseaux.

Module 7 Discovery 2 version 4.1 - Page 7 sur 51 Protocole de couche transport Différents types de données peuvent avoir des spécifications particulières. Pour certaines applications, les segments de communication doivent arriver dans un ordre donné pour être traités avec succès. Dans d autres cas, toutes les données doivent être reçues avant d être utilisées. Parfois, une application peut tolérer la perte d une petite quantité de données en cours de transmission via le réseau. Dans les réseaux convergents d aujourd hui, des applications dont les besoins en matière de transport sont très différents peuvent communiquer sur le même réseau. Les différents protocoles de la couche transport sont régis par des règles différentes pour permettre aux périphériques de traiter ces attentes variables en matière de données. De plus, les couches les plus basses ne savent pas que de nombreuses applications envoient des données par le réseau. Leur responsabilité consiste à faire en sorte que les données accèdent au périphérique. C est la mission de la couche transport de fournir les données à l application appropriée. Les deux protocoles principaux de la couche transport sont TCP et UDP. Le modèle TCP/IP et le modèle OSI présentent des similitudes et des différences. Similitudes

Module 7 Discovery 2 version 4.1 - Page 8 sur 51 Utilisation de couches pour visualiser l interaction des protocoles et des services Couches transport et réseau comparables Application dans le domaine de la gestion de réseau lorsqu il est fait référence à l interaction des protocoles Différences Le modèle OSI scinde la fonction de la couche application du protocole TCP/IP en couches distinctes. Les trois couches supérieures du modèle OSI spécifient la même fonctionnalité que la couche application du modèle TCP/IP. La suite TCP/IP ne spécifie pas de protocoles pour l interconnexion réseau physique. Les deux couches inférieures du modèle OSI s intéressent à l accès au réseau physique et au transfert des bits entre les hôtes sur un réseau local. Le modèle TCP/IP repose sur des protocoles réels et des standards établis, tandis que le modèle OSI est un guide théorique sur l interaction des protocoles. 2.2 Protocole de couche transport Différentes applications ont différents besoins en matière de transport. Il existe deux protocoles dans la couche transport : TCP et UDP Protocole TCP TCP est un protocole fiable, avec livraison garantie. Il spécifie les méthodes que les hôtes utilisent pour accuser réception des paquets et nécessite que l hôte source renvoie les paquets dont la réception n est pas confirmée. Le protocole TCP régit également l échange de messages entre les hôtes sources et de destination pour créer une session de communication.

Module 7 Discovery 2 version 4.1 - Page 9 sur 51 Ce protocole est souvent comparé à un pipeline, ou à une connexion permanente, entre hôtes. C est pourquoi TCP est appelé protocole orienté connexion. Le protocole TCP impose une surcharge pour conserver la trace des conversations individuelles entre les hôtes sources et de destination et pour traiter les reçus ainsi que les retransmissions. Dans certains cas, les retards causés par cette surcharge ne sont pas tolérés par l application. Ces applications sont plus adaptées à l UDP. Protocole UDP Le protocole UDP est un protocole très simple, sans connexion. Il n impose qu un très faible surdébit pour la remise des données. Le protocole UDP est un protocole de couche transport dit «au mieux» car il n effectue aucune vérification d erreurs, ne garantit aucune livraison de données ni aucun contrôle de flux. Étant donné que l UDP est un protocole de couche transport «au mieux», les datagrammes UDP peuvent arriver à destination dans le désordre, ou même se perdre. Les applications qui utilisent l UDP peuvent tolérer la perte de petites quantités de données. La webradio est un exemple d application UDP. Si quelques données manquent à l arrivée, la qualité de la diffusion ne s en trouvera que modérément affectée.

Module 7 Discovery 2 version 4.1 - Page 10 sur 51 Les applications, telles que les bases de données, les pages Web et le courriel, exigent que toutes les données arrivent à destination dans leurs conditions d origine pour être exploitables. Toute donnée manquante peut endommager les messages ou les rendre illisibles. Ces applications sont conçues pour utiliser un protocole de couche transport qui implémente la fiabilité. La surcharge réseau supplémentaire requise pour assurer cette fiabilité est considérée comme un coût raisonnable pour une communication réussie. Le protocole de couche transport est déterminé en fonction du type des données d application qui sont envoyées. Par exemple, un message électronique nécessite que sa livraison soit confirmée et utilisera donc le protocole TCP. Un client de messagerie, qui utilise SMTP, envoie un message électronique sous la forme d un flux d octets à la couche transport. Dans la couche transport, la fonctionnalité TCP divise le flux en segments. Au sein de chaque segment, TCP identifie chaque octet à l aide d un numéro de séquence. Ces segments sont transférés à la couche Internet, qui les place chacun dans un paquet, pour transmission. Ce processus s appelle l encapsulation. À destination, le processus est inversé, et les paquets sont désencapsulés. Les segments insérés dans les paquets sont envoyés via le processus TCP, qui reconvertit les segments en un flux d octets à passer à l application du serveur de messagerie.

Module 7 Discovery 2 version 4.1 - Page 11 sur 51 Avant qu une session TCP puisse être utilisée, les hôtes sources et de destination échangent des messages pour configurer la connexion par laquelle seront acheminés les segments de données. Les deux hôtes utilisent un processus à trois étapes pour établir la connexion. Au cours de la première étape, l hôte source envoie un type de message appelé SYN (message de synchronisation) pour démarrer le processus d établissement de session TCP. Le message a deux objectifs : Indiquer l intention de l hôte source d établir une connexion avec l hôte de destination pour l envoi des données Synchroniser les numéros de séquence TCP entre les deux hôtes de sorte que chaque hôte conserve la trace des segments envoyés et reçus au cours de la conversation Lors de la deuxième étape, l hôte de destination répond au message SYN avec un reçu de synchronisation, ou message SYN-ACK. À la dernière étape, l hôte qui envoie les données reçoit le message SYN-ACK et renvoie un message ACK (acknowledgment) afin de mettre fin à la configuration de la connexion. Les segments de données peuvent maintenant être envoyés en toute sécurité. Cette activité SYN, SYN-ACK, ACK entre les processus TCP sur les deux hôtes s appelle une connexion en trois étapes.

Module 7 Discovery 2 version 4.1 - Page 12 sur 51 Lorsqu un hôte envoie des segments de message à un hôte de destination par TCP, le processus TCP démarre un chronomètre sur l hôte source. Le chronomètre laisse suffisamment de temps au message pour atteindre l hôte de destination et à un accusé de réception d être envoyé. Si l hôte source ne reçoit pas de reçu de la destination dans le délai imparti, le chronomètre expire et la source estime que le message est perdu. La partie du message non reçue est renvoyée. Outre le reçu et la retransmission, le protocole TCP spécifie également comment les messages sont réassemblés sur l hôte de destination. Chaque segment TCP contient un numéro de séquence. Sur l hôte de destination, le processus TCP stocke les segments reçus dans une mémoire tampon. En évaluant les numéros de séquence du segment, le processus TCP peut confirmer que les données reçues ne subissent aucune rupture. Lorsque les données sont reçues dans le désordre, le processus TCP peut également réordonner les segments.

Module 7 Discovery 2 version 4.1 - Page 13 sur 51 2.3 Différences entre les protocoles TCP et UDP Le protocole UDP est un protocole très simple. Étant donné qu il est sans connexion et qu il est dépourvu de mécanismes sophistiqués de retransmission, de séquençage et de contrôle de flux du protocole TCP, le protocole UPD impose beaucoup moins de surcharge. On en parle souvent comme d un protocole de livraison non fiable, car aucune garantie n est faite à l expéditeur que le message a été reçu par l hôte de destination. Cela ne signifie pas que les applications qui utilisent ce protocole ne sont pas fiables. Cela signifie simplement que ces fonctions ne sont pas fournies par le protocole de la couche transport et qu elles doivent être implémentées ailleurs, si nécessaire. Bien que la quantité totale du trafic UDP d un réseau moyen soit souvent relativement faible, les principaux protocoles de couche application qui utilisent le protocole UDP comprennent : le système de noms de domaine (DNS) ; le protocole SNMP (Simple Network Management Protocol) ; le protocole DHCP (Dynamic Host Configuration Protocol) ; le protocole de routage RIP ; le protocole TFTP (Trivial File Transfer Protocol) ; des jeux en ligne. Ce sont les fonctions spécifiques implémentées par chaque protocole et la surcharge occasionnée qui différencient principalement TCP et UDP. Il suffit d examiner leur en-tête pour constater facilement les différences qui séparent ces deux protocoles. Chaque segment du protocole TCP utilise 20 octets de surcharge dans l en-tête pour encapsuler les données de la couche application. Cette surcharge est occasionnée par les mécanismes de vérification des erreurs pris en charge par TCP.

Module 7 Discovery 2 version 4.1 - Page 14 sur 51 Les blocs de communications utilisés dans le protocole UDP sont appelés des datagrammes. Ces datagrammes sont envoyés «au mieux» est nécessitent seulement 8 octets de surcharge. Corrigé

Module 7 Discovery 2 version 4.1 - Page 15 sur 51 2.4 Prise de charge de services multiples La tâche consistant à gérer plusieurs processus de communication simultanés est assurée par la couche transport. Les services TCP et UDP conservent la trace des différentes applications qui communiquent via le réseau. Pour différencier les segments et les datagrammes de chaque application, les protocoles TCP et UDP utilisent chacun des champs d en-tête identifiant ces applications de façon unique à des fins de communication des données. Dans l en-tête de chaque segment ou datagramme se trouvent un port source et un port de destination. Les numéros de port sont assignés de différentes manières, suivant que le message est une requête ou une réponse. Lorsqu une application envoie une requête à une application serveur, le port de destination contenu dans l en-tête est celui qui est assigné à l application exécutée sur le serveur. Par exemple, lorsqu une application de navigateur Web envoie une requête à un serveur Web, le navigateur utilise le protocole TCP et le port numéro 80. La raison en est que le port TCP 80 est le port assigné par défaut aux applications Web. De nombreuses applications courantes ont des ports assignés par défaut. Les serveurs de messagerie qui utilisent SMTP se voient généralement assigner le port TCP 25. À mesure que les segments sont reçus pour un port spécifique, TCP ou UDP place les segments entrants dans la file appropriée. Par exemple, si la requête d application est pour le protocole HTTP, le processus TCP exécuté sur un serveur Web place les segments entrants dans la file d attente du serveur Web. Ces segments sont ensuite passé à l application HTTP aussi rapidement que le protocole HTTP peut les accepter.

Module 7 Discovery 2 version 4.1 - Page 16 sur 51 Les segments pour lequel le port 25 est spécifié sont placés dans une file d attente séparée dirigée vers les services de messagerie. De cette manière, les protocoles de la couche transport permettent aux serveurs situés chez le FAI d héberger simultanément de nombreuses applications et services. Dans toute transaction Internet, on trouve un hôte source et un hôte de destination, normalement un client et un serveur. Les processus TCP des hôtes émetteur et récepteur sont légèrement différents. Les clients sont actifs et demandent des connexions, tandis que les serveurs sont passifs, écoutant et acceptant les connexions. Les processus serveur se voient généralement attribuer de manière statique des numéros de port réservés compris entre 0 et 1023. Les numéros de ports de ce type permettent à une application cliente d attribuer le port de destination correct lorsqu ils lancent une requête de services. Les clients requièrent également des numéros de port pour identifier l application cliente. Les ports sources sont assignés de manière dynamique dans la plage de ports comprise entre 1024 et 65535. Cette affectation de port agit comme une adresse de retour pour l application qui en fait la demande. La couche transport conserve la trace du port source et de l application qui a lancé la requête, de sorte qu elle peut être transmise à l application voulue lorsqu une réponse est renvoyée.

Module 7 Discovery 2 version 4.1 - Page 17 sur 51 La combinaison du numéro de port de la couche transport et de l adresse IP de la couche réseau de l hôte suffisent à identifier de manière unique un processus d application particulier exécuté sur un périphérique hôte individuel. Cette combinaison s appelle une interface de connexion, ou socket. Une paire de sockets, composée des adresse IP et numéros de port source et de destination, est également unique et identifie la conversation spécifique entre les deux hôtes.

Module 7 Discovery 2 version 4.1 - Page 18 sur 51 Un socket client peut se présenter comme suit, 7151 représentant le numéro de port source : 192.168.1.1:7151 Le socket d un serveur Web peut avoir la forme suivante : 10.10.10.101:80 Ensemble, ces deux sockets constituent une paire de sockets : 192.168.1.1:7151, 10.10.10.101:80 Avec la création de sockets, les points de communication sont connus de sorte que les données peuvent passer d une application sur un hôte à une application sur un autre. Les sockets permettent à plusieurs processus exécutés sur un client de se différencier les uns des autres, et aux multiples connexions à un processus serveur de se distinguer les unes des autres. 3 Système de noms de domaine (DNS) 3.1 Nom d hôte TCP/IP La communication entre les hôtes sources et de destination via Internet nécessite que chaque hôte dispose d une adresse IP valide. Toutefois, les adresses IP numériques, notamment les centaines de milliers d adresses assignées aux serveurs disponibles sur Internet, ne sont pas simples à retenir pour les utilisateurs. Les noms de domaine lisibles par des humains, tels que cisco.com, sont plus simples à utiliser. Les systèmes d attribution de nom sont conçus pour traduire les noms lisibles par les humains en adresses IP numériques pouvant être utilisées pour communiquer sur le réseau. Les personnes utilisent les systèmes d attribution de nom du réseau chaque jour lorsqu elles surfent sur le Web ou envoient des messages électroniques, même si elles n en ont pas conscience. S ils sont masqués, les systèmes d attribution de nom n en constituent pas moins une partie intégrante de la communication en réseau. Par exemple, pour accéder au site Web de Cisco Systems, ouvrez un navigateur, puis entrez http://www.cisco.com dans le champ d adresse. www.cisco.com est un nom réseau associé à une adresse IP spécifique. La saisie de l adresse IP serveur dans le navigateur entraîne l affichage de la même page Web.

Module 7 Discovery 2 version 4.1 - Page 19 sur 51 Les systèmes d attribution de noms sont des outils destinés à faciliter l usage d Internet aux personnes en les aidant à accéder aux ressources dont elles ont besoin sans avoir à se souvenir d adresses IP complexes. Aux premiers temps d Internet, les noms d hôtes et les adresses IP étaient gérés à l aide d un fichier HOSTS situé sur un serveur central. Le fichier HOSTS central contenait le mappage entre le nom d hôte et l adresse IP de chaque périphérique connecté à l Internet des débuts. Chaque site pouvait télécharger le fichier HOSTS et l utiliser pour résoudre les noms d hôtes sur le réseau. À chaque entrée de nom d hôte, l hôte émetteur vérifiait l adresse IP du périphérique de destination dans le fichier HOSTS téléchargé. Au départ, le système du fichier HOSTS fonctionnait en raison du nombre limité d ordinateurs constituant l Internet d alors. Le nombre d hôtes nécessitant des conversions de noms en adresses IP augmenta dans la même mesure que le réseau et il devint impossible de maintenir le fichier HOSTS à jour. Une nouvelle méthode de résolution des noms d hôtes en adresses IP vit alors le jour. DNS fut créé pour convertir les noms de domaines en adresses. Ce système utilise un ensemble distribué de serveurs pour convertir les noms associés à ces adresses numérotées. Un fichier HOSTS unique et central n est plus de mise. Toutefois, le fichier HOSTS demeure utilisé par la majorité des systèmes d ordinateurs. Un fichier HOSTS local est créé sur un périphérique hôte lorsque celui-ci télécharge le protocole TCP/IP. Le fichier HOSTS est scanné avant même que le service DNS, plus robuste, soit interrogé, au cours du processus de résolution de nom sur un système d ordinateur. Un fichier HOSTS local peut être utilisé pour réparer ou remplacer des enregistrements trouvés dans un serveur DNS.

Module 7 Discovery 2 version 4.1 - Page 20 sur 51 Travaux pratiques : Configurez la résolution de noms à l aide du fichier HOSTS.

Module 7 Discovery 2 version 4.1 - Page 21 sur 51 3.2 Hiérarchie DNS DNS pallie les carences du fichier HOSTS. La structure du DNS est hiérarchique, avec une base de données distribuée de mappages entre noms d hôte et adresses IP couvrant de nombreux serveurs DNS dans le monde. Ce système est donc différent de celui du fichier HOSTS, dans lequel tous les mappages étaient conservés et gérés dans un seul serveur. DNS utilise des noms de domaines pour élaborer sa hiérarchie. La structure d attribution de noms est divisée en petites zones gérables. Chaque serveur DNS tient à jour un fichier de base de données spécifique et se charge uniquement des mappages entre noms et adresses IP dans cette petite partie de la structure DNS globale. Lorsqu un serveur DNS reçoit une requête de traduction de noms qui n appartiennent pas à cette zone DNS, le serveur DNS peut transférer la requête à un autre serveur DNS se trouvant dans la zone de traduction voulue. Le serveur de noms de domaines (DNS) est évolutif car la conversion des noms d hôte s étend à plusieurs serveurs. DNS est composé de trois éléments. Enregistrement de ressources et espace de noms de domaine Un enregistrement de ressource est un enregistrement de données dans le fichier de base de données de zone DNS. Il permet d identifier un type d hôte, une adresse IP d hôte ou un paramètre de la base de données DNS. L espace de noms de domaine fait référence à la structure d attribution de nom hiérarchique permettant d organiser les enregistrements de ressources. L espace de noms de domaine est composé de différents domaines, ou groupes, et des enregistrements de ressources contenus dans chaque groupe. Serveurs de système de noms de domaine Ces serveurs gèrent les bases de données qui stockent les enregistrements de ressources et les informations sur la structure d espace de noms de domaine. Les serveurs DNS essaient de résoudre les requêtes de leurs clients à l aide de l espace de noms de domaine et des enregistrements de ressources qu ils gèrent dans leurs fichiers de base de données de zone. Si la base de données de zone DNS du serveur de noms ne comporte pas les informations demandées, il se sert de serveurs de noms prédéfinis supplémentaires pour l aider à convertir la requête de traduction de nom en adresse IP. Résolveurs

Module 7 Discovery 2 version 4.1 - Page 22 sur 51 Les résolveurs sont des applications ou fonctions de système d exploitation qui s exécutent sur des clients DNS et des serveurs DNS. Lorsqu un nom de domaine est utilisé, le résolveur demande au serveur DNS de traduire ce nom en adresse IP. Un résolveur est chargé sur un client DNS puis utilisé pour créer la requête de nom DNS qui est envoyée à un serveur DNS. Les résolveurs sont également chargés sur des serveurs DNS. Si le serveur DNS ne possède pas le mappage nom-adresse IP demandé, il utilise le résolveur pour transmettre la requête à un autre serveur DNS. DNS utilise un système hiérarchique pour convertir les noms. La hiérarchie ressemble à un arbre inversé, avec la racine au sommet et les branches au-dessous. Au sommet de la hiérarchie, les serveurs racines gèrent des enregistrements sur la manière d accéder aux serveurs de domaine de niveau supérieur, qui à leur tour possèdent des enregistrements qui pointent vers les serveurs de domaine de niveau secondaire. Les différents domaines de niveau supérieur représentent soit le type d organisation, soit le pays d origine. Ci-après quelques exemples de domaines :.au - Australie.co - Colombie.com - entreprise ou industrie.jp - Japon.org - organisations à but non lucratif Après les domaines de niveau supérieur, se trouvent les noms de domaine de niveau secondaire et, plus bas encore, les domaines de niveau inférieur.

Module 7 Discovery 2 version 4.1 - Page 23 sur 51 Le serveur DNS racine peut ne pas savoir exactement où se trouve l hôte H1.cisco.com, mais il possède un enregistrement pour le domaine de niveau supérieur.com. De même, les serveurs du domaine.com peuvent ne pas avoir d enregistrement pour H1.cisco.com non plus, mais ils possèdent un enregistrement pour le domaine cisco.com. Les serveurs DNS du domaine cisco.com ont l enregistrement pour H1.cisco.com et peuvent résoudre l adresse. DNS repose sur cette hiérarchie de serveurs décentralisés pour stocker et gérer ces enregistrements de ressources. Les enregistrements de ressources contiennent des noms de domaine que le serveur peut convertir, et d autres serveurs pouvant également traiter les requêtes. Le nom H1.cisco.com est appelé nom de domaine complet (FQDN pour Fully Qualified Domain Name) ou nom DNS, car il définit l emplacement exact de l ordinateur dans l espace de noms DNS hiérarchique.

Module 7 Discovery 2 version 4.1 - Page 24 sur 51 3.3 Résolution de noms DNS Lorsqu un hôte doit convertir un nom DNS, il se sert du résolveur pour contacter un serveur DNS de son domaine. Le résolveur connaît l adresse IP du serveur DNS à contacter, car il a été préconfiguré dans le cadre de la configuration IP de l hôte. Lorsque le serveur DNS reçoit la requête du résolveur client, il vérifie d abord les enregistrements DNS locaux mis en cache dans sa mémoire. S il est incapable de résoudre localement l adresse IP, le serveur utilise son résolveur pour transférer la requête à un autre serveur DNS préconfiguré. Ce processus se poursuit jusqu à ce que l adresse IP soit résolue. L information de résolution de nom est renvoyée au serveur DNS d origine, qui utilise cette information pour répondre à la requête initiale. Au cours du processus de résolution de noms DNS, chaque serveur DNS place dans sa mémoire cache, ou stocke, les informations qu il reçoit en réponse aux demandes. Les informations en cache permettent au serveur DNS de répondre plus rapidement aux requêtes ultérieures du résolveur, car le serveur cherche d abord parmi les enregistrements en cache avant d interroger les autres serveurs DNS. Les serveurs DNS ne conservent les informations en cache que pendant une durée limitée. Les serveurs DNS ne doivent pas conserver les informations en cache trop longtemps, car les

Module 7 Discovery 2 version 4.1 - Page 25 sur 51 enregistrements de noms d hôte changent régulièrement. Si un serveur DNS conservait des informations trop anciennes en cache, il pourrait fournir une adresse IP d ordinateur erronée.

Module 7 Discovery 2 version 4.1 - Page 26 sur 51 Travaux pratiques :Examinez l interface d un serveur DNS Windows pour consulter les informations DNS en cache provenant d une recherche DNS. Dans les premières implémentations du système DNS, les enregistrements de ressources pour hôtes étaient tous ajoutés et mis à jour manuellement. Toutefois, à mesure que les réseaux grandissaient et que le nombre d enregistrements d hôtes à gérer augmentait, il devenait très inefficace de continuer à gérer manuellement les enregistrements de ressources. De plus, lorsque le protocole DHCP est utilisé, les enregistrements de ressources au sein de la zone DNS doivent être mis à jour encore plus fréquemment. Pour faciliter la mise à jour des informations de zone DNS, le protocole DNS a été modifié pour permettre aux systèmes informatiques de mettre à jour leur propre enregistrement dans la zone DNS grâce à des mises à jour dynamiques. Les mises à jour dynamiques permettent aux clients DNS d identifier et d actualiser dynamiquement leurs enregistrements de ressources sur un serveur DNS à chaque modification. Pour utiliser la mise à jour dynamique, le serveur DNS et les clients DNS ou le serveur DHCP doivent prendre en charge la fonctionnalité de mise à jour dynamique. Les mises à jour dynamiques sur le serveur DNS ne sont pas activées par défaut ; elles doivent donc être explicitement activées. La plupart des systèmes informatiques actuels prennent en charge l utilisation de mises à jour dynamiques. Les serveurs DNS gèrent la base de données de zone d une portion donnée de la hiérarchie DNS globale. Les enregistrements de ressources sont stockés dans cette zone DNS. Les zones DNS sont soit des zones de recherche directe, soit des zones de recherche inversée. Elles peuvent être également des zones de recherche directe ou inverse principales ou secondaires. Chaque type de zone tient un rôle spécifique au sein de l infrastructure DNS générale. Zones de recherche directe Une zone de recherche directe est une zone DNS standard qui convertit les noms de domaine complets en adresses IP. Il s agit du type de zone le plus répandu sur Internet. Lorsque vous

Module 7 Discovery 2 version 4.1 - Page 27 sur 51 saisissez une adresse de site Web, telle que www.cisco.com, une requête récursive est envoyée au serveur DNS local pour convertir ce nom en une adresse IP afin d établir une connexion au serveur Web distant. Zones de recherche inversée Une zone de recherche inversée est une zone spéciale qui permet de convertir une adresse IP en un nom de domaine complet. Certaines applications utilisent la fonctionnalité de recherche inversée pour identifier les systèmes informatiques qui communiquent activement avec elles. Il existe sur Internet une hiérarchie DNS entière à recherche inversée qui permet de résoudre n importe quelle adresse IP enregistrée publiquement. De nombreux réseaux privés choisissent d implémenter leurs propres zones de recherche inversée locales pour identifier plus facilement les systèmes informatiques au sein de leur réseau. Les recherches inverses portant sur les adresses IP s obtiennent à l aide de la commande ping -a [adresse_ip].

Module 7 Discovery 2 version 4.1 - Page 28 sur 51 Zones principales Une zone DNS principale est une zone modifiable. Lorsqu il est nécessaire d ajouter une ressource ou de mettre à jour ou de supprimer un enregistrement, les modifications s effectuent sur une zone DNS principale. Lorsqu il existe une zone principale sur un serveur DNS, ce serveur en a l autorité. En effet, il fournira la réponse aux requêtes DNS pour les enregistrements figurant dans cette zone. Il ne peut y avoir qu une seule zone DNS principale pour un domaine DNS donné. Cependant, il peut exister une zone principale de recherche directe et une zone principale de recherche inversée. Zones secondaires Une zone secondaire est une zone de sauvegarde en lecture seule gérée sur un serveur DNS distinct. La zone secondaire est la réplique de la zone principale. Elle reçoit les mises à jour des informations de zone du serveur principal. Cette zone secondaire est une copie en lecture seule de la zone. C est pourquoi tous les enregistrements doivent être effectués dans la zone principale correspondante. Les zones secondaires peuvent également être utilisées pour effectuer des recherches directes ou inverses. Selon les critères de disponibilité relatifs à une zone DNS, il peut y avoir de nombreuses zones DNS secondaires réparties sur plusieurs serveurs DNS. Travaux pratiques : Créez des zones DNS principales et secondaires sur un serveur Windows.

Module 7 Discovery 2 version 4.1 - Page 29 sur 51 3.4 Implémentations de solutions DNS Il existe différents moyens d implémenter des solutions DNS. Serveurs DNS du FAI Les FAI gèrent le plus souvent des serveurs DNS en cache uniquement. Ces serveurs sont configurés pour transférer toutes les demandes de résolution de noms aux serveurs racines sur Internet. Les résultats sont mis en cache puis servent à répondre à toute demande ultérieure. Étant donné que les clients du FAI sont nombreux, le nombre de recherches DNS en cache est élevé. La taille importante du cache économise la bande passante du réseau en diminuant la fréquence de transfert des demandes DNS aux serveurs racines. Les serveurs en cache uniquement ne gèrent aucune information de zone autorisée, ce qui signifie qu ils ne stockent aucun mappage nom-adresse IP directement dans leur base de données. Serveurs DNS locaux Une entreprise peut opérer son propre serveur DNS. Les ordinateurs clients de ce réseau sont configurés de manière à pointer vers le serveur DNS local plutôt que vers le serveur DNS du FAI. Le serveur DNS local peut gérer quelques entrées autorisées pour cette zone et dispose ainsi des mappages nom-adresse IP de tout hôte appartenant à la zone. Si le serveur DNS reçoit une requête à laquelle il ne peut répondre, celle-ci est transférée. Le cache requis sur un serveur local est relativement petit comparé au serveur DNS du FAI, en raison du plus petit nombre de requêtes. Il est possible de configurer les serveurs DNS locaux de sorte qu ils dirigent les requêtes directement vers le serveur DNS racine. Toutefois, certains administrateurs configurent les serveurs DNS locaux afin qu ils dirigent toutes les requêtes DNS vers un serveur DNS en amont, tel que le serveur DNS du FAI. De cette manière, le serveur DNS local bénéficie du grand nombre d entrées DNS en cache du FAI, sans avoir à effectuer une recherche complète à partir du serveur racine.

Module 7 Discovery 2 version 4.1 - Page 30 sur 51 La perte d accès aux serveurs DNS affecte la visibilité des ressources publiques. Si les utilisateurs entrent des noms de domaine qui ne peuvent pas être convertis, ils ne peuvent pas accéder à ces ressources. C est pourquoi, lorsqu une organisation enregistre un nom de domaine sur Internet, elle doit fournir au moins deux serveurs DNS. Ces serveurs sont ceux qui possèdent la base de données de zone. Avec des serveurs DNS redondants, l un est toujours disponible pour la conversion du nom, même si l autre est défaillant. Cette pratique permet une tolérance aux pannes. Si les ressources matérielles le permettent, il est préférable d avoir plus de deux serveurs DNS dans une zone, afin d améliorer la sécurité et l organisation. Il est également préférable de s assurer que les différents serveurs DNS qui contiennent les informations de zone sont hébergés par des réseaux physiques différents. Par exemple, les informations de zone principale DNS sont stockées sur un serveur DNS dans les locaux de l entreprise. Généralement, le FAI héberge un deuxième serveur DNS secondaire pour garantir la tolérance aux erreurs. DNS est un service réseau sensible. C est pourquoi les serveurs DNS doivent être protégés à l aide d un pare-feu et d autres mesures de protection. Si le DNS est défaillant, les autres services Web sont inaccessibles.

Module 7 Discovery 2 version 4.1 - Page 31 sur 51 4 Services et protocoles 4.1 Services Outre la connectivité et les services DNS dispensés aux personnes et aux entreprises, les FAI offrent de nombreux services de gestion à leurs clients. Ces services sont activés par des logiciels installés sur les serveurs. Parmi les différents services fournis par les FAI, notons les suivants : hébergement de messagerie ; hébergement de site Web ; sites de commerce électronique ; stockage et transfert de fichiers ; tableaux d affichage électronique et blogs ; services de lecture vidéo et audio en continu. Les protocoles de couche application TCP/IP rendent possibles nombre de ces services et applications des FAI. Les protocoles TCP/IP de couche application les plus courants sont HTTP, FTP, SMTP, POP3 et IMAP4.

Module 7 Discovery 2 version 4.1 - Page 32 sur 51 Certains clients étant plus concernés que d autres par la sécurité, ces protocoles de couche application proposent également des versions sécurisées telles que FTPS et HTTPS.

Module 7 Discovery 2 version 4.1 - Page 33 sur 51

Module 7 Discovery 2 version 4.1 - Page 34 sur 51 Corrigé 4.2 HTTP et HTTPS HTTP, l un des protocoles de la suite TCP/IP, fut développé à l origine pour permettre l extraction de pages Web formatées en HTML. Il est désormais utilisé pour le partage d informations collaboratives distribuées. HTTP a évolué au gré de multiples versions. La plupart des FAI utilisent la version HTTP 1.1 pour leurs services d hébergement de pages Web. Contrairement aux précédentes, la version 1.1 permet à un même serveur Web d héberger plusieurs sites Web. Elle permet également d établir des connexions permanentes de sorte que plusieurs messages de requête et de réponse puissent utiliser la même connexion, réduisant ainsi le temps nécessaire pour initier de nouvelles sessions TCP. Le protocole HTTP constitue un protocole de requête/réponse. Lorsqu un client, généralement un navigateur Web, envoie un message de requête à un serveur, HTTP définit les types de message que le client utilise pour demander la page Web. Il définit également les types de messages que le serveur utilise pour répondre. Bien qu il soit remarquablement flexible, HTTP n est pas un protocole sécurisé. Les messages de demande transmettent au serveur des informations en texte brut pouvant être interceptées et lues. De même, les réponses du serveur, des pages HTML le plus souvent, sont également envoyées sans être chiffrées. Pour une communication sécurisée via Internet, le protocole HTTPS (HTTP Secure) est utilisé lors de l accès aux informations du serveur Web ou de leur publication. HTTPS peut utiliser l authentification et le chiffrement pour sécuriser les données pendant leur transfert entre le client et le serveur. HTTPS spécifie des règles supplémentaires pour transférer les données entre la couche application et la couche transport.

Module 7 Discovery 2 version 4.1 - Page 35 sur 51 Lorsque vous contactez un serveur HTTP pour télécharger une page Web, une URL permet de localiser le serveur et une ressource spécifique. L URL identifie les éléments suivants : protocoles utilisés nom de domaine du serveur auquel accéder emplacement de la ressource sur le serveur, comme http://example.com/example1/index.htm De nombreuses applications de serveur Web autorisent les URL courtes. Celles-ci sont appréciées, car elles sont plus faciles à écrire, retenir ou partager. Avec une URL courte, une page de ressource par défaut est attendue lors de la saisie d une URL spécifique. Lorsqu un utilisateur saisit une URL raccourcie, comme http://example.com, la page par défaut qui est envoyée à l utilisateur est en fait la page Web http://example.com/example1/index.htm. HTTP prend en charge les services de proxy. Un serveur proxy permet aux clients d établir des connexions réseau indirectes avec d autres services réseau. Un proxy est un périphérique du flux de communication qui se comporte comme un serveur pour le client et comme un client pour le serveur.

Module 7 Discovery 2 version 4.1 - Page 36 sur 51 Le client se connecte au serveur proxy et demande, depuis le proxy, une ressource sur un autre serveur. Le proxy se connecte au serveur spécifié et récupère la ressource demandée. Il transfère ensuite la ressource au client. Le serveur proxy peut mettre en cache la page ou la ressource en question pendant une durée configurable. Cela permet aux futurs clients d accéder rapidement à la page Web, sans avoir à accéder au serveur sur lequel la page est stockée. Les proxys sont utilisés pour les trois motifs suivants : Vitesse - la mise en cache permet de mettre les ressources demandées par un utilisateur à disposition des utilisateurs suivants sans devoir accéder au serveur où la page est effectivement stockée. Sécurité - les serveurs proxy peuvent être utilisés pour intercepter les virus informatiques et autres contenus nuisibles, afin d empêcher leur téléchargement par les clients. Filtrage - les serveurs proxy permettent de visualiser le contenu des messages HTTP entrants et de filtrer les contenus indésirables en provenance du Web.

Module 7 Discovery 2 version 4.1 - Page 37 sur 51 Le protocole HTTP envoie des messages en texte brut entre clients et serveurs. Des utilisateurs non autorisés peuvent donc aisément intercepter et lire ces messages textuels. Pour protéger vos données, notamment les informations confidentielles, certains FAI proposent des services Web sécurisés via HTTPS. HTTPS est un protocole HTTP via SSL. HTTPS utilise le même processus de demande client-réponse serveur que le protocole HTTP, à ceci près que le flux de données est chiffré avec le protocole SSL avant d être transporté sur le réseau. Lorsque le flux de données HTTP parvient au serveur, la couche TCP le transmet au protocole SSL dans la couche application du serveur, où il est chiffré. Le nombre maximum de connexions simultanées qu un serveur peut prendre en charge est plus petit pour HTTPS que pour HTTP. HTTPS crée une charge et un temps de traitement supplémentaire sur le serveur, en raison du chiffrement et du déchiffrement du trafic. Pour conserver un niveau de performance élevé du serveur, HTTPS ne doit être utilisé qu en cas de nécessité, notamment pour échanger des informations confidentielles.

Module 7 Discovery 2 version 4.1 - Page 38 sur 51 Corrigé

Module 7 Discovery 2 version 4.1 - Page 39 sur 51 4.3 FTP FTP est un protocole avec connexion qui utilise le protocole TCP pour communiquer entre un processus FTP client et un processus FTP sur un serveur. Le protocole FTP est notamment appliqué à des fonctions d interpréteur de protocole (PI) et à un processus de transmission de données (DTP). L interpréteur de protocole et le processus de transmission de données représentent deux processus distincts qui coopèrent pour transférer les fichiers. De ce fait, le protocole FTP nécessite deux connexions pour exister entre le client et le serveur, une pour envoyer des informations de contrôle et des commandes, et une autre pour la transmission proprement dite des données des fichiers. Interpréteur de protocole (PI) La fonction PI (interpréteur de protocole) constitue la connexion de contrôle principale entre le client FTP et le serveur FTP. Il établit la connexion TCP et transmet les informations de contrôle au serveur. Les informations de contrôle contiennent les commandes de navigation dans une hiérarchie de fichiers, de changement de nom ou de déplacement des fichiers. La connexion de contrôle, ou flux de contrôle, reste ouverte jusqu à ce qu elle soit fermée par l utilisateur. Lorsqu un utilisateur veut se connecter à un serveur FTP, il doit suivre sept étapes de base : Étape 1 L interpréteur de protocole utilisateur envoie une requête de connexion à l interpréteur de protocole serveur sur le port réservé 21. Étape 2 L interpréteur de protocole serveur répond et la connexion est établie. Étape 3 Avec la connexion de contrôle TCP ouverte, le processus de l interpréteur de protocole serveur commence sa séquence d ouverture de session. Étape 4 L utilisateur entre ses informations d identification via l interface utilisateur et termine l authentification. Étape 5 Le processus de transmission de données peut désormais commencer.

Module 7 Discovery 2 version 4.1 - Page 40 sur 51 Processus de transmission de données (DTP) DTP est une fonction de transmission de données distincte, qui est activée uniquement lorsque l utilisateur souhaite vraiment transférer des fichiers à destination ou en provenance du serveur FTP. Contrairement à la connexion de l interpréteur de protocole, qui reste ouverte, la connexion DTP se ferme automatiquement dès la fin du transfert de fichier. Les deux types de connexions de transmission de données pris en charge par le protocole FTP sont les connexions de données actives et les connexions de données passives. Connexions de données actives Dans une connexion de données active, un client initie une requête à destination du serveur et ouvre un port pour les données attendues. Le serveur se connecte ensuite au client sur ce port, ce qui marque le début du transfert de fichier.

Module 7 Discovery 2 version 4.1 - Page 41 sur 51 Connexions de données passives Dans une connexion de données passive, le serveur FTP ouvre un port source au hasard (supérieur à 1 023). Le serveur transfère son adresse IP et ce port aléatoire au client FTP par le flux de contrôle. Le serveur attend ensuite une connexion du client FTP pour commencer le transfert de fichiers de données. Les FAI prennent généralement en charge les connexions de données passives vers leurs serveurs FTP. Les pare-feu interdisent souvent les connexions FTP actives aux hôtes situés dans le réseau intérieur. 4.4 SMTP, POP3 et IMAP4 L un des principaux services offerts par un FAI est l hébergement de la messagerie. Le courriel est une méthode de stockage et de transfert qui permet d envoyer, de stocker et de

Module 7 Discovery 2 version 4.1 - Page 42 sur 51 récupérer des messages électroniques à travers un réseau. Les messages électroniques sont stockés dans des bases de données sur des serveurs de messagerie. Les FAI gèrent souvent des serveurs de messagerie qui prennent en charge de nombreux comptes client différents. Les clients de messagerie communiquent avec les serveurs de messagerie pour envoyer et recevoir des messages. Les serveurs de messagerie communiquent avec d autres serveurs de messagerie pour acheminer les messages d un domaine à un autre. Un client de messagerie ne communique pas directement avec un autre client de messagerie lors de l envoi de courriel. En fait, les deux clients dépendent du serveur de messagerie pour transporter les messages. Cela se vérifie également lorsque les deux utilisateurs appartiennent au même domaine. Les clients de messagerie envoient des messages au serveur de messagerie configuré dans les paramètres de l application. Lorsque le serveur reçoit le message, il vérifie si le domaine destinataire se trouve dans sa base de données locale. Si tel n est pas le cas, il envoie une demande DNS pour identifier le serveur de messagerie du domaine de destination. Une fois l adresse IP du serveur de messagerie de destination connue, le message est envoyé au serveur approprié. Le message prend en charge trois protocoles pour son exécution : SMTP, POP3 et IMAP4. Le processus de couche application qui envoie le message, soit d un client vers un serveur, soit entre serveurs, met en œuvre le protocole SMTP. Un client récupère son courriel à l aide d un des deux protocoles de couche application suivants : POP3 ou IMAP4.

Module 7 Discovery 2 version 4.1 - Page 43 sur 51 Le protocole SMTP permet de transférer le courriel avec fiabilité et efficacité. Pour que les applications SMTP fonctionnent, le message doit être correctement formaté et les processus SMTP doivent être exécutés à la fois sur le client et sur le serveur. Les formats de message SMTP exigent un en-tête et un corps de message. Si le corps du message peut contenir n importe quelle quantité de texte, l en-tête doit contenir une adresse de messagerie de destinataire et une adresse d expéditeur correctement mises en forme. Toute autre information est facultative dans l en-tête. Lorsqu un client envoie un message, le processus SMTP client se connecte à un processus SMTP serveur sur le port réservé 25. Une fois la connexion établie, le client essaie d envoyer un message au serveur via la connexion. Lorsque le serveur a reçu le message, il place le message dans un compte local ou dirige le message à l aide du même processus de connexion SMTP vers un autre serveur de messagerie. Le serveur de messagerie de destination peut ne pas être en ligne, ou peut être occupé, lors de l envoi des messages. Par conséquent, le protocole SMTP met le message en attente pour envoi ultérieur. Régulièrement, le serveur vérifie si des messages se trouvent dans la file d attente et essaie de les renvoyer. À l issue d une durée donnée, si le message n est toujours pas transmis, il est renvoyé à son expéditeur comme non délivrable. L un des champs requis dans un en-tête de message est l adresse de messagerie du destinataire. La structure d une adresse de messagerie comprend le nom du compte de messagerie ou un alias, ainsi que le nom de domaine du serveur de messagerie. Exemple d adresse de messagerie : destinataire@cisco.com. Le symbole @ sépare le compte et le nom de domaine du serveur. Lorsque le serveur DNS reçoit une demande de nom contenant le symbole @, il sait qu il doit rechercher une adresse IP correspondant à un serveur de messagerie. Lorsqu un message est envoyé à destinataire@cisco.com, le nom de domaine est envoyé au serveur DNS afin d obtenir l adresse IP du serveur de messagerie du domaine. Les serveurs de messagerie sont identifiés dans le système DNS par un indicateur d enregistrement MX. MX est un type d enregistrement de ressources stocké sur le serveur DNS. Lorsque le serveur de messagerie de destination reçoit le message, il le stocke dans la boîte aux lettres appropriée. L emplacement de la boîte aux lettres est déterminé en fonction du compte spécifié dans la première partie de l adresse de messagerie (dans notre cas, le compte du destinataire). Le message reste dans la boîte aux lettres jusqu à ce que le destinataire se connecte au serveur pour récupérer le courriel. Si le serveur de messagerie reçoit un message électronique faisant référence à un compte inexistant, le message est renvoyé à l expéditeur comme étant non délivrable.

Module 7 Discovery 2 version 4.1 - Page 44 sur 51 Le protocole POP3 (Post Office Protocol version 3) permet à une station de travail de récupérer des messages depuis un serveur de messagerie. Avec POP3, le courriel est téléchargé du serveur au client puis supprimé du serveur. Le serveur démarre le service POP3 en écoutant passivement les éventuelles requêtes de connexion client sur le port TCP 110. Lorsqu un client souhaite utiliser le service, il envoie une requête d établissement de connexion TCP au serveur. Une fois la connexion établie, le serveur POP3 envoie un message de bienvenue. Le client et le serveur POP3 échangent alors des commandes et des réponses jusqu à ce que la connexion soit fermée ou abandonnée. Étant donné que les messages électroniques sont téléchargés chez le client et supprimés du serveur, il n existe pas d emplacement centralisé de conservation des messages. Comme le protocole POP3 ne stocke pas les messages, il est inadapté dans une petite entreprise qui a besoin d une solution de sauvegarde centralisée. Le protocole POP3 convient en revanche à un FAI puisqu il lui évite d avoir à gérer de grandes quantités de messages stockés. Le protocole de messagerie IMAP4 (Internet Message Access Protocol) décrit une autre méthode de récupération des messages électroniques. Toutefois, contrairement au protocole POP3, lorsque l utilisateur se connecte à un serveur IMAP, des copies des messages sont téléchargées vers l application cliente. Les messages originaux sont conservés sur le serveur jusqu à ce qu ils soient supprimés manuellement. Les utilisateurs affichent des copies des messages dans leur logiciel de messagerie.

Module 7 Discovery 2 version 4.1 - Page 45 sur 51 Ils peuvent créer une hiérarchie de fichiers sur le serveur afin d organiser et de stocker leur courriel. Cette structure de fichiers est également dupliquée sur le client de messagerie. Lorsqu un utilisateur décide de supprimer un message, le serveur synchronise cette action et supprime le message du serveur. Pour les petites et moyennes entreprises, le protocole IMAP présente de nombreux avantages. Il permet un stockage à long terme des messages sur les serveurs de messagerie et une sauvegarde centralisée. Il permet également aux employés d accéder aux messages depuis différents emplacements à l aide de différents périphériques ou logiciels clients. La structure de dossiers de boîte aux lettres à laquelle est habitué l utilisateur reste consultable quel que soit le moyen qu il choisit pour consulter sa boîte aux lettres. Pour un FAI, le protocole IMAP peut ne pas être le choix idéal. Il peut s avérer coûteux à l achat et en maintenance de l espace disque nécessaire au stockage des messages électroniques. De plus, cette contrainte sur le FAI s accentue si les clients paramètrent des sauvegardes régulières de leurs boîtes aux lettres.

Module 7 Discovery 2 version 4.1 - Page 46 sur 51 5 Résumé du chapitre

Module 7 Discovery 2 version 4.1 - Page 47 sur 51

Module 7 Discovery 2 version 4.1 - Page 48 sur 51 6 Questionnaire du chapitre Question 1 Question 2 Question 3 Question 4

Module 7 Discovery 2 version 4.1 - Page 49 sur 51 Question 5 Question 6 Question 7 Question 8

Module 7 Discovery 2 version 4.1 - Page 50 sur 51 Question 9 Question 10