Introduction

UDP and TCP are both transport protocols used for communication between different hosts. They’re part of the transport layer in the broadly-known OSI model. The transport layer is responsible for delivering data to the correct application processes over a network.

UDP and TCP combined together contribute to pretty much all traffic on the Internet no matter if you’re watching a movie on Netflix, browsing the web or checking your banking app.

Although both UDP and TCP are ultimately used for the same purpose (communication) there are many differences between them.

Before we jump into the comparison let’s quickly review both of the protocols.

UDP

UDP or the User Datagram Protocol is a simple connectionless protocol that can be used to send messages a.k.a. datagrams between different systems. UDP datagram consists of a header and a data section. The header consists of 4 fields: source port, destination port, length and checksum each one of them is 2 bytes which make the header size equal to 8 bytes.

UDP is fast as it doesn’t have to establish a connection before it can start sending data. On top of that, it doesn’t care about acknowledgements which results in overall less data being sent over a network. The other characteristic that makes it fast is no concept of congestion control, so the data is always sent immediately even if the receiver cannot keep up with the speed.

The main downside of UDP is the fact that it’s not reliable. The way how UDP sends messages is sometimes called fire and forget as the sender doesn’t care if the data was successfully delivered, it doesn’t attempt to resend lost messages and it doesn’t wait for any acknowledgements. On top of having a potential of not delivering all the data, the messages can also arrive in a different order to what they were sent in or they can contain duplicates. The only thing that UDP provides is integrity verification of the header and the payload that is implemented using checksums. If two systems want to communicate via UDP in a reliable way they would have to add reliability on the application level.

So what kind of applications use UDP?

UDP is used across different systems ranging from simple query-response protocols that don’t have to establish a connection at all, for example, DNS or NTP protocols to time-sensitive applications that prefer to drop messages instead of waiting for delayed packets caused by retransmission, for example, IPTV, VOIP or online games. The other group of systems that UDP is suitable for are broadcasting services where one message has to be delivered to multiple recipients which can be easily achieved with multicast that UDP supports. Some of the examples are service discovery systems or routing protocols.

It’s also worth noting that UDP cannot be used in situations when all data must arrive at the destination in the correct order, so sending an important file or an email via UDP may not be the best idea.

Now, let’s jump into the UDP’s biggest rival – TCP.

TCP

TCP or the Transmission Control Protocol is a complex, connection-oriented protocol that can be used for reliable communication between different systems. TCP divides data into chunks and adds a TCP header creating a TCP segment. TCP header consists of multiple fields including source and destination port, sequence number, acknowledgement number and checksum. The total minimum size of the TCP header is 20 bytes.

TCP as a connection-oriented protocol initiates communication by establishing a connection between two parties before data can be sent. It does it by using a mechanism called a three-way handshake. When parties decide they are done with sending data, the connection can be terminated by another mechanism called a four-way handshake, with each side of the connection terminating independently.

TCP is a reliable protocol as it provides multiple features for guaranteed data delivery. The main features are a retransmission of lost packets, congestion control, error detection, guaranteed ordering of packets and sending acknowledgements for delivered packets.

The main downsides are the usually lower speed of sending data and higher latency as data doesn’t always get sent out immediately. Also, overall more data is being sent over the network because of the acknowledgements.

TCP is one of the most commonly used protocols on the Internet. HTTP uses it, so whenever you’re browsing the web you’re using TCP. Other examples include FTP for file transfers, SSH for remote sessions and SMTP for sending emails.

Time for the main comparison.

UDP vs TCP

Let’s compare UDP and TCP one to one.

Summary

UDP and TCP protocols despite major differences are both extremely useful in their own way. They provide intrinsic trade-offs when it comes to reliability, speed and simplicity.

The key for choosing which one is more appropriate for our system is knowing those trade-offs and understanding our system requirements.

If you have any questions about UDP and TCP or any suggestions for the next posts/videos please comment down below.

Extra

TCP/IP Illustrated by Addison-Wesley Professional → https://amzn.to/2VNYG69

What is the Two Generals’ Problem?

The Two Generals’ Problem, also known as the Two Generals’ Paradox or the Two Armies Problem, is a classic computer science and computer communication thought experiment that we’re going to talk about in this post.

First of all, to avoid any confusion, we need to remember that the Two Generals’ Problem, although related to the Byzantine Generals’ Problem is not the same. Byzantine Generals’ Problem is a more general version of the Two Generals’ Problem and it’s often discussed when talking about distributed systems, fault tolerance and blockchain. We’ll be talking about it in the following post.

But now let’s move to the story of the two generals.

