====== Les protocoles ====== ===== C'est quoi un protocole? ===== Essayons d'en donner une définition satisfaisante... C'est un mode opératoire qui doit être commun à tous les éléments qui désirent communiquer entre eux. Il n'y a pas de communication possible sans avoir recours à un protocole. Bien entendu, le protocole doit être adapté au type de communication que l'on souhaite mettre en œuvre Nous passons notre vie à utiliser des protocoles, heureusement sans en être conscients la plupart du temps. ==== Rappel ==== Le modèle OSI définit sept couches. TCP/IP est basé sur le modèle DOD, qui ne comporte que quatre couches, mais en cohérence avec le modèle OSI. {{ :tcpip:modeles.gif |Les couches réseau suivant les modèles}} ===== Les principaux protocoles rencontrés sur un réseau TCP/IP ===== ==== Organisation hiérarchique ==== | {{:tcpip:proto4.png|Couche « application »}} | Nous trouvons ici les protocoles applicatifs. Ce sont des protocoles de haut niveau, destinés à permettre le dialogue entre applications serveurs et clientes.  HTTP, FTP, POP et SMTP sont loin d'être les seuls. Ce sont cependant ceux que les internautes utilisent le plus souvent. Parmi l'un des plus « dangereux", il y a TELNET qui permet de piloter une machine à distance. | | {{:tcpip:proto3.png|Couche « transport »}} | Ici, ce sont les protocoles orientés transport de données. UDP est dit « sans connexion » et TCP « est dit « avec connexion ». Nous verrons plus loin ce que ceci veut dire. Ces protocoles permettent à ceux de la couche 4 de transporter leurs données de façon fiable. | | {{:tcpip:proto2.png|Couche « internet »}} | Ce sont ici des protocoles de haut niveau de la couche réseau. IP permet le routage des informations entre réseaux, c'est ici que l'adresse IP est utilisée. ICMP est un protocole de « contrôle » il met à disposition des outils de dépistage d'erreur et de signalisation. C'est un protocole important qui mérite que l'on s'y arrête. Nous en reparlerons plus en détail. | | {{:tcpip:proto1.png|Couche « réseau »}} | Protocole de plus bas niveau sur le réseau, il assure la bonne gestion du médium (détection de collisions) et permet l'acheminement des informations entre émetteur et destinataire au niveau des adresses MAC. IP s'appuie dessus bien évidement. | ==== Ethernet ==== **Le vocable « Ethernet » est souvent employé à contre sens. Peut-être n'est-il pas inutile de préciser un peu, même si, pour l'utilisateur (qui travaille sur la couche supérieure), ce qu'il se passe sur la couche 1 n'a pas beaucoup de répercussions.** Le mot « Ethernet » fait référence au support de propagation des informations utilisé. Historiquement, de trois types (mais d'autres peuvent être utilisés): * Coaxial épais * Coaxial fin (RG58) * Paire torsadée. Pour être tout à fait précis, la norme qui décrit les réseaux de type Ethernet qui sont utilisés sur la majorité des réseaux locaux est la norme IEEE 802.3 Cette norme décrit dans le détail le fonctionnement du réseau sur les supports cités précédemment. Elle définit entre autre, le protocole d'émission de données utilisé: le CSMA/CD persistant 1 (qui n'est pas le plus performant). === Remarque fine... === Les réseaux France Télécom ne sont pas des réseaux IEEE 802.3, mais des réseaux ATM (Asynchronous Transfer Mode). Le réseau ATM a été développé dans l'optique d'un transport de données de natures diverses (voix, vidéo, informatique...). ATM est capable de gérer finement le partage des ressources d'une dorsale. Bien que cette technologie soit pas mal controversée, c'est tout de même elle qui est utilisée par notre opérateur « historique » (et d'autres également). Cependant, les trames IEEE 802.3 peuvent être encapsulées sur de l'ATM, TCP/IP peut s'appuyer sur ATM, si bien que nous autres, utilisateurs, « voyons » tout de même un réseau classique de l'Internet. En fait, le Com21 est connecté sur un réseau ATM via le câble. ---- ==== IP ==== Internet Protocol. C'est le protocole dont on parle le plus, il est en effet directement impliqué dans la configuration réseau de l'hôte. C'est lui qui, en fonction de l'adresse IP du destinataire acheminera l'information sur la bonne route. * Les considérations relatives à la topologie d'une adresse IP sont vues un peu plus loin dans ce chapitre. * Les concepts du routage sont vus dans le chapitre suivant sur ce site. ==== ICMP ==== Internet Control Message Protocol. En termes de sécurité, ce protocole fait peur à beaucoup de monde (parfois à juste titre d'ailleurs), il est cependant fondamental pour le bon fonctionnement de l'Internet. C'est grâce à ce protocole que les anomalies de fonctionnement peuvent être signalées à l'émetteur, afin qu'il puisse essayer d'y remédier. ICMP génère des messages de types différents, selon la nature du problème à traiter: ^ Valeur ^ Nom ^ Description ^ | 0 | Réponse d'écho |Rien de plus que la réponse à un PING| | 3 | Destination inaccessible |C'est un message intéressant, parce qu'il permet à celui qui le reçoit d'être informé que l'hôte avec lequel il veut communiquer n'est pas accessible. Ca peut souvent éviter à une application de rester « plantée » à attendre une réponse qui ne viendra pas.| | 4 | Etranglement de la source |Principalement utilisés par les routeurs, ce signal permet d'expliquer à un hôte qui parle un peu trop qu'il faut qu'il se taise, parce qu'il inonde la file d'attente.| | 5 | Redirection nécessaire |Information utile pour la mise à jour des tables de routage.| | 8 | Demande d'écho |C'est la question posée à un hôte par la commande PING.| | 11 | TTL Expiré |Un paquet est toujours émis avec une durée de vie. Cette durée de vie est décrémentée à chaque nœud qui traite le paquet (d'une durée minimum d'une seconde, ou du temps qu'a mis la paquet à traverser le nœud). Si le paquet arrive en fin de vie, il est jeté et un message ICPM de type 11 est envoyé à l'émetteur. Cette propriété est utilisée dans la commande « tracert » (traceroute sur Linux) pour calculer les temps d'accès sur les diverses passerelles du chemin parcouru.| | 12 | Problème de paramètre |Ce message indique qu'il y a une erreur dans le champ d'en-tête du paquet. Ce problème ne peut normalement arriver que dans le cas d'un bug du logiciel.| | 13 | Requête d'horodatage |Assez similaire à la requête d'écho, avec en plus le marquage de l'heure Ce type d'écho permet de connaître l'heure d'arrivée de la requête et l'heure de départ de la réponse sur l'hôte cible.| | 14 | Réponse de d'horodatage. | | | 17 | Requête de masque d'adresse |Ces messages sont utilisés pour effectuer des tests au sein d'un réseau ou d'un sous-réseau.| | 18 | Réponse de masque d'adresse. | | Les protocoles de la couche transport permettent, comme l'indique le nom de la couche, de mettre à disposition des niveaux supérieurs  des outils de transport de données fiables. Il existe deux modes de transfert: ==== Le mode connecté (TCP) ==== Dans ce mode, il se met en place un processus de « handshake » (poignée de main) entre le client et le serveur. Ce processus permet d'établir un dialogue à propos du transfert de données. Il y a des accusés réception, des demandes d'émission etc. qui permettent aux applications de savoir exactement où en est le processus de transfert de données. Ce protocole est très robuste et permet un transfert de données dans de bonnes conditions. Voir les détails [[040_mode_connecte|plus loin dans ce chapitre]]. **Le « handshake » est un concept fondamental dans un protocole de dialogue robuste. En gros, ça veut dire: « Chaque fois que tu envoies un message à son destinataire, assure-toi qu'il l'a reçu et compris »** La lettre recommandée avec accusé de réception est un bon exemple de mode connecté. Si l'émetteur reçoit l'accusé réception, alors il est certain que sa lettre est arrivée à destination. ==== Le mode non connecté (UDP) ==== C'est un mode simple, de type « on envoie les données et on espère qu'elles arriveront ». Il n'y a pas de « connexion », au sens où on l'a vu pour le mode connecté. En revanche, il est possible de mettre en place un processus d'acquittement. Ce mode est utilisé, par exemple, pour les requêtes DNS. Il offre l'avantage d'être moins gourmand en ressources, mais ne peut être efficace pour un transfert de fichiers et en général, pour les transferts de données volumineuses. Là aussi, vous aurez plus de détails [[050_mode_non_connecte| un peu plus loin sur ce site]]. Dans ce mode, il n'y a pas de « handshake ». Une lettre simple et ici un bon exemple. L'émetteur ne reçoit à priori aucune confirmation de réception. Les protocoles d'application sont des protocoles de haut niveau, adaptés aux besoins d'applications spécifiques. Ils s'appuient sur UDP et TCP pour permettre le transfert d'informations entre une application serveur et ses applications clientes. Il en existe un grand nombre, nous allons effectuer un rapide tour d'horizon de ceux qui sont le plus souvent utilisés. | **__HTTP__** | **//Hyper Text Transfert Protocol//** Ce protocole est utilisé pour la navigation web entre un serveur HTTP et un butineur. Le protocole assure (normalement) qu'un client comme Internet Explorer ou Netscape Communicator peut envoyer des requêtes et recevoir les réponses de serveurs HTTP comme APACHE ou Internet Information Server sans problèmes particuliers. Les ennuis viennent du fait que les clients supportent bien souvent des extensions « propriétaires » du protocole. Ces extensions sont d'ailleurs la plupart du temps entérinées dans les versions successives du protocole, c'est comme ça que tout évolue. | | **__FTP__** | **//File Transfert Protocol//** Protocole qui permet d'assurer le transfert de fichiers de façon indépendante des spécificités des NOS (Network Operatind System, pour mémoire). Ainsi, un client FTP sous Windows peut télécharger un fichier depuis un serveur UNIX | | **__SMTP__** | **//Simple Mail Transfert Protocol//** Le protocole qui permet d'acheminer le courrier depuis le serveur SMTP de l'émetteur, jusqu'au serveur SMTP du destinataire, qui le classe dans les Boîtes aux lettres de ses clients. (Décrit en détail par ailleurs dans ce site). | | **__POP3__** | **//Post Office Protocol version 3.//** Le protocole qui permet au client de relever à distance le courrier classé dans sa boîte aux lettres. Egalement détaillé par ailleurs sur ce site. | | **__IMAP4__** | **//Interactive Mail Access Protocol version 4//** Normalement, ce protocole devrait prendre la place de POP3. Certains fournisseurs sérieux, comme FREE l'implémentent déjà. Contrairement à POP3 qui ne permet une gestion des messages qu'une fois qu'ils sont rapatriés localement, IMAP propose des fonctionnalités plus fines. | | **__NNTP__** | **//Network News Transfert Protocol//** Très proche de SMTP, ce protocole est employé par les forums usenet. Bien que l'usage des forums NNTP n'entre que tardivement dans les mœurs des internautes « débutants", ce moyen de communication offre des avantages incomparables par rapport aux listes de diffusion par exemple. | | **__TELNET__** | C'est le « couteau suisse » du travail à distance. En fait, un client TELNET est une console en mode texte, capable de se connecter sur la plupart des serveurs, comme POP3 ou SMTP. Il devient alors possible d'envoyer et de lire des messages, si l'on connait les commandes inhérentes aux protocoles SMTP et POP3. Un serveur TELNET permet cependant des choses bien plus puissantes et « dangereuses » puisqu'il devient possible de prendre à distance le contrôle d'un hôte. C'est un outil qui permet l'administration distante d'une machine, du moment que l'on est capable d'ouvrir une session et d'acquérir les droits de « super utilisateur ». | Il en existe bien entendu beaucoup d'autres, il n'est pas, encore une fois, question ici de référencer tous les protocoles applicatifs de la création.