Search for a command to run...
Not all data travels the same way. Learn the difference between the internet’s two main transport protocols, and how they relate to HTTP.
No comments yet. Be the first to comment.
These are the assignments or knowledge dumps I decide to write for the "Chai aur Code's web Dev Cohort 2026"
Leave the graphical interface behind. Learn how to talk directly to servers and APIs from your command line.
RAG helps LLMs answer questions using your own data, but it doesn't guarantee correct answers. Here's how the pipeline works and where it commonly breaks down.
Imagine asking an AI, "Write a blog," versus "Act as an SEO expert and write a 1,000-word blog on AI safety formatted in markdown." The difference in the resulting output is night and day. A prompt is
Spotify and Apple Music make it incredibly easy to showcase your live listening habits on your website. YouTube Music? Not so much. After doing some setup you can do an API call and fetch your account
Arthur C. Clarke's famous third law: "Any sufficiently advanced technology is indistinguishable from magic" perfectly captures how the pace of human innovation works. From carrying supercomputers in o
Why HTTP is amnesiac, the difference between transport and state, and how to choose the right auth strategy for your Node.js app.
When you build a web application, you spend most of your time thinking about the data itself: the JSON response from your API, the HTML of your landing page, the video file you are streaming.
But once that data leaves your server, it has to traverse a chaotic, noisy network of physical cables and routers to reach your user. The internet needs rules for how to move those bytes. If it didn't have rules, packets would collide, get lost, or arrive completely out of order, and your webpage would look like a scrambled puzzle.
At the transport layer of the internet, we rely on two primary protocols to move our data: TCP and UDP.
They both have the exact same job, moving bytes from Point A to Point B. But they take completely opposite approaches to how they do it. As a developer, understanding the difference between them, and knowing exactly where HTTP fits into the picture, is crucial for designing scalable systems.
TCP (Transmission Control Protocol) is the internet’s reliable workhorse.
When you use TCP, you are prioritizing correctness over speed. TCP refuses to send data blindly. Before it sends a single byte, it reaches out to the receiving server and performs a handshake to establish a dedicated connection.
Once the data starts flowing, TCP acts like a meticulous certified courier. It numbers every single packet of data. When the receiver gets a packet, it must send a "receipt" (an acknowledgement) back to the sender. If the sender doesn't get that receipt, it assumes the packet was lost and resends it.
The Analogy: Sending a legally binding contract via a courier. The courier makes sure the recipient is home, hands the document over, gets a signature, and reports back to you. It takes a little longer, but you are 100% certain the document arrived intact.
When to use TCP: Use TCP whenever losing data is unacceptable.
Loading a webpage (Missing an HTML tag breaks the page).
Downloading a file (A missing megabyte corrupts the file).
Sending an email or a text message.
Querying a database.
UDP (User Datagram Protocol) is the rebellious, lightning-fast alternative to TCP.
When you use UDP, you are prioritizing time over correctness. UDP does not perform a handshake. It does not establish a connection. It does not number its packets, and it absolutely does not wait for receipts. It just grabs your data, throws it at the destination IP address as fast as the network will allow, and immediately forgets about it.
Because it strips away all the overhead of handshakes and acknowledgements, UDP is incredibly fast. But it is "fire and forget." If a router drops a packet along the way, UDP doesn't care. That data is gone forever.
The Analogy: A radio broadcast. The radio station blasts the signal out into the world. They don't know if you have your radio turned on, they don't know if you drove through a tunnel and missed ten seconds of the song, and they aren't going to rewind and replay it for you.
When to use UDP: Use UDP when data is time-sensitive, and losing a little bit of it doesn't matter.
Video Calls (Zoom/Meet): If you lose a packet of video data, your screen might glitch for a millisecond. If we used TCP, the video would constantly freeze while waiting for the dropped frame to be re-transmitted. We'd rather skip the frame and keep the live conversation going.
Live Multiplayer Gaming: Your character's position is updated 60 times a second. If update #42 gets lost, it doesn't matter, because update #43 is already arriving.
DNS Lookups: Resolving a domain name needs to be instantly fast. If the UDP request fails, the browser just asks again.
When beginners learn about TCP and UDP, a common question immediately comes up: "Wait, I thought the web used HTTP? Is HTTP the same as TCP? Did HTTP replace it?"
No. They are entirely different layers of the networking stack. They do not compete; they collaborate.
To understand the relationship, we need to separate the Transport Layer from the Application Layer.
TCP is the Transport Layer. It is the pipeline. It doesn't care what data it is carrying. It just guarantees that whatever you put into the pipe will come out the other side intact and in order.
HTTP is the Application Layer. It is the language spoken inside the pipeline.
Imagine you are writing a letter to a friend. You write the letter in English. You use nouns, verbs, and punctuation. Then, you put the letter in a FedEx truck.
HTTP is the English language. It defines verbs like GET and POST, and headers like Content-Type: application/json.
TCP is the FedEx truck.
When your browser wants to fetch a web page, it first uses TCP to establish a reliable connection to the server. Once that connection is open, the browser sends an HTTP message through the TCP connection.
[ How HTTP and TCP Layer Together ]
1. Browser: "Hello server, let's open a TCP connection." (SYN)
2. Server: "I'm ready, TCP connection open." (SYN-ACK)
------------------------------------------------------
[ The pipeline is now open. Now we speak HTTP. ]
3. Browser (via TCP): "GET /index.html HTTP/1.1"
4. Server (via TCP): "HTTP/1.1 200 OK \n\n <html>..."
HTTP cannot replace TCP because HTTP has no idea how to navigate routers, handle lost packets, or manage network congestion. HTTP relies on TCP to do the dirty work of reliable delivery.
Here is a quick reference table to solidify the differences between the two transport protocols:
| Feature | TCP (Transmission Control Protocol) | UDP (User Datagram Protocol) |
|---|---|---|
| Connection Type | Connection-oriented (requires a handshake). | Connectionless (fire and forget). |
| Reliability | Guaranteed delivery. Resends lost packets. | Unreliable. No receipts, no retransmissions. |
| Ordering | Guarantees packets arrive in the exact order sent. | Packets may arrive out of order. |
| Speed | Slower (due to overhead and acknowledgements). | Very Fast (no overhead). |
| Overhead | High. | Low. |
| Everyday Analogy | Certified Courier Delivery. | Radio Broadcast / Megaphone. |
| Real-World Uses | Web pages (HTTP), Email, File transfers (FTP). | Video streaming, VoIP calls, Live gaming. |
You don't need to write custom TCP or UDP packets to be a web developer. But you do need to know the physics of the environment you are building in. When you know that HTTP sits on top of TCP, and that TCP requires a multi-step handshake to start, you suddenly understand why making 50 separate API calls to a server is slow, and how you can optimize it.
Understand the pipeline, and you will write better applications.