为什么 SCTP 没有被广泛使用/了解
我最近查阅了 Richards Stevens 和我发现除了 TCP 和 UDP 之外还有第三个传输层标准：SCTP。
简介： SCTP 是一种传输层协议，它像 UDP 一样是消息驱动的，但又像 TCP 一样可靠。 以下是 IBM DeveloperWorks 的简短介绍 。
老实说，我以前从未听说过 SCTP。 我不记得在任何网络书籍中读到过它或在我参加的课程中听说过它。 阅读提到 SCTP 的其他 stackoverflow 问题表明我并不是唯一一个缺乏知识的人。
为什么 SCTP 如此不为人知？ 为什么用得不多？
I recently checked out the book "UNIX Network Programming, Vol. 1" by Richards Stevens and I found that there is a third transport layer standard besides TCP and UDP: SCTP.
Summary: SCTP is a transport-level protocol that is message-driven like UDP, but reliable like TCP. Here is a short introduction from IBM DeveloperWorks.
Honestly, I have never heard of SCTP before. I can't remember reading about it in any networking books or hearing about it in classes I had taken. Reading other stackoverflow questions that mentions SCTP suggests that I'm not alone with this lack of knowledge.
Why is SCTP so unknown? Why is it not much used?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（11）
阅读 SCTP 维基百科页面 我想说主要原因是 SCTP 还很年轻协议（2000 年提出），目前主流操作系统（
Windows、OS X、Linux）不支持。如果“非常年轻”对您来说似乎不合适，请考虑 IPV6：“2008 年 12 月，尽管IPv6 正值其作为标准跟踪协议诞生 10 周年，但就全球范围内的普遍部署而言，IPv6 还处于起步阶段。”
Reading the SCTP Wikipedia page I'd say that the main reason is that SCTP is a very young protocol (proposed in 2000) that is currently unsupported by the mainstream OSs (
Windows,OS X,Linux).If "very young" seems inappropriate to you, think about IPV6: "in December 2008, despite marking its 10th anniversary as a Standards Track protocol, IPv6 was only in its infancy in terms of general worldwide deployment."
SCTP 广泛用于 4G LTE 网络，其中 Diameter 用于 AAA。
SCTP is used extensively in the 4G LTE network where Diameter is used for AAA.
参考有关商业路由器损坏或缺乏 SCTP 支持的所有评论，问题是带有 NAT 的 SCTP 仍处于 IETF 的草案形式。 所以没有 RFC 规范供他们实现。
https://datatracker.ietf.org/doc/html/草案-ietf-behave-sctpnat-09
In reference to all of the comments about commercial routers being broken or lacking SCTP support, the issue is that SCTP with NAT is still in draft form with the IETF. So there is no RFC specification for them to implement it.
https://datatracker.ietf.org/doc/html/draft-ietf-behave-sctpnat-09
它可能不太为人所知，但并非没有使用过。 最近有一个草案发布于IETF 关于使用 SCTP 作为 HTTP 的传输层协议。
It might not be well known, but it's not unused. Quite recently there was a draft published at the IETF about Using SCTP as a Transport Layer Protocol for HTTP.
sctp诞生得太晚了，对于很多情况TCP就足够了。
另外，据我所知，它的大部分用途是在电信领域。
Sctp is born too late, and for many situation TCP is enough.
Also, as I know most of its usage is on telecommunication area.
事实上，SCTP 主要用于电信领域。 传统上，电信交换机使用 SS7（7 号信令系统）来互连电信网络中的不同实体。 例如-电信提供商的用户数据库（HLR），与交换机（MSC），用户也连接（MSC）。
电信领域正在转向更高速度和更可达的环境。 这些变化之一是用一些更优雅、快速和灵活的基于 IP 的协议来取代 SS7 协议。
电信领域非常保守。 SS7 网络已经在这里使用了几十年。 这是一个非常可靠且封闭的网络。 这意味着普通用户无法访问它。
相比之下，IP 网络是开放的且不可靠，如果它不能至少处理 SS7 处理的负载，电信公司就不会转换到它。 这就是开发 SCTP 的原因。 它试图：
Linux 的最新版本已经支持 SCTP。
Indeed, SCTP is used mostly in the telecom area. Traditionally, telecom switches use SS7 (Signaling System No. 7) to interconnect different entities in the telecom network. For example - the telecom provider's subscriber data base(HLR), with a switch (MSC), the subscriber is connected too (MSC).
The telecom area is moving to higher speeds and more reachable environment. One of these changes is to replace SS7 protocol by some more elegant, fast and flexible IP-based protocol.
The telecom area is very conservative. The SS7 network has been used here for decades. It is very a reliable and closed network. This means a regular user has no access to it.
The IP network, in contrast, is open and not reliable, and telecoms will not convert to it if it won't handle at least the load that SS7 handles. This is why SCTP was developed. It tries:
The latest releases of Linux already have SCTP support.
我们现在已经在多个应用程序中部署了 SCTP，并且在各种家用路由器中遇到了 SCTP 支持的重大问题。 他们根本就没有正确处理 SCTP。 我认为这主要是一个性能问题（SCTP 协议规范要求重新计算整个数据包的校验和，而不仅仅是标头）。
与许多其他有前途的协议一样，在 D-link 和 Netgear 修复其破损的 NAT 盒之前，SCTP 不幸地陷入了困境。
We have been deploying SCTP in several applications now, and encountered significant problem with SCTP support in various home routers. They simply don't handle SCTP correctly. I believe this is primarily a performance issue (the SCTP protocol specification require checksums for the whole packets to be recalculated and not just for headers).
Like many other promising protocols SCTP is sadly dead in the water until D-link and Netgear fixes their broken NAT boxes.
SCTP 并不是很为人所知，也没有被大量使用/部署，因为：
SCTP is not very much known and not used/deployed a lot because:
SCTP 需要在应用程序中进行更多设计才能充分利用它。 比 TCP 有更多的选择，类似 Sockets 的 API 出现得更晚，而且还很年轻。 然而，我认为大多数花时间理解它的人（并且知道 TCP 的缺点）都会欣赏它——它是一个设计良好的协议，建立在我们大约 30 年的 TCP 和 UDP 知识之上。
需要思考的方面之一是流。 流在其中提供（通常，我认为您可以将其关闭）顺序保证（很像 TCP 连接），但每个 SCTP 连接可以有多个流。 如果您的应用程序的数据可以通过多个流发送，那么您就可以避免队头阻塞，即接收器因一个丢失的数据包而陷入饥饿状态。 实际上，可以通过同一连接进行不同的对话，而不会相互影响。
另一个有用的补充是多宿主支持——一个连接可以跨越两端的多个接口，并且可以处理故障。 您可以在 TCP 中模拟这一点，但是是在应用程序层。
适当的链路检测信号是任何使用 TCP 进行非瞬时连接的应用程序实现的第一件事，并且是免费的。
我个人对 SCTP 的总结是，它不会做任何其他方式（TCP 或 UDP）做不到的事情，并且有大量的应用程序支持。 它提供的功能是不必自己（糟糕地）实现该代码。
仅供参考，SCTP 被强制要求支持 Diameter（参见下一代 RADIUS）。 参见 RFC 3588
SCTP requires more design within the application to get the best use of it. There are more options than TCP, the Sockets-like API came later, and it is young. However I think most people that take the time to understand it (and who know the shortcomings of TCP) appreciate it -- it is a well designed protocol that builds on our ~30 years of knowledge of TCP and UDP.
One of the aspects that requires some thought is that of streams. Streams provide (usually, I think you can turn it off) an order guarantee within them (much like a TCP connection) but there can be multiple streams per SCTP connection. If your application's data can be sent over multiple streams then you avoid head-of-line blocking where the receiver starves due to one mislaid packet. Effectively different conversations can be had over the same connection without impacting each other.
Another useful addition is that of multi-homing support -- one connection can be across multiple interfaces on both ends and it copes with failures. You can emulate this in TCP, but at the application layer.
Proper link heartbeating, which is the first thing any application using TCP for non-transient connections implements, is there for free.
My personal summary of SCTP is that it doesn't do anything you couldn't do another way (in TCP or UDP) with substantial application support. The thing it provides is the ability to not have to implement that code (badly) yourself.
FYI, SCTP is mandated as supported for Diameter (cf RADIUS next gen). see RFC 3588
p1。 直接映射到 IPv4 上的 SCTP 需要 NAT 网关的支持，而 NAT 网关从未在任何地方广泛部署过，如果没有它，典型的 NAT 网关将只允许每个公共地址一次使用一台私有主机。
p2。 通过 UDP/IPv4 映射的 SCTP 允许每个公共地址有更多的私有主机，但众所周知，IPv4/NAT 网关中的 UDP 映射很难建立和维护，因为 UDP 是一种无连接传输，没有任何明确的状态供 NAT 跟踪。
p3。 直接映射到 IPv6 上的 SCTP 需要……嗯……IPv6。 您尝试过部署 IPv6 吗？ 如果是这样，您是否尝试过购买 IPv6 防火墙？ 支持SCTP吗？ 负载均衡器怎么样？ SSL 加速器？
p4。 最后，互联网上的许多内容几乎都受到 TCP 端口 80 和端口 443 的限制，因此任何类型的 SCTP 往往都会在这些方面失败。 因此，您会看到 IETF 中的 MPTCP 工作组所做的努力。
p1. SCTP mapped directly over IPv4 requires support in NAT gateways, which has never been widely deployed anywhere, and without it the typical NAT gateway will only permit one private host per public address to be using SCTP at a time.
p2. SCTP mapped over UDP/IPv4 allows more private hosts per public address, but UDP mappings in IPv4/NAT gateways are notoriously tricky to establish and keep maintained, due to the fact that UDP is a connectionless transport without any explicit state for a NAT to track.
p3. SCTP mapped directly over IPv6 requires... well... IPv6. Have you tried to deploy IPv6? If so, have you tried to buy an IPv6 firewall? Does it support SCTP? How about a load balancer? A SSL accelerator?
p4. Finally, a lot of the Internet is pretty much constrained to what can fit through TCP port 80 and port 443, so SCTP of any flavor tends to lose there. Hence, you see efforts like the MPTCP working group in IETF.
我们中的许多人很快就会使用 SCTP，因为 WebRTC 数据通道使用它在 UDP 之上创建类似 TCP 的可靠层 - SCTP over DTLS over UDP：https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-data-channel -13#section-6
Many of us will be using SCTP soon, since it's used by WebRTC datachannels to create a TCP-like reliable layer on top of UDP -- SCTP over DTLS over UDP: https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-data-channel-13#section-6