Free lesson · Computer Networking

What Is Computer Networking And Why Should You Care

Easy10 min readnetworkingcomputer-networkstcp-ip

Every Line of Code You Write Depends on a Network

Open your browser and type a URL. In under a second, a page appears - text, images, interactive elements, data pulled from databases thousands of kilometers away. Behind that one-second experience, dozens of networking protocols coordinated across physical cables, wireless signals, routers, switches, DNS servers, CDN edge nodes, load balancers, and application servers. Your code runs on one machine but serves users on millions of machines across the planet. The network is what connects them.

Computer networking is the discipline of understanding how that connection works - how data moves from one device to another across a room or across an ocean, how devices find each other on a network of billions, how failures are detected and recovered from, how security is enforced, and how all of these concerns interact to create the experience users call "the internet."

If you are a software engineer who has ever debugged a timeout, configured a load balancer, reasoned about latency in a System Design interview, or wondered why a request that works locally fails in production - you have already encountered networking. You have networking knowledge, but it is scattered and incomplete - fragments picked up from Stack Overflow answers, blog posts, and painful debugging sessions. This course takes those fragments and builds them into a coherent, layered understanding that you can reason with confidently.

What Is a Network?

At its simplest, a computer network is two or more devices connected so they can exchange data. Your laptop connected to your home router is a network. A data center with 100,000 servers connected through switches and routers is a network. The internet - billions of devices across every country on Earth, connected through undersea cables, satellite links, and terrestrial fiber - is a network of networks.

The defining characteristic of a network is not its size or technology. It is the ability for any connected device to communicate with any other connected device through a shared set of rules. Those shared rules are called protocols, and they are the foundation everything else builds on.

What makes networks powerful is that they enable distributed computing - spreading work across multiple machines. Without networks, every application would run on a single computer, limited by that computer's memory, storage, and processing power. With networks, an application can use a database on one machine, a cache on another, a queue on a third, and serve users through load balancers distributing traffic across dozens of application servers. Every modern software architecture is a networked system, whether you think of it that way or not.

Networks exist at different scales, and each scale has a name:

LAN (Local Area Network): A network within a single building or campus. Your home Wi-Fi network, your office network, a university campus network. LANs typically use Ethernet or Wi-Fi and are owned and operated by a single organization.
WAN (Wide Area Network): A network spanning multiple geographic locations. A company connecting its New York and London offices over a leased telecommunications link operates a WAN. WANs use different technologies than LANs - longer-distance fiber optic cables, leased lines from telecommunications providers, and sometimes satellite or microwave links. The internet itself is the largest WAN ever built, spanning every continent including research stations in Antarctica.
Data center network: A specialized LAN inside a data center, optimized for extremely high bandwidth and low latency between servers. When your application runs on AWS, Azure, or GCP, it runs inside a data center network designed to move enormous volumes of data between thousands of machines with minimal delay. Data center networks use high-end switches, redundant paths, and sophisticated routing protocols to ensure that any server can communicate with any other server at speeds of 10-100+ Gbps with sub-millisecond latency. Understanding data center network architecture helps you reason about the performance characteristics of cloud-hosted applications.
The internet: The global WAN that connects LANs, data center networks, home networks, mobile devices, and everything else. The internet is not a single network owned by a single entity - it is a cooperative system where thousands of independently operated networks agree to exchange traffic using common protocols.

graph TD
    subgraph Internet["The Internet - Network of Networks"]
        ISP1["ISP Network<br/>(Comcast)"]
        ISP2["ISP Network<br/>(AT&T)"]
        CLOUD["Cloud Provider<br/>(AWS)"]
        BACKBONE["Internet Backbone<br/>(Tier 1 Provider)"]

        ISP1 --- BACKBONE
        ISP2 --- BACKBONE
        CLOUD --- BACKBONE
    end

    subgraph Home["Home LAN"]
        LAPTOP["Laptop"]
        PHONE["Phone"]
        HROUTER["Home Router"]
        LAPTOP --- HROUTER
        PHONE --- HROUTER
    end

    subgraph Office["Office LAN"]
        DESK["Desktop"]
        PRINTER["Printer"]
        OROUTER["Office Switch"]
        DESK --- OROUTER
        PRINTER --- OROUTER
    end

    subgraph DC["Data Center"]
        SRV1["Server"]
        SRV2["Server"]
        DCSW["DC Switch"]
        SRV1 --- DCSW
        SRV2 --- DCSW
    end

    HROUTER --- ISP1
    OROUTER --- ISP2
    DCSW --- CLOUD

    style BACKBONE fill:#4f46e5,stroke:#4338ca,color:#fff
    style ISP1 fill:#7c3aed,stroke:#6d28d9,color:#fff
    style ISP2 fill:#7c3aed,stroke:#6d28d9,color:#fff
    style CLOUD fill:#7c3aed,stroke:#6d28d9,color:#fff
    style HROUTER fill:#8b5cf6,stroke:#7c3aed,color:#fff
    style OROUTER fill:#8b5cf6,stroke:#7c3aed,color:#fff
    style DCSW fill:#8b5cf6,stroke:#7c3aed,color:#fff

