SCTP (Stream control transmission protocol) : le protocole de transport fiable axé sur les messages

La suite des protocoles Internet constitue la base de la communication entre les systèmes d’un réseau comme Internet. Au total, plus de 500 protocoles différents assument des rôles généralement bien distincts, même si certains protocoles ont plus ou moins la même fonction. Le TCP (Transmission Control Protocol) et l’UDP (User Datagram Protocol) définissent par exemple tous les deux le type de données échangées entre les participants 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 transmission protocol), l’IETF (Internet Engineering Task Force) a publié en 2000 un autre protocole qui associe les caractéristiques du TCP et de l’UDP.

Le Stream control transmission protocol, abrégé en SCTP, est un protocole réseau fiable de la suite des protocoles 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 principalement défini comme un protocole servant à la représentation d’infrastructure de téléphonie 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éralement 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 caractéristiques suivantes :

• une transmission avec accusé de réception des données utilisateurs (sans erreur ni doublon)
• une fragmentation des données afin de pouvoir respecter la taille maximale des paquets du chemin réseau concerné
• une distribution séquencée de messages utilisateurs au sein de plusieurs flux de données (multi-streaming), incluant la possibilité de déterminer l’ordre de ces messages
• le regroupement (facultatif) de plusieurs messages utilisateur 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 partenaire(s) de la communication

Le Stream control transmission protocol met donc l’accent sur une transmission sûre et fiable des données. En principe, il n’est pas nécessaire de fixer de manière stricte l’ordre des flux de données envoyés même si cette possibilité est offerte à tout moment. De cette manière, une planification fixe de la transmission des paquets est uniquement nécessaire avec le SCTP si l’application 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 particulièrement utile pour les services axés sur les messages.

La sécurité évoquée est assurée par un handshaking en quatre temps (authentification mutuelle avec établissement de connexion) entre l’émetteur et le destinataire, sans lequel le transfert des données ne serait pas possible via SCTP. L’en-tête contient par ailleurs une balise de vérification et un champ de somme de contrôle facultatif.

Afin d’expliquer le fonctionnement du transport de données via le Stream control transmission protocol, nous vous présentons tout d’abord ses principales fonctions, du handshaking en quatre temps à la transmission des paquets en passant par la fragmentation.

Les connexions SCTP établies peuvent être clôturées par l’application ou par l’utilisateur dès que la transmission est terminée ou sont interrompues 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 complètement arrêté dès qu’un participant coupe la connexion.

Dans le standard SCTP, le terme « stream » désigne une séquence de données utilisateurs échangées entre le serveur et le client. Une seule et même connexion SCTP permet un nombre illimité de streams. L’utilisateur peut en définir le nombre exact lors de l’établissement de la connexion. Alors que l’ordre des données est strictement respecté au sein d’un flux de données, il n’existe en revanche aucune hiérarchie définie ni aucune dépendance dans la livraison des différents streams. Par conséquent, si des problèmes surviennent dans la transmission d’un flux de données, cela n’a aucun impact sur le transfert des autres flux. Par ailleurs, il existe un mécanisme permettant de contourner la transmission séquencée et d’envoyer les paquets de messages de façon hiérarchisée.

SCTP offre la possibilité de fragmenter des paquets afin de toujours respecter le PMTU (Path Maximum Transmission 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 différents fragments sont rassemblés et transmis à l’utilisateur en tant que message complet. Par rapport à la fragmentation au niveau du réseau effectuée à l’aide du protocole IP, une fragmentation au niveau de la couche de transport de ce type présente certains avantages : elle décharge par exemple les routeurs qui sont responsables de la fragmentation 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 transmission protocol marque tous les fragments de données ou les messages non fragmentés d’un Transmission Sequence Number (numéro de séquence de transmission). Pour chacun de ces numéros de séquence, l’émetteur attend un accusé de réception de la part du destinataire. Si cet accusé de réception reste sans réponse pendant une période définie, le paquet correspondant est renvoyé. Afin de pouvoir garantir cette fiabilité de la transmission indépendamment de la transmission séquencée, le destinataire accuse également réception d’un Transmission Sequence Number lorsque la séquence transmise présente des lacunes. Pour que la transmission soit non seulement fiable mais aussi passablement rapide, le SCTP utilise des algorithmes de contrôle de congestion similaires à ceux du TCP. Ces algorithmes codifient l’envoi afin d’éviter toute congestion 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 informations de contrôle et/ou données utilisateurs, 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 responsable du regroupement que du fractionnement du paquet complet côté destinataire.

Lors de l’établissement de la connexion SCTP, les deux extrémités de la chaîne de transmission doivent convenir d’une balise de vérification, qui devra être indiquée tout au long de la transmission dans les en-têtes des différents paquets. Si l’un des partenaires de communication reçoit un paquet ne contenant pas cette balise, il le rejette automatiquement. De cette façon, le protocole offre une protection contre un accès par des tiers et empêche d’autre part que les paquets de connexions antérieures ne soient reçus dans le cadre d’une nouvelle connexion.

Afin d’apporter une protection supplémentaire aux données, l’émetteur a la possibilité de prolonger l’en-tête avec une somme de contrôle CRC32C. À cet effet, le protocole met à disposition un champ facultatif de 32 bits.

Comme le SCTP supporte le multi-homing, les utilisateurs peuvent indiquer tout un ensemble d’adresses de transport potentiellement utilisables comme destinations des paquets envoyés. Si plusieurs adresses sont enregistrées, le protocole utilise par défaut le chemin d’adresse primaire. Si ce dernier n’est pas accessible, les adresses alternatives sont traitées, afin de poursuivre la transmission sans interruption. Afin de pouvoir offrir ce service, le Streaming Control Transmission Protocol a implémenté une fonction de gestion de chemin, qui a recours aux instructions d’adresse indiquées. Cette fonction surveille également l’accessibilité de tous les chemins d’adresse définis en leur envoyant régulièrement ce qu’on appelle des heartbeats (signaux de contrôle).

Trois points communs fondamentaux entre le TCP et le SCTP peuvent ainsi être constatés : les deux protocoles sont fiables, présupposent une connexion entre les partenaires de communication et offrent un mécanisme de gestion des congestions. Ils veillent tous deux à ce que les paquets parviennent sans perte au destinataire. L’UDP ne disposant pas d’accusés de réception, il n’apporte aucune garantie de ce type. En contrepartie, l’UDP permet cependant à l’application 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 flexibilité, 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 alternatifs) L’UDP et le TCP en sont incapables. Grâce à un handshaking en quatre temps (comprenant des cookies d’authentification) et à la balise de vérification obligatoire dans l’en-tête de chaque paquet envoyé, le Stream control transmission protocol garantit de plus la plus haute sécurité parmi ces trois protocoles de transport.