This chapter breaks down the 20 most important networking concepts in an order that actually makes sense, using simple visuals and real-world examples.

These are the concepts that come up most often in interviews, in system design discussions, and in day-to-day work as a software engineer. Each one builds on the one before it. Packets need addresses, addresses need routers, routers need names, and so on. By the end, you will have a connected mental model instead of a list of disconnected terms.

The diagram below groups the 20 concepts into four stages. The chapter follows them in this order.

Let's start with the framework that gives us a high-level view of how networking works and helps us understand where each concept fits: the OSI model.

The OSI model is a conceptual framework that breaks network communication into seven layers.

At the bottom, the Physical and Data Link layers handle how data moves across a local network. The Network layer handles IP addresses and routing between networks. The Transport layer handles communication between applications using protocols like TCP and UDP. And the upper layers handle things like sessions, data formatting, encryption, and application protocols such as HTTP.

Most engineers spend their time in layers 3, 4, and 7. Those three layers are where IP addresses, ports, and HTTP live, and they are where most debugging happens.

How Data Moves Through the Layers

When a request is sent, the data moves down the network stack, and each layer adds the information it needs, such as headers for addressing, routing, or delivery. On the receiving side, the process happens in reverse. Each layer reads and removes its own information before passing the remaining data to the layer above.

The sender wraps the application data in a TCP header, then an IP header, then a frame header. The receiver unwraps them in the opposite order until only the application data remains.

OSI vs. TCP/IP

The OSI model is mainly conceptual. In the real world, the internet is usually described using the simpler TCP/IP model, which combines several OSI layers.

But regardless of the model, we still need a way to efficiently move data across the network. That brings us to packets.

When data travels across a network, it usually isn't sent as one large block. Instead, it is broken into smaller units called packets.

For example, when you download an image, its data may be split across many packets. These packets can travel through the network independently and are combined again at the destination.

Breaking data into packets also allows the network to carry traffic from many different devices over the same links, with their packets interleaved as they move through the network. A single link between two routers can carry a packet from your video call, then a packet from someone else's file download, then another packet from your call, one after another.

Header and Payload

Each packet contains two main parts: a header and a payload. The payload carries the actual data, while the header contains information needed to deliver it, such as the source and destination IP addresses.

Routers read the header to decide where the packet should go. They do not need to understand the payload. That separation is what lets the same network carry web pages, video, email, and game traffic without caring what any of it means.

Since the header's most important job is carrying addresses, let's understand IP addresses in more detail.

An IP address identifies a device or network interface and helps the network determine where packets should be delivered.

There are two main versions of IP in use today: IPv4 and IPv6. IPv4 uses 32-bit addresses, giving us about 4.3 billion possible addresses. But that's not big enough for the modern internet. IPv6 uses 128-bit addresses and provides a significantly larger address space.

Every device on the internet has an IP address, but a packet usually doesn't travel directly from the source to the destination address. Instead, it passes through multiple networks along the way. At each step, something has to decide where the packet should go next. That's the job of a router.

A router connects different networks and forwards packets between them. When a packet arrives, the router looks at its destination IP address, checks its routing table, and decides where to send the packet next.

On the internet, many routers repeat this process until the packet reaches its destination network. Each router only needs to know the next hop, not the entire path. A simplified routing table looks like this:

The router matches the destination address against these entries and picks the most specific match. If nothing else matches, the default route sends the packet toward the internet.

Your home router connects your local network to your internet service provider. It is the first hop for every packet leaving your house.

Routers move packets between networks using IP addresses. But nobody wants to type an IP address every time they visit a website. We want names like google.com. To translate those names into addresses, we use DNS.

DNS, or the Domain Name System, translates human-readable domain names like algomaster.io into IP addresses that computers can use to connect to servers.

When you enter a website in your browser, it first checks whether the IP address is already cached. If not, it sends a DNS query. That query may go through a DNS resolver, which can contact the root servers, the top-level domain servers, and finally the authoritative DNS server for that domain. The result is an IP address, which your browser can then use to connect to the correct server.

The resolver caches the answer, so the next lookup for the same name usually returns immediately without repeating the whole chain.

But reaching the right machine is only part of the journey. A single machine can run many applications and services at the same time, so the operating system still needs to know which application should receive the incoming data. That's where ports come in.

A port identifies a specific application or service running on a machine. The IP address gets the packet to the right machine. The port number then tells the operating system which application or service on that machine should receive it.

You can think of the IP address as the building address, and the port number as the apartment number inside that building.

Ports range from 0 to 65,535, and multiple applications on a machine can communicate over the network at the same time by using different ports. Some port numbers are conventionally reserved for well-known services:

So far, we've seen how devices communicate across public networks using IP addresses. But most devices in homes and offices don't have their own public IP address. Instead, they use private IP addresses and connect to the internet through a router.

So how can your laptop, phone, TV, and other devices all share a single public IP address and still receive the correct responses? That's where NAT, or Network Address Translation, comes in.

