我最近看了Richards Stevens写的“UNIX网络编程,Vol. 1”,我发现除了TCP和UDP之外还有第三个传输层标准:SCTP。
概要:SCTP是一种传输级协议,它像UDP一样是消息驱动的,但像TCP一样可靠。下面是来自IBM DeveloperWorks的简短介绍。
老实说,我以前从未听说过SCTP。我不记得在任何网络书籍中读到过它,也不记得在我上的课上听说过它。阅读其他提到SCTP的stackoverflow问题表明,我并不是唯一一个缺乏这种知识的人。
为什么SCTP如此不为人知?为什么不怎么使用呢?
事实上,SCTP主要用于电信领域。传统上,电信交换机使用SS7 (Signaling System No. 7)实现电信网络中不同实体之间的互连。例如,电信供应商的用户数据库(HLR),通过交换机(MSC),用户也被连接(MSC)。
电信领域正在向更高的速度和更可达的环境发展。其中一个变化是用一些更优雅、更快、更灵活的基于ip的协议取代SS7协议。
电信领域非常保守。七号信令网络在这里已经使用了几十年。这是一个非常可靠和封闭的网络。这意味着普通用户无法访问它。
相比之下,IP网络是开放的,不可靠,如果它不能至少处理SS7处理的负载,电信公司就不会转换到IP网络。这就是开发SCTP的原因。它尝试:
模仿SS7网络几十年来积累的所有优势。
创建一个在速度、安全性和冗余方面优于TCP的面向连接的协议
Linux的最新版本已经支持SCTP。
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.
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不是很为人所知,也不是经常使用/部署,因为:
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.