我们现在已经在几个应用程序中部署了SCTP，并且在各种家用路由器中遇到了SCTP支持的重大问题。它们不能正确地处理SCTP。我认为这主要是一个性能问题(SCTP协议规范要求重新计算整个数据包的校验和，而不仅仅是报头)。

和许多其他有前途的协议一样，SCTP在D-link和Netgear修复它们坏掉的NAT盒子之前已经不幸地死在水里了。

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工作组这样的努力。

阅读SCTP维基百科页面，我想说主要原因是SCTP是一个非常年轻的协议(在2000年提出)，目前主流操作系统(Windows、OS X、Linux)都不支持它。

如果“非常年轻”对你来说似乎不合适，那么想想IPV6:“2008年12月，尽管已经是标准跟踪协议诞生10周年，IPV6在全球范围内的普遍部署还处于起步阶段。”

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，并且在各种家用路由器中遇到了SCTP支持的重大问题。它们不能正确地处理SCTP。我认为这主要是一个性能问题(SCTP协议规范要求重新计算整个数据包的校验和，而不仅仅是报头)。

和许多其他有前途的协议一样，SCTP在D-link和Netgear修复它们坏掉的NAT盒子之前已经不幸地死在水里了。

SCTP广泛应用于4G LTE网络，其中Diameter用于AAA。