Internet Protocol Explained: How Data Travels Across Networks

Computer Networking for Beginners series — Part 6. This post continues Part 1: A Complete Guide to How Networks Work, Part 2: What Is the OSI Model?, Part 3: Networking Devices Explained, Part 4: CDNs, VPNs, QoS, and TTL, and Part 5: Cloud Networking Explained. Each post in the series takes one topic and covers it in depth. This one zooms in on how data actually travels: the Internet Protocol, TCP and UDP, ports, and sockets.

Every time you load a web page, check your email, or join a video call, your data is broken into pieces, packed up, labeled with addresses, and sent across a series of networks to exactly the right program on exactly the right computer. The system that makes this possible is the Internet Protocol (IP), working together with two transport protocols, TCP and UDP.

This post explains how those pieces fit together using a simple analogy — moving boxes in a truck — and then covers the details you need to understand real network traffic: how TCP and UDP differ, how IP addresses and port numbers work together, what a socket is, and why some port numbers are permanent while others are temporary.

Moving Data Like Moving House: The Truck Analogy

Imagine you’re moving to a new home. You don’t carry your belongings one at a time. You pack them into boxes, label each box, load the boxes onto a truck, and drive the truck along the roads to your new address. When the truck arrives, the boxes are unloaded and taken to the right rooms.

Network data travels the same way:

This process of putting data inside a protocol, and then that protocol inside another, is called encapsulation, which you first saw in Part 2:

1. An application, like your web browser, creates some data.
2. The data is placed in a TCP or UDP “box” that’s labeled with the source and destination port numbers.
3. The box is loaded onto an IP “truck” that’s labeled with the source and destination IP addresses.
4. The truck drives across the “road” — the network hardware — from router to router until it reaches its destination.
5. At the destination, the truck is unloaded: the IP packet is opened, the TCP or UDP box inside is delivered to the right port, and the data reaches the right application.

The important idea is that each layer only cares about its own job. The truck driver doesn’t need to know what’s inside the boxes, and the boxes don’t care which roads the truck takes.

IP: The Truck That Carries Everything

The Internet Protocol is responsible for addressing and routing: putting the source and destination IP addresses on every packet, and moving packets from network to network until they arrive. Routers read the destination IP address on each packet and send it one hop closer to its destination, just as a driver follows road signs toward an address.

IP itself is a best-effort delivery service. It does its best to deliver every packet, but it makes no promises: packets can be lost, arrive out of order, or even arrive twice. IP leaves reliability to the protocol riding inside it — which is where TCP and UDP come in.

To learn more about what’s inside an IP packet’s header and how routing decisions are made, see What Is Internet Protocol (IP)?, and for IPv4, IPv6, and public vs. private addresses, see What Is an IP Address?.

The Boxes: TCP and UDP

The transport layer (OSI Layer 4) decides how data is packed into boxes and whether delivery is guaranteed. There are two main options, and each is good at different things.

TCP: Reliable, Connection-Oriented Delivery

TCP (Transmission Control Protocol) is connection-oriented and reliable. It’s like a delivery service that requires a signature for every box and replaces anything that goes missing.

TCP guarantees that data arrives complete and in order using several techniques:

• The three-way handshake. Before sending any data, the two devices set up a connection:
  1. The client sends a SYN (“synchronize”): “I’d like to talk.”
  2. The server replies with a SYN-ACK: “OK, I’m ready too.”
  3. The client sends an ACK (“acknowledge”): “Great, let’s start.”
• Packet numbering. Every byte of data is given a sequence number, so the receiver can put segments back in the right order even if they arrive out of order.
• Acknowledgments. The receiver confirms what it has received. If the sender doesn’t get an acknowledgment in time, it retransmits the missing data.
• Flow control. The receiver tells the sender how much data it can accept at once, so a fast sender doesn’t overwhelm a slow receiver. TCP also slows down automatically when the network is congested.
• A clean goodbye. When the conversation is over, both sides close the connection with FIN messages.

All of this checking adds a little overhead and delay, but it means every byte arrives correctly. That’s why TCP is used for web pages (HTTP and HTTPS), email, file transfers, and remote logins (SSH) — anything where missing or scrambled data isn’t acceptable.

UDP: Fast, Connectionless Delivery

UDP (User Datagram Protocol) is connectionless and barebones. It’s like dropping postcards in the mail: you send them and hope they arrive.

UDP has:

• No handshake — it just starts sending.
• No acknowledgments — the receiver never confirms what arrived.
• No retransmission — lost data stays lost.
• No ordering — datagrams can arrive in any order.
• No flow control — the sender doesn’t slow down for the receiver.