When your laptop sends a request to the internet, the router translates its private IP address and source port into the router's public IP address and typically a different port. It stores this mapping in a NAT table.

When the response comes back, the router looks up that mapping and forwards the response to the correct device inside the private network.

The NAT table for the diagram above looks like this:

When a response arrives at port 40001, the router checks the table and forwards it to the laptop. A response to port 40002 goes to the phone. The web server never sees the private addresses.

This allows many devices to share a single public IPv4 address, helping conserve the limited IPv4 address space while keeping private addresses hidden from the public internet.

This setup works well for a small number of devices. But as a network grows to hundreds or thousands of devices, like in a data center, managing all those private IP addresses as one large network becomes difficult and inefficient. That's where subnetting comes in.

Subnetting is the process of dividing a larger IP network into smaller networks, called subnets, to make the network easier to organize and manage.

This helps organize devices, reduce unnecessary traffic, and control which parts of a network can communicate with each other.

CIDR Notation

To describe the size of a subnet, we often use CIDR notation. For example, in a /24 subnet, the first 24 bits identify the network, while the remaining 8 bits are used for addresses within that subnet.

The larger the CIDR prefix, the smaller the subnet. For example, a /24 subnet contains 256 IPv4 addresses, while a /16 subnet gives us a much larger network of more than 65 thousand addresses. So as the prefix gets smaller, the network can contain more IP addresses.

No matter how many devices are on a private network, each one needs an IP address. But how does a device get that address in the first place? That's where DHCP comes in.

DHCP, or Dynamic Host Configuration Protocol, automatically gives a device the network settings it needs when it joins a network.

For example, when your laptop connects to Wi-Fi, it usually doesn't choose an IP address manually. Instead, it asks a DHCP server, which assigns an IP address along with other settings such as the subnet mask, default gateway, and DNS server. In a typical home network, the DHCP server runs on the home router itself.

The exchange happens in four steps, often remembered by the acronym DORA: Discover, Offer, Request, Acknowledge.

This assignment is usually temporary and is called a lease. Before the lease expires, the device can request to renew it. So DHCP removes the need to manually configure network settings on every device.

But an IP address isn't the only address involved in local communication. Technologies like Ethernet and Wi-Fi also use another identifier: the MAC address.

A MAC, or Media Access Control, address identifies a network interface on a local network. It is typically assigned by the device manufacturer and is usually represented as a 48-bit hexadecimal value that looks something like this:

The first three bytes identify the manufacturer, and the last three bytes identify the specific interface. MAC addresses operate at Layer 2, the Data Link layer.

While an IP address is used to route packets across different networks, a MAC address is used to deliver frames between devices on the same local network.

IP addresses can change as devices move between networks, while MAC addresses usually stay the same, making them a more consistent identifier within a local network.

But there's a problem. Applications usually know the destination's IP address, while the local network needs a MAC address to deliver the frame. So how do we map one to the other? That's where ARP comes in.

ARP, or Address Resolution Protocol, finds the MAC address associated with an IP address on the local network.

Suppose your laptop wants to send data to another device on the same network. It knows the destination IP address, but it still needs the destination MAC address for the Ethernet frame. So it broadcasts an ARP request, essentially asking: "Who has this IP address?" The device with that IP responds with its MAC address, and your laptop can store that mapping in its ARP cache, so it doesn't have to ask every time.

So ARP bridges the gap between IP addresses at Layer 3 and MAC addresses at Layer 2.

Now imagine dozens of devices connected to the same local network. Once we know the destination MAC address, how does the frame actually reach the correct device without being sent to everyone? That's the job of a switch.

Unlike a router, which forwards packets between different networks, a switch mainly forwards frames between devices on the same network.

It does this using MAC addresses. When a frame arrives, the switch looks at the destination MAC address, checks its MAC address table, and forwards the frame to the correct device.

The switch learns its MAC table by watching the source address of every frame that arrives on each port. Once it knows that the server's MAC address lives on port 2, it sends frames for that address out of port 2 and nowhere else.

This allows laptops, servers, printers, and other devices to communicate efficiently without every frame being sent to every device.

Switches mainly operate at Layer 2, the Data Link layer. Most modern Wi-Fi routers have a switch built in, which is why they have several Ethernet ports on the back.

Now we know how data reaches the correct device on the local network. But how do we make sure that data sent between applications actually arrives reliably and in the right order? That's where our first transport protocol, TCP, comes in.

TCP, or Transmission Control Protocol, provides reliable, ordered communication between applications.

The Three-Way Handshake

Before sending application data, TCP first establishes a connection using the three-way handshake. The client sends a SYN packet to request a connection. The server responds with SYN-ACK to acknowledge the request and indicate that it is ready. Finally, the client sends an ACK back to the server.

Once these three steps are complete, the TCP connection is established and both sides can start exchanging data reliably.

Reliable, Ordered Delivery

TCP then breaks the data into smaller segments and uses sequence numbers and acknowledgments to make sure those segments arrive correctly and in the right order. If a segment is lost along the way, TCP detects it and retransmits it.

