DEV Community: vigneshgs271096

Quick Learn Docker

vigneshgs271096 — Sun, 30 Aug 2026 13:10:10 +0000

Why Docker?
Docker is a tool that packages the application we develop along with the dependencies it needs. Why do we package it like this? Software needs dependent libraries, tools, settings, and runtimes. To run the software on another machine, we need the same versions of the dependencies as those used when we create it.

**Overall Concepts to Know while working with Docker

Dockerfile -> Docker image -> Container**

A Dockerfile is a saved, shareable instruction file. We use the Docker CLI to send this file to the Docker Daemon. The Daemon reads the instructions and builds a Docker Image (the packaged software/template). We can then use the CLI to tell the Daemon to run multiple Containers (the live applications) from that single Image.

If we need to start many containers and the containers have to communicate with each other for many practical uses. To define containers with details to start, stop, and manage the container lifecycle ( Orchestration ) and communicate with each other ( Networking ), we use a docker-compose file.

VM vs Docker

Each virtual machine displayed above acts like a completely different computer inside real computers.

Virtual machine architecture starts with the hypervisor, which takes part( abstracts and allocates, or we can call it partitions) of the machine's hardware and prepares virtual hardware. A guest OS runs inside each VM to run applications.

Unlike VMs, Docker containers don’t need a heavy Guest OS. Instead, they share the Host OS Kernel. By using Linux features like Namespaces, Docker creates an isolated environment (specific folders, networks, and files) where the process thinks it is running alone. Because Linux containers require a Linux kernel, running them on Windows or Mac requires Docker Desktop to spin up a single, lightweight Linux VM in the background, and all containers share that VM's kernel.

When we start a container, the Docker daemon starts a standard process but wraps it in two Linux features: Namespaces to isolate what the process can see, and cgroups to limit the CPU and RAM it can use. Because of this namespace isolation, the process has two identities: a standard PID assigned by the host OS, and an isolated PID (usually PID 1) inside the container's own namespace.

Commands

1. docker run –– name container1 ubuntu

The docker run ubuntu command tells Docker to run the latest version of the Ubuntu image. Docker first searches its local image cache on your machine. If the image is not found there, it reaches out to a Docker Registry (like Docker Hub), downloads the image to your cache, and then runs it as a container. If we didn’t mention its name by flag (–name < our name>), Docker assigns some random name to the container.

docker run –– name container1 -d ubuntu

If we start the container, the terminal is active, and logs are printed from the container. To use the same terminal for various uses, use the detach flag.

docker run –– name container1 ubuntu:4.0

We can specify a version instead of the latest version.

docker run –– name container1 -p 80:5000 ubuntu:4.0

We map host port 80 to the container’s app port 5000. From the outside world, we can communicate through the host port 80.

docker run –– name my-db -v /opt/datadir:/var/lib/mysql mysql

Containers are temporary and disposable. So if we store the DB inside the container, it is not recoverable. We can map the host folder to the container folder.
**
Container Folder = /var/lib/mysql

Host Folder = /opt/datadir**

docker run -e APP_COLOUR=blue kodekloud/simple-webapp

It is an environment variable, APP_COLOUR; we can use it in our container

docker ps

We can see all the active containers.
**
docker ps -a**

We can see all the containers, including inactive ones

docker start container1

Start the container

docker stop container1

Stops the container

docker rm container1

Deletes the container

docker images

Lists all the images

docker rmi nginx

Removes the image

docker pull ubuntu

Just pulls the image from Docker Hub, without running it.

docker exec -it container1 sh

It opens the container ubuntu, execute the command sh.

-i (Interactive): Keeps the input stream (STDIN) open so you can type.
-t (TTY): Allocates a fake terminal screen so it looks and acts like a normal command prompt. Together (-it), they give you an interactive shell.

docker inspect container1

Details about the container

docker logs container1

Prints out what the application has printed.

Example Dockerfile

FROM ubuntu:latest

