为什么 SCTP 没有太多使用/知道答案

【问题标题】：Why is SCTP not much used/known为什么 SCTP 没有太多使用/知道
【发布时间】：2010-11-13 09:08:58
【问题描述】：

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

总结：SCTP 是一种传输层协议，它像 UDP 一样是消息驱动的，但像 TCP 一样可靠。这是short introduction from IBM DeveloperWorks。

老实说，我以前从未听说过 SCTP。我不记得在任何网络书籍中读过它或在我上过的课程中听说过它。阅读提到 SCTP 的 other stackoverflow questions 表明我并不孤单。

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

【问题讨论】：

+1 从未听说过 - 谢谢。
任何人都关心将 SCTP 与 ZeroMQ 进行比较（除了一个是协议，另一个是库 - 将它们视为解决问题的工具）。
我只是好奇：2013 年 3 月 1 日有什么问题/不同？为什么这一天这么多票？
@dmeister：因为I put you on Reddit。来自达姆施塔特的问候。
请不要写 3/1/2013。 “2013 年 3 月 1 日”、“2013 年 1 月 1 日”、“2013 年 3 月 1 日”中的任何一个都是优选的。只是不要以可能被误解的方式写月份和日期。

标签： networking tcp popularity sctp

【解决方案1】：

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

如果您觉得“非常年轻”不合适，请想想IPV6：“2008 年 12 月，尽管是标准跟踪协议的 10 周年纪念日，但 IPv6 在全球范围内的普遍部署方面仍处于起步阶段。”

【讨论】：

根据您链接到的维基百科文章，SCTP 在 Linux、Solaris、FreeBSD、HP-UX 等中实现。
链接的文章现在还说它可以在 OS X 和 Windows 上运行。

【解决方案2】：

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

【讨论】：

当你说“未使用”时，我想到了协议的实际用法。但是你只给出了一个草稿文件的例子，这可能会导致未来的实际使用。

【解决方案3】：

Sctp 来得太晚了，很多情况下 TCP 就足够了。

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

【讨论】：

【解决方案4】：

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

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

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

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

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

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

【讨论】：

具体来说，您应该查看 IETF 的“SIGTRAN”工作组的输出，该工作组编写了 SS7 和 SCTP 之间的映射。
可能 SCTP 在公共 Internet 上没有大量使用的主要原因是住宅 IPv4/NAT 网关需要能够感知 SCTP，以支持多个同时的专用端点和外部主机之间的多路复用关联。一旦 IPv6 过渡开始加速，SCTP 会变得更加有用。
@jameswoodyatt 有 SCTP over UDP 的库实现。它解决了消费级路由器的一些问题。
这根本不能回答问题。詹姆斯的回复包含的信息比答案实际包含的更多。
@jameswoodyatt 我用过的消费级路由器都支持它，甚至是一些相当老的路由器。问题是它没有通过常规 UI 暴露出来，所以你必须对系统做一些可怕的事情才能进入你可以配置它的地方。在我看来有些疏忽。

【解决方案5】：

SCTP 需要在应用程序中进行更多设计才能充分利用它。比 TCP 有更多的选择，类似 Sockets 的 API 来得比较晚，而且很年轻。不过，我认为大多数花时间理解它的人（以及知道 TCP 缺点的人）都会欣赏它——它是一个精心设计的协议，建立在我们约 30 年的 TCP 和 UDP 知识之上。

需要考虑的方面之一是流。流提供（通常，我认为您可以将其关闭）其中的顺序保证（很像 TCP 连接），但每个 SCTP 连接可以有多个流。如果您的应用程序的数据可以通过多个流发送，那么您可以避免由于一个错误放置的数据包而导致接收器饿死的线头阻塞。可以通过同一连接进行有效的不同对话，而不会相互影响。

另一个有用的补充是多宿主支持——一个连接可以跨越两端的多个接口，它可以应对故障。您可以在 TCP 中模拟这一点，但在应用层。

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

我对 SCTP 的个人总结是，它不会做任何其他方式（在 TCP 或 UDP 中）无法通过大量应用程序支持做的事情。它提供的功能是不必自己（糟糕地）实现该代码。

仅供参考，Diameter 支持 SCTP（参见下一代 RADIUS）。请参阅 RFC 3588

Diameter 客户端必须支持 TCP 或 SCTP，而代理和服务器必须同时支持两者。本规范的未来版本可能要求客户支持 SCTP。

【讨论】：

【解决方案6】：

我们现在已经在多个应用程序中部署 SCTP，但在各种家庭路由器中的 SCTP 支持方面遇到了重大问题。他们根本无法正确处理 SCTP。我认为这主要是一个性能问题（SCTP 协议规范要求重新计算整个数据包的校验和，而不仅仅是标头）。

与许多其他有前途的协议一样，在 D-link 和 Netgear 修复其损坏的 NAT 盒之前，SCTP 不幸地死在水中。

【讨论】：

