164: SCTP vs. TCP vs. UDP

Take Up Code - Un pódcast de Take Up Code: build your own computer games, apps, and robotics with podcasts and live classes

Categorías:

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 b

Visit the podcast's native language site