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 (Stream control transmission protocol) est un protocole de transport fiable de la suite des protocoles Internet permettant la transmission de messages de télécommunication à travers des réseaux IP. Il réunit plusieurs caractéristiques des protocoles TCP (orienté connexion) et UDP (sans connexion) servant également au transfert des données, et comprend notamment des mécanismes de gestion des congestions (Congestion Control) et d’amélioration de la tolérance aux erreurs lors de l’envoi des paquets. Grâce à sa grande flexibilité, le SCTP est également utilisé dans d’autres applications (par exemple pour la gestion et l’administration de pools de serveurs).
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 :
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.
À l’instar du TCP, le SCTP est essentiellement un protocole avec connexion imposant une connexion entre le client et le serveur afin de permettre l’échange des paquets de données. Afin d’établir une telle connexion, les deux parties procèdent à un handshaking en quatre temps que le client initialise avec une requête INIT. Le serveur répond à cette requête avec un message INIT-ACK qui contient à la fois l’accusé de réception et un cookie identifiant sans équivoque la connexion proposée. Le client renvoie à son tour le cookie intégré dans une requête COOKIE-ECHO au serveur qui achève d’établir la connexion avec un message COOKIE-ACK.
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.
Alors que les streams SCTP caractérisent une séquence de données utilisateurs, dans des connexions TCP, un stream désigne toujours une séquence de bytes précise.
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.
Afin de protéger votre vie privée, la vidéo ne se chargera qu'après votre clic.
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).
La gestion de chemin et la validation du paquet ont toujours lieu simultanément.
En tant que protocole de la couche de transport, le SCTP est notamment en concurrence avec les protocoles TCP et UDP déjà évoqués. Il suffit toutefois de jeter un œil aux fonctionnalités et caractéristiques implémentées par le SCTP pour voir qu’il ne remplace pas l’un ou l’autre protocole et se présente davantage comme une combinaison des deux. Le tableau suivant résume sur quels points le Stream control transmission protocol ressemble davantage au protocole TCP ou au protocole UDP :
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.
Quick UDP Internet Connections (en abrégé QUIC) est un protocole de réseau expérimental de Google. Le développement du protocole est piloté par l’IETF, qui a mis en place un groupe dédié à cette fin. Le protocole QUIC est destiné à offrir une alternative optimisée en termes de vitesse à la norme de transport TCP actuelle et s'appuie sur le protocole sans connexion UDP pour y parvenir.
La suite des protocoles Internet, fondement de la communication sur Internet, compte près de 500 protocoles utilisés pour des couches bien différentes. Le User Datagram Protocol (UDP) sans connexion est par exemple chargé de la transmission de paquets ayant été adressés au préalable à l’aide de l’Internet protocol (IP) sur la couche transport. Vous découvrirez dans ce guide en quoi ce protocole se...
Offrez un service performant et fiable à vos clients avec l'hébergement web de IONOS.
Voir les packs