# Update OS and install Python
RUN apt-get update && apt-get install -y python3 python3-pip

# Install the exact Flask version needed
RUN pip3 install Flask==2.0.1

# Set the folder and copy your laptop's code into the image
WORKDIR /opt
COPY . /opt

# The command to run when the container starts
CMD ["python3", "-m", "flask", "run", "--host=0.0.0.0"]

The Dockerfile instructs the Docker daemon to start from the Ubuntu base image, and within that environment, we use RUN to install packages. We use WORKDIR to tell Docker to create a folder at /opt/home and execute all subsequent commands from that directory. We then copy the code from our host directory directly into that workspace. Finally, when we start the container, it executes the command provided inside the CMD array.

CMD is a flexible suggestion; the user can override CMD, as explained in the image.

docker run my-app bash

Here, when running the container, by default it has to run python3 -m flask –host=0.0.0.0, but we override it with bash. When the container is started, it won’t start the Flask app; it will start bash. So we can use an ENTRYPOINT array, which prevents the command from being overridden. We can use a combination of them to our advantage.

# Lock in the main program 
ENTRYPOINT ["python3", "app.py"] 
# Provide a default argument 
CMD ["--port=8080"]

In the above example, the runtime command is fixed as python3 app.py, but the port can be overridden.

Docker has a layered architecture; instructions that add or change files (RUN, COPY, ADD) create actual filesystem layers. Commands like ENTRYPOINT, CMD, or ENV just add lightweight metadata to the configuration, not physical layers

Layer 1 (Base Ubuntu Layer): The heavy foundation.
Layers 2 & 3 (apt and pip packages): The installed tools stacked on top.
Layer 4 (Source Code): Your actual application files.
The metadata telling Docker how to behave (Entrypoint): The final startup instructions.

Once the image is built, the underlying layers of the image are already created and read-only. The Docker daemon has a cache of every layer and can reuse it when rebuilding the image. For example, if you alter the source code ( 4th layer ), Docker won’t start rebuilding from scratch from Layer1. It will start from the 4th; it can recognise that the top 3 layers are unchanged, and it has the cache of the layers to reuse. So it will build layer 4 and the metadata step.

On top of this, there is a temporary, read-and-write container layer above all read-only stable image layers. It is like placing a glass board on top of the book; we can scribble anything on top of the glass board. It creates an illusion of changing the book, but in reality, the book is static. If the container is deleted, this layer’s memory is lost. This is the reason it is termed temporary. It uses Copy-on-Write to create an illusion of changing files in the container layer. Please research it separately if you want more detail, but this abstraction is enough to work with Docker.

To save permanently on the host file system, use volumes, which were discussed above.

docker run -d -v ./Downloads/db:/var/lib/mysql mysql

If we are building a simple API for an online store, we create two microservices: a database and a backend process containing the business logic. If a customer requests to see products, the backend queries the database and returns the result to the client. Without Docker, these processes use a socket address (IP + PORT) to establish a connection. In Docker, we use a network abstraction.

By default, the Docker daemon acts as a router/gateway. It assigns a dynamic IP to each container and places them in the default bridge network. These dynamic IPs can be used for communication, but they change every time a container restarts.

To overcome this, the Docker daemon has an embedded DNS that resolves container names into IPs, allowing containers to communicate using just their names. However, this DNS feature does not work on the default bridge network. To use it, we must create a user-defined network and place both of our containers inside it.

We can bind a port on the host machine to the process inside the container. This is called port binding. It opens a doorway so the external world can communicate with the container, allowing users to access the API or web server running inside it.

docker network create my-store-network

# Start the database and put it on the network
docker run -d --name my-database --network my-store-network mysql

# Start the web server and put it on the exact same network
docker run -d --name my-web-server --network my-store-network my-python-app

OLD WAY without Docker

# The web app connects to the database installed directly on your laptop
db_connection = mysql.connect(
    host="localhost",
    user="admin",
    password="my-secret-pw",
    port=3306
)

