How TCP and UDP Work

Introduction

Welcome to Part 7 of the Network Fundamentals study notes! If you haven’t already, we recommend watching the video first.

In the last two parts, we looked at the OSI and TCP/IP models and saw that the transport layer uses TCP and UDP. Now it’s time to look at those protocols in detail — how they use port numbers to track conversations, how multiple applications share the network at once, and why TCP and UDP take such different approaches to their job.

The Transport Layer’s Job

IP (at layer 3) handles getting data between devices — including routing across multiple networks. The transport layer takes a different view. It doesn’t care much about the networks in between, and it doesn’t really care about the devices themselves. Its job is getting data between applications.

The two protocols that do this are TCP (Transmission Control Protocol) and UDP (User Datagram Protocol). They share a few things — both use headers, and both use port numbers — but TCP is significantly more complex. That’s because TCP supports a rich set of features, while UDP was deliberately designed to be lightweight.

Port Numbers

Both TCP and UDP headers contain a source port and a destination port. Port numbers identify applications on a device — think of them as addresses for applications, in the same way IP addresses identify devices.

Source Ports

When an application starts a conversation, it chooses a random source port — any value from 1024 to 65535 that isn’t already in use on the device. One port number can only be assigned to one process at a time.

Destination Ports

The destination port is usually a well-known port — a standardised number that identifies a particular service. Well-known ports are in the 0–1023 range. For example, HTTP web traffic uses port 80, and HTTPS uses port 443. Because these are well-known, the client can reliably guess what port to use without being told.

A server application can be configured to use a non-standard port (for example, port 81 for HTTP), but then the client must be manually configured to connect to that port — it can no longer guess.

Multiplexing

Different port numbers give us a powerful feature called multiplexing — the ability for one host to run several applications accessing the network at the same time, all sharing the same network card, network stack, and IP address.

For example, you might have a web browser open at the same time as an email client. Both are communicating over the network simultaneously. When data arrives at your device, the port number tells the operating system which application it belongs to — without port numbers, there would be no way to tell them apart.

Sockets and the Five Tuple

A socket is the combination of a local IP address, a local port number, and a protocol (TCP or UDP). Because port numbers are unique per device, a socket can identify exactly which application owns a particular network connection.

But consider a busy web server. It has one IP address and listens on port 80 — so multiple incoming client connections all share the same socket. How does the server tell one client from another?

The answer is the five tuple: the combination of local IP, local port, remote IP, remote port, and protocol. Every conversation is unique when you consider all five values together. The server reads this information from the layer 3 and layer 4 headers in each packet to distinguish between clients.

You can see this in action on any computer using the netstat -an -o command. This lists all active connections, showing the protocol, local address and port, remote address and port, connection state, and the process ID — everything that makes up the five tuple.

TCP vs UDP

Beyond port numbers, TCP and UDP take very different approaches.

Connection-Oriented vs Connectionless

TCP is connection-oriented. Before sending any data, TCP builds and tracks a connection between the two applications. When the transfer is done, TCP closes the connection cleanly. This stateful connection is what enables features like error recovery and flow control.

UDP is connectionless. It doesn’t build a connection — it just starts sending data immediately, without any setup or tracking. We’ll look at how TCP builds its connection in detail in the next video.

Reliability and Error Handling

TCP is known as reliable — the receiver must acknowledge every piece of data received, and if anything goes missing, TCP manages the retransmission automatically.

UDP is unreliable — if a packet is lost, UDP doesn’t notice and doesn’t care. It just moves on to the next piece of data.

Windowing

TCP uses a feature called windowing. Both sides agree on how much data can be sent at once before the receiver must acknowledge it — this is the window size. If data is being received cleanly, the window size grows dynamically, allowing more data to flow. If data is being lost, the window size shrinks. We’ll cover windowing in detail in Part 9.

Ordered Data Transfer

TCP uses sequence numbers in the header to track the order that segments should be processed. This ensures data is reassembled correctly even if packets arrive out of order. UDP has no concept of ordering — data is processed as it arrives.

When to Use UDP

It might seem odd to use a protocol with no error recovery or ordering — but there are good reasons to.

Consider a voice call. If the network drops a few seconds of audio, TCP would notice, request the missing data, and wait for it to arrive. But the phone call is still happening in real time — the retransmitted audio would arrive late and make the call laggy. It’s actually better to just skip the lost data and continue. That’s exactly what UDP does.

UDP is ideal for real-time applications like voice and video streaming, where timeliness matters more than completeness. It’s also used by applications like DNS that handle their own reliability logic and don’t need TCP to do it for them.

TCP, on the other hand, is the right choice when data must arrive completely and correctly — file transfers, web pages, email, and so on.

Resources

Test your knowledge with the Introduction to Networking quizzes.