Its header is tiny (just 8 bytes, compared with at least 20 for TCP), and there’s no waiting around, so UDP is faster and more efficient. It’s used where speed matters more than perfection, or where the application handles reliability itself:

• Voice and video calls, live streaming, and online games — a late packet is useless anyway, so it’s better to skip it than to wait.
• DNS lookups — a single question and answer; if no reply comes, the device just asks again.
• DHCP — getting an IP address when a device joins a network (see Part 1).

Interestingly, the newest version of the web protocol, HTTP/3, runs on a protocol called QUIC that’s built on top of UDP. QUIC adds its own reliability and encryption, getting the speed of UDP with the guarantees web pages need.

TCP vs. UDP at a Glance

Addresses and Rooms: IP Addresses and Port Numbers

Back to the moving truck. The truck needs a street address to reach the right house, but once it gets there, each box still has to go to the right room.

• The IP address gets the data to the right device — the house.
• The port number gets the data to the right application on that device — the room.

That’s necessary because one computer runs many network applications at the same time: a web browser, an email app, a chat app, a music streaming app. Every one of them receives data through the same network connection and the same IP address. Port numbers keep their data separate.

A port number is a 16-bit number, so there are 65,536 possible ports, numbered 0 to 65535, for TCP and another 65,536 for UDP. Every TCP or UDP box carries two of them: a source port (where it came from) and a destination port (where it’s going).

Sockets: The Complete Address

A socket is the complete address of one end of a network conversation: the combination of an IP address, a protocol (TCP or UDP), and a port number. It’s often written like this:

203.0.113.10:443  (TCP)

That’s the web server at 203.0.113.10, listening for HTTPS on TCP port 443.

A complete conversation has two sockets, one on each end — the client’s and the server’s. Together, the protocol, the source IP address and port, and the destination IP address and port uniquely identify every single connection on the internet. That’s how a server can talk to thousands of visitors at once without mixing up their data: each visitor’s connection has a different combination.

Port Number Ranges: Permanent and Temporary

Not all port numbers are used the same way. They fall into two broad groups.

Non-Ephemeral Ports: Permanent Addresses for Services

A non-ephemeral port is permanent: a server application listens on it all the time, so clients know exactly where to find it. The most important services use well-known ports in the range 0–1023:

On most operating systems, an application needs administrator privileges to listen on a port below 1024. Many services also use permanent ports above 1023, like MySQL on 3306, PostgreSQL on 5432, and test web servers on 8080. For a longer list, see What Are the Well-Known Port Numbers?

Ephemeral Ports: Temporary Ports for Clients

An ephemeral port is temporary. When a client application, like your browser, starts a conversation, your operating system picks an unused port number at random for it to use as its source port. The port is used only for that one conversation and is freed when the connection closes. You never choose it yourself — and the server doesn’t care which one it is, because it simply sends its replies back to whatever source port the request came from.

The Official Ranges

For certifications like CompTIA Network+, you’ll often see a simple split: 0–1023 for non-ephemeral ports and 1024–65535 for ephemeral ports. The official registry, maintained by IANA (the Internet Assigned Numbers Authority), divides the ports into three ranges:

Operating systems choose their own range for ephemeral ports. Windows and macOS use 49152–65535, following IANA, while most Linux systems use 32768–60999. You can check on macOS with:

sysctl net.inet.ip.portrange.first net.inet.ip.portrange.last

net.inet.ip.portrange.first: 49152
net.inet.ip.portrange.last: 65535

(On Linux, run cat /proc/sys/net/ipv4/ip_local_port_range.)

One Client, Many Conversations

Now you can see how one computer has many conversations with the same server at the same time. Imagine your laptop, at 192.168.1.25, connects to a single server at 203.0.113.10 that offers a website, email, and SSH. Each application on your laptop gets its own ephemeral port, while the server uses the well-known port for each service:

All four conversations travel over the same network connection between the same two IP addresses, yet nothing gets mixed up. When the server sends a reply to port 53490, your laptop knows it belongs to the email app. Even the two browser tabs talking to the same port 443 are kept apart, because their client ports are different.

See It on Your Own Computer

You can see sockets like these on your own computer. Here’s a real example from a Mac, where one client program opened two connections to a test web server on port 8080 and one to a test server on port 2222, all on the same computer (127.0.0.1 is the address a computer uses to talk to itself). The lsof command lists open network connections (a few columns are removed here to save space):

lsof -nP -iTCP

