TCP vs. UDP

Christoph Krassnigg
4 min readApr 4, 2021

Both the Transmission Control Protocol and the User Datagram Protocol are on the transport layer in the OSI-Model. The big difference between those protocols is how they secure that the data arrives. To cut a long story short, TCP guarantees data arrival, UDP does not.

This article aims to provide further details on how these two different protocols work and what they are used for.

What does TCP do exactly?

Opening a session

TCP does not just send any data out on the internet without having a connection first. So, the first step is to ensure that the receiver of the data exists. If the receiver does not answer, then TCP will not send out any data. The process looks like the following:

TCP: “Hello, are you there?” (SYN)
Receiver: “Yes, I am here.” (SYN-ACK)
TCP: “Alrighty, you will now get some data.” (ACK)

The first step is to send a synchronize message. The receiver now has a limited time frame to answer with a synchronize acknowledged message. If the receiver answer, then TCP responds with an acknowledgment message.

Sending data

If you send 100 messages to the receiver via TCP, those messages will arrive in order, which means the first message comes first, the second one arrives afterward, then the third one…

As I mentioned earlier, TCP also guarantees data arrival. If the receiver does not acknowledge all of those 100 messages from above, TCP will retransmit the missing messages.

The receiver does not need to acknowledge every message. During the opening of a session, the receiver and TCP could argue on, e.g., one acknowledgment for every 10th packet to save resources.

Closing session

To open a session, as explained above, TCP uses a three-way handshake method. To close one, it uses two two-way handshakes.

TCP: “Hello again, I want to close this session.” (FIN)
Receiver: “Sure, no problem” (ACK)
Receiver: “Hello there! I want to close this session.” (ACK)
TCP: “Okay, bye.” (ACK)

What does UDP do exactly?

UDP does not establish a connection, either does it guarantee the arrival of data. UDP sends the data and does not care if or how it arrives.

UCP: “Here is your data… either take it or leave it.”

Even if the receiver does not exist, UDP still sends the data.

Where do you use what?

Data sent via TCP always arrives, so why does UDP even exist? Let us only use TCP!

This is not how it works actually because in some use cases, UDP is the better choice. TCP generates an overhead, and more data is being transmitted than with UDP to ensure that arrival. Having that overhead takes more time to send the data.

A general example is video games. Most games out there use UDP for certain things because data arrival is not always necessary. As an example, player positions. Someone is playing a game with many players in a single world. Those players are moving fast. The game sends out the position of all players to all players, e.g., every 50 milliseconds. It is not crucial to miss one package because you will get a new one with the current data in some milliseconds again. Just wait for it. If the message arrives afterward, then the game dismisses it because it is already outdated.
However, other aspects of a game, like chat messages, are sent via TCP. It would not be enjoyable to have a conversation, and your responses are not arriving at your chat partner.

If you download a file from the web, then guaranteed data arrival in the correct order is essential. Imagine downloading a text file where everything is mixed up. Or software that you can’t open because it is corrupted. As you see, having TCP, which holds your back and guarantees necessary data's arrival, is essential.

Conclusion

If you care about data arrival, use TCP, otherwise UDP.

--

--

Christoph Krassnigg

Developer at block42. Student. Java fanatic. Loves to write about techy things.