Day 4 — CS Fundamentals December — About Networking — TCP vs UDP — A Duel
There are many many protocols which are studied under the subject of Networking and TCP and UDP are one of the most important protocols to look into.
But the way they both work is pretty differentiating and contrasting, and understanding those differences is very important because the knowledge of those differences will let you to know when to use one protocol and when NOT to use one protocol.
At times, in the software engineering interviews, the interviewers might ask you, “Do you think TCP is suitable for this use case? Why/Why not?”
So, this article will be focusing on explaining as well as differentiating between TCP and UDP, and also highlighting when to use which one.
Let’s dive in!
But wait, what is a protocol?
So, the sole purpose of a network is to transmit data from one point to other. Now, there might be a plethora of requirements and variations for transmitting data from one point to another. One approach of transmission can be suitable for fast transmission but error prone too. One approach can be suitable for safe and secure transmission but slow. One approach can be suitable for transmitting only media files and so on.
So, when transmitting data across a network, we define a set of rules and policies as to how that data is going to be transmitted and these rules are called protocols.
TCP
First of all, it is “Transmission Control Protocol”
It is a connection-oriented protocol.
What do I mean by connection-oriented protocol, you ask?
Basically, before sending data packets from sender to receiver, TCP establishes a connection between sender and receiver through a process called TCP 3-Way Handshake. (Read more about it here). Hence, this is the connection-oriented nature of this protocol.
Now, instead of enlisting all the features of TCP’s and then telling its use case, I’ll just give a spoiler.
TCP.. is.. reliable, hands down!
Why?
It does the following things:
Reliability
TCP makes sure that the data sent from sender is always delivered to the receiver rightfully. Whenever a data packet is sent from sender, it waits for an acknowledgement from receiver whether it received that data packet. Now, there can be three possibilities.
First, data packet successfully reaches the receiver and receiver sends positive acknowledgement to the sender and everything’s cool.
Second, the data packet gets lost in the middle of transmission, then, receiver won’t receive the packet and sender will never get an acknowledgement and after a timeout period, sender will resend the packet assuming the packet didn’t reach the receiver.
Third, the data packet reaches the receiver but it is corrupted, so, the receiver sends a NEGATIVE acknowledgement and hence, the sender re-sends that data packet.
Flow Control — My personal favorite
TCP makes sure that it doesn’t cause network congestion at the receiver by allowing sender to keep on sending data packets quickly and meanwhile, receiver not being able to process those packets that quickly.
For this, TCP maintains a sender buffer and a receiver buffer.
The data packets sent are received at the receiver buffer and then, the receiver keeps on polling the receiver buffer so as to get and process the packets.
The moment receiver buffer gets full, it notifies the sender/sender buffer to stop sending packets.
And the moment receiver buffer gets available, it again notifies the sender/sender buffer to start sending the packets again.
How does this happen, you ask?
Whenever a packet is received on the receiver side, the receiver sends an acknowledgement. Along with acknowledgement, it also sends details about how much capacity is left in the buffer, hence, from the acknowledgement, the sender can interpret whether there is any space left in the reverse buffer or not and hence, should a new packet be sent or not.
Maintaining the order of packets
By the process of sequencing, TCP makes sure that the receiver receives all the packets in the right order.
If the receiver receives a packet out of order, it will send a “selective acknowledgement” and sender would re-send all the packets in between that selective acknowledgment so as to retain the order of the packets.
So, yeah! Hence, TCP is preetttyy reliable!
UDP — This is not gonna take much time
First of all, it is “User Datagram Protocol”
It is a connectionless protocol.
Unlike TCP, it does not care about establishing a connection between sender and receiver. It straight away starts sending packets.
Unlike TCP, it is NOT a reliable protocol as:
- It does not care if the packets are lost in between the transmission.
- It does not care if the packets received are corrupted.
- It does not care if the packets received are out of order.
All it cares about is just, “sender is sending a continuous stream of packets”.
“So, Yash! Why the heck would anyone use UDP?”
One word answer — Speed
TCP gets engaged in a LOT of latency and overhead in order to establish and maintain connection, flow control, reliability and ordering of data packets.
UDP does not care about any of them and hence, involves no latency associated and hence, it keeps things fast. And in some use cases (which I am going to discuss next), speed is much much more important than reliability.
So, yeah! Hence, UDP is preetttyy quick!
When to use what
TCP — Reliability
Use TCP when reliability is very important and speed is relatively not much of a concern.
For example
- Our sweet World Wide Web (HTTP, HTTPS) — Obviously, you would want a website to be perfectly loaded even if it takes 1 or 2 seconds more to load. So, reliability is important hence, TCP
- File Transfer Protocol (FTP) — Just imagine sending a picture to your friend through FTP and for the sake of quick transfer, the image gets messed up. Doesn’t make much sense right! Hence, TCP.
- Secure Shell (SSH) — Imagine sending the right command to another computer through SSH but still it says wrong command and now, you’re pulling your hair. Sounds horrible right? Hence, TCP.
UDP — Speed
Use UDP when speed is the most important concern even if it means to sacrifice reliability and a loss of few packets.
For example,
- Our beloved Livestreams — In livestreams, even if it lags or messes up for 2–3 seconds, it is okay. But it is not okay if it shifts from realtime just to maintain video quality because then it won’t be “live”. So, speed is very important here and hence, UDP.
- Online games — Even if the online game lags or freezes for a few seconds, it is okay but it must must maintain the realtime sync otherwise we all know that gamers become more hostile than terrorists when they are enraged. Hence, to save the world from the terror of enraged online gamers, UDP is used for online games.
That’s it!
Thanks a lot for reaching till here!
I hope you understood every bit of this article and if you liked it, do give it some claps :)
Stay tuned for another article which is going to come tomorrow associated with some other interesting CS fundamental.
Find me on
LinkedIn — https://www.linkedin.com/in/yashvardhan-kukreja-607b24142/
GitHub — https://www.github.com/yashvardhan-kukreja
Email — yash.kukreja.98@gmail.com
Adios!