The story of the Two Generals

Let’s imagine two armies, led by two generals, planning an attack on a common enemy. The enemy’s city is in a valley and has a strong defence that can easily fight off a single army. The two generals have to communicate with each other to plan a synchronised attack as this is their only chance to win. The only problem is that to communicate with each other they have to send a messenger across the enemy’s territory. If a messenger is captured the message he’s carrying is lost. Also, each general wants to know that the other general knows when to attack. Otherwise, a general wouldn’t be sure if he’s attacking alone and as we know attacking alone is rather pointless.

Now, let’s go through a simple scenario. Let’s call our generals A and B and let’s assume everything goes perfectly fine. General A, who is the leader, sends a message – “Attack tomorrow at dawn”. General B receives a message and sends back an acknowledgement – “I confirm, attack tomorrow at dawn”. A receives B’s confirmation. Is this enough to form a consensus between the generals? Unfortunately not, as General B still doesn’t know if his confirmation was received by General A. Ok, so what if General A confirms General’s B confirmation? Then, of course, that confirmation has to be also confirmed and we end up with an infinite exchange of confirmations.

In the second scenario, let’s also assume that General A sends a message to General B. Some time has passed and General A starts wondering what happened to his message as there is no confirmation coming back from General B. There are two possibilities here. Either the messenger sent by General A has been captured and hasn’t delivered a message or maybe B’s messenger carrying B’s confirmation has been captured. In both scenarios, they cannot come to a consensus again as A is not able to tell if his message was lost or if it was B’s confirmation that didn’t get through. Again, we ended up in an inconsistent state which would result in either General A or B attacking by himself.

We can quickly realise that no matter how many different scenarios we try and how many messages we send we cannot guarantee that consensus is reached and each general is certain that his ally will attack at the same time. To make it even worse, there is no solution to the Two Generals’ Problem, so the problem remains unsolvable.

I hope you can clearly see an analogy to computers’ communication here.

How is this related to computer science and TCP?

Instead of two generals, let’s imagine two computer systems talking to each other. The main problem here is again the untrusted communication channel and inconsistent state between two machines. A very common example that always comes up when talking about the Two Generals’ Problem is the TCP protocol.

As we probably know, TCP uses a mechanism called 4-way handshake to terminate the connection. In this mechanism, a system that wants to terminate a connection sends a FIN message. The system on the other side of the communication channel replies with an ACK and sends its own FIN message which is followed by another ACK from the system which initialised termination. When all of those messages are received correctly, both sides know that the connection is terminated. So far it looks ok, but the problem here is again the shared knowledge between the two systems. When, for example, the second FIN is lost we end up with a half-open connection where one side is not aware that the connection has been closed. That’s why even though TCP is very reliable protocol it doesn’t solve the Two Generals’ Problem.

So maybe a pragmatic approach?

I’m happy you’re not giving up. Unsurprisingly, there was a number of people trying to solve unsolvable Two General’s Problem and they came up with a few practical approaches. The main assumption here is to accept the uncertainty of the communication channel and mitigate it to a sufficient degree.

Let’s go back to our generals. What if General A instead of sending only 1 messenger sends 100 of them assuming that General B will receive at least 1 message. How about marking each message with a serial number starting from 1 up to 100. General B, based on the missing numbers in the sequence, would be able to gauge how reliable the communication channel is and reply with an appropriate number of confirmations. These approaches, even though, quite expensive are helping the generals to build up their confidence and come to a consensus.

If sacrificing messengers is a problem, we can come up with yet another approach where the absence of the messengers would build up generals’ confidence. Let’s assume that it takes 20 minutes to cross the valley, deliver a message and come back. General A starts sending messengers every 20 minutes until he gets a confirmation from General B. Whenever confirmation arrives General A stops sending messengers. In the meantime, General B after sending his messenger with his confirmation awaits for the other messengers coming from General A, but this time an absence of a messenger builds up General’s B confidence as this is what the Generals agreed on.

In this case, we have a clear speed vs cost tradeoff and it’s up to us which approach is more suitable to our problem.

That’s the end of the story of the Two Generals. Time for a quick summary.

Summary

Two Generals’ Problem is a classic computer science problem that remains unsolvable.

It comes up whenever we talk about communication over an unreliable channel.

The main problem is an inconsistent state caused by lack of common knowledge

There are some pragmatic approaches to the Two Generals’ Problem.

Extras

Two Generals’ Problem was first published in 1975 in “Some Constraints and Trade-offs in the Design of Network Communications” paper and described a problem with communication between two groups of gangsters. If you want to read the original version check this link.