SCTP (Stream control trans­mis­sion protocol) : le protocole de transport fiable axé sur les messages

La suite des pro­to­coles Internet constitue la base de la com­mu­ni­ca­tion entre les systèmes d’un réseau comme Internet. Au total, plus de 500 pro­to­coles dif­fé­rents assument des rôles gé­né­ra­le­ment bien distincts, même si certains pro­to­coles ont plus ou moins la même fonction. Le TCP (Trans­mis­sion Control Protocol) et l’UDP (User Datagram Protocol) dé­fi­nis­sent par exemple tous les deux le type de données échangées entre les par­ti­ci­pants au réseau. Alors que le TCP a besoin d’une connexion existante, l’UDP permet un transfert de fichiers sans connexion. Avec le SCTP (Stream control trans­mis­sion protocol), l’IETF (Internet En­gi­nee­ring Task Force) a publié en 2000 un autre protocole qui associe les ca­rac­té­ris­tiques du TCP et de l’UDP.

Le Stream control trans­mis­sion protocol, abrégé en SCTP, est un protocole réseau fiable de la suite des pro­to­coles Internet qui été conçu par le groupe de travail Signaling Transport (SIGTRAN) de l’IETF. La première version du protocole a été définie dans la RFC 2960 publiée en 2000. Sept ans plus tard, l’IETF a publié une version révisée dans la RFC 4960. Dans ces RFC, le SCTP est prin­ci­pa­le­ment défini comme un protocole servant à la re­pré­sen­ta­tion d’in­fras­truc­ture de té­lé­pho­nie dans les réseaux IP. Il est par ailleurs utilisé dans d’autres domaines, par exemple pour le Reliable Server Pooling (gestion de pools de serveurs dans le but de répartir la charge).

Le SCTP utilise gé­né­ra­le­ment l’IP comme base, mais peut en principe s’appuyer sur d’autres services de paquets sans connexion. Le transport des paquets se démarque alors notamment par les ca­rac­té­ris­tiques suivantes :

• une trans­mis­sion avec accusé de réception des données uti­li­sa­teurs (sans erreur ni doublon)
• une frag­men­ta­tion des données afin de pouvoir respecter la taille maximale des paquets du chemin réseau concerné
• une dis­tri­bu­tion séquencée de messages uti­li­sa­teurs au sein de plusieurs flux de données (multi-streaming), incluant la pos­si­bi­lité de dé­ter­mi­ner l’ordre de ces messages
• le re­grou­pe­ment (fa­cul­ta­tif) de plusieurs messages uti­li­sa­teur dans un même paquet SCTP (chunk bundling)
• la tolérance aux erreurs au niveau des réseaux grâce au multi-homing (hôte avec plusieurs adresses réseau valides) d’un ou des deux par­te­naire(s) de la com­mu­ni­ca­tion

Le Stream control trans­mis­sion protocol met donc l’accent sur une trans­mis­sion sûre et fiable des données. En principe, il n’est pas né­ces­saire de fixer de manière stricte l’ordre des flux de données envoyés même si cette pos­si­bi­lité est offerte à tout moment. De cette manière, une pla­ni­fi­ca­tion fixe de la trans­mis­sion des paquets est uni­que­ment né­ces­saire avec le SCTP si l’ap­pli­ca­tion en a besoin. Les données envoyées dans ce cadre sont les données pouvant être divisées en plusieurs flux, non pas en fonction des bits mais des paquets, ce qui s’avère par­ti­cu­liè­re­ment utile pour les services axés sur les messages.

La sécurité évoquée est assurée par un hand­sha­king en quatre temps (au­then­ti­fi­ca­tion mutuelle avec éta­blis­se­ment de connexion) entre l’émetteur et le des­ti­na­taire, sans lequel le transfert des données ne serait pas possible via SCTP. L’en-tête contient par ailleurs une balise de vé­ri­fi­ca­tion et un champ de somme de contrôle fa­cul­ta­tif.

Afin d’expliquer le fonc­tion­ne­ment du transport de données via le Stream control trans­mis­sion protocol, nous vous pré­sen­tons tout d’abord ses prin­ci­pales fonctions, du hand­sha­king en quatre temps à la trans­mis­sion des paquets en passant par la frag­men­ta­tion.

Les con­nexions SCTP établies peuvent être clôturées par l’ap­pli­ca­tion ou par l’uti­li­sa­teur dès que la trans­mis­sion est terminée ou sont in­ter­rom­pues de façon anticipée lorsqu’une erreur s’est produite. Il est par ailleurs possible de mettre fin à la connexion à tout moment à l’aide d’une requête. Dans tous les cas, le transfert des données est com­plè­te­ment arrêté dès qu’un par­ti­ci­pant coupe la connexion.

Dans le standard SCTP, le terme « stream » désigne une séquence de données uti­li­sa­teurs échangées entre le serveur et le client. Une seule et même connexion SCTP permet un nombre illimité de streams. L’uti­li­sa­teur peut en définir le nombre exact lors de l’éta­blis­se­ment de la connexion. Alors que l’ordre des données est stric­te­ment respecté au sein d’un flux de données, il n’existe en revanche aucune hié­rar­chie définie ni aucune dé­pen­dance dans la livraison des dif­fé­rents streams. Par con­sé­quent, si des problèmes sur­vien­nent dans la trans­mis­sion d’un flux de données, cela n’a aucun impact sur le transfert des autres flux. Par ailleurs, il existe un mécanisme per­met­tant de con­tour­ner la trans­mis­sion séquencée et d’envoyer les paquets de messages de façon hié­rar­chi­sée.

