Pourquoi le SCTP est-il peu utilisé / connu?

J'ai récemment consulté le livre "UNIX Network Programming, Vol. 1" de Richards Stevens et j'ai découvert qu'il existe une troisième norme de couche de transport en plus de TCP et UDP: SCTP .

Résumé: SCTP est un protocole de niveau transport qui est piloté par message comme UDP, mais fiable comme TCP. Voici une brève introduction d'IBM DeveloperWorks .

Honnêtement, je n'ai jamais entendu parler du SCTP auparavant. Je ne me souviens pas avoir lu à ce sujet dans aucun livre de réseautage ou en avoir entendu parler dans les cours que j'avais suivis. La lecture d' autres questions de stackoverflow qui mentionnent SCTP suggère que je ne suis pas seul avec ce manque de connaissances.

Pourquoi le SCTP est-il si inconnu? Pourquoi est-il peu utilisé?

En effet, le SCTP est principalement utilisé dans le domaine des télécommunications. Traditionnellement, les commutateurs de télécommunications utilisent SS7 ( système de signalisation n ° 7 ) pour interconnecter différentes entités du réseau de télécommunications. Par exemple - la base de données d'abonnés (HLR) du fournisseur de télécommunications, avec un commutateur (MSC), l'abonné est également connecté (MSC).

Le secteur des télécommunications évolue vers des vitesses plus élevées et un environnement plus accessible. L'un de ces changements consiste à remplacer le protocole SS7 par un protocole IP plus élégant, plus rapide et plus flexible.

Le domaine des télécommunications est très conservateur. Le réseau SS7 est utilisé ici depuis des décennies. C'est un réseau très fiable et fermé. Cela signifie qu'un utilisateur régulier n'y a pas accès.

Le réseau IP, en revanche, est ouvert et non fiable, et les télécoms ne s'y convertiront pas s'ils ne gèrent pas au moins la charge que SS7 gère. C'est pourquoi SCTP a été développé. Il essaie:

• pour reproduire tous les avantages du réseau SS7 accumulés au fil des décennies.
• pour créer un protocole orienté connexion meilleur que TCP en termes de vitesse, de sécurité et de redondance

Les dernières versions de Linux prennent déjà en charge SCTP.

Nous avons déployé SCTP dans plusieurs applications maintenant et avons rencontré un problème important avec la prise en charge de SCTP dans divers routeurs domestiques. Ils ne gèrent tout simplement pas correctement SCTP. Je crois que c'est principalement un problème de performances (la spécification du protocole SCTP exige que les sommes de contrôle pour l'ensemble des paquets soient recalculées et pas seulement pour les en-têtes).

Comme beaucoup d'autres protocoles prometteurs, SCTP est malheureusement mort dans l'eau jusqu'à ce que D-link et Netgear réparent leurs boîtes NAT cassées.

SCTP nécessite plus de conception dans l'application pour en tirer le meilleur parti. Il y a plus d'options que TCP, l'API de type Sockets est arrivée plus tard et elle est jeune. Cependant, je pense que la plupart des gens qui prennent le temps de le comprendre (et qui connaissent les défauts de TCP) l'apprécient - c'est un protocole bien conçu qui s'appuie sur nos ~ 30 ans de connaissance de TCP et UDP.

L'un des aspects qui nécessite une réflexion est celui des flux. Les flux fournissent (généralement, je pense que vous pouvez le désactiver) une garantie de commande en leur sein (un peu comme une connexion TCP), mais il peut y avoir plusieurs flux par connexion SCTP. Si les données de votre application peuvent être envoyées sur plusieurs flux, vous évitez le blocage de tête de ligne où le récepteur meurt de faim en raison d'un paquet égaré. Des conversations effectivement différentes peuvent avoir lieu sur la même connexion sans se répercuter.

Un autre ajout utile est celui de la prise en charge du multi-homing - une connexion peut être à travers plusieurs interfaces aux deux extrémités et elle résout les échecs. Vous pouvez émuler cela dans TCP, mais au niveau de la couche application.

Le battement de cœur de lien approprié, qui est la première chose que toute application utilisant TCP pour les connexions non transitoires implémente, est disponible gratuitement.

Mon résumé personnel de SCTP est qu'il ne fait rien que vous ne pourriez pas faire autrement (en TCP ou UDP) avec un support d'application substantiel. Ce qu'il offre, c'est la possibilité de ne pas avoir à implémenter (mal) ce code vous-même.

Pour info, SCTP est mandaté comme supporté pour Diameter (cf RADIUS next gen). voir RFC 3588

   Les clients de diamètre DOIVENT prendre en charge TCP ou SCTP, tandis que les agents et
   les serveurs DOIVENT prendre en charge les deux. Les futures versions de cette spécification PEUVENT
   mandat que les clients soutiennent SCTP.

Le SCTP est peu connu et peu utilisé / déployé car:

• Largement répandu: pas largement intégré dans les piles TCP / IP (en 2013: toujours absent nativement dans les derniers Mac OSX et Windows)
• Bibliothèques: Peu de liaisons de haut niveau dans des langages faciles à utiliser (Avertissement: je suis le mainteneur de pysctp , support SCTP easy stack pour Python)
• NAT: ne traverse pas très bien / pas du tout le NAT (moins de 1% des routeurs Internet domestiques et d'entreprise font du NAT sur SCTP).
• Popularité: Aucune application grand public ne l'utilise
• Paradigme de programmation: ça a un peu changé: c'est toujours une socket, mais on peut connecter de nombreux hôtes à de nombreux hôtes (multihoming), le datagramme est ordonné et fiable, erc ...
• Complexité: la pile SCTP est complexe à implémenter (en raison de ci-dessus)
• Concurrence: Multipath TCP arrive et devrait répondre aux besoins / capacités de multi-hébergement afin que les gens s'abstiennent de mettre en œuvre SCTP si possible, en attendant MTCP
• Niche: Les besoins de remplissage SCTP sont très particuliers (datagrammes fiables ordonnés, multiflux) et ne sont pas nécessaires à de nombreuses applications
• Sécurité: SCTP échappe aux contrôles de sécurité (certains pare-feu, la plupart des IDS, tous les DLP, n'apparaissent pas sur netstat sauf CentOS / Redhat / Fedora ...)
• Capacité d'audit: quelque chose comme 3 entreprises dans le monde effectuent régulièrement des audits de sécurité SCTP (Avertissement: je travaille dans l'une d'entre elles)
• Courbe d'apprentissage: pas beaucoup de chaîne d'outils pour jouer avec SCTP (vérifiez l'excellent withsctp qui se combine bien avec netcat ou utilisez socat)
• Sous le capot: Utilisé principalement dans les télécommunications et chaque fois que vous envoyez des SMS, commencez à surfer sur le net sur votre mobile ou passez des appels téléphoniques, vous déclenchez souvent des messages qui circulent sur SCTP (SIGTRAN / SS7 avec GSM / UMTS, Diamètre avec LTE / IMS / RCS, S1AP / X2AP avec LTE), donc vous l'utilisez beaucoup mais vous ne le savez jamais ;-)

p1. SCTP mappé directement sur IPv4 nécessite la prise en charge des passerelles NAT, qui n'ont jamais été largement déployées nulle part, et sans elle, la passerelle NAT typique ne permettra qu'à un seul hôte privé par adresse publique d'utiliser SCTP à la fois.

p2. SCTP mappé sur UDP / IPv4 permet plus d'hôtes privés par adresse publique, mais les mappages UDP dans les passerelles IPv4 / NAT sont notoirement difficiles à établir et à maintenir, en raison du fait qu'UDP est un transport sans connexion sans aucun état explicite pour un NAT à suivre .

p3. SCTP mappé directement sur IPv6 nécessite ... enfin ... IPv6. Avez-vous essayé de déployer IPv6? Si oui, avez-vous essayé d'acheter un pare-feu IPv6? Prend-il en charge SCTP? Et un équilibreur de charge? Un accélérateur SSL?

p4. Enfin, une grande partie d'Internet est pratiquement limitée à ce qui peut passer par le port TCP 80 et le port 443, de sorte que SCTP de toute saveur a tendance à y perdre. Par conséquent, vous voyez des efforts comme le groupe de travail MPTCP de l'IETF.

Beaucoup d'entre nous utiliseront bientôt SCTP, car il est utilisé par les canaux de données WebRTC pour créer une couche fiable de type TCP au-dessus d'UDP - SCTP sur DTLS sur UDP: https://tools.ietf.org/html/draft-ietf -rtcweb-data-channel-13 # section-6

En lisant la page Wikipédia du SCTP, je dirais que la raison principale est que SCTP est un protocole très jeune (proposé en 2000) qui n'est actuellement pas pris en charge par les OS grand public ( Windows , OS X , Linux ).

Si «très jeune» vous semble inapproprié, pensez à IPV6 : «en décembre 2008, alors qu'il fêtait son 10e anniversaire en tant que protocole Standards Track, IPv6 n'en était qu'à ses balbutiements en termes de déploiement général dans le monde».

SCTP est largement utilisé dans le réseau 4G LTE où le diamètre est utilisé pour AAA.

Ce n'est peut-être pas bien connu, mais il n'est pas utilisé. Tout récemment, un projet a été publié à l' IETF sur l' utilisation de SCTP comme protocole de couche de transport pour HTTP .

En référence à tous les commentaires sur les routeurs commerciaux cassés ou manquant de support SCTP, le problème est que SCTP avec NAT est toujours sous forme de projet avec l'IETF. Il n'y a donc pas de spécification RFC pour qu'ils l'implémentent.

https://tools.ietf.org/html/draft-ietf-behave-sctpnat-09

Sctp est né trop tard, et pour de nombreuses situations, TCP suffit.

De plus, comme je le sais, la plupart de son utilisation concerne le domaine des télécommunications.