AlgoInsight

System Design

20 Networking Concepts in 15 Minutes

Networking quietly underpins every system you'll ever design, and the same twenty concepts come up again and again. This is the fast tour - each one explained clearly enough to use in an interview, with links to go deeper.

By Admin2026-06-1815 min readnetworkingsystem-designtcpdnshttpinterview

Networking is the invisible foundation under every system you'll ever build. Two computers talking to each other - which is what every web request, API call, and database query ultimately is - relies on a stack of networking concepts that most engineers use daily without quite being able to explain. The good news: you don't need to be a network engineer. The same twenty concepts come up again and again in system design and interviews, and understanding them clearly is enough to reason about how systems actually communicate.

This is the fast tour. Each concept is explained clearly enough to use, with links to the deeper guides where they exist.

graph TD
    APP[Your request] --> DNS[1. DNS resolves name to IP]
    DNS --> IP[2. IP routes packets to the server]
    IP --> TCP[3. TCP/UDP carries the data]
    TCP --> HTTP[4. HTTP/HTTPS formats the request]
    HTTP --> INFRA[5. Load balancers, proxies, CDNs<br/>route and accelerate it]

This diagram shows how the core networking concepts fit together in a single request. Your request starts with DNS, which resolves a domain name to an IP address. IP then routes packets to that server. TCP or UDP carries the data across the network. HTTP or HTTPS formats the request and response. And along the way, infrastructure like load balancers, proxies, and CDNs route and accelerate the traffic. The twenty concepts in this guide expand on each of these pieces.

The fundamentals: addressing and packets

1. IP address. A unique numerical address identifying a device on a network - like a postal address for a computer. Every device on the internet has one, and it's how data knows where to go. IPv4 addresses look like 192.0.2.1; the newer IPv6 exists because the world ran out of IPv4 addresses.

2. Port. A number that identifies a specific service or application on a device. If the IP address is the building, the port is the apartment number - it lets one machine run many services (web on port 443, etc.) and route incoming traffic to the right one.

3. Packet. Data sent over a network is broken into small chunks called packets, each carrying a piece of the data plus addressing information. Packets travel independently across the network and are reassembled at the destination. Almost everything on a network moves as packets.

4. DNS. The Domain Name System translates human-friendly domain names (like example.com) into the IP addresses computers actually use. It's the phonebook of the internet - you type a name, DNS finds the number. Nearly every connection starts with a DNS lookup. (See the dedicated DNS guide.)

The transport layer: how data moves

5. TCP. The Transmission Control Protocol - a reliable, connection-oriented way to send data. It guarantees that data arrives complete and in order, retransmitting anything lost. Most things that need reliability (web pages, files, email) use TCP. (See the TCP vs UDP guide.)

6. UDP. The User Datagram Protocol - a fast, connectionless way to send data with no guarantees of delivery or order. It trades reliability for speed and low overhead, ideal where being fast matters more than being perfect (live video, gaming). (See the TCP vs UDP guide.)

7. Socket. The endpoint of a network connection - a combination of an IP address and a port that two programs use to talk. When two machines communicate, they do so through sockets; it's the programming abstraction for a network connection.

The application layer: the web

8. HTTP. The HyperText Transfer Protocol - the protocol of the web, defining how clients (browsers) request resources and servers respond. Every web page load is HTTP requests and responses. (See the HTTP versions guide.)

9. HTTPS / TLS. HTTPS is HTTP secured with TLS (Transport Layer Security), which encrypts the connection so data can't be read or tampered with in transit. The padlock in your browser means TLS is protecting the connection. (See the HTTPS and TLS guide.)

