TCP and UDP are the two fundamental transport layer protocols that dictate how data moves across networks.
Let’s see them in action. Imagine you’re downloading a large file. Your browser uses HTTP, which itself relies on TCP.
# Simulating a TCP data stream (conceptual)
# In reality, this involves many packets, acknowledgments, and retransmissions.
# Sender:
# Sends data segments with sequence numbers.
# Example: Segment 1 (Seq: 0, Data: "Hello")
# Example: Segment 2 (Seq: 5, Data: "World")
# Receiver:
# Acknowledges receipt.
# Example: ACK for Segment 1 (Ack: 5) - indicates next expected byte is 5.
# Reassembles segments in order.
Now, consider a video call. It uses UDP.
# Simulating a UDP data stream (conceptual)
# Packets are sent without guaranteed delivery or order.
# Sender:
# Sends datagrams.
# Example: Datagram 1 (Payload: Video Frame A)
# Example: Datagram 2 (Payload: Video Frame B) - might arrive before A!
# Receiver:
# Receives datagrams as they arrive.
# If Datagram 2 arrives first, it might be displayed, or dropped if out of sync.
HTTP, the protocol you use to browse the web, is an application layer protocol. It sits on top of TCP. When your browser requests a webpage, it constructs an HTTP GET request. This request is then broken down by TCP into segments, sent over the network, and reassembled by the server. The server’s response (the HTML, CSS, images) is also sent back via TCP segments. The magic of TCP is its ability to ensure that all these pieces arrive correctly and in the right order, even if the network is a bit messy.
DNS, the Domain Name System, is like the internet’s phonebook. When you type www.example.com into your browser, your computer needs to translate that human-readable name into a machine-readable IP address (like 93.184.216.34). DNS is the protocol that handles this translation. It’s typically implemented using UDP for speed, because a quick lookup is usually more important than guaranteeing a single DNS query/response packet. If a UDP DNS request gets lost, the client will simply try again.
The core problem TCP solves is reliable data transfer over an unreliable network. It achieves this through a three-way handshake to establish a connection, sequence numbers to order packets, acknowledgments to confirm receipt, and timeouts with retransmissions to recover from lost packets. This makes it suitable for applications where data integrity and order are paramount, like file transfers, email, and web browsing.
UDP, on the other hand, is all about speed and low overhead. It’s a "fire and forget" protocol. There’s no handshake, no guaranteed delivery, no ordering. It just sends datagrams. This makes it ideal for real-time applications like streaming video, online gaming, and VoIP, where a slight packet loss or out-of-order arrival is less disruptive than the latency introduced by TCP’s reliability mechanisms. The application layer is then responsible for handling any necessary error correction or ordering if needed.
When you configure a service to listen on a specific port, say port 80 for HTTP or port 53 for DNS, you’re telling the operating system which protocol (TCP or UDP) to expect data on and which application should receive it. The port number is a logical endpoint for communication.
The surprising thing about TCP’s congestion control is that it doesn’t just react to packet loss; it actively probes for available bandwidth. Algorithms like Cubic (the default in Linux) will increase the sending rate exponentially until packet loss is detected, then it will reduce the rate linearly. This continuous adjustment is what keeps the internet from grinding to a halt under heavy load, ensuring fair sharing of network resources.
After understanding the fundamentals of TCP and UDP, the next logical step is to explore how these protocols are used by higher-level application protocols like HTTP, FTP, and SMTP.