ÉCHAPPEMENT DES OCTETS SÉRIE
Comment un délimiteur peut-il aussi être une donnée ?
Un récepteur série reçoit des caractères, tandis que l’application doit identifier les messages. SLIP échappe les octets C0 et DB de la charge utile à l’aide de séquences de deux octets, afin qu’un END non échappé puisse délimiter un paquet. Le récepteur effectue la conversion inverse tout en conservant son état entre les lectures. Ces valeurs spécifiques appartiennent à SLIP et n’assurent pas automatiquement de contrôle d’erreurs ni de sécurité.
Caractère et paquet
Une limite de caractère ne suffit pas à identifier un message applicatif.
Échapper les données spéciales
SLIP représente les octets spéciaux de la charge utile par des séquences de deux octets.
Conserver l’état
Un analyseur doit conserver son état d’échappement même lorsqu’une lecture se termine après DB.
Repérer les extrémités et le périmètre.
Confirmer le protocole et les paramètres réellement utilisés.
Effectuer des essais autorisés avec des données inoffensives.
Liste de contrôle de sélection et de vérification — développer
Confirmez le protocole et la couche de capture ; testez les octets ordinaires et spéciaux ; vérifiez les lectures fractionnées, les marqueurs répétés et la gestion des erreurs dans un environnement autorisé.
Une ligne série fournit un flux d’octets. Comment le programme récepteur sait-il où se termine un message ? Une approche consiste à réserver un marqueur. Mais une mesure ou un fichier peut contenir la même valeur d’octet, dont l’envoi sans modification risque d’être interprété comme une fin. L’échappement des octets résout cette ambiguïté. Pour le comprendre, il faut distinguer la réception des caractères, les limites des paquets et la signification applicative, plutôt que de considérer uniquement le débit en bauds.
Des caractères corrects ne forment pas automatiquement un paquet
Une interface série asynchrone courante utilise un bit de départ, des bits de données et des bits d’arrêt pour identifier un caractère. Lorsque les caractères parviennent à un programme, ils forment une séquence d’octets. Le récepteur ne sait pas automatiquement où commence et où se termine une mesure de température. Les limites des caractères et celles des messages complets sont deux problèmes distincts.
Un protocole applicatif peut utiliser une longueur fixe, un champ de longueur, la temporisation ou des marqueurs spéciaux pour délimiter les messages. Chaque méthode comporte des conditions et des compromis. Cet article utilise SLIP, un exemple simple de délimitation des paquets sur liaison série, pour expliquer les marqueurs et l’échappement. Il ne suggère ni que tous les protocoles série utilisent SLIP, ni qu’un protocole existant devrait être modifié à la légère.
Le serveur de périphériques série trois-en-un à un seul port FCT-1100-F1S1 de Feichang fournit un contexte concret de liaison série-réseau. Les octets acheminés par une interface ou un réseau n’acquièrent pas automatiquement une nouvelle signification métier. Cet article ne déduit pas le protocole interne de délimitation des paquets du produit ; consultez sa documentation et sa configuration pour connaître ses capacités réelles.
Pourquoi un même marqueur peut avoir deux rôles
Supposons que les deux extrémités conviennent qu’un octet particulier indique la fin. À sa réception, un analyseur transmet les données précédentes conservées en mémoire tampon. L’idée ressemble à un signe de ponctuation qui marque la fin d’une phrase. Cependant, un contenu binaire peut contenir n’importe quelle valeur d’octet ; aucune valeur choisie n’est automatiquement absente de la charge utile.
Un enregistrement de mesure peut contenir la même valeur que le marqueur de fin. L’analyseur doit-il traiter cette occurrence comme une donnée ou comme une limite ? La valeur seule ne permet pas de trancher entre ces deux rôles. L’émetteur et le récepteur ont besoin d’une règle commune qui modifie la représentation des valeurs spéciales sur la liaison.
Interdire simplement une valeur limite ce que les données d’origine peuvent exprimer et risque de modifier silencieusement les mesures. Remplacer le cuivre par de la fibre ne supprime pas non plus l’ambiguïté : la conversion optique change le support de transmission, pas l’interprétation du protocole applicatif. La qualité de la liaison et les règles d’encodage doivent être vérifiées séparément.
L’échappement modifie la représentation, pas les données
L’échappement peut être considéré comme un signal indiquant qu’il faut interpréter l’octet suivant selon une règle convenue. L’émetteur examine la charge utile et remplace les valeurs d’octets protégées par des séquences spéciales. Le récepteur effectue la conversion inverse et doit retrouver le même contenu d’origine.
Dans l’exemple SLIP décrit par la RFC 1055, la valeur hexadécimale C0 correspond à END et DB à ESC. Un C0 dans la charge utile devient DB DC ; un DB dans la charge utile devient DB DD. Un C0 non échappé indique la véritable limite de fin. Ces valeurs particulières appartiennent à cet exemple, et non à tous les protocoles série.
Pourquoi échapper également DB ? Cet octet introduit une interprétation spéciale de l’octet suivant. Si un DB d’origine était envoyé sans distinction, la valeur ordinaire suivante pourrait être prise pour un suffixe d’échappement. Protéger à la fois le délimiteur et l’octet introducteur d’échappement évite de créer une nouvelle ambiguïté.
Suivre un exemple court de l’émetteur au récepteur
Prenons la charge utile d’origine 11 C0 22 DB 33. Les deux valeurs spéciales ne peuvent pas être placées directement dans le flux délimité comme du contenu ordinaire. L’encodage donne 11 DB DC 22 DB DD 33 ; de véritables marqueurs END délimitent le résultat pour que le récepteur puisse distinguer les rôles de contrôle des données reconstituées.
Cette illustration place C0 avant et après le paquet. La RFC 1055 présente l’envoi d’un END au début comme un moyen d’éliminer le bruit accumulé ; un résultat de longueur nulle issu de marqueurs consécutifs ne doit pas être transmis comme un paquet IP normal. Les autres protocoles n’utilisent pas nécessairement des marqueurs identiques aux deux extrémités.
Après décodage, les octets C0 et DB de la charge utile redeviennent des données ordinaires. Les délimiteurs eux-mêmes ne font pas partie du contenu transmis à l’application. L’encodage peut augmenter le nombre d’octets sur la liaison. Les compteurs du serveur série, les captures et les longueurs observées par l’application peuvent différer lorsqu’ils sont mesurés à des couches différentes, sans que cela prouve une perte de données.
Un récepteur doit mémoriser son état courant
L’analyseur ne peut pas toujours interpréter chaque octet isolément. Il doit au minimum distinguer la lecture normale de l’attente d’un suffixe après un octet introducteur d’échappement. À l’état normal, un END marque la limite du paquet ; un DB fait passer l’analyseur à l’état d’attente du suffixe au lieu d’émettre immédiatement DB comme donnée d’origine.
Dans l’état d’attente, le récepteur applique la correspondance convenue et revient à l’état normal. La relation entre les deux octets est conservée par l’état de l’analyseur ; les octets n’ont pas besoin d’arriver lors de la même lecture logicielle. Si une lecture se termine par DB et que la suivante commence par DC, le récepteur doit conserver son état et terminer la conversion.
Une implémentation réelle nécessite également des règles pour les suffixes invalides, les limites des tampons, les paquets vides et les interruptions. Cet article n’impose pas de stratégie universelle de gestion des erreurs. Si le logiciel réinitialise l’état d’analyse à chaque lecture réseau, ou suppose que chaque lecture constitue un message, la délimitation peut échouer même si le transport a livré tous les octets.
Une limite n’est ni un contrôle d’erreurs ni une garantie de sécurité
L’échappement résout l’ambiguïté de représentation. Il n’ajoute pas automatiquement de détection d’erreurs, de retransmission, d’authentification ou de chiffrement. Découper un flux en paquets ne prouve ni que chaque paquet est correct, ni que son émetteur est digne de confiance. SLIP lui-même offre des services limités et ne doit pas être considéré comme un protocole général de sécurité pour le contrôle industriel.
Différents protocoles peuvent aussi appliquer les contrôles et l’échappement à des étapes différentes. La délimitation de type HDLC de PPP possède ses propres règles de fanion, de transparence et de contrôle de trame ; ces détails ne sont pas identiques à ceux de SLIP. Mélanger les valeurs des marqueurs, les suffixes d’échappement ou les étapes de contrôle peut conduire les deux extrémités à recevoir des octets sans qu’aucune n’accepte de paquet.
Repérez les emplacements des données applicatives d’origine, de l’encodage, du transport physique ou réseau, du décodage et de la validation applicative. Lors de l’analyse d’erreurs, identifiez la couche d’observation avant de comparer le contenu attendu. Une comparaison directe, octet par octet, du trafic encodé avec les champs applicatifs décodés peut faire apparaître un défaut inexistant.
Vérifier les règles convenues avec de petits échantillons reproductibles
Commencez par la documentation du périphérique et du protocole. Consignez les versions, les paramètres d’interface, la mise en paquets et les points de capture. Testez des données ordinaires, des données contenant la valeur de fin, des données contenant la valeur d’échappement et des valeurs spéciales consécutives. Vérifiez les formes encodées et décodées. Ces méthodes sont données à titre d’illustration et ne constituent pas une affirmation selon laquelle un produit particulier aurait fait l’objet de mesures.
Testez ensuite les lectures fractionnées, les lectures regroupées et les connexions interrompues lorsque l’implémentation doit les prendre en charge. Utilisez des données inoffensives dans un environnement autorisé, et non les octets d’exemple comme commandes sur un système de production en service. Si les extrémités utilisent des protocoles différents, déterminez laquelle effectue la conversion avant de modifier à répétition les débits en bauds.
Gardez les couches à l’esprit : l’UART identifie les caractères, une règle de délimitation identifie les messages, et l’échappement empêche que les valeurs spéciales de la charge utile soient prises pour des marqueurs de contrôle. Les distinguer explique pourquoi un port peut recevoir des octets alors qu’une application ne parvient toujours pas à reconstituer un message complet.
Références principales
RFC 1055 : SLIP, juin 1988, ne constitue pas une norme Internet ; RFC 1662 : PPP avec une délimitation de type HDLC, juillet 1994. Contexte produit : serveur de périphériques série FCT-1100-F1S1 ; cela ne signifie pas qu’il utilise SLIP.
Traduit de l’article technique en chinois : Lire l’article original en chinois.
Questions pratiques fréquentes
La réception de caractères série identifie-t-elle automatiquement un paquet ?
Non. La réception des caractères par l’UART et la délimitation applicative sont distinctes ; les deux extrémités doivent utiliser les mêmes règles de délimitation.
Comment SLIP échappe-t-il les octets C0 et DB de la charge utile ?
C0 dans la charge utile devient DB DC et DB dans la charge utile devient DB DD ; un END non échappé indique une limite. D’autres protocoles peuvent utiliser des règles différentes.
L’échappement des octets remplace-t-il les contrôles d’intégrité ou le chiffrement ?
Non. Il supprime l’ambiguïté entre les marqueurs de contrôle et les valeurs de la charge utile ; il n’assure pas automatiquement de détection d’erreurs, de retransmission, d’authentification ou de chiffrement.
Périmètre et lectures complémentaires
Exemple générique de délimitation SLIP, ne constituant pas une affirmation concernant un produit particulier ou des données mesurées.
Demi-fermeture TCP et réponses série · Charges unitaires RS485 et budget de charge du circuit de commande
