TCP vs UDP

CertBrosCisco CCNA

TCP vs UDP. What’s the difference? Is one better than the other? Let’s answer these questions.

So, let’s look back to our TCP/IP model, which should hopefully look familiar to you now.

When sending data, we start at the top of the model and work our way down.

We’re going to ignore the application layer as it’s largely out of our control. Instead, we’ll start at the transport layer.

The two primary protocols at this layer are TCP and UDP.

A network application has to choose how to send its data. That choice comes down to reliable or unreliable transmission.

Both reliable and unreliable have their benefits and drawbacks.

First, let’s look at TCP, or Transmission control protocol.

TCP (Transmission Control Protocol)

The first thing to understand is when we send data, a file, for example, it’s not sent all as one piece. It actually sent in lots of different pieces of data.

The receiving computer then collects these pieces, puts them all together and then spits out the file.

That’s fine. But what happens if some of the data we send is lost on the way?

The receiving computer won’t be able to put the pieces together and you’d probably end up with a corrupted file.

So this is the reason we need some method to reliably send data. Something that can resend and resolve missing or corrupted data. This is exactly what TCP does.

TCP is the most widely chosen option for transmitting data. This is because it can reliably send and receive data.

If there is a network blip and some of these segments are lost along the way, TCP can recover them. This means the user experience shouldn’t be compromised with half-loaded websites or corrupted documents.

The way TCP can provide such stable and reliable connections is in three ways.

  • Acknowledgements
  • Sequencing
  • Checksum

But, before any of that can happen, first we need to start a reliable connection. TCP does this by using what’s called a three-way handshake. It looks something like this.

First, the sending computer sends a message called a SYN. which is short for synchronize.

The receiving computer then replies with an ACK message, which is short for acknowledgement. It also includes a SYN message of its own. This message is called a SYN-ACK.

Lastly, the sending computer acknowledges again with an Ack message.

Now we have an open TCP connection. A similar process will be followed when closing this connection as well.

Sequence Numbers

OK, so the next step is to look at sequence numbers.

TCP will assign numbers to segments as they are sent. This way, the receiving device can collect these segments, reorder them correctly and determine if any segments are missing.

Acknowledgements

The messages are acknowledged when they are received. It’s almost like saying “Sending data” and the receiving computer says “Got it” and so on, and so forth.

So this is what happens when everything is working as it should. But the real beauty is when things don’t go to plan.

For example, if a segment is lost, and no acknowledgement is received, a re-transmission time kicks in.

The timer starts as soon a segment is sent and then stops when that acknowledgement has been received. The duration of the timer can vary and is calculated automatically.

Once the timer expires, the segment is retransmitted and then, hopefully, traffic flow goes back to normal.

Checksum

I also mentioned a checksum. The checksum is the result of a simple algorithm ran against the data.

If the data has been transmitted successfully, the checksum ran on the receiving side should match the sender’s checksum.

If there have been some problems along the way and some bits got messed up, then there will be a checksum mismatch and the segment will be discarded.

TCP Header

As we have already seen, a TCP header is added to the application data to create a segment.

This is what a TCP header looks like.

We have destination and source port numbers, the sequence number, acknowledgement number, and the checksum.

For now, there is no need to worry about the other bits of information.

UDP (User Datagram Protocol)

Unreliable communication comes in the form of UDP or User Datagram Protocol.

UDP has none of the error handling, sequencing or reliability of TCP.

You can think of UDP as a kind of machine gun of data. Just firing and firing not caring if data is lost or not.

It has one goal, and that goal is to send data.

So why would we ever even consider using UDP if it’s so unreliable?

Well, while TCP offers great connection reliability, it comes at a price of resource and latency.

This is great for the most common tasks such as web browsing, file transfers, etc where we don’t mind the latency issue in return for a stable connection.

Where UDP is very useful is in a situation when we need live, real-time connections. For example, voice calls, video calls, and gaming all need fast real-time connections.

We can handle a loss of voice data because who cares about a bit jitter in a voice call? On the other hand, if we start trying to resend voice data (Like TCP) then this could cause latency and make the call unusable.

UDP Header

Ok, so now let’s look at a UDP header.

As you can see, there is a lot let information here than the TCP header.

We only have the port numbers, the length of the data and a checksum.

The small header means less information but its lighter and quicker. Perfect for real-time traffic.

That’s it for the TCP and UDP, two ways to send data, for two different purposes.

Follow us