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.