Un flux d'octets fiable est un paradigme de service courant dans les réseaux informatiques ; il désigne un flux d'octets dans lequel les octets qui émergent du canal de communication chez le destinataire sont exactement les mêmes, et dans exactement le même ordre, que ceux qu'ils avaient lorsque l'expéditeur les a insérés dans le canal.
L'exemple classique d'un protocole de communication fiable par flux d'octets est le protocole de contrôle de transmission (TCP) , l'un des principaux éléments constitutifs d' Internet .
Un flux d'octets fiable n'est cependant pas le seul paradigme de service fiable que fournissent les protocoles de communication des réseaux informatiques ; d'autres protocoles (par exemple SCTP ) fournissent un flux de messages fiable, c'est-à-dire que les données sont divisées en unités distinctes, qui sont fournies au consommateur des données sous forme d'objets discrets.
Mécanisme
Les protocoles de communication qui mettent en œuvre des flux d'octets fiables, généralement sur un niveau inférieur non fiable, utilisent plusieurs mécanismes pour garantir cette fiabilité. Les protocoles de requêtes de répétition automatique (ARQ) jouent un rôle important à cet égard.
Chaque donnée est identifiée par un numéro de séquence , permettant à la fois de garantir sa livraison dans le bon ordre au destinataire et de détecter les données perdues. Le destinataire renvoie un accusé de réception pour les données correctement reçues . Si aucun accusé de réception n'est reçu dans un délai raisonnable , un délai d'attente est déclenché chez l'émetteur, entraînant la retransmission des données (présumées perdues) . Pour vérifier l'intégrité des données, une somme de contrôle est calculée chez l'émetteur pour chaque bloc de données avant son envoi et vérifiée chez le destinataire. Les données erronées ou manquantes sont signalées à l'émetteur afin qu'il puisse les retransmettre. Les données dupliquées sont supprimées.
Blocage en tête de file
Le blocage en tête de file peut survenir dans les flux d'octets fiables : si des paquets sont réordonnés ou perdus et doivent être retransmis (arrivant ainsi dans le désordre), les données provenant de parties séquentiellement postérieures du flux peuvent être reçues avant les parties séquentiellement antérieures ; or, ces données postérieures ne peuvent généralement pas être utilisées tant que les données antérieures n'ont pas été reçues, ce qui engendre une latence réseau . Si plusieurs messages indépendants de niveau supérieur sont encapsulés et multiplexés sur un seul flux d'octets fiable, le blocage en tête de file peut entraîner l'attente, pour le traitement d'un message entièrement reçu mais envoyé ultérieurement, de la réception d'un message envoyé antérieurement. Ceci affecte, par exemple, HTTP/2 , qui regroupe plusieurs paires requête - réponse sur un seul flux ; HTTP/3 , qui utilise une architecture de trames au niveau de la couche application et le transport par datagrammes plutôt que par flux, évite ce problème. La dégradation de la latence due au blocage en tête de file dépend du taux de perte de paquets sous-jacent et du temps d'aller-retour ; plus les pertes sont importantes, plus la latence est grande. Sans modifier l'abstraction du flux, la réduction des pertes de paquets peut atténuer les effets néfastes du blocage en tête de file ; une autre solution consiste à implémenter un flux d'octets fiable utilisant la correction d'erreurs sans voie de retour pour envoyer des données redondantes, de sorte qu'un certain niveau de perte puisse être toléré sans entraîner de retransmissions.