This diagram shows how different types of networks connect to form the internet. At the center is the Internet Backbone operated by Tier 1 providers. Three ISP and cloud provider networks connect to the backbone. Below them, a Home LAN with a laptop and phone connects through a home router to one ISP. An Office LAN with a desktop and printer connects through an office switch to another ISP. A Data Center with servers connects through a data center switch to a cloud provider. Each small network is a LAN, and together they form the global internet.

Why Software Engineers Need Networking Knowledge

You might wonder: do I actually need to know how TCP works, or can I just use HTTP libraries and ignore everything underneath? The answer depends on what kind of engineer you want to be and what kinds of problems you want to solve.

You Already Use Networking Concepts Daily

Every time you make an API call, you are using HTTP over TCP over IP. Every time you deploy to a cloud provider, your application lives inside a VPC (Virtual Private Cloud) with subnets, routing tables, and security groups - all networking constructs. Every time you configure a database connection string, you specify a hostname and port - networking primitives. Every time you set a timeout on an HTTP request, you are making a decision about how long to wait for a network round trip.

The difference between an engineer who understands networking and one who does not shows up when things go wrong. The engineer who understands networking can reason about why a request is timing out (is it DNS resolution? TCP handshake? TLS negotiation? Server processing? Network congestion?), while the engineer who does not must resort to trial and error.

System Design Interviews Require It

If you are preparing for FAANG or top-tier tech company interviews, System Design questions are unavoidable from mid-level onward. And System Design is fundamentally about networked systems. "Design a URL shortener," "Design a chat application," "Design a CDN" - every one of these requires understanding how data moves between clients and servers, how DNS works, how load balancers distribute traffic, how caching reduces latency, and how geographic distribution affects performance.

You do not need to be a network engineer to pass these interviews. But you need a solid mental model of what the network is doing beneath your application. This course builds that mental model.

Production Debugging Demands It

In production, the network is often the first suspect when something goes wrong. Latency spikes, connection resets, DNS failures, certificate expirations, packet loss, bandwidth saturation, firewall misconfigurations - these are networking problems that manifest as application problems. Without networking knowledge, you cannot tell the difference between a slow database query and a saturated network link. With it, you can isolate the problem layer by layer in minutes instead of hours. You know to check DNS resolution time first, then TCP connection time, then TLS handshake time, then time-to-first-byte from the server. Each of these measurements tells you something different about where the delay is occurring, and each points to a different fix. This systematic approach to debugging networked systems is one of the most valuable skills this course teaches.

Interactive animation: Debugging layer by layer - DNS lookup, TCP handshake, TLS handshake and time to first byte each point to a different fix.

Cloud Infrastructure Is Networking

Modern cloud platforms are networking products at their core. AWS VPCs, Azure Virtual Networks, GCP VPC networks - these are all networking constructs. Security groups are firewall rules. Load balancers are network devices. CDNs are globally distributed caches placed at network edge points. Service meshes are application-layer networking overlays. If you work in cloud infrastructure in any capacity, you are doing networking whether you realize it or not. The engineers who understand the networking layer beneath their cloud resources consistently make better architecture decisions - choosing the right instance placement for low latency, configuring security groups correctly on the first try, and understanding why their cross-region replication has a latency floor that no optimization can reduce.

How This Course Is Structured

This course takes you from absolute fundamentals to production-level networking knowledge across 18 modules. Whether you are learning networking for the first time or revisiting it for interview preparation, the goal is the same: build a clear, layered mental model of how data moves through networks, and connect every concept to the real engineering decisions you will face. The structure follows the network stack from the bottom up - starting with how bits become signals on a wire, moving through the layers that organize and route data, and ending with the application-layer protocols and security mechanisms that you interact with every day.

The Learning Path

Interactive animation: The course in four stages up the stack - foundations, core protocols, infrastructure and advanced topics, modules 0 to 17.

The course is organized into roughly four stages:

Foundations (Modules 0-2): What the internet is, how data physically travels, network models that organize everything else. If you are a complete beginner, start here. If you already understand the OSI model and can explain what a packet is, you can skim these and move to Module 3.

Core Protocols (Modules 3-8): IP addressing, subnetting, routing, TCP, UDP, DNS, HTTP. This is the heart of the course - the protocols you will reference in System Design interviews and encounter in production every day. Most learners should spend the majority of their time here.

Infrastructure (Modules 9-13): Network security (TLS, firewalls), load balancers, CDNs, network programming (sockets), and cloud networking (VPCs, SDN). This is where networking meets the infrastructure you build on as a software engineer.