10. WebSocket. A protocol providing a persistent, two-way connection between client and server, so the server can push data to the client in real time (unlike HTTP's request-response). Used for chat, live updates, and real-time features. (See the WebSockets guide.)

Performance concepts

11. Latency. The time it takes for data to travel from source to destination - the delay. Measured in milliseconds, it's heavily influenced by physical distance. Low latency means snappy; high latency means laggy. (See the latency guide.)

12. Bandwidth. The maximum amount of data that can be transferred per unit of time - the capacity of the connection, like the width of a pipe. High bandwidth moves a lot of data at once.

13. Throughput. The actual amount of data successfully transferred per unit of time - what you really get, which can be less than the bandwidth due to latency, congestion, and overhead. Bandwidth is the ceiling; throughput is the reality.

Infrastructure that routes and accelerates

14. Load balancer. A component that distributes incoming traffic across multiple servers, so no single server is overwhelmed and the system scales and stays available. Essential for any system serving significant traffic. (See the load balancer guides.)

15. Proxy / reverse proxy. A proxy is an intermediary that forwards requests. A forward proxy sits in front of clients (representing them); a reverse proxy sits in front of servers (representing them), handling incoming requests - often doing load balancing, caching, and TLS termination. (See the proxy guides.)

16. CDN. A Content Delivery Network is a geographically distributed set of servers that cache content close to users, so it's delivered faster and the origin server is offloaded. Essential for serving static content (and increasingly more) at global scale. (See the CDN guide.)

17. NAT. Network Address Translation lets many devices on a private network share a single public IP address, translating between private and public addresses. It's why all the devices on your home network can share one public IP.

Network management and security

18. DHCP. The Dynamic Host Configuration Protocol automatically assigns IP addresses (and other network settings) to devices when they join a network, so you don't configure each one by hand. It's why a device just works when it connects to Wi-Fi.

19. Firewall. A security system that monitors and controls network traffic based on rules, blocking unauthorized or malicious traffic while allowing legitimate traffic. The gatekeeper between networks, deciding what's allowed in and out.

20. VPN. A Virtual Private Network creates a secure, encrypted connection over a public network, so traffic is protected and can appear to originate elsewhere. Used for secure remote access and privacy.

The layered model that ties it together

The twenty concepts above aren't a flat list - they're organized into layers, and understanding the layering is the single most clarifying idea in networking. The networking stack is built as layers, each handling one job and building on the one below, so each layer does its work without worrying about the details of the others.

The classic teaching model is the OSI model (seven layers), but the practical model is the simpler TCP/IP model, which groups networking into four layers:

The power of layering is separation of concerns. When you make an HTTP request (application layer), you don't worry about how packets are routed (internet layer) or whether the cable is copper or fiber (link layer) - each layer handles its job and hands off to the next. HTTP runs on top of TCP, which runs on top of IP, which runs on top of the physical network, each layer trusting the one below to do its part. Understanding which layer a concept lives in - IP at the internet layer, TCP/UDP at the transport layer, HTTP/DNS at the application layer - organizes the whole list into a coherent stack rather than twenty disconnected terms.

A deeper look: loading a web page

To see the concepts working together, trace a web page load in more detail. You type example.com and hit enter.

First, DNS resolves example.com to an IP address - your device asks a resolver, which finds the address (often from cache). Now your device knows where to send data.

Your device opens a connection to that IP on a specific port (443 for HTTPS), forming a socket. A TCP connection is established (the handshake), and then TLS negotiates encryption so the connection is secure. Your data will travel as packets, reliably and in order, thanks to TCP.

Your browser sends an HTTP request over this secure connection. But it might not go straight to the origin: a CDN may intercept it and serve cached content from an edge server near you (fast), and a load balancer and reverse proxy at the destination may route it across multiple servers. Throughout, latency (distance delay) and bandwidth (capacity) shape how fast it feels - which is exactly why the CDN serving from nearby helps.

The server's response travels back the same way, as packets, secured by TLS, reassembled by TCP, rendered by your browser. And underneath it all, NAT let your device share a public IP, DHCP gave your device its address when it joined the network, and a firewall checked the traffic. One page load, and nearly every concept on the list played a part. That's why these twenty are worth knowing - they're not trivia, they're the machinery of every interaction.

The concepts you'll touch most as a developer

Of the twenty, some you'll work with directly and constantly, others you'll mostly just need to understand. As a practical guide to where to focus:

You'll directly use and configure: HTTP/HTTPS (every API and web interaction), DNS (pointing domains, debugging why something can't be reached), TLS (certificates, the padlock), load balancers and CDNs (in nearly every production system), and WebSockets (when building real-time features). These show up in day-to-day development and architecture.

You'll mostly need to understand without configuring directly: TCP vs UDP (knowing which your protocols use and why), IP, ports, packets, and sockets (the addressing and transport beneath everything), latency, bandwidth, and throughput (reasoning about performance), and NAT, DHCP, firewalls, and VPNs (the network management layer that's usually handled for you but matters when things break).

This isn't a hard line, but it helps prioritize. The application-layer concepts (HTTP, DNS, TLS, CDN, load balancing) are where you'll spend the most time and where system design questions concentrate, so understand those deeply. The lower-layer concepts you can understand more lightly, knowing enough to reason about them and recognize when they're the issue. Either way, having the whole map means that when a problem or design touches any layer, you know what you're looking at - and that fluency is exactly what separates someone who uses the network from someone who understands it.

A few more worth knowing

The twenty above are the core, but a handful of adjacent terms round out the picture and occasionally appear:

You don't need these to the same depth as the core twenty, but recognizing them keeps you from being thrown when they come up. Together with the main list, they complete a working developer's networking vocabulary - enough to read an architecture diagram, reason about where a bottleneck lives, and follow a networking discussion without getting lost.

How they fit together

These twenty aren't isolated facts - they're layers cooperating on every request. When you load a web page: DNS resolves the name to an IP address; your device opens a TCP connection to a port on that IP (a socket); the data travels as packets; HTTPS/TLS secures it; the request is HTTP; along the way a CDN may serve cached content from nearby, a load balancer distributes it across servers, and a reverse proxy handles it; latency and bandwidth determine how fast it feels; and firewalls, NAT, and DHCP quietly manage and protect the network underneath. One page load touches most of this list.

Interview: You won't be quizzed on all twenty, but networking concepts thread through system design constantly. Knowing what DNS does (and that it's the first step), the difference between TCP and UDP (reliable vs fast), what a CDN and load balancer do, and the latency-versus-bandwidth distinction lets you reason about how systems communicate and where bottlenecks live. When you say "I'll put a CDN here to cut latency" or "this needs UDP because it's real-time," you're showing you understand the networking layer your design runs on - which is exactly the kind of fluency interviewers notice.

The bottom line

Networking underpins every system, and twenty concepts cover most of what you need: IP addresses, ports, packets, and DNS for addressing and naming; TCP, UDP, and sockets for transporting data; HTTP, HTTPS/TLS, and WebSockets for the web; latency, bandwidth, and throughput for performance; load balancers, proxies, CDNs, and NAT for routing and acceleration; and DHCP, firewalls, and VPNs for management and security. Each is simple on its own, and together they explain how any two computers on the internet actually talk.

Learn these twenty and the networking layer of system design stops being a black box. Use this as a map, and follow the links to go deeper on the ones that matter most. We cover networking fundamentals across System Design Fundamentals.

Go deeper

More articles