Cet article ne cite pas suffisamment ses sources (janvier 2024).

Si vous disposez d'ouvrages ou d'articles de référence ou si vous connaissez des sites web de qualité traitant du thème abordé ici, merci de compléter l'article en donnant les références utiles à sa vérifiabilité et en les liant à la section « Notes et références ».

En pratique : Quelles sources sont attendues ? Comment ajouter mes sources ?

Dans les réseaux informatiques, un protocole fiable fournit l'assurance de la livraison des données au destinataire(s), par opposition à un protocole peu fiable, qui ne fournit pas de notifications à l'expéditeur concernant la livraison des données transmises.

La fiabilité est un synonyme de l'assurance, qui est le terme utilisé par l'UIT et le forum de l'ATM dans le cadre de sa fonction de coordination spécifique au service ATM, par exemple pour assurer la transparence de la livraison assurée avec AAL5.

Les protocoles fiables impliquent généralement davantage de ressources à l'implémentation que les protocoles non fiables, et fonctionnent donc plus lentement et avec moins d'évolutivité. Ce n'est que rarement un problème pour les protocoles de type unicast, mais il pourrait devenir un problème pour les protocoles faibles multicast.

TCP, le principal protocole utilisé sur l'Internet, est un protocole unicast fiable. UDP, souvent utilisé dans les jeux sur ordinateur ou dans d'autres situations où la vitesse est cruciale et la perte d'un peu de données n'est pas si importante en raison de la nature transitoire des données, est quant à lui un protocole non fiable.

Souvent, un protocole fiable unicast est également orienté connexion. Par exemple, le protocole TCP est orienté connexion, avec l'ID de virtuel-circuit composée des adresses IP de source et de destinatinon et les numéros de port. Certains protocoles non fiables sont également orientés connexion. Ceux-ci comprennent ATM et le relayage de trames. Il y a aussi des protocoles sans connexion fiables, tels que AX.25 lorsqu'il transmet des données dans des inter-trames. Mais cette combinaison se produit rarement: la combinaison fiable-sans connexion est rare dans les réseaux commerciaux et universitaires.

Après que le réseau NPL ait mis en place pour la première fois la commutation de paquets, l'ARPANET fournit une procédure fiable de livraison de paquets à ses hôtes connectés, par l'intermédiaire de son interface 1822^[1],[2]. Un ordinateur hôte arrangeait simplement les données dans le bon format de paquet, insérait l'adresse de l'ordinateur hôte de destination, et envoyait un message à travers l'interface vers l'Interface Message Processor auquel il était connecté. Une fois que le message avait été livré à l'hôte de destination, un accusé de réception était remis à l'hôte émetteur. Si le réseau ne pouvait pas livrer le message, il envoyait un message d'erreur à l'hôte émetteur.

Pendant ce temps, les développeurs de Cyclades et de ALOHAnet ont démontré qu'il était possible de construire un réseau informatique efficace sans fournir une transmission fiable des paquets. Ce savoir a plus tard été réemployé par les concepteurs de l'Ethernet.

Si un réseau ne garantit pas la livraison de paquets, il devient de la responsabilité de l'hôte de s'occuper de la fiabilité en détectant et retransmettant les paquets perdus. L'expérience sur l'Arpanet a démontré que le réseau lui-même ne pouvait pas détecter de manière fiable tous les échecs de livraison de paquets, ce qui a renvoyé la responsabilité de la détection des erreurs sur l'hôte émetteur dans tous les cas. Cela a conduit à l'élaboration du principe de bout en bout, qui est un des choix de design fondamentaux de l'Internet.

Cet article peut contenir un travail inédit ou des déclarations non vérifiées, malgré la présence de sources. En effet, la portée de certaines d'entre elles semble avoir été détournée de leur véritable signification par l'interprétation d’un contributeur ({{{date}}}).

Le contenu peut paraître crédible au vu des sources présentées, mais il ne faut pas s'y fier, car il ne les reflète pas forcément. Vous pouvez aider en mettant le texte de l'article en accord avec les sources. Voir la page de discussion pour plus de détails.

Un service fiable est un service qui informe l'utilisateur si la livraison échoue, tandis qu'un service peu fiable ne garantit pas ce comportement. Par exemple, IP fournit un service non fiable. Ensemble, TCP et IP fournissent un service fiable, alors que UDP et IP ne le font pas. Tous ces protocoles utilisent des paquets, mais les paquets UDP sont généralement appelés datagrammes. Dans le cadre de protocoles distribués, les propriétés de la fiabilité spécifient les garanties que le protocole prévoit à l'égard de la diffusion de messages au(x) destinataire(s).

Un exemple de propriété de la fiabilité pour un protocole de diffusion unicast est au moins une fois, c'est-à-dire qu'au moins une copie de ce message a la garantie d'être livrée à son destinataire.