COMMAND   PID   USER   FD   TYPE   NODE NAME
Python  97064   you    3u   IPv4   TCP 127.0.0.1:8080 (LISTEN)
Python  97064   you    4u   IPv4   TCP 127.0.0.1:2222 (LISTEN)
Python  97064   you    5u   IPv4   TCP 127.0.0.1:53488->127.0.0.1:8080 (ESTABLISHED)
Python  97064   you    6u   IPv4   TCP 127.0.0.1:53489->127.0.0.1:8080 (ESTABLISHED)
Python  97064   you    9u   IPv4   TCP 127.0.0.1:53490->127.0.0.1:2222 (ESTABLISHED)

The LISTEN lines are the two servers waiting on their permanent ports. The ESTABLISHED lines are the three client connections: each one got its own ephemeral port — 53488, 53489, and 53490, all in macOS’s 49152–65535 range — even though two of them connect to the very same server port.

To see your own computer’s connections:

• macOS and Linux: lsof -nP -iTCP -sTCP:ESTABLISHED (or ss -tn on Linux).
• Windows: netstat -an in Command Prompt, or Get-NetTCPConnection in PowerShell.

Open a few websites first, and you’ll see your browser’s ephemeral ports connected to remote servers on port 443.

Putting It All Together

Here’s the full journey when you open https://example.com in your browser:

1. The application creates the data. Your browser prepares an HTTPS request for the page.
2. TCP packs the box. Your operating system picks an ephemeral source port — say, 53488 — and TCP sets up a connection with the server’s port 443 using the three-way handshake, then packs the request into numbered segments.
3. IP loads the truck. Each segment is placed in an IP packet with your IP address as the source and the server’s IP address as the destination. (Your router’s NAT swaps in your public IP address on the way out, as you learned in Part 1.)
4. The truck drives the roads. The packets cross Wi-Fi, Ethernet, and fiber, hopping from router to router across the internet. Each router reads only the IP address and forwards the packet closer to the server.
5. The server unloads. The server’s IP layer accepts the packets, TCP puts the segments back in order and acknowledges them, and port 443 delivers the request to the web server software.
6. The reply comes back. The server sends the page back the same way, addressed to your IP address and port 53488, so it arrives at exactly the right browser tab.

Common Misconceptions

• “IP guarantees delivery.” It doesn’t — IP is best-effort. Reliability comes from TCP, or from the application when it uses UDP.
• “UDP is unreliable, so it’s worse.” UDP isn’t worse; it’s built for a different job. For live voice and video, waiting for a lost packet would make things worse, not better.
• “A port is a physical connector.” Network port numbers are just numbers in a packet header. They have nothing to do with the Ethernet ports on the back of a switch.
• “Only one connection can use a port at a time.” A server can handle thousands of connections on the same port, like 443, because each connection’s socket pair is different.
• “Ports above 1023 are always ephemeral.” Many permanent services, like databases, listen above 1023. “Ephemeral” describes how a port is used — temporarily — not just its number.

What’s Next in This Series

Now you know how data is packed, addressed, and delivered: application data in TCP or UDP boxes, carried by IP trucks across the network’s roads to the right IP address and port. Upcoming posts in the Computer Networking for Beginners series will keep building on these foundations. Until then, try the commands from this post: check your computer’s ephemeral port range, and look at your open connections while you browse.

Conclusion

The Internet Protocol is the truck of the internet: it carries every packet from network to network using IP addresses, on a best-effort basis. Inside each packet rides a box from the transport layer. TCP is the careful option — connection-oriented, with a three-way handshake, sequence numbers, acknowledgments, retransmission, and flow control to guarantee delivery. UDP is the fast option — connectionless and barebones, with no guarantees, perfect for real-time traffic and quick lookups.

IP addresses get data to the right device, and port numbers get it to the right application. Together with the protocol, they form a socket. Servers listen on permanent, non-ephemeral ports like 80 and 443, while clients use temporary ephemeral ports for each conversation — which is how one computer can talk to many applications on many servers at the same time, without ever mixing up the data.

Next in the Computer Networking for Beginners series: What Are the Well-Known Port Numbers?, a practical cheat sheet of the ports you’ll see most often.

Computer Networking for Beginners series: Part 1: A Complete Guide to How Networks Work · Part 2: What Is the OSI Model? · Part 3: Networking Devices Explained · Part 4: CDNs, VPNs, QoS, and TTL · Part 5: Cloud Networking Explained · Part 6: Internet Protocol Explained · Part 7: Well-Known Port Numbers · Part 8: Protocols for Troubleshooting, Tunneling, and Security