How Computers Talk to Each Other: A Beginner's Guide to IP, Ports, and Sockets

Have you thought about how your phone talks to a website? Or how a computer knows where to send a message across the internet?
In this article, we'll explore the hidden rules of the internet, and I'll explain concepts that make sense for absolute beginners.

The Problem: How Devices Find Each Other among Billions of Devices?

Imagine we want to send a letter to one person among billions of people in the world. You need two things:

• name (so you know who to contact)
• address (so the letter gets to the right place)

The internet needs similar unique identifications. When a process (a program that is currently running ) on our computer wants to talk to another process on another computer, it needs to know:

• Which machine it's trying to reach
• Which process on that machine it's trying to reach

Meet the IP Address: Your Computer's Home Address

Think of IP (Internet Protocol) as your computer's unique home address on the internet. Just like your physical address (123 Main Street) identifies where you live, an IP address identifies your computer on the network.

For example, it might look like 192.168.1.1.
But here's the thing: finding the right machine isn't enough.

A single computer runs many programs (processes) at once. Your email app, web browser, and video player they're all running simultaneously. How does the internet know which program should receive the incoming message?

Meet the Port: Finding the Right Program

This is where port numbers come in.

A port is a door number on a house, and our computer is the house (IP address).

Each running program is a different room (port number). Each room has its own door number.

• A web browser might be listening on port 80 for web pages
• Simultaneously, an email app might be listening on port 25 for incoming emails
• Simultaneously, a video game might be on port 5000

When data arrives at our computer, the operating system (Windows, Mac, or Linux) reads the
port number and delivers the message to the correct process (application/program currently running in the OS).

So remember:

• IP Address = Which computer on the internet?
• Port Number = Which running program on that computer? Together, they form a complete address for the data.

The Client and Server: Who Talks to Whom?

The Client: The One Who Asks
The client is the process that starts the conversation. It's like we're initiating an order to a restaurant.

When we see a website in a browser, the browser ( representing us) is the client. It's requesting the server: "Hey server, can you send me the webpage?"

The Server: The One Who Listens.

The server is the process in the OS that waits for someone to talk to it.

It's a restaurant receptionist waiting for customers.

A server doesn't initiate conversations but listens on a specific port. When a client (a browser) requests information, the server responds to that client( browser ) or rejects the request.

Here's the pattern:

• Client: "Hello, I want some data"

• Server: "Sure, here's the data asked for"

• Client: "Thanks, received and goodbye"

Sockets: The Operating System's Magic Tool

Do you think like: "How does the operating system really manage all of this?"
Yes—and it does it with something called a socket.

A socket is the operating system's way of managing a network connection. Think of a socket like a special tool that hides all the messy details of how data actually travels across the internet.

When an application wants to connect to another application, the OS creates a socket and assigns it a unique number called a file descriptor (label for sockets and files). This file descriptor lets the OS quickly locate your specific connection (the correct socket among many) when data arrives.

Inside this socket, the OS stores everything needed for the conversation:

• Memory buffers (temporary storage for data coming in and going out)
• IP address (which computer)
• Port number (which program)

The brilliance of sockets is that the OS treats them almost exactly like files. Just as you can read from a file and write to a file, you can read data from a socket and write data to a socket.

Client Socket vs. Server Socket

There are two types of sockets, based on behavior:

Client Socket:

• Actively reaches out across the network
• Initiates the connection
• Sends requests and waits for responses

Server Socket:

• Claims a specific port on its home machine
• Listens patiently for incoming connections
• Waits for clients to "knock on its door"

Important: A server doesn't need its own IP address. Multiple server programs can run on the same IP address because the operating system separates them using different port numbers. A single IP address for a machine, many organized by ports for different processes.

The Life of a Connection: Step by Step
Now let's see exactly what happens when a client and server connect. It's like a choreographed dance with specific moves.

The Server's Setup (The Restaurant Preparing to Open)
Before a server can accept any connections, it goes through these steps:

1. Create — The server asks the OS: "Create a new socket for me"

2. The OS creates the socket and hands back a file descriptor

3. Bind — The server says: "Attach this socket to port 8080 on my IP address"

4. Now the OS knows: "When data arrives for port 8080, deliver it to this socket"

5. Listen — The server tells the OS: "I'm ready for connections. Queue up to 100 clients waiting"

6. The OS prepares to accept incoming connections

7. Accept — A client calls. The server accepts the connection.

8. Here's the magic: The OS creates a brand new socket just for this conversation

9. The original socket keeps listening for more clients

10. Receive/Send — The server listens to the client's request and sends back the response

The Client's Journey (The Customer Calling the Restaurant)
Meanwhile, the client follows a simpler path:

1. Create — The client asks the OS: "Create a socket for me"

2. The OS creates it and assigns a file descriptor

3. Connect — The client says: "Connect me to IP address 192.168.1.1, port 8080"