Les propriétés de fiabilité pour les protocoles multicast peuvent être exprimées en fonction du destinataire (on parle alors de propriétés de fiabilité simples), ou elles peuvent avoir trait à la livraison et/ou à l'ordre de la livraison entre les différents destinataires (on parle de propriétés de fiabilité fortes).

Dans le cadre de protocoles de multicast, des propriétés de fiabilité fortes spécifient les garanties que le protocole prévoit quant à la diffusion de messages à des destinataires différents.

Un exemple d'une propriété de fiabilité forte est le rappel de la dernière copie, ce qui signifie que tant qu'au moins une copie d'un message demeure disponible à l'un des destinataires, tous les autres destinataires qui ne rencontrent pas d'erreur finiront par en recevoir aussi une copie. Des propriétés de fiabilité forte comme celle-ci exigent généralement que les messages soient retransmis ou transférés entre les destinataires.

Un exemple d'une propriété de fiabilité plus forte que le rappel de la dernière copie est l'atomicité. Cette propriété exige que, si au moins une copie d'un message a été transmise à un destinataire, tous les autres destinataires finiront par recevoir une copie de ce message. En d'autres termes, chaque message est toujours livré soit à tous, soit à aucun des destinataires.

L'une des propriétés de fiabilité les plus complexes est la synchronie virtuelle.

Des propriétés de fiabilité fortes sont proposées par des systèmes de communication de groupe (GCS) tels IS-IS, Appia framework, Spread, JGroups ou QuickSilver Scalable Multicast. Le QuickSilver Proprerties Framework est une plateforme flexible qui permet d'exprimer des propriétés de fiabilité fortes de manière purement déclarative, à l'aide d'un langage simple basé sur des règles, qui sont automatiquement traduites dans un protocole hiérarchique.

Il y a, cependant, un problème avec la définition de la fiabilité comme la livraison ou notification de l'échec (de livraison) en informatique en temps réel. Dans de tels systèmes, le défaut de livraison de données temps-réel nuit aux performances, et certains systèmes tels les systèmes critiques, et certains systèmes sécurisés critiques dans le cadre de la mission, doivent prouver qu'ils sont capables de garantir un niveau de service minimum. Ceci, à son tour, exige un minimum de fiabilité lors de la livraison des données critiques. Par conséquent, c'est seulement la livraison qui compte, et notifier l'expéditeur de l'échec de la transmission n'empêche pas, ni n'atténue, l'échec de la couche transport du système temps réel à délivrer les données.

Dans les systèmes temps réel stricts et souples, les données doivent être livrées dans un délai fixé, c'est-à-dire que des données délivrées en retard n'ont plus de valeur. Dans le cas de systèmes temps réel stricts, toutes les données doivent être fournies avant la date d'échéance, ou le système sera considéré comme en état de défaillance. Dans les systèmes temps réel dits souples, il existe une certaine probabilité acceptable que les données soient pas livrées ou soient livrées en retard - ce qui est équivalent.

