You’ll learn more about the strengths of the SCTP, TCP, and UDP protocols by comparing them. The audio recording has much more detail about the following five questions.
- Is the protocol connection oriented? Both SCTP and TCP are but UDP does not establish connections.
- Is the data transfer reliable? In a way, this is related to the first question. I already said that UDP is not reliable. And both SCTP and TCP offer reliable data transfer.
- Are the data packets ordered? TCP guarantees that a receiver will receive packets in the order they were sent. UDP makes no guarantee at all about order. SCTP lets you choose.
- Is the protocol message based? With UDP, you’re sending packets of self-contained information. You have to because there’s no ordering and no connection to relate one message to the next. With TCP, you establish a connection and then just start sending data. SCTP acts more like UDP in this sense because it preserves message boundaries.
- Does the protocol support flow control and congestion control? Both SCTP and TCP support flow control and congestion control. UDP does not help with either of these.
Listen to the full episode for more details or you can also read the full transcript below.
Transcript
The previous episode introduced the SCTP protocol and explained a couple big problems that it solves. Make sure to listen to that episode first as well as some of the other recent episodes.
For this episode, I’m going to just ask 5 questions and talk a little about each one while comparing the three protocols. We learn things by establishing relationships with other concepts and my goal here is to give you many different ways to relate these protocols with each other. You should end up understanding all of them even more.
#1 Is the protocol connection oriented? Both SCTP and TCP are but UDP does not establish connections. This is why UDP is easier and quicker to send information. But because there’s no connection, it’s like yelling information out a window and hoping somebody will hear you. SCTP uses a more security conscious connection than TCP. A common problem with TCP connections is that they can be misused in what’s called a SYN flooding attack. It works like this: you want to establish a connection with a server computer so you send a synchronize message to the server. This is often just called a SYN message. The server goes ahead and gets the connection ready and sends a SYN-ACK message and then waits for you to reply with just an ACK message. This is called a 3-way handshake because it takes three messages to setup the connection. But what if you either don’t send the third message or it gets lost? Well, the server will wait a while just in case the third message is a bit delayed. But while the server is waiting, it keeps the connection ready for you. That open connection uses some amount or resources on the server. What if a bad person sends a bunch of SYN messages? Enough to cause the server to run out of memory or start turning away other visitors? This is a denial of service attack cause by a flood of SYN messages. SCTP fixes this by introducing a 4-way handshake that uses signed cookies to prove the identity of the original request and also doesn’t hold connections open until the proper replies have been made.
#2 Is the data transfer reliable? In a way, this is related to the first question. I already said that UDP is not reliable. And both SCTP and TCP offer reliable data transfer. This means that when you send information, both SCTP and TCP will keep trying to send any packets that get lost or are damaged. But SCTP has another trick here. Maybe you have some information that’s more like a regular status update. If you miss an update, then it’ll be retried. But do you still need to keep retrying when the next update is ready? If something new comes along that replaces an old packet, then if that old packet is still having problems, it’s better to just forget about it and move on to the newer packet. TCP would never let you do this. It will keep trying to deliver that old packet as long as possible. And UDP would forget about a missing or damaged packet right away. So SCTP offers reliable delivery but with a more common-sense approach.
#3 Are the data packets ordered? TCP guarantees that a receiver will receive packets in the order they were sent. UDP makes no guarantee at all about order. If you don’t care about order, then UDP is a good choice. And if you do care about order but don’t want to manage this yourself, then you can let TCP take care of it for you. SCTP lets you choose. If you can’t care about ordering but still want to make sure that anything you send will be received, then SCTP will behave like a more reliable UDP. Or maybe ordering is something you can deal with yourself. When I first described ordering in TCP, I used an example of a document without any page numbers. But what if your document does have page numbers already? With SCTP, you can reliably send information and not worry about slowing things down because the protocol is trying to keep everything ordered. If something arrives out of order, you can fix it yourself. But SCTP adds another aspect to this by supporting multiple separate streams. Each stream is separate and ordered but between streams, information can arrive in different orders. This is useful if you want to send many separate streams of information and make sure that SCTP takes care of the ordering for you within each stream. Maybe you want to send a hundred files. Each file is separate. The important thing abut ordering is really just within each file. You don’t want your files to arrive all jumbled up. But you don’t really care if the second file completes the transfer ahead of the first file.
#4 Is the protocol message based? With UDP, you’re sending packets of self-contained information. You have to because there’s no ordering and no connection to relate one message to the next. This means that if you send 5 UDP messages, then the receiver will receive 5 separate messages. That is, of course, assuming that they all arrive. But TCP is different because it’s based on a stream. Not quite like the streams I’ve been talking about with SCTP. With TCP, you establish a connection and then just start sending data. And TCP will determine how to divide or even combine the data into packets. This means you could send some data in as a single message through TCP but the receiver will need to read multiple times to get it all. Or it could go the other way and you send several small bits of data through TCP and the receiver can read them all with just one read. SCTP acts more like UDP in this sense because it preserves message boundaries. So if you send a message in SCTP that’s a hundred bytes long, then that’s exactly what will be received.
And #5 Does the protocol support flow control and congestion control? Both SCTP and TCP support flow control and congestion control which helps deal with slow machines trying to communicate with fast machines or with network traffic overwhelming routers. UDP does not help with either of these.