为什么SCTP没有太多使用/已知
最近我查阅了Richards Stevens 编写的“UNIX Network Programming，Vol。1”一书，发现TCP和UDP之外还有第三种传输层标准： SCTP 。
简介：SCTP是一种像UDP一样的消息驱动的传输级协议，但像TCP一样可靠。 这是IBM DeveloperWorks的简短介绍 。
老实说，我从来没有听说过SCTP。 我不记得在任何networking书籍中读过这些东西，或者我在课堂上听说过这些东西。 阅读提到SCTP的其他stackoverflow问题表明，我并不孤单知识缺乏。
为什么SCTP如此不明？ 为什么没有太多的使用？
事实上，SCTP主要用于电信领域。 传统上，电信交换机使用SS7（ 7号信令系统 ）互连电信networking中的不同实体。 例如 – 电信运营商的用户数据库（HLR）和交换机（MSC），用户也被连接（MSC）。
电信领域正在向更高速度和更可达的环境转移。 其中一个变化就是用一些更优雅，快速和灵活的基于IP的协议取代SS7协议。
电信领域非常保守。 七号信令networking在这里已经使用了几十年了。 这是一个非常可靠和封闭的networking。 这意味着普通用户无法访问它。
相比之下，IPnetworking是开放的，不可靠的，如果不处理SS7处理的负载，电信将不会转换成它。 这就是SCTP开发的原因。 它尝试：
- 模仿几十年来积累的七号信令networking的所有优势。
- 在速度，安全性和冗余方面创build比TCP更好的面向连接的协议
Linux的最新版本已经有SCTP支持。
我们现在已经在几个应用中部署了SCTP，并且在各种家庭路由器中遇到了SCTP支持的重大问题。 他们根本不正确地处理SCTP。 我相信这主要是一个性能问题（SCTP协议规范要求重新计算整个数据包的校验和，而不仅仅是头）。
像其他许多有希望的协议一样，在D-link和Netgear修复他们破损的NAT盒子之前，SCTP可悲地死在水中。
SCTP需要在应用程序中进行更多的devise以充分利用它。 有比TCP更多的选项，类似于套接字的API稍后出现，而且还很年轻。 然而，我认为大多数花时间去了解TCP的人（以及谁知道TCP的缺点）非常感谢它 – 这是一个devise良好的协议，build立在我们对TCP和UDP的30多年的知识基础之上。
需要思考的一个方面是stream。 stream提供（通常，我认为你可以把它closures）在他们内部的订单保证（很像TCP连接），但每个SCTP连接可以有多个stream。 如果您的应用程序的数据可以通过多个stream发送，那么您可以避免由于一个数据包丢失导致接收器挨饿的线头阻塞。 通过相同的连接可以有效地进行不同的对话，而不会相互影响。
另一个有用的补充是多宿主支持 – 一个连接可以跨越两端的多个接口，并且应付失败。 你可以在TCP中模拟这个，但是在应用层。
正确的链接心跳，这是任何应用程序使用TCP非瞬态连接实现的第一件事情，是免费的。
我个人对SCTP的总结是，它没有做任何你无法以其他方式做的事情（在TCP或者UDP中），并且有大量的应用程序支持。 它提供的东西是不必自己实现这个代码（坏）的能力。
仅供参考，SCTP被规定为支持Diameter（参见RADIUS下一代）。 请参阅RFC 3588
Diameter客户端必须支持TCP或SCTP，而代理和
服务器必须同时支持。 本规范的未来版本可能
要求客户支持SCTP。
SCTP并不是很知名，也没有被大量使用/部署，因为：
- 普遍：未广泛集成在TCP / IP堆栈中（在2013年：在最新的Mac OSX和Windows中本身仍然缺less）
- 图书馆：简单易用的语言很less有高级别的绑定（免责声明：我是pysctp的维护者 ，SCTP对Python的简单堆栈支持）
- NAT：不能很好地跨越NAT（根本不足1％的互联网家庭和企业路由器在SCTP上做NAT）。
- 人气：没有一般的公共应用程序使用它
- 编程范例：它有点改变：它仍然是一个套接字，但你可以连接许多主机到多个主机（multihoming），数据报有序和可靠，erc …
- 复杂性：SCTP协议栈实施起来很复杂（由于上述原因）
- 竞争：多pathTCP即将到来，应该解决多宿主的需求/能力，所以如果可能的话，人们不要实施SCTP，等待MTCP
- 利基：需要SCTP填充是非常奇特的（有序的可靠的数据报，多stream），并不需要太多的应用程序
- 安全性：SCTP逃避安全控制（一些防火墙，大多数IDS，所有DLP，除了CentOS / Redhat / Fedora之外，不会出现在netstat上）
- 审计能力：像世界上3家公司一样对SCTP安全进行例行审计（免责声明：我在其中一个公司工作）
- 学习曲线：没有太多的工具链玩SCTP（检查优秀withsctp与netcat很好地结合或使用socat）
- 引擎盖下：主要用于电信，每次发短信，开始在手机上网或拨打电话，都会触发SCTP上的信息（SIGTRAN / SS7与GSM / UMTS，Diameter与LTE / IMS / RCS，使用LTE的S1AP / X2AP），所以你真的使用它很多，但你永远不知道它;-)
P1。 直接映射到IPv4上的SCTP需要NAT网关的支持，而NAT网关在任何地方都没有被广泛部署过。没有它，典型的NAT网关将只允许每个公共地址的一个专用主机同时使用SCTP。
P2。 通过UDP / IPv4映射的SCTP允许每个公有地址拥有更多的私有主机，但是IPv4 / NAT网关中的UDP映射在build立和维护上是非常棘手的，因为UDP是无连接的传输，没有任何显式的NAT状态。
P3。 直接在IPv6上映射的SCTP需要…好… IPv6。 您是否尝试过部署IPv6？ 如果是这样，你有没有试图购买IPv6防火墙？ 它支持SCTP吗？ 如何负载平衡器？ 一个SSL加速器？
P4。 最后，很多互联网几乎都限制在TCP端口80和端口443上，所以任何风格的SCTP都会丢失。 因此，您看到IETF中MPTCP工作组的努力。
我们中的许多人将很快使用SCTP，因为它被WebRTC数据通道用来在UDP之上创build类似TCP的可靠层 – 通过UDP上的DTLS创buildSCTP： https ： //tools.ietf.org/html/draft-ietf -rtcweb数据信道-13＃部-6-
阅读SCTP维基百科页面我想说的主要原因是SCTP是一个非常年轻的协议（2000年提出），目前主stream操作系统（ Windows ， OS X ， Linux ）不支持。
如果“非常年轻”对您来说似乎不合适，请考虑一下IPV6 ：“在2008年12月，尽pipe将其十周年定为标准跟踪协议，IPv6在全球范围内的部署方面还处于起步阶段。
这可能不是众所周知的，但不是没有用的。 最近在IETF上发表了一个关于使用SCTP作为HTTP的传输层协议的草案 。
SCTP广泛用于Diameter用于AAA的4G LTEnetworking。
关于所有关于商用路由器被破坏或缺lessSCTP支持的评论，问题是带有NAT的SCTP仍然是IETF的草案forms。 所以他们没有RFC规范来实现它。
Sctp出生得太晚了，对于很多情况TCP就足够了。
另外，据我所知大部分的用途是在电信领域。