Docker way

# The web app connects to the separate database container
db_connection = mysql.connect(
    host="my-database", # <--- Notice this change!
    user="admin",
    password="my-secret-pw",
    port=3306
)

We have already discussed the volume above

#Create volume
docker volume create data_volume

# Use the volume
docker run -v data_volume:/var/lib/mysql mysql

Data_volume is a permanent folder on the host. /var/lib/mysql is a folder in the container.

There are two main ways to persist data in Docker. Volumes are entirely managed by the Docker daemon and stored in a hidden area on the host. Bind Mounts allow you to map a specific, known folder on your host machine directly into the container(-v /opt/datadir:/var/lib/mysql). With a bind mount, Docker doesn't copy or sync files; it simply allows the container to read and write directly to that exact host folder in real-time. The modern way to attach either of these in the CLI is by using the explicit --mount flag.

Docker compose

In the example image, we need 5 containers. A Python app for people to vote and update an in-memory Redis DB; from this in-memory DB, the .NET worker gets the data and updates the actual Postgres DB. The Postgres app was fetched to show the result in the Node.js result app. This single file helps to orchestrate multiple containers.

services:
  vote:
    image: dockersamples/examplevotingapp_vote
    ports:
      - "5000:80"
    networks:
      - front1

  redis:
    image: redis:alpine
    networks:
      - front1
      - back1

  worker:
    image: dockersamples/examplevotingapp_worker
    networks:
      - back1
      - back2

  db:
    image: postgres:15-alpine
    environment:
      - POSTGRES_PASSWORD=postgres
    volumes:
      - db-data:/var/lib/postgresql/data
    networks:
      - back2
      - front2

  result:
    image: dockersamples/examplevotingapp_result
    ports:
      - "5001:80"
    networks:
      - front2

volumes:
  db-data:

networks:
  front1:
  front2:
  back1:
  back2:

These are some commands for a Dockerfile

docker compose up -d

#Start all the containers without a live terminal

docker compose ps

#List of all containers

docker compose logs -f vote

#Logs of the container from the vote app

docker compose down

#Stop all the containers

docker compose up -d --build

#Rebuild all the containers

Docker Hub is a popular public container registry used widely for open-source images. For enterprise security, organizations usually host their own private registries (like AWS ECR or a self-hosted Docker Registry). We push our built images to these registries, and our servers pull those images to run them as containers.

docker login registry.mycompany.com

docker tag my-api:latest username/my-api:v1.0

docker push username/my-api:v1.0

docker pull username/my-api:v1.0

How can people use the internet without IPs?

vigneshgs271096 — Wed, 26 Aug 2026 13:03:02 +0000

Highly recommend you read the previous article and spend time understanding IPs, sockets, and ports.

Why URL ?
Suppose an application is running on our computer and needs the IP and port of another application to communicate over the internet. But remembering IP addresses is hard, so we use human-readable names to name computers, which computers don’t understand, but we use a middleman called DNS to map the name to machine-readable numbers ( IP ). In addition to the computer's name, we need other kinds of information to communicate, like which PORT the server is running on and which application-level protocol we are using; we need to communicate what all the resources we need from the server, etc., so a URL is the standard way to represent the information needed to communicate with other computers, which is agreed globally.

The main Idea of protocols
I live in Chennai, India. If people get into a cab and tell the driver a location like “Chennai Central Railway Station”, the driver gets the exact location the passenger wants to go to. He doesn’t need to know the full address or geolocation. If the passenger and driver were both locals, they would both agree that the phrase “Chennai Central Railway Station” is the particular location through their experience.

The Master Format:
://:@:/;?#

Scheme (How are we connecting?)

From the previous article, we know that simply by knowing the IP ( host name )and PORT, we can able to create a socket connection. But the goal of a connection is to transfer resources/services from the server to the client. To achieve this, we need to transfer large amounts of data using a universally agreed standard to communicate. When we are building a server and client using TCP/UDP sockets, we have to write some extra logic for the standard that both party agrees.

