208

我最近查阅了 Richards Stevens 的《UNIX Network Programming, Vol. 1》一书，发现除了 TCP 和 UDP 之外还有第三种传输层标准：SCTP。

总结：SCTP 是一种传输层协议，它像 UDP 一样是消息驱动的，但像 TCP 一样可靠。这是来自 IBM DeveloperWorks 的简短介绍。

老实说，我以前从未听说过 SCTP。我不记得在任何网络书籍中读过它或在我上过的课程中听说过它。阅读其他提到 SCTP 的 stackoverflow 问题表明，我并不是唯一一个缺乏知识的人。

为什么 SCTP 如此不为人知？为什么用的不多？

4

11 回答 11

103

事实上，SCTP 主要用于电信领域。传统上，电信交换机使用 SS7（7 号信令系统）来互连电信网络中的不同实体。例如-电信提供商的用户数据库（HLR），带有交换机（MSC），用户也被连接（MSC）。

电信领域正在向更高速度和更可达的环境发展。其中一项更改是用一些更优雅、快速和灵活的基于 IP 的协议来替换 SS7 协议。

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

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:

  • to mimic all advantages of the SS7 network accumulated over the decades.
  • to create a connection-oriented protocol better than TCP in speed, security, and redundancy

The latest releases of Linux already have SCTP support.

于 2009-07-23T14:27:21.057 回答
72

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.

于 2011-09-09T09:09:11.647 回答
56

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

   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.
于 2009-09-14T11:25:25.700 回答
54

SCTP is not very much known and not used/deployed a lot because:

  • Widespread: Not widely integrated in TCP/IP stacks (in 2013: still missing natively in latest Mac OSX and Windows. 2020 update: still not in Windows nor Mac OS X)
  • Libraries: Few high level bindings in easy to use languages (Disclaimer: i'm maintainer of pysctp, SCTP easy stack support for Python)
  • NAT: Doesn't cross NAT very well/at all (less than 1% internet home & enterprise routers do NAT on SCTP).
  • Popularity: No general public app use it
  • Programming paradigm: it changed a bit: it's still a socket, but you can connect many hosts to many hosts (multihoming), datagram is ordered and reliable, erc...
  • Complexity: SCTP stack is complex to implement (due to above)
  • Competition: Multipath TCP is coming and should address multihoming needs / capabilities so people refrain from implementing SCTP if possible, waiting for MTCP
  • Niche: Needs SCTP fills are very peculiar (ordered reliable datagrams, multistream) and not needed by much applications
  • Security: SCTP evades security controls (some firewalls, most IDSes, all DLPs, does not appear on netstat except CentOS/Redhat/Fedora...)
  • Audit-ability: Something like 3 companies in the world routinely do audits of SCTP security (Disclaimer: I work in one of them)
  • Learning curve: Not much toolchain to play with SCTP (check the excellent withsctp that combines nicely with netcat or use socat, 2020 edit: nmap supports it for a few years now )
  • Under the hood: Used mostly in telecom and everytime you send SMS, start surfing the net on your mobile or make phone calls, you're often triggering messages that flow over SCTP (SIGTRAN/SS7 with GSM/UMTS, Diameter with LTE/IMS/RCS, S1AP/X2AP with LTE), so you actually use it a lot but you never know about it ;-) 2020 edit: it's being removed from the core 5G network (no more Diameter, HTTP/2 instead) and will be only used in the 5G radio access network between antennas and core.
于 2013-11-29T17:20:07.347 回答
15

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.

于 2013-03-01T20:31:24.907 回答
13

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

于 2013-03-02T13:06:45.280 回答
6

阅读SCTP Wikipedia 页面，我想说主要原因是 SCTP 是一个非常年轻的协议（在 2000 年提出），目前主流操作系统（Windows、OS X、Linux）不支持。

如果“非常年轻”对您来说不合适，请考虑一下IPV6：“2008 年 12 月，尽管标志着它作为标准跟踪协议的 10 周年，但就全球普遍部署而言，IPv6 仍处于起步阶段。”

于 2009-07-23T13:16:11.073 回答
3

SCTP is used extensively in the 4G LTE network where Diameter is used for AAA.

于 2014-05-20T21:52:12.660 回答
2

它可能不为人所知，但它并没有被使用。最近在IETF上发布了一份关于使用 SCTP 作为 HTTP 传输层协议的草案。

于 2009-07-23T13:17:30.090 回答
2

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

于 2014-11-19T16:19:11.263 回答
-1

sctp 来得太晚了，很多情况下 TCP 就够用了。

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

于 2009-07-23T13:21:26.450 回答