TCP vs UDP: The Basics
The internet runs on certain rules (protocols in technical terms) and one can say that they’re pretty strict. Whenever we do anything on the internet, be it send a message, watch a video, or comment on one, the data doesn’t simply “go” wherever we want it to. It follows certain rules and regulations which are agreed upon. These basically define how data is sent, received, and interpreted. Two of these rules are the topic of this article - TCP and UDP.
Introduction
TCP stands for Transmission Control Protocol and UDP for User Datagram Protocol. These are simply two different ways of transmitting data. Let us understand both in basic terms.
TCP is like a courier service (say Blue Dart, if you’re from India). It makes sure that your parcel or package:
Reaches the destination
Arrives in the order in which it was sent
Is returned to source if lost
Is acknowledged by the receiver
UDP is like a live announcement or broadcast. Data is sent out quickly, but:
There’s no guarantee it reaches
No confirmation from the receiver
No retries if something is lost
Both are used widely, the only thing is that it depends on the use case, or what you care about more: reliability or speed.
In the above diagrams, both TCP and UDP data flows are visualized. As you can see, TCP sets up the connection using a 3-way handshake - SYN, SYN + ACK, ACK (synchronize and acknowledge) - between client and server before data flow starts. After the data transmission ends, it has a similar procedure for ending the connection as well. But in UDP, the client simply sends a request to the server from which it wants data, and boom! The server just throws out data one-way without caring whether it is being received reliably or not.
What is HTTP?
HTTP (Hypertext Transfer Protocol) is an application-level protocol, not a data transmission protocol like TCP or UDP. HTTP defines:
How requests are made (
GET,POST)How responses are structured
Status codes like
200,404,500
In other words, HTTP describes what is being communicated—not how it travels across the network.
Let us touch upon the OSI (Open Systems Interconnection) model briefly to understand the relationship between HTTP and TCP. It was created by the ISO in 1984 to standardize network communications into seven distinct layers (Physical to Application).
For now, in the diagram above, only focus on application and transport layers. As you can see, the transport and application are two layers apart. HTTP sits at the application layer, and TCP sits at the transport layer.
In simple terms:
TCP handles safe delivery of data
HTTP defines the meaning of that data
So when you open a website:
TCP establishes a reliable connection
HTTP sends requests and receives responses over that connection
TCP ensures all the HTTP data arrives correctly
So, in conclusion, we can say that HTTP does not replace TCP, it runs on top of it. Both solve different problems.
TCP vs UDP use cases
Generally, TCP is used when correctness matters:
Loading web pages
Sending emails
File downloads
APIs and backend communication
Even if a small piece of data is missing or not in order, the result could be completely wrong—so TCP’s reliability is important.
Generally, UDP is used when speed matters more than correctness of data:
Live video or audio streaming
Online multiplayer games
Video calls
DNS lookups
In a video call, a frame skip is better than the whole call getting stuck waiting for missing data. UDP is okay with small losses as long as things are moving smoothly.
Notice I used the word “generally”. This means that there are exceptions to the rule. For example, with new custom/proprietary protocols (used by Zoom, for example), UDP’s reliability can be considerably increased, making it closer to TCP.