Flow Control and Congestion Control

TCP also provides flow control, which prevents the sender from overwhelming the receiver, and congestion control, which reduces the sending rate when the network becomes overloaded.

All of this reliability adds some overhead, but it makes TCP a good fit for applications where correct delivery matters, such as web traffic, file transfers, email, and database connections.

But not every application needs all of those guarantees. In some cases, speed and low overhead matter more than making sure every packet arrives or arrives in order. That's where the next protocol, UDP, comes in.

UDP, or User Datagram Protocol, is a simpler, connectionless alternative to TCP. It sends data without first establishing a connection, and it does not guarantee delivery, ordering, or retransmission.

Because of that, UDP has less overhead and can be faster when low latency matters more than perfect reliability.

It is commonly used for things like video calls, online gaming, live streaming, and DNS queries, where waiting to retransmit old data may be worse than simply moving on. In a video call, a frame that arrives two seconds late is useless. It is better to drop it and show the next one.

TCP and UDP operate at the transport layer, but in most modern application development, we rarely work with them directly. Instead, we usually interact with higher-level application protocols built on top of them. One of the most important is HTTP, the protocol that powers most communication on the web.

HTTP, or Hypertext Transfer Protocol, is the protocol used for communication between web clients and servers. When you open a website, your browser sends an HTTP request to the server, and the server returns an HTTP response.

Anatomy of a Request and Response

An HTTP request typically includes the method, URL, headers, and sometimes a body. The response usually contains a status code, headers, and the requested data.

A request looks like this:

And the response looks like this:

HTTP Methods

HTTP provides different methods for different types of operations. For example, GET is commonly used to fetch data, POST to create or submit data, PUT or PATCH to update data, and DELETE to remove it.

HTTP vs. HTTPS

HTTP itself does not encrypt the data being transmitted. Most modern systems use HTTPS, which is simply HTTP secured with encryption, so the data exchanged between the client and server cannot easily be read or modified by someone intercepting the connection.

And that security is provided by our next concept: TLS.

TLS, or Transport Layer Security, secures communication between a client and server.

When you connect to an HTTPS website, TLS starts with a handshake. During the handshake, the server presents a digital certificate to prove its identity, and the client and server agree on cryptographic settings and establish shared session keys. Once the handshake is complete, the actual data is encrypted using fast symmetric encryption.

TLS gives us three important protections:

So TLS protects the data while it is in transit.

But security isn't only about encrypting traffic. Sometimes, we also need to control which traffic is allowed in or out in the first place. That brings us to firewalls.

A firewall controls which network traffic is allowed to enter or leave a system. It examines traffic and applies rules based on things like IP addresses, ports, protocols, and connection state. For example, a server might allow HTTPS traffic on port 443 while blocking incoming traffic on other ports.

A typical rule set for a public web server looks like this:

Firewalls can run on individual machines, inside routers, or at the edge of an entire network. Cloud providers expose the same idea as security groups or network access control lists.

Next, let's look at how we can create a secure connection across an untrusted network using a VPN.

A VPN, or Virtual Private Network, creates an encrypted tunnel between your device and a VPN server or private network. Instead of sending traffic directly over the public internet, your device first sends it through this secure tunnel. So websites may see the VPN server's public IP address instead of your own.

Anyone watching the public Wi-Fi sees only encrypted traffic heading to the VPN server. They cannot see which websites you visit or what you send.

VPNs are commonly used to securely access a company's internal network from outside, or to protect traffic when using an untrusted network like public Wi-Fi.

Next, let's look at another kind of intermediary that forwards requests on behalf of clients or servers: proxies and reverse proxies.

Forward Proxy

A proxy, usually called a forward proxy, sits between clients and the internet. Instead of connecting directly to the destination server, a client sends its request to the proxy. The proxy then forwards that request on the client's behalf. As a result, the destination server sees the request coming from the proxy's IP address rather than directly from the original client.

For example, a company might route employee traffic through a forward proxy to block certain websites, enforce access policies, or cache responses.

Reverse Proxy

A reverse proxy works on the other side. It sits in front of one or more backend servers and handles incoming requests on their behalf. Clients connect to the reverse proxy, and it forwards each request to the appropriate backend.

Reverse proxies are commonly used for TLS termination, caching, rate limiting, and hiding backend infrastructure. They can also distribute traffic across multiple backend servers.

And that brings us to load balancers.

A load balancer is often implemented as a reverse proxy that decides which backend server should handle each incoming request. Its main job is to distribute traffic across multiple servers so that no single server gets overwhelmed.

Load balancers also perform health checks. If a server stops responding, the load balancer can stop sending traffic to it and route requests to the healthy servers instead.

To decide where each request should go, load balancers use algorithms like round robin, least connections, and IP hash.

This chapter covered networking as a whole. In the next chapter, we’ll take a closer look at what actually happens behind the scenes after you enter a URL into your browser and press Enter.