Advanced Topics (Modules 14-17): Network troubleshooting, performance optimization, emerging technologies, and a comprehensive review that ties everything together.

Where to Start Based on Your Experience

If you are entirely new to networking and do not know what TCP or DNS mean, start at Module 0 and read sequentially. The course is designed to build concepts on top of each other, and skipping ahead will leave gaps.

If you have some networking exposure - you know roughly what IP addresses are, you have heard of TCP and UDP, you know DNS translates hostnames to IP addresses - consider starting at Module 3 (IP Addressing) and returning to Modules 0-2 only if something in a later module does not make sense.

If you are an experienced engineer reviewing for System Design interviews, jump directly to the topics that matter most for interviews: DNS (Module 7), HTTP (Module 8), TLS (Module 9), Load Balancers and CDNs (Modules 10-11), and Cloud Networking (Module 13). Use the rest of the course as reference when you encounter a concept you want to understand more deeply.

graph LR
    subgraph Path["Course Learning Path"]
        direction LR
        FOUND["Foundations<br/>M00-M02<br/>Internet basics,<br/>Physical & Data Link"]
        CORE["Core Protocols<br/>M03-M08<br/>IP, TCP, UDP,<br/>DNS, HTTP"]
        INFRA["Infrastructure<br/>M09-M13<br/>Security, LBs,<br/>CDNs, Cloud"]
        ADV["Advanced<br/>M14-M17<br/>Troubleshooting,<br/>Performance"]
    end

    FOUND --> CORE --> INFRA --> ADV

    style FOUND fill:#c4b5fd,stroke:#a78bfa,color:#000
    style CORE fill:#7c3aed,stroke:#6d28d9,color:#fff
    style INFRA fill:#4f46e5,stroke:#4338ca,color:#fff
    style ADV fill:#4338ca,stroke:#3730a3,color:#fff

This diagram shows the four stages of the course learning path from left to right. Foundations covers Modules 0 through 2, including internet basics and the physical and data link layers. Core Protocols covers Modules 3 through 8, including IP, TCP, UDP, DNS, and HTTP. Infrastructure covers Modules 9 through 13, including security, load balancers, CDNs, and cloud networking. Advanced covers Modules 14 through 17, including troubleshooting and performance. Arrows show the recommended sequential progression through all four stages.

What This Course Is and Is Not

Interactive animation: A first-principles guide for software engineers - not certification prep for network administrators, and not a substitute for the RFCs.

This course is a comprehensive guide to computer networking for software engineers. It explains concepts from first principles, uses real-world examples and analogies, includes hands-on exercises, and connects every topic to practical engineering and interview relevance.

This course is not a certification prep course for the CCNA, CompTIA Network+, or other networking certifications. Those certifications focus on network administration and hardware configuration - important skills for network engineers, but a different audience from software engineers preparing for FAANG interviews. The concepts overlap significantly, but the depth and emphasis differ.

This course is not a replacement for reading RFCs or protocol specifications. When you need the precise, authoritative definition of how TCP handles retransmission, the RFC is the source. This course gives you the mental model that makes reading the RFC productive.

Interview: Networking knowledge appears in System Design interviews in predictable ways. Interviewers rarely ask you to recite protocol specifications. Instead, they test whether you understand the implications of networking on system architecture:

"How would you reduce latency for users in Asia?" (CDN placement, DNS-based routing, regional deployments)

"What happens when the database server is unreachable?" (TCP timeouts, retries, circuit breakers, health checks)

"How would you handle 10 million concurrent connections?" (load balancing, connection pooling, protocol selection - HTTP/2, WebSockets, gRPC)

This course equips you to answer these questions with confidence because you will understand the networking primitives that underpin every system design decision.

What Comes Next

The next topic takes you on a 10,000-foot tour of the internet itself - what it physically is, how it is organized, who runs it, and how data gets from your device to a server on the other side of the planet. Understanding the physical reality of the internet prevents the common mistake of thinking about networking as purely abstract.

Exercise: Starter: Open a terminal and run ping google.com. Look at the output - you will see round-trip times in milliseconds. This is how long it takes for a tiny packet of data to travel from your device to a Google server and back. Try pinging a few different sites (ping amazon.com, ping github.com). Are the round-trip times different? Why might some servers respond faster than others?

Intermediate: Run traceroute google.com (Mac/Linux) or tracert google.com (Windows). This shows every router your data passes through on the way to Google. Count the number of hops. Can you identify any of them by their hostnames (many routers are named after the city they are in)? What does this tell you about the physical path your data takes?

Advanced: Research the concept of "peering" between internet service providers. When you access a website, your data may pass through multiple ISP networks before reaching the destination. How do ISPs decide which networks to exchange traffic with? What is the difference between peering (free exchange) and transit (paid exchange)? Look up a peering exchange near you (like DE-CIX, AMS-IX, or Equinix) and see how many networks connect there.

Back to Computer Networking