4. The OS initiates a handshake (we'll skip the technical details, but it's like saying "Hello,
   are you there?")

5. Once the server accepts, the connection is established

6. Send/Receive — The client sends its request and waits for the response

Handling Thousands of Customers at Once: The 4-Tuple Magic

Here's a question that might seem confusing: if a thousand customers connect to the same restaurant on the same port, how does the server keep them separate?

The answer is hidden in something called the TCP 4-Tuple.

The Problem
When the server accepts a client connection, it creates a new socket for that conversation. But this new socket uses the same port as the original listening socket. If port 443 is the "front door" of a web server, all thousand customer conversations still go through that same door.

How does the OS prevent chaos?

The Solution: Four Pieces of Information
The operating system doesn't identify a connection based on the port alone. Instead, it uses four pieces of information:

1. Client IP Address (e.g., 192.168.50.5)
2. Client Port Number (e.g., 51234)
3. Server IP Address (e.g., 192.168.1.1)
4. Server Port Number (e.g., 443) This combination of four numbers is called the 4-Tuple, and it's always unique for every connection.

Here's why: Even if a thousand users connect to your server on the same IP and port, each user's computer has a different IP and is assigned a different port number for each client socket. So:

• User 1: (192.168.50.5, 51234, 192.168.1.1, 443)
• User 2: (192.168.50.6, 51235, 192.168.1.1, 443)
• User 3: (192.168.50.7, 51236, 192.168.1.1, 443)

Every 4-Tuple is unique. When data arrives, the OS looks at all four numbers, finds the
matching socket, and delivers the data to the correct conversation.

The Restaurant Analogy
The main listening socket is a receptionist standing at the restaurant's front door. The receptionist's job is to watch for new arrivals.

When a customer walks in (client socket's request), the receptionist greets (accepts the client socket request) and immediately assigns you a dedicated waiter (a new child socket). That waiter is now exclusively assigned to you, even though the waiter works at the same restaurant address as the receptionist.

You and your waiter communicate directly while the receptionist turns back to the front door to greet the next customer. Thanks to your unique combination of information (your face, your table number, your arrival time, etc is the 4-tuple), the kitchen never mixes up your order with anyone else's.

Making Multiple Requests: Smart Reuse
Here's another practical question: if I want to view 50 different things on the same website, do I need to open 50 different connections?

The short answer: No.

Opening and closing network connections is slow and expensive. Instead, modern applications use a feature called Keep-Alive to reuse a single socket connection for multiple requests.

So your browser might:

1. Load the webpage (Request 1)
2. Load an image (Request 2)
3. Load a stylesheet (Request 3)

All through the same single socket connection, one after another. The server doesn't close the connection; it just waits for the next request.

The Blindness of Sockets

But here's something important to understand:
The socket itself has no idea what an "API call" or "request" is.
To the operating system, a socket is just a dumb pipe. Data goes in one end, comes out the other. The OS doesn't care about organizing messages or separating API requests(The images, website HTML, and other resource requests are different API requests). It just moves bytes.

So if you send 50 requests through one socket, how does the server know where one request ends and another begins?
Who Keeps the Conversations Straight?

The answer is: the application layer (protocols like HTTP).

When your browser sends multiple requests through a single socket, it attaches a unique identifier—called a stream ID—to each piece of data.

For example:

• Your browser sends: "Get me the profile" (tagged as Request #1)
• Your browser sends: "Get me the profile picture" (tagged as Request #2) Both travel through the same socket to the server.

When the server sends responses back, it includes those same tags:

• Response to Request #1: "Here's your profile" (tagged as #1)
• Response to Request #2: "Here's your profile picture" (tagged as #2)

Your browser reads the incoming stream, examines the tags, and routes each response to the appropriate place in your software.

The Waiter and the Kitchen Tickets

Back to our restaurant analogy: Imagine your dedicated waiter is the physical pipe (the socket).

If a customer orders an appetizer, a main course, and dessert, he doesn't need three different waiters.

One waiter carries all his orders back and forth. How does the kitchen avoid mixing up different customers' dishes?

The waiter writes a unique ticket number on every order slip (stream ID). The waiter doesn't care about the numbers; they just carry the paper.

But the kitchen staff (the application layer) reads
the numbers to make sure the right food reaches the right table.

Putting It All Together
Let's trace the complete journey of a simple action: you opening a website in your browser.

1. Your browser (client) creates a socket
2. Your browser asks the OS: "Connect me to google.com (the server) on port 443"
3. Google's server has been sitting and listening on port 443 with its own socket
4. Google's server accepts your connection and creates a new socket just for you
5. The OS uses the 4-Tuple (your-ip, your-port, google-ip, 443) to remember this conversation
6. Your browser sends a request: "Send me the homepage"
7. Google's server sends back the webpage data
8. Your browser displays the page

All of this happens in milliseconds, and the OS manages thousands or millions of simultaneous connections.

Conclusion

The internet's foundation is built on a few simple ideas:

• IP addresses find the right computer
• Port numbers find the right program on that computer
• Sockets are the OS's way of managing these connections
• The 4-Tuple keeps thousands of conversations from getting mixed up between two processes on the internet
• The application layer handles the higher-level logic of requests and responses from the same processes but different reasons.

I'm going to add engineering content in simple words like this. To see more like this, please follow me on dev. to.

https://www.linkedin.com/in/vigneshgs271096/

Did this help clarify how the internet works? Share your thoughts in the comments!