哇，我不知道这个进入障碍。你是完全正确的——请参阅tools.ietf.org/html/draft-ietf-behave-sctpnat-05 以了解解决此问题的建议方法。这是同一主题的第三套互联网草稿......
你听起来很悲观——至少对于家用路由器来说。假设专业生产环境中使用的路由器确实支持它，SCTP 看起来仍然非常有用。有很多网络拓扑不离开数据中心的用例，在这种情况下，SCTP 应该是完美的。
@EugeneBeresovksy：我发布这个答案已经有几年了。我的印象是 SCTP 从那时起就没有取得重大进展。它仍在受控环境中的一些专业应用中使用，但在野外很少见。 Windows 和 Mac OS X 仍然缺乏开箱即用的 SCTP 支持。大多数防火墙和 NAT 设备所破坏的协议缺乏熟悉性和脆弱性，使人们不愿意使用它。
@pehrs 我想在数据中心内使用它，所以不涉及 NAT，也没有防火墙，除了操作系统内置的。在 Linux 服务器环境中，我希望它能正常工作。但即使使用 Windows，也有 SCTP 库 - 我相信无需修改操作系统。
SCTP 通常不会在 Linux 中启用，因为它缺乏采用，但即使在我的 Ubuntu Precise（旧）系统上，它也可以作为可加载模块使用。提供一个希望使用 SCTP 但会回退到 TCP（例如）的应用程序是一个类似于双栈的问题，但更痛苦。

【解决方案7】：

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

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

p3。直接在 IPv6 上映射的 SCTP 需要……嗯…… IPv6。您是否尝试过部署 IPv6？如果是这样，您是否尝试过购买 IPv6 防火墙？它支持 SCTP 吗？负载均衡器怎么样？ SSL 加速器？

p4。最后，很多 Internet 几乎都受限于 TCP 端口 80 和端口 443 可以容纳的内容，因此任何风格的 SCTP 往往会丢失在那里。因此，您会看到像 IETF 中的 MPTCP 工作组这样的努力。

【讨论】：

“你试过购买 IPv6 防火墙吗？它是否支持 SCTP”——通常免费分发的iptablessupports them just fine。不过我不是网络人，所以我不能说其余的。

【解决方案8】：

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

【讨论】：

忘了提到 WebRTC 的主要关注点是结合视频和音频流。它不打算用作消息中继。 turn/ice/stun 服务是 WebRTC 在其之上运行的技术的另一部分。但这些是 WebRTC 使用的技术。这些技术不是 WebRTC。

【解决方案9】：

SCTP 不太为人所知，也没有被大量使用/部署，因为：

广泛：未广泛集成到 TCP/IP 堆栈中（2013 年：在最新的 Mac OSX 和 Windows 中仍然原生缺失。2020 年更新：在 Windows 和 Mac OS X 中仍然没有）
库：易于使用的语言中很少有高级绑定（免责声明：我是 pysctp 的维护者，SCTP 对 Python 的简易堆栈支持）
NAT：不能很好地/根本不能通过 NAT（不到 1% 的互联网家庭和企业路由器在 SCTP 上进行 NAT）。
受欢迎程度：没有一般公共应用使用它
编程范式：有点改变：它仍然是一个套接字，但可以将许多主机连接到许多主机（多宿主），数据报有序且可靠，erc...
复杂性：SCTP 堆栈实现起来很复杂（由于上述原因）
竞争：多路径 TCP 即将到来，应该解决多宿主需求/功能，因此人们尽可能避免实施 SCTP，等待 MTCP
利基市场：需要 SCTP 填充非常特殊（有序可靠数据报、多流），很多应用程序不需要
安全性：SCTP 逃避安全控制（一些防火墙、大多数 IDS、所有 DLP，除了 CentOS/Redhat/Fedora 之外，不会出现在 netstat 上...）
审计能力：世界上大约有 3 家公司定期对 SCTP 安全性进行审计（免责声明：我在其中一家工作）
学习曲线：使用 SCTP 的工具链不多（查看优秀的 withsctp 与 netcat 或使用 socat 很好地结合，2020 年编辑：nmap 支持它几年了）
幕后：主要用于电信行业，每次发送 SMS、开始在手机上上网或拨打电话时，您经常会触发通过 SCTP 传输的消息（SIGTRAN/SS7 与 GSM/UMTS，Diameter 与LTE/IMS/RCS、S1AP/X2AP with LTE），所以你实际上经常使用它，但你永远不知道它；-) 2020 年编辑：它正在从核心 5G 网络中移除（不再是 Diameter，而是 HTTP/2）并且将仅用于天线和核心之间的 5G 无线接入网络。

【讨论】：

回复：“利基/不需要很多应用程序”。 Web 浏览器将从中受益，请参阅HTTP2 及其尝试在 TCP 之上实现 SCTP 免费提供的一些功能。大多数 HTTP 优化技术（分割、分片、内联、连接）将被 SCTP 冗余（几乎完全 - HTTP1 的浪费标头仍未解决）。对于具有连接池以启用对数据库或任何其他服务的并发访问的应用程序也是如此。换句话说：许多应用程序都非常需要 SCTP 的某些功能。
“没有一般公共应用程序使用它”：不再适用，因为 WebRTC 使用 SCTP。 “安全性：SCTP 逃避安全控制”——这更多的是“安全”控制的问题。如果它确实避免了这些检查，那么它将是恶意软件保持低调的绝佳协议。

【解决方案10】：

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

【讨论】：

【解决方案11】：

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

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

【讨论】：