TCP vs UDP: When to Use What, and How TCP Relates to HTTP
Understanding reliable🛡️ vs fast⚡ data transfer on the Internet
The Internet is basically a globally connected network that follows some common rules. These common rules are called protocols in computer language.
But the Internet becomes the World Wide Web when data transfer starts happening between computers. To transfer this data, there must be a set of agreed rules that ensures glitch-free and conflict-free communication across the World Wide Web. Some of these data transfer rules are exactly what we will be looking at today.
Firstly, we need to understand that if these rules were not present, then we would not be able to send and receive data smoothly between computers and devices. This is because every computer and every network would follow its own rules. Think of it like a country in which there are no traffic rules-people can drive on the left side or right side without speed limits, no rules for traffic signals, some would stop at green light, some would run their vehicles at red light, and some might even stop at green and go at red. Imagine such a scenario: a disastrous chaos would be created, accidents would happen, damages to vehicles would happen, and more importantly, people would lose their lives. No one would be able to reach their destination on time and in a safe condition, and ultimately havoc would be created on every road carrying traffic.
A similar condition would happen to our Internet if globally accepted rules were not laid down. Our data, which travels in the form of packets, frames, and bits, would get lost. People would not be able to communicate, because every system and network would follow its own rules and would not accept data in any other format than its own. In short, a paralysed network would be formed which is of no value. Hence, to avoid such a situation, a set of rules for data transfer are made and accepted globally. It is organisations like ICANN and similar entities that oversee regulations and laws related to the Internet that need to be implemented globally for smooth functioning.
In this blog, we will be seeing Transport layer protocols, i.e., TCP and UDP.
| TCP | UDP |
| It is reliable | It is less reliable |
| It follows order, i.e., numbering of the segmented data happens here | It does not emphasise ordering the data; it is more about speed, order does not matter much |
| Loss detection mechanism is present, so if a packet is lost it gets notified | No loss detection mechanism; if a packet gets lost, it still carries on |
| Retransmission happens if a packet is not received | No retransmission in UDP if a packet is not delivered |
| Follows congestion control algorithm, to ensure smooth delivery of data packets | No congestion control algorithm is followed |
| Follows three-way handshake, hence relatively slow | Quite fast and does not follow a check like handshake |
| Used when we need full data. Example: HTTP requests are primarily made over TCP. E-commerce sites for showing their landing page and products use TCP at the transport layer | Used when we need data quickly. Example: DNS queries use UDP if the size is less than 512 bytes. Live streaming of matches like Hotstar cricket matches uses UDP at the transport layer |
So, in short, if we want full data to be delivered to the client and don’t want any data to get lost mid-way (even if it becomes a bit slow), we use TCP. Generally, all (exceptions depending upon use case) HTTP/HTTPS uses TCP as the transport layer protocol.
Whereas, when we don’t mind a few data packets getting lost because we want the data to be delivered quickly (irrespective of the fact that some data gets lost in between), then we use UDP. Like, we would not mind a few frames dropping in a live cricket match as long as we are getting almost real-time broadcasting of the match.
Now, TCP and UDP are transport layer protocols which run underneath the application layer protocols. So, an application layer protocol is what the client deals with at the application layer. At the application layer, whatever the client does, it gets a result/response. But in order to get that response for the request being made by the client, we need a whole layer of protocols internally that does the labour-intensive job of sending and receiving data to and fro between the system and the server. These labour-intensive tasks follow a set of rules, and the ones that specifically handle transport are called transport layer protocols. Hence, application layer protocols like HTTP run on top of transport layer protocols like TCP.
➤ HTTP is an application-layer protocol that follows a request-response architecture, i.e., the client sends a request for something and receives the response as an answer to that request. This response is mostly text-based and is stateless, meaning it does not remember anything. What this means is that the server does not remember what previous request the client made—each request is treated as a separate and completely new entity.
And this brings us to a helpful insight on why HTTP does not replace TCP, because HTTP operates only at the application layer, while TCP works at the operating system’s transport layer. The job of TCP is to transport the request correctly from higher levels down to the network layer so that proper routing can happen. It breaks the request into pieces called segments (in TCP), attaches ports to it (both sender’s and receiver’s port, like an address of which application is making this request and where exactly on the server this request needs to be delivered), and then transfers it to the network layer via multiplexing. Hence, HTTP does not replace TCP; instead, both work in synchronization to execute tasks.
➤ Bursting a myth: A lot of people feel that HTTP and TCP are the same. It is not so. As discussed above, HTTP and TCP run at two different layers, work in synchronization with each other, and are not protocols of the same layer.
➤ Extra stuff: In case you are not aware of the OSI model, here it is. The layers which we have been talking about all over the blog are basically part of the OSI model, contains seven layers:
Application layer
Presentation layer
Session layer
Transport layer
Network layer
Data link layer
Physical layer