Example
Let me build my own simple application protocol

The request from the client has to mention the type of the file, like jpg, txt, etc and on the next line I add txt, jpg, or binary file. I know the request format is going to come in the format and file from the server side; I can easily code to take the format, take the file from the next line, and save it as a file with its actual format, e.g., dummy.jpg

# socket is tool by OS to abstract network connection
import socket

# create a socket of IPV4 and TCP
server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
# giving the socket ip and port
server.bind(('127.0.0.1', 8080))
# telling the os to prepare connection , max 1
server.listen(1)
print("Server waiting for connection...")

# sever listen , when got request, create a dedicated connectionSocket for communication 
connectionSocket, clientAddress = server.accept()
# receves data
raw_data = connectionSocket.recv(4096)

# extract header of our protocol
header, first_chunk = raw_data.split(b'\n', 1)
extension = header.decode()

# create a file and save all the data in that file
filename = f"dummy.{extension}"
with open(filename, "wb") as f:
    f.write(first_chunk) # Write the body from the first packet

    # Keep receiving if the file is large
    while True:
        chunk = connectionSocket.recv(4096)
        if not chunk: break
        f.write(chunk)


# close the socket
print(f"Successfully saved {filename}")
server.close()
connectionSocket.close()

The above one is a one-time server

# socket is a tool provided by the OS to abstract network connections
import socket

# 1. Prepare data (Let's send a simple text file)
extension = "txt"
file_data = b"This is the content of my custom protocol file!"

# 2. Apply Your Protocol format: extension + \n + file_data
protocol_message = f"{extension}\n".encode() + file_data

# 3. Setup TCP Socket and Connect
client = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
client.connect(('127.0.0.1', 8080))

# 4. Send everything and close
client.sendall(protocol_message)
print("Message sent using custom protocol.")
client.close()

The above code is the client to connect to the server code