Il y a un certain nombre de protocoles qui sont capables de répondre à des exigences de temps réel pour la fiabilité de la livraison et la ponctualité, du moins pour les systèmes temps réel dits souples (en raison des inévitables et inéluctables pertes causées, par exemple, par le taux d'erreurs de la couche physique):

MIL-STD-1553B et STANAG 3910 sont des exemples bien connus de tels protocoles ponctuels et fiables pour les bus de données en avionique. MIL-1553 utilise un média à 1 Mbit/s partagé pour la transmission de données et le contrôle de ces transmissions, et est largement utilisé dans les systèmes avioniques militaires (dans lequel Chaque système a ses propres ordinateurs exerçant ses propres fonctions.

Il utilise un contrôleur de Bus (BC) pour commander les terminaux à distance (RTs) connecté de recevoir ou transmettre ces données. Le BC peut donc s'assurer qu'il n'y ait pas de congestion, et les transferts sont toujours ponctuels. Le protocole MIL-1553 permet également les nouvelles tentatives automatiques qui peuvent toujours assurer la livraison endéans le temps imparti et augmenter la fiabilité au-dessus de la couche physique. STANAG 3910, aussi connu comme EFABus dans son utilisation sur l'Eurofighter Typhoon, est, dans les faits, une version de la norme MIL-1553 augmentée avec un bus média à 20 Mbit/s partagé pour les transferts de données, tout en gardant le bus media partagé de 1 Mbit/s destiné au contrôle.

Le Mode de Transfert Asynchrone (ATM), le Avionics Full Duplex Switched Ethernet (AFDX), et le Time Triggered Ethernet (TTEthernet) sont des exemples de protocoles réseaux à commutation de paquets dans lesquels la ponctualité et la fiabilité des transferts de données peuvent être assurées par le réseau. AFDX et TTEthernet sont également basés sur la norme IEEE 802.3 Ethernet, bien qu'ils ne soient pas entièrement compatible avec celle-ci.

ATM utilise des canaux virtuels (VCs) orientés connexion, qui ont des chemins entièrement déterministes à travers le réseau, ainsi que le contrôle des paramètres d'utilisation et de réseau (UPC/NPC), qui sont mis en œuvre au sein du réseau, afin de limiter le trafic sur chaque VC individuellement. Cela permet que l'utilisation des ressources partagées (tampons de switches) dans le réseau soit calculée à l'avance à partir des paramètres du trafic qui sera acheminé, c'est-à-dire au moment de la conception du système. Le fait qu'ils soient mis en œuvre par le réseau signifie que ces calculs restent valables, même si d'autres utilisateurs du réseau se comportent de manière inattendue, c'est-à-dire de transmettre plus de données que ce qui était attendu. Les usages calculés peuvent ensuite être comparés avec les capacités des ressources pour montrer que, étant donné les contraintes sur les routes et les bandes passantes de ces connexions, la ressource utilisée pour ces transferts ne sera jamais dépassée. Ces transferts ne seront dès lors jamais être affectés par des problèmes de congestion et il n'y aura pas de pertes dues à cet effet. Ensuite, à partir de l'utilisation maximum prédite des tampons des switches, le délai maximum à travers le réseau peut également être prédit. Cependant, pour prouver la fiabilité et la ponctualité, et pour que les preuves soient insensibles aux défaillances du réseau et aux actes de malveillance causés par l'équipement connecté au réseau, le calcul de ces utilisations de ressources ne peut pas être fondée sur des paramètres qui ne sont pas imposés de façon active par le réseau, c'est-à-dire qu'ils ne peuvent pas se baser sur ce que les sources de trafic sont censées faire ou sur des analyses statistiques des caractéristiques du trafic (voir calcul de réseau).

AFDX utilise la limitation du flux ou l'allocation de bande passante, ce qui permet que le trafic sur chaque lien virtuel (VL) soit limité, de sorte que les exigences en matière de ressources partagées puissent être prédites et la congestion évitée. On peut ainsi prouver qu'elle n'affectera pas les données critiques. Cependant, les techniques de prévision des besoins en ressources et de preuve de l'impossibilité de la congestion ne font pas partie du standard AFDX.

TTEthernet fournit la latence la plus faible possible dans le transfert de données sur un réseau en utilisant des méthodes de contrôle de domaine temporel – à chaque fois, le déclenchement d'un transfert est prévu à un moment précis, de sorte que les conflits pour les ressources partagées soient entièrement contrôlés, et la possibilité de congestion éliminée. Les switches du réseau imposent ce moment pour assurer une résistance aux défauts du réseau, et aux actes de malveillance de la part d'autres équipements connectés. Cependant, des « horloges locales synchronisées sont la condition sine qua non pour la communication déclenchée par le temps ». En effet, les sources des données critiques devront avoir la même conception du temps que le switch, afin qu'ils puissent transmettre au bon moment et que le switch l'interprète correctement. Cela implique également que la séquence dans laquelle un transfert critique est prévu doit être prévisible à la fois pour la source et le switch. Ceci, à son tour, limitera la planification de la transmission à une planification très déterministe, comme un cyclic executive.

Cependant, une faible latence dans le transfert des données sur le bus ou le réseau ne se traduit pas nécessairement par de faibles délais dans le transport entre l'application qui émet et celle qui reçoit ces données. Ceci est particulièrement vrai lorsque les transferts sur le bus ou le réseau sont prévus de manière cyclique (comme c'est souvent le cas avec la norme MIL-STD-1553B et STANAG 3910, et toujours le cas avec AFDX et TTEthernet), mais que les processus des applications sont asynchrones, comme le multitâche préemptif ou seulement plésiochrones par rapport à ce cycle. Dans ce cas, le délai et la gigue maximum sera égal au double de la fréquence de mise à jour pour le transfert cyclique (les transferts attendent pendant la durée de l'intervalle de mise à jour entre l'émission et la réception, puis attendent encore pendant la durée de l'intervalle de mise à jour entre la réception et l'utilisation de la donnée transmise).

Avec AFDX et TTEthernet, il y a d'autres fonctions additionnelles exigées des interfaces avec le réseau pour la transmission de données critiques, etc., ce qui rend difficile l'utilisation d'interfaces Ethernet standard. Le contrôle d'écart d'allocation de bande passante d'AFDX, et les exigences de TTEthernet quant à la synchronisation très précise de l'envoi des données sont des exemples de ces fonctions. D'autres méthodes de contrôle du trafic dans le réseau, qui permettraient l'utilisation d'interfaces standard IEEE 802.3 sont à l'étude actuellement.

• (en) Cet article est partiellement ou en totalité issu de l’article de Wikipédia en anglais intitulé « Reliability (computer networking) » (voir la liste des auteurs).

• Portail de l’informatique