Pourquoi SCTP n'est-il pas tellement utilisé / connu
J'ai récemment lu le livre "UNIX Network Programming, Vol. 1" de Richards Stevens et j'ai constaté 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 transport basé sur le message comme UDP, mais fiable comme TCP. Voici une brève introduction d'IBM DeveloperWorks .
Honnêtement, je n'ai jamais entendu parler de SCTP auparavant. Je ne me souviens pas d'avoir lu cela dans des livres de réseautage ni d'en avoir entendu parler dans les cours que j'avais suivis. Lecture autres questions de stackoverflow qui mentionne SCTP suggère que je ne suis pas seul avec ce manque de connaissances.
Pourquoi SCTP est-il si inconnu? Pourquoi n'est-il pas très utilisé?
En effet, le protocole SCTP est principalement utilisé dans le domaine des télécommunications. Traditionnellement, les commutateurs de télécommunication utilisent SS7 ( Système de signalisation n ° 7 ) pour interconnecter différentes entités dans le réseau de télécommunication. Par exemple, la base de données d'abonné (HLR) du fournisseur de télécommunications, avec un commutateur (MSC), l'abonné est également connecté (MSC).
La zone des télécommunications évolue à des vitesses plus élevées et à un environnement plus accessible. L'une de ces modifications consiste à remplacer le protocole SS7 par un protocole IP plus élégant, rapide et flexible.
Le secteur 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 peu fiable, et les télécommunications ne le convertiront pas s’il ne gère pas au moins la charge supportée par SS7. C'est pourquoi SCTP a été développé. Il essaie:
- de mimer tous les avantages du réseau SS7 accumulés au fil des décennies.
- créer un protocole orienté connexion meilleur que TCP en vitesse, sécurité et redondance
Les dernières versions de Linux prennent déjà en charge SCTP.
Nous déployons maintenant SCTP dans plusieurs applications 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 SCTP correctement. Je pense que c'est principalement un problème de performances (la spécification du protocole SCTP exige des sommes de contrôle pour l'ensemble des paquets à recalculer et pas seulement pour les en-têtes).
Comme beaucoup d’autres protocoles prometteurs, SCTP est tristement mort dans l’eau jusqu’à ce que D-link et Netgear corrigent leurs erreurs NAT).
SCTP nécessite davantage de conception au sein de 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 faiblesses de TCP) l’apprécient - c’est un protocole bien conçu qui s’appuie sur nos ~ 30 années de connaissance de TCP = et UDP.
Un des aspects qui nécessite une réflexion est celui des ruisseaux. 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é sur plusieurs flux, vous évitez ainsi le blocage en tête de ligne lorsque le récepteur meurt de faim en raison d'un paquet égaré.En réalité, différentes conversations peuvent être menées sur la même connexion sans se gêner mutuellement.
Un autre ajout utile est celui de la prise en charge de la multi-hébergement - une connexion peut s’effectuer via plusieurs interfaces aux deux extrémités et gérer les défaillances. Vous pouvez émuler ceci dans TCP, mais au niveau de la couche d'application.
La fréquence de liaison correcte, qui est la première chose que toute application utilisant TCP pour les connexions non transitoires implémentées), est disponible gratuitement.
Mon résumé personnel de SCTP est qu’il ne fait rien que vous ne puissiez pas faire autrement (avec TCP ou UDP) avec un support applicatif important. Ce qu’il fournit est la possibilité de ne pas avoir d'implémenter (mal) ce code vous-même.
Pour votre information, SCTP est obligatoire comme supporté pour Diameter (cf RADIUS next gen). Voir RFC 3588
Les clients Diameter DOIVENT prendre en charge TCP ou SCTP, tandis que les agents et les serveurs DOIVENT prendre en charge les deux. Les versions futures de cette spécification PEUVENT Obliger les clients supporte SCTP.
SCTP est peu connu et peu utilisé/déployé car:
- Répandu: peu intégré dans les piles TCP/IP (en 2013: manquait encore de manière native dans les derniers Mac OSX et Windows)
- Bibliothèques: peu de liaisons de haut niveau dans des langages faciles à utiliser (Avertissement: je suis le responsable de pysctp , prise en charge de la pile SCTP easy pour Python)
- NAT: Ne se croise pas NAT très bien/pas du tout (moins de 1% des routeurs Internet pour la maison et l'entreprise) font NAT sur SCTP).
- Popularité: Aucune application grand public ne l'utilise
- Paradigme de la programmation: ça a un peu changé: c'est toujours un socket, mais vous pouvez connecter plusieurs hôtes à plusieurs (multihoming), le datagramme est ordonné et fiable, erc ...
- Complexité: la pile SCTP est complexe à mettre en œuvre (en raison de ce qui précède)
- Compétition: Multipath TCP arrive et devrait répondre aux besoins/capacités du multihébergement afin que les personnes s’abstiennent de mettre en œuvre SCTP si possible en attendant MTCP
- Niche: les besoins de remplissage SCTP sont très particuliers (datagrammes fiables commandés, flux multiples) et ne sont pas nécessaires pour de nombreuses applications
- Sécurité: SCTP échappe aux contrôles de sécurité (certains pare-feux, la plupart des IDS, tous les DLP, n'apparaissent pas sur netstat sauf CentOS/Redhat/Fedora ...)
- Capacité d'audit: environ 3 sociétés dans le monde effectuent régulièrement des audits de la sécurité SCTP (Avertissement: je travaille dans l'une d'elles)
- Courbe d'apprentissage: peu d'outils pour jouer avec SCTP (vérifiez l'excellent avecsctp 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 transitent par SCTP (SIGTRAN/SS7 avec GSM/UMTS, Diameter 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 une prise en charge dans les passerelles NAT), qui n’a jamais été déployée partout, et sans elle, la passerelle typique NAT ne permettra qu’un seul hôte privé par adresse publique à utiliser SCTP à la fois.
p2. SCTP mappé sur UDP/IPv4 autorise davantage d'hôtes privés par adresse publique, mais les mappages UDP dans les passerelles IPv4/NAT sont notoirement difficiles à établir et à maintenir, car 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? Est-ce qu'il prend en charge SCTP? Que diriez-vous d'un équilibreur de charge? Un accélérateur SSL?
p4. Enfin, une grande partie de l’Internet est assez limitée à ce qui peut passer par TCP le port 80 et le port 443, de sorte que le SCTP a tendance à y perdre quelque saveur que ce soit. Par conséquent, vous voyez des efforts comme le - MPTCP groupe de travail de l'IETF.
Beaucoup d'entre nous utiliserons bientôt SCTP, car il utilise les canaux de données WebRTC pour créer une couche fiable semblable à TCP au-dessus de UDP - SCTP sur DTLS sur UDP: https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13 # section-6
Lire le page Wikipedia de SCTP Je dirais que la raison principale est que SCTP est un très jeune protocole (proposé en 2000) qui n’est actuellement pas pris en charge par les systèmes d’exploitation traditionnels (Les fenêtres, OS X, Linux).
Si "très jeune" vous semble inapproprié, pensez à IPV6 : "en décembre 2008, bien que son protocole anniversaire ait été célébré comme son dixième anniversaire, IPv6 n'en était qu'à ses débuts en termes de déploiement mondial général. "
SCTP est largement utilisé dans le réseau 4G LTE où Diameter est utilisé pour AAA.
En ce qui concerne tous les commentaires sur les routeurs commerciaux en panne ou dépourvus de support SCTP, le problème est que SCTP avec NAT est toujours sous forme brouillon avec l'IETF. Il n'y a donc pas de spécification RFC pour eux. pour le mettre en œuvre.
Sctp est né trop tard et pour beaucoup, la situation TCP est suffisant.
En outre, comme je le sais, la plupart de ses utilisations s’appliquent aux télécommunications.