TCP Wants an Answer. UDP Just Sends the Message.

Two computers can exchange the same kind of data in very different ways. The difference starts with one simple question, do we need to known that message arrived?

When two computers communicate across a network, sending data is only part of the problem. They also need to decide how that data should travel. Shouls the sender create a connection first? Should it check that the information arrived correctly? Or sshould it simply send the message and continue?

This is where TCP and UDP enter the conversation? Both work at the transport layer of the TCP/IP stack, and both use port numbers to help applications communicate. But they follow very different ideas.

TCP prefers control and reliability. UDP prefers simplicity and less overhead.

Neither one is better every situation. They exist because not every network communication has the same needs.

TCP likes confirmation

Suppose you need to send something important. You probably want to know that the other person received it. If something goes wrong, you want a way to recover from the problem.

This is close to the idea behind TCP, or Transmission Control Protocol.

TCP is connection-oriented. Before normal data is exchanged, a connection is established betwenn the two systels. TCP is designed to provide reliable delivery, which makes it useful when the information needs to arrive correctly.

Think about sensitive information sent to a website. If you are entering payment information, losing part of the communication is not something you you want to ignore. In this type of situation, reliability is more important than avoiding a little extra work.

That reliability has a cost. Creating and managing a connection produces more overhead. TCP does more work because it is trying to provide a controlled conversation between the two devices.

Sometimes that extra work is exactly what we need.

Sometimes it is not.

UDP does not wait for the same conversation

UDP, or User Datagram Protocol, takes a different approach.

UDP is connectionless. It does not estblish the same type of dedicated connection before sendind information, and it does not provide the same guarantee tha the data will arrive.

At first, this may sound like a bad idea. Why would we use a protcol that does not guarantee delivery?

Because sometimes we do not needt the transport protocol to mange everything.

DHCP is a good examlpe. A computer that needs network configuration can send a request looking for a DHCP server. It does not need to create a complete connection with a specific server berfore making the request. If no response arrives, the DHCP client can try again.

UDP removes some of the overhead associated with TCP. That can male it useful when simple communication is more important than creating a reliable connection first.

So TCP asks, in effect, "Can we establish a proper conversation?"

UDP says, "Here is the message."

The port tells the computer who the message is for

TCP and UDP both use port numbers.

A computer can run many network services at the same time. I t may provide a webside, accept remote connections, share files and answer other network requests. The IP address identifies the computer, but the port helps identify the service that should receive the communication.

One simple way to think about this is to imagine an office building. The street address gets you to the correct building, but you still need to know which office you want.

The IP address is the building address.

The port is the office number.

For example, a web server can listen for normal HTTP communication on port 80, while secure HTTPS communication uses port 443. An SSH service normally listens on port 22. These services can exist on the same machine because their traffic arrives through differennt ports.

The numbers are not the services themselves. They are simply the default places where we normally expect find them.

Port 443 is useful because some conversations matter

HTTPS is good example of communication where a controlled connection is important.

HTTP is used between a web browser and a web server and normally uses port 80. HTTPS provides secure web communication and normally uses port 443.

HTTPS is a good example of why TCP is useful. When we send important information, we want the communication to be reliable. TCP creates a connection and makes sure the data arrives correctly.

UDP has a different job

UDP works differently. It does not create the same type of connection before sending data. It simply sends the information.

DHCP is a good example. When a computer connects to a network, it can use DHCP to request an IP address. DHCP uses UDP ports 67 and 68. If the computer does not receive an answer, it can simply try again.

This does not mean that UDP is bad or that TCP is always better. They are designed for different situations. TCP gives more reliability, while UDP has less overhead and can be useful when a complete connection is not necessary.

Ports make more sense with a purpose

Port numbers can look difficult when we see them in a long list. But they become easier when we connect them to something real.

Port 22 means SSH and secure remote administration. Port 53 is used by DNS. Port 80 is associated with HTTP, and port 443 with HTTPS. DHCP uses ports 67 and 68.

I do not think the best way to learn ports is to memorize dozens of numbers at once. It is easier to understand what a protocol does first and then connect the port number to that purpose.

TCP or UDP?

The main difference is actually simple.

TCP wants a reliable connection. UDP sends data without creating the same type of connection first.

Sometimes we need TCP because the information must arrive correctly. Sometimes UDP is enough because the application can manage the communication in another way.

So when you see TCP and UDP in network traffic, do not only think about two protocol names.

Think about two different ways of communicating.

TCP wants an answer.

UDP just sends the message.