Like the scheme we created above, there are globally accepted schemes: HTTP, FTP, SMTP, and database schemes(e.g., postgres://, mongodb://, redis://).

**
Host (Where is the server?)**
We already discussed IP in depth, and the domain name is resolved to an IP. We already discussed this in our previous article in depth, so I’m skipping it with a link.

Path, query, and params in the URL are used to convey the client's requirements to the server in different styles.

Example

https://www.example-store.com/shop/shoes.html;color=red;size=10?sort=price&gender=mens#reviews

Here, the path is /shop/shoes.html, which is used to specify that, in this store, we are interested in the shoe HTML on the server.

Params are ;color=red;size=10, which tells the server that the client is interested in size 10 and red shoes.

The query was ?sort=price&gender=mens, which tells the server to sort the page by price, and we were interested in men's shoes

HTTPS is the scheme; from the scheme, we can derive that the default port is 443.

www.example-store.com is the domain name resolved by DNS into an IP address.

For some schemes like ftp, we need a username and password.

#reviews is the fragment here; this notation is used to indicate which part of the HTML document is viewed. Here, in the HTML page, the user views the review part. The fragment is useless for the server and is used as a bookmark.

How we use URLs practically

We know about URLs now; we never type the full URL in the browser in our daily life, and web developers themselves won’t use the full URL during development.

In the above example, this part https://www.example-store.com is the base URL; irrespective of what page/resource we see, this base URL has to be the same. The rest of the URLs, other than the base URL, are relative URLs

/shop/shoes.html;color=red;size=10?sort=price&gender=mens#reviews

The browser understands that the current page's base URL is the first part of the relative URL unless it is explicitly mentioned. Developers ( including myself ) build webpages using relative URLs; the base URL can be changed in one place if we are changing the domain name. I am personally part of the team building jewellery software, where we change theme colors, logo, and base URL to run. The remaining codes remain same; the company sold the same software to many jewellers.

We observe that the browser is intelligent enough to suggest the URL when we half type with the help of browser history. The browser, like Google, Safari, etc have their website details in its database; if we search a related word, we see it in the result. If we click, we will go to the website. The question that comes to my mind is how Google's DB knows all its websites. The answer is that the website owners themselves expose it to Google, Safari, etc nobody wants to hide their website in e-commerce competition. Even if they don’t, google have crawler that crawls the internet's pages; if it finds any webpage link that it does not know, it will go to the website and try to crawl all its pages and save the important keywords that help the google to show the website for relevant searches in the browser.

URL ENCODING AND DECODING
In this URL, we cannot use characters which was in other languages, or any special symbol which was not in ASCII, or any reserved words in a URL with a different meaning. So we have a workaround: the illegal characters mentioned here are converted to ASCII code, which is URL encoding. When the browser reads it, it knows it is some kind of special character, and on the receiving end of the request, it is decoded to normal form, called URL decoding. I will add the examples below.

Spaces (The most common) You type: apple pie Browser sends: apple%20pie
Reserved Characters (To prevent confusing the server) You type: Ben & Jerry (The & usually splits a query!) Browser sends: Ben%20%26%20Jerry (The & becomes %26) You type: 100% Browser sends: 100%25 (The % becomes %25)
Other Languages & Symbols You type: café Browser sends: caf%C3%A9 You type: hello 👋 Browser sends: hello%20%F0%9F%91%8B

We have a question: if we encode to make the URL safe, why can’t we do it for the entire URL text except the special characters?
The answer is no. The receiving side only expects special characters to be encoded and normal text to remain normal. Overdoing it here creates confusion.

From the above and the past two articles, we know about the OS role in communication ( sockets ) and socket addresses ( IP + PORT). Now we know, as common users, why we don't see IPs in our next articles; we explore More about the application layer and how frameworks and libraries were built to make API calls.

How are computers named on the internet: IPV4 and IPV6

vigneshgs271096 — Mon, 24 Aug 2026 05:04:46 +0000

RECAP

In the last article, we discussed how two applications running on different computers on the internet communicate through IP addresses and Ports, and how the OS’s socket handles the hidden details of the communication network. In this chapter, we can go deeper into IPs.

vigneshgs271096

Aug 11

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

#api #crawler #webdev #computernetwork

8 min read

** Let's Start**

When we ask an internet service provider for internet, we can get the router/modem connected to the external cable. After the setup, we can connect all the devices in our home and use the internet. But there is a logical system behind this magic. I will discuss it here.

For computers, everything is binary: 1s and 0s. If we want to build a system for computers that identifies each other, we have to name each computer like places, people, etc. We cannot name them in the alphabet or with numbers like 1,2,3…, we have to name them in binary numbers.

If we have a bit, it has only two options: 0 or 1. So we can name one computer 0 and another one 1. If we have 2 bits, we have 4 combinations.

0 0
0 1
1 0
1 1

If we have n bits, we have ( 2n ) combinations, which can label 2n computers. In the IPv4 standard, we have 4 decimal numbers separated by dots; each number is 8 bits.

If we calculate the total number of devices that can be labelled by IPV4 is 4,294,967,296 (2³²). It is sufficient in the initial days, but as the number of devices that connect to the internet grows exponentially, we need to introduce a new method to connect a large number of devices.

Subnetting is dividing a larger network into many smaller networks, and NAT is one of the solutions. We go back to the ISP: if we request an internet connection for home, very rarely ISP give a direct IP.

WAN ( wide area network ) is the network that connects globally, but we have limitations here as discussed above. The ISP gets WAN public IPs, creates its own small network LAN ( local area network ) which covers our home along with the neighbourhood.

The ISP edge router ( WAN IP ) is the gateway to communicate with the external world. From the ISP edge router, they create a subnet for various routers, which includes our home. The router which is in our home creates its own network to manage all the devices that we connect. With this concept, we can connect many devices from a single WAN IP.

Our router in the home gets an IP from the ISP edge router. As we discussed above, the router in home which gives IP to each device we connect to it.

In our above example, we can see a local network that connects many hosts ( devices).

CIDR NOTATION ( classless inter-domain routing)

It's a modern way of representing IP. It purposefully avoids older class conventions of IP to avoid confusion, and it is no longer used.

EXAMPLE : 198.162.30.3 / 24

Here we have 32 bits IP; in this IP, 24 bits are dedicated to the network’s identification. We can observe that the first 3 parts were the same for all hosts, and the network ID of the network was 198.162.30.0.

If we identified the network 198.162.30.0, we need to find the exact host next; here, the remaining 32 - 24 = 8 bits after the network ID is host ID, which points to the exact host in the network. So the host ID is 3

DEFAULT GATEWAY
The router is generally a gateway, which connects this host to external devices. Other hosts communicate to this router; the router communicates outside of the network on behalf of the other devices. It is common to dedicate the first IP of the network to the router: 198.162.30.1

Number of networks vs. size of networks

There are only 32 bits in IPV4; if we dedicate more bits, we can create more labels. In our example, we dedicate 24 bits to the network ID ( label networks ). We can have 2 power 24 is 16,777,216 networks, but only 2 power 8, which is 256 devices, can be connected to each network.

Similarly, if we create a network, network ID = 198.0.0.0 and
host IP = 198.162.30.3 / 8

We have only 256 networks, but for each network we can connect 16,777,216 devices.

In the above paragraph, I mentioned the number of devices that can be connected to a network, but there are some special IDS which is reserved: the network ID and Broadcast ID. Broadcast ID will be discussed in future articles.

The number of networks is inversely proportional to the size of each network.

Let's discuss IPV6 to overcome the limitation of the 4 billion cap in IPV4. There are 8 groups of 16-bit numbers separated by “: “, and it is represented by hexadecimal numbers ( 0, 1, 2,.. 9, A, B, C, D, E, F).

Example

In CIDR Notation
2001:0db8:85a3:0000:0000:0000:0000:0015/64

Here in IPv6, the bits dedicated to representing the network ID are termed as Network prefix ( 2001:0db8:85a3:0000 ), and the host ID is termed as Interface ID ( 0000:0000:0000:0015 ).

Going to explain networking from a common point of view; follow me if you want to stay up to date with my content. And also feel free to discuss concepts in comments, let we interact

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

vigneshgs271096 — Tue, 11 Aug 2026 03:27:29 +0000

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:

Create — The server asks the OS: "Create a new socket for me"
The OS creates the socket and hands back a file descriptor
Bind — The server says: "Attach this socket to port 8080 on my IP address"
Now the OS knows: "When data arrives for port 8080, deliver it to this socket"
Listen — The server tells the OS: "I'm ready for connections. Queue up to 100 clients waiting"
The OS prepares to accept incoming connections
Accept — A client calls. The server accepts the connection.
Here's the magic: The OS creates a brand new socket just for this conversation
The original socket keeps listening for more clients
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:

Create — The client asks the OS: "Create a socket for me"
The OS creates it and assigns a file descriptor
Connect — The client says: "Connect me to IP address 192.168.1.1, port 8080"
The OS initiates a handshake (we'll skip the technical details, but it's like saying "Hello,
are you there?")
Once the server accepts, the connection is established
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:

Client IP Address (e.g., 192.168.50.5)
Client Port Number (e.g., 51234)
Server IP Address (e.g., 192.168.1.1)
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:

Load the webpage (Request 1)
Load an image (Request 2)
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.

Your browser (client) creates a socket
Your browser asks the OS: "Connect me to google.com (the server) on port 443"
Google's server has been sitting and listening on port 443 with its own socket
Google's server accepts your connection and creates a new socket just for you
The OS uses the 4-Tuple (your-ip, your-port, google-ip, 443) to remember this conversation
Your browser sends a request: "Send me the homepage"
Google's server sends back the webpage data
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!