SCTP
Stream Control Transmission ProtocolSCTP is what you would design if you started transport again. It keeps TCP’s reliability but delivers whole messages rather than a byte stream, carries many independent streams in one association, and can hold that association open across several IP addresses at once.
SCTP is reliable like TCP, message-based like UDP — with multiple streams and multi-homing built in.
How it works
A signed cookie in the third message means the server keeps no state until the client proves it is real.
What you send is what the far end receives — no reassembling a stream into records yourself.
Both ends list several addresses; heartbeats watch them and failover is automatic.
The cookie handshake makes SCTP immune to SYN-flood-style state exhaustion, and multi-homing gives it failover no other common transport has — which is why telecom signalling runs on it.
What SCTP does, step by step
INIT, INIT-ACK with a signed cookie, COOKIE-ECHO, COOKIE-ACK — the server allocates nothing until step three.
Data chunks carry message boundaries and a stream number, so streams are delivered independently.
SACK reports exactly what arrived; only genuinely missing chunks are retransmitted.
Heartbeats probe the alternate addresses, and traffic moves to a healthy one if the primary fails.
In cybersecurity
SCTP fixed some of TCP’s weaknesses by design — but being unfamiliar to middleboxes means it is both under-inspected and often simply blocked.
The cookie handshake means a flood of INITs costs the server no memory at all.
Many firewalls and IDS don’t parse protocol 132, so SCTP traffic passes uninspected.
SCTP INIT scans find open services that a TCP-only scan misses entirely.
An association can move to an address the firewall policy never anticipated.
SCTP is plaintext; DTLS over SCTP is what WebRTC uses to secure it.
Most NAT gateways cannot translate it, which is much of why it stayed off the public internet.