SCTP需要在应用程序中进行更多的设计，以便更好地利用它。它比TCP有更多的选择，类似socket的API是后来才出现的，而且它很年轻。然而，我认为大多数花时间理解它的人(并且知道TCP的缺点)都很欣赏它——这是一个设计良好的协议，建立在我们对TCP和UDP大约30年的知识之上。

其中一个需要思考的方面是流。流提供了(通常，我认为您可以关闭它)它们之间的顺序保证(很像TCP连接)，但是每个SCTP连接可以有多个流。如果您的应用程序的数据可以通过多个流发送，那么您就可以避免由于一个错误放置的数据包而导致的接收端阻塞。有效地，不同的对话可以在同一个连接上进行，而不会相互影响。

另一个有用的附加功能是多归属支持——一个连接可以跨两端的多个接口，它可以处理故障。您可以在TCP中模拟这一点，但是是在应用层。

正确的链接心跳是任何使用TCP进行非瞬态连接的应用程序实现的第一件事，它是免费的。

我个人对SCTP的总结是，它没有做任何其他方式(在TCP或UDP中)在大量应用程序支持下不能做的事情。它所提供的是不必自己(糟糕地)实现代码的能力。

供参考，SCTP是强制支持的直径(cf RADIUS下一代)。参见RFC 3588

   Diameter clients MUST support either TCP or SCTP, while agents and
   servers MUST support both.  Future versions of this specification MAY
   mandate that clients support SCTP.

事实上，SCTP主要用于电信领域。传统上，电信交换机使用SS7 (Signaling System No. 7)实现电信网络中不同实体之间的互连。例如，电信供应商的用户数据库(HLR)，通过交换机(MSC)，用户也被连接(MSC)。

电信领域正在向更高的速度和更可达的环境发展。其中一个变化是用一些更优雅、更快、更灵活的基于ip的协议取代SS7协议。

电信领域非常保守。七号信令网络在这里已经使用了几十年。这是一个非常可靠和封闭的网络。这意味着普通用户无法访问它。

相比之下，IP网络是开放的，不可靠，如果它不能至少处理SS7处理的负载，电信公司就不会转换到IP网络。这就是开发SCTP的原因。它尝试:

模仿SS7网络几十年来积累的所有优势。 创建一个在速度、安全性和冗余方面优于TCP的面向连接的协议

Linux的最新版本已经支持SCTP。

我们中的许多人很快就会使用SCTP，因为WebRTC数据通道使用它在UDP之上创建一个类似tcp的可靠层——SCTP over DTLS over UDP: https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-data-channel-13#section-6

Sctp诞生得太晚了，对于很多情况，TCP已经足够了。

此外，据我所知，它的大部分使用是在电信领域。

关于商业路由器被破坏或缺乏SCTP支持的所有评论，问题是带有NAT的SCTP仍处于IETF的草案形式。所以他们没有RFC规范来实现它。

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

p1。直接通过IPv4映射的SCTP需要NAT网关的支持，而NAT网关从未在任何地方广泛部署，如果没有它，典型的NAT网关一次只允许每个公共地址有一台私有主机使用SCTP。

p2。通过UDP/IPv4映射的SCTP允许每个公共地址有更多的私有主机，但是IPv4/NAT网关中的UDP映射非常难以建立和维护，因为UDP是一种无连接传输，没有任何显式的状态供NAT跟踪。

p3。SCTP直接映射到IPv6需要…嗯…IPv6。你试过部署IPv6吗?如果是的话，你试过买IPv6防火墙吗?是否支持SCTP?负载均衡器怎么样?SSL加速器?

p4。最后，许多Internet在很大程度上受到限制，只能通过TCP端口80和端口443进行传输，因此任何类型的SCTP都可能在这两个端口上丢失。因此，您可以在IETF中看到像MPTCP工作组这样的努力。