SCTP offre la pos­si­bi­lité de frag­men­ter des paquets afin de toujours respecter le PMTU (Path Maximum Trans­mis­sion Unit) déterminé, c’est-à-dire la taille de paquet maximale pouvant être transmise par le chemin de connexion concerné. Au moment de la réception, les dif­fé­rents fragments sont ras­sem­blés et transmis à l’uti­li­sa­teur en tant que message complet. Par rapport à la frag­men­ta­tion au niveau du réseau effectuée à l’aide du protocole IP, une frag­men­ta­tion au niveau de la couche de transport de ce type présente certains avantages : elle décharge par exemple les routeurs qui sont res­pon­sables de la frag­men­ta­tion des paquets IP. Elle permet en outre d’éviter de renvoyer des messages complets en raison de la perte d’un seul fragment sur le réseau.

Le Stream control trans­mis­sion protocol marque tous les fragments de données ou les messages non frag­men­tés d’un Trans­mis­sion Sequence Number (numéro de séquence de trans­mis­sion). Pour chacun de ces numéros de séquence, l’émetteur attend un accusé de réception de la part du des­ti­na­taire. Si cet accusé de réception reste sans réponse pendant une période définie, le paquet cor­res­pon­dant est renvoyé. Afin de pouvoir garantir cette fiabilité de la trans­mis­sion in­dé­pen­dam­ment de la trans­mis­sion séquencée, le des­ti­na­taire accuse également réception d’un Trans­mis­sion Sequence Number lorsque la séquence transmise présente des lacunes. Pour que la trans­mis­sion soit non seulement fiable mais aussi pas­sa­ble­ment rapide, le SCTP utilise des al­go­rithmes de contrôle de con­ges­tion si­mi­laires à ceux du TCP. Ces al­go­rithmes codifient l’envoi afin d’éviter toute con­ges­tion des paquets et donc toute surcharge de l’hôte.

Le SCTP permet de regrouper plusieurs messages dans un même paquet. De cette façon, plusieurs in­for­ma­tions de contrôle et/ou données uti­li­sa­teurs, qu’on appelle également « chunks » (« fragments ») dans le standard SCTP, peuvent être envoyées sous un même en-tête. Le mécanisme de chunk bundling est aussi bien res­pon­sable du re­grou­pe­ment que du frac­tion­ne­ment du paquet complet côté des­ti­na­taire.

Lors de l’éta­blis­se­ment de la connexion SCTP, les deux ex­tré­mi­tés de la chaîne de trans­mis­sion doivent convenir d’une balise de vé­ri­fi­ca­tion, qui devra être indiquée tout au long de la trans­mis­sion dans les en-têtes des dif­fé­rents paquets. Si l’un des par­te­naires de com­mu­ni­ca­tion reçoit un paquet ne contenant pas cette balise, il le rejette au­to­ma­ti­que­ment. De cette façon, le protocole offre une pro­tec­tion contre un accès par des tiers et empêche d’autre part que les paquets de con­nexions an­té­rieures ne soient reçus dans le cadre d’une nouvelle connexion.

Afin d’apporter une pro­tec­tion sup­plé­men­taire aux données, l’émetteur a la pos­si­bi­lité de prolonger l’en-tête avec une somme de contrôle CRC32C. À cet effet, le protocole met à dis­po­si­tion un champ fa­cul­ta­tif de 32 bits.

Comme le SCTP supporte le multi-homing, les uti­li­sa­teurs peuvent indiquer tout un ensemble d’adresses de transport po­ten­tiel­le­ment uti­li­sables comme des­ti­na­tions des paquets envoyés. Si plusieurs adresses sont en­re­gis­trées, le protocole utilise par défaut le chemin d’adresse primaire. Si ce dernier n’est pas ac­ces­sible, les adresses al­ter­na­tives sont traitées, afin de pour­suivre la trans­mis­sion sans in­ter­rup­tion. Afin de pouvoir offrir ce service, le Streaming Control Trans­mis­sion Protocol a im­plé­menté une fonction de gestion de chemin, qui a recours aux ins­truc­tions d’adresse indiquées. Cette fonction surveille également l’ac­ces­si­bi­lité de tous les chemins d’adresse définis en leur envoyant ré­gu­liè­re­ment ce qu’on appelle des heart­beats (signaux de contrôle).

Trois points communs fon­da­men­taux entre le TCP et le SCTP peuvent ainsi être constatés : les deux pro­to­coles sont fiables, pré­sup­po­sent une connexion entre les par­te­naires de com­mu­ni­ca­tion et offrent un mécanisme de gestion des con­ges­tions. Ils veillent tous deux à ce que les paquets par­vien­nent sans perte au des­ti­na­taire. L’UDP ne disposant pas d’accusés de réception, il n’apporte aucune garantie de ce type. En con­tre­par­tie, l’UDP permet cependant à l’ap­pli­ca­tion qui l’utilise de ne pas avoir à mettre en place des marqueurs de groupes de données propres (pour le marquage des limites du paquet), puisqu’il n’est pas axé sur les bits mais sur les messages. Le SCTP présente également cet avantage.

À part cette flexi­bi­lité, qui fait du SCTP la solution idéale pour les services vocaux tels que le VoIP (Voice over IP), ce protocole se démarque également par sa capacité à supporter le multi-streaming et le multi-homing (tolérance aux erreurs au lieu d’hôtes al­ter­na­tifs) L’UDP et le TCP en sont in­ca­pables. Grâce à un hand­sha­king en quatre temps (com­pre­nant des cookies d’au­then­ti­fi­ca­tion) et à la balise de vé­ri­fi­ca­tion obli­ga­toire dans l’en-tête de chaque paquet envoyé, le Stream control trans­mis­sion protocol garantit de plus la plus haute sécurité parmi ces trois pro­to­coles de transport.