What is a Network?

LinkedIn Hook

Every developer has written fetch("https://api.example.com/data") — but almost none of them can answer: what actually happens between that line of code and the response coming back?

Spoiler: your request doesn't travel as one chunk. It's shredded into dozens of tiny labeled envelopes, sent across multiple countries through cables under the ocean, reassembled at the other end — all in under 100ms.

Understanding networks is not just "ops stuff." It's the difference between debugging a timeout in 10 minutes versus 10 hours. It explains why your API is slow, why WebSockets exist, and why your CORS error is not what you think it is.

In this lesson: what a network actually is, how data moves as packets, the client-server model, peer-to-peer, and why every developer — not just DevOps — needs to understand this.

Read the full lesson → [link]

#Networking #WebDevelopment #BackendEngineering #SystemDesign #InterviewPrep

---

---

What You'll Learn

• What a computer network is and the real-world analogy that makes it click
• How data is broken into packets and why that design decision changed everything
• The difference between the client-server model and peer-to-peer (P2P) — and when each is used
• Why networking knowledge is essential for application developers, not just infrastructure engineers

---

The Postal System Analogy

Imagine you need to send a 500-page manuscript from New York to London. You would not wrap the entire manuscript in one enormous envelope — it would be too heavy, unreliable, and if it got lost in transit, everything would be gone.

Instead, a smart postal service would:

1. Split the manuscript into 50 numbered envelopes of 10 pages each
2. Write the sender's address and receiver's address on every envelope
3. Let each envelope travel independently — some via air, some via ship
4. Have the receiver collect all 50 envelopes and reassemble them in order

This is almost exactly how computer networks work. Replace "envelopes" with packets, replace "address" with IP address, and replace "postal routes" with network routers — and you have the internet.

The insight is profound: by breaking data into small, independently routed pieces, the network becomes fault-tolerant, scalable, and fast. If one route is congested, packets take a different path. If one packet is lost, only that packet is re-sent, not the entire message.

---

What is a Network?

A computer network is two or more devices connected in a way that allows them to exchange data. That definition sounds simple, but the scale ranges from two laptops connected by a cable in your living room (a Local Area Network, or LAN) to the entire internet — billions of devices communicating simultaneously through a global mesh of cables, routers, and wireless signals.

Every network has three fundamental components:

Component	Role	Real-World Analogy
Devices (nodes)	The participants that send or receive data	People sending/receiving letters
Links	The physical or wireless channels connecting devices	Roads, cables, phone lines
Protocols	The agreed rules for how data is formatted and transmitted	Language and postal standards

Without protocols, two devices cannot communicate even if they are physically connected — just as two people speaking different languages cannot understand each other even if they are in the same room.

---

How Data Moves — Packets

When you load a webpage, the server does not send you the entire HTML file as one stream. The data is split into packets — small fixed-size chunks, typically 1,500 bytes each (the standard Ethernet MTU).

Each packet contains:

• Header: source IP address, destination IP address, packet sequence number, protocol info
• Payload: the actual chunk of data
• Trailer: error-checking information (checksum)

Packets from the same request may travel different physical routes across the internet, arriving out of order. The receiving device uses the sequence numbers to reassemble them correctly. If a packet is lost or corrupted, the protocol (TCP) requests only that packet again.

Code Example — Visualizing Packet Structure Conceptually

// Conceptual representation of how a packet is structured
// This is NOT actual low-level code — it models the concept in JavaScript

function createPacket(sequenceNumber, sourceIP, destinationIP, payload) {
  return {
    header: {
      sourceIP: sourceIP,           // Where this packet came from
      destinationIP: destinationIP, // Where this packet is going
      sequenceNumber: sequenceNumber, // Used to reassemble in correct order
      protocol: "TCP",              // Rules for transmission
      ttl: 64,                      // Time To Live — max hops before discard
    },
    payload: payload,               // The actual chunk of data
    trailer: {
      checksum: computeChecksum(payload), // Detects corruption in transit
    },
  };
}

function computeChecksum(data) {
  // Simplified — real checksum is a mathematical hash of the payload bytes
  return data.split("").reduce((sum, char) => sum + char.charCodeAt(0), 0);
}

// Simulating splitting a message into packets
function splitIntoPackets(message, sourceIP, destinationIP, chunkSize = 20) {
  const packets = [];
  for (let i = 0; i < message.length; i += chunkSize) {
    const chunk = message.slice(i, i + chunkSize);
    const seqNum = Math.floor(i / chunkSize);
    packets.push(createPacket(seqNum, sourceIP, destinationIP, chunk));
  }
  return packets;
}

// Example usage
const message = "Hello, this is a network message being split into packets.";
const packets = splitIntoPackets(message, "192.168.1.10", "93.184.216.34");

console.log(`Original message length: ${message.length} characters`);
console.log(`Total packets created: ${packets.length}`);
console.log("\nFirst packet:");
console.log(JSON.stringify(packets[0], null, 2));

Output:

Original message length: 59 characters
Total packets created: 3

First packet:
{
  "header": {
    "sourceIP": "192.168.1.10",
    "destinationIP": "93.184.216.34",
    "sequenceNumber": 0,
    "protocol": "TCP",
    "ttl": 64
  },
  "payload": "Hello, this is a netw",
  "trailer": {
    "checksum": 1890
  }
}

---

The Client-Server Model

The most common network architecture you encounter as a developer is client-server. One device (the client) requests a resource or service. Another device (the server) fulfills that request.

Key characteristics:

• The server is always-on, waiting for incoming requests
• The client initiates the connection
• One server can handle thousands of simultaneous clients
• The server holds the authoritative data; clients consume it

Every time you open a browser, your browser is a client. Every API call your application makes turns your app into a client. The machine responding — whether it is AWS, a VPS, or a Raspberry Pi — is the server.

Code Example — A Real HTTP Client-Server Interaction in Node.js

// ---- SERVER SIDE ----
// A minimal HTTP server in Node.js (built-in 'http' module, no frameworks)
const http = require("http");

const server = http.createServer((request, response) => {
  // The server receives a request object containing all client information
  console.log(`Incoming request: ${request.method} ${request.url}`);
  console.log(`Client IP: ${request.socket.remoteAddress}`);

  if (request.method === "GET" && request.url === "/api/greeting") {
    // Server processes the request and sends a response
    response.writeHead(200, { "Content-Type": "application/json" });
    response.end(JSON.stringify({ message: "Hello from the server!", time: new Date().toISOString() }));
  } else {
    response.writeHead(404, { "Content-Type": "application/json" });
    response.end(JSON.stringify({ error: "Route not found" }));
  }
});

// The server listens on port 3000 — waiting for clients to connect
server.listen(3000, () => {
  console.log("Server is running and listening on port 3000");
  console.log("Waiting for client connections...");
});

// ---- CLIENT SIDE ----
// A simple HTTP client making a request to the server above
// Run this in a separate process or browser

async function fetchGreeting() {
  try {
    // The client initiates the connection to the server's IP and port
    const response = await fetch("http://localhost:3000/api/greeting");

    // The client receives the server's response
    const data = await response.json();

    console.log("Response received from server:");
    console.log(`Status: ${response.status}`);   // 200 means success
    console.log(`Message: ${data.message}`);
    console.log(`Server time: ${data.time}`);
  } catch (error) {
    // Network errors (server down, timeout, wrong port) surface here
    console.error("Could not reach the server:", error.message);
  }
}

fetchGreeting();

Server output (when client connects):

Server is running and listening on port 3000
Waiting for client connections...
Incoming request: GET /api/greeting
Client IP: 127.0.0.1

Client output:

Response received from server:
Status: 200
Message: Hello from the server!
Server time: 2026-04-21T09:00:00.000Z

This entire exchange — initiation, transmission, response — is the client-server model in action. The same flow happens when your React frontend calls a REST API, when your Node.js backend queries a PostgreSQL database, or when a mobile app syncs data.

---

Peer-to-Peer (P2P) Networking

Not all networks follow the client-server model. In peer-to-peer (P2P) networking, each device (called a peer) acts as both a client and a server simultaneously. There is no central authority.

Examples you already know:

• BitTorrent: When downloading a file, your machine downloads pieces from dozens of peers while simultaneously uploading pieces to other peers
• WebRTC: Video calls in the browser (Google Meet, browser-based games) use P2P to send audio/video directly between browsers without routing through a central server
• Blockchain: Each node holds a full copy of the ledger and validates transactions without a central database

When to choose P2P:

Scenario	Why P2P Fits
File sharing at scale	No single server needs to host the entire file
Real-time communication	Lower latency — no round-trip through a central server
Resilience	No single point of failure — the network survives node loss
Censorship resistance	No central server to shut down

When to choose Client-Server:

Scenario	Why Client-Server Fits
Centralized data authority	One source of truth for databases
Access control and auth	Server enforces permissions
Complex business logic	Easier to update server code than distributed peers
Billing and metering	Server tracks usage reliably

Most production applications you build will use client-server. But knowing P2P exists — and when to reach for WebRTC for real-time features — is what separates a senior developer from a junior one.

---

Why Developers (Not Just Network Engineers) Need This

A common misconception is that networking is "infrastructure knowledge" — relevant only to DevOps, SREs, and network engineers. This is wrong, and it becomes obvious the moment something breaks.

Here is what networking knowledge directly enables for application developers:

Debugging: When a request fails, you need to know: Is the DNS not resolving? Is the TCP handshake completing? Is the server receiving the request but returning an error? Without networking knowledge, every problem looks like a code bug.

Performance: Understanding that each HTTP/1.1 request opens a new TCP connection (with a 3-way handshake taking ~100ms) explains why HTTP/2 (which multiplexes requests over one connection) is faster. You cannot optimize what you do not understand.

Security: SQL injection and XSS are application-layer vulnerabilities. But man-in-the-middle attacks, DNS spoofing, and session hijacking are network-layer vulnerabilities. You cannot write secure code without understanding the transport layer your code runs on.

Architecture decisions: Choosing between REST and WebSockets, between polling and long-polling, between TCP and UDP for a game — all of these decisions require networking fundamentals.

System design interviews: Every system design interview at Google, Meta, Amazon, or a startup will involve network topology, load balancers, CDNs, and latency budgets. You cannot fake this knowledge in a 45-minute interview.

---

Common Mistakes

• Assuming the network is reliable. Developers often write code that assumes HTTP requests will always succeed. In reality, packets get dropped, connections time out, DNS resolution fails, and servers restart. Always handle network errors explicitly — never assume fetch() will succeed.

• Treating network latency as zero. Making 20 sequential API calls inside a loop feels fine locally (localhost latency is ~0.1ms). In production across the internet (latency of 80–200ms per round trip), this creates a 1.6–4 second delay. Developers who understand networking batch requests, use parallel calls, and cache aggressively.

• Confusing client-server with request-response. The client-server model does not mandate that the server can only respond — it can also push data. WebSockets, Server-Sent Events (SSE), and HTTP/2 server push all allow the server to send data to the client without a new request. Developers who understand the model at the network layer are not confused when these patterns appear.

---

Interview Questions

Q: What is a computer network, and what are its three core components?

A computer network is two or more devices connected to exchange data. The three core components are: nodes (the devices sending or receiving data), links (the physical or wireless channels connecting them), and protocols (the agreed-upon rules for formatting and transmitting data). Without all three, communication cannot happen reliably.

Q: Why is data sent as packets rather than as a continuous stream?

Packets make the network fault-tolerant and efficient. If data traveled as one continuous stream, a single point of failure would drop the entire transmission. With packets, each chunk is independently routed — if one packet is lost, only that packet is retransmitted. Packets can also take different routes around congestion, making the network self-healing. This design, from the original ARPANET, is why the internet is resilient.

Q: What is the difference between the client-server model and peer-to-peer networking? Give a real-world example of each.

In the client-server model, one device (the client) requests resources from a dedicated device (the server) that is always available. Example: your browser (client) requesting a webpage from nginx running on AWS (server). In peer-to-peer, every device acts as both client and server — there is no central authority. Example: BitTorrent, where each downloader simultaneously uploads pieces to other peers. The client-server model offers centralized control and easier consistency; P2P offers resilience and eliminates the need for a central host.

Q: You make an API call from your React frontend and it fails. Walk me through the network layers you would check to diagnose the problem.

Start from the outermost layer and work inward: (1) DNS — is the hostname resolving to an IP address? Use nslookup or dig. (2) TCP connection — is the TCP handshake completing? Use telnet <host> <port> or nc. (3) TLS/SSL — if HTTPS, is the certificate valid and the TLS handshake succeeding? (4) HTTP — is the server receiving the request? Check status codes — 4xx means client error, 5xx means server error. (5) Application layer — is the response body correct? Is there a CORS header missing? Systematically checking each layer eliminates guesswork.

Q: A junior developer says "networking is for DevOps, not developers." How would you respond?

Networking is foundational for application developers because it directly impacts debugging, performance, security, and architecture decisions. When a request times out, you need to know if it is a DNS failure, a TCP timeout, or an application error — this is impossible to diagnose without networking knowledge. Performance optimization (batching requests, using HTTP/2, choosing the right protocol) requires understanding how data travels. Security vulnerabilities like man-in-the-middle attacks operate at the network layer. And system design interviews at top companies explicitly test networking knowledge. Every abstraction in web development — HTTP, WebSockets, REST, gRPC — sits on top of networking fundamentals.

---

Quick Reference — Cheat Sheet

Key Concepts

Concept	One-Line Definition
Network	Two or more devices connected to exchange data
Packet	A fixed-size chunk of data with a header, payload, and trailer
IP Address	A unique numerical label identifying a device on a network
Protocol	Agreed-upon rules for formatting and transmitting data
Client	A device that initiates a request for a resource
Server	A device that listens for and fulfills client requests
Peer (P2P)	A device that acts as both client and server simultaneously
Port	A logical endpoint on a device; separates traffic by service
Latency	The time it takes for a packet to travel from source to destination
Bandwidth	The maximum rate of data transfer across a network connection

Client-Server vs. Peer-to-Peer

CLIENT-SERVER MODEL
===================

  [Client A] ──┐
  [Client B] ──┤──► [Server] ◄──┬── [Client C]
  [Client D] ──┘                └── [Client E]

  - One authoritative server
  - Clients only talk to the server
  - Server can become a bottleneck
  - Easier access control and consistency

PEER-TO-PEER MODEL
==================

  [Peer A] ──────── [Peer B]
     │    ╲         │
     │     ╲        │
  [Peer C] ─── [Peer D]

  - Every node is both client and server
  - No single point of failure
  - Decentralized — no central authority
  - Used in: BitTorrent, WebRTC, Blockchain

Packet Anatomy

┌─────────────────────────────────────────────────────────┐
│                        PACKET                           │
├──────────────────┬────────────────────┬─────────────────┤
│     HEADER       │      PAYLOAD       │    TRAILER      │
│  Source IP       │                    │                 │
│  Dest IP         │  Actual data chunk │  Checksum       │
│  Seq Number      │  (up to ~1,500 B)  │  (error check)  │
│  Protocol        │                    │                 │
│  TTL             │                    │                 │
└──────────────────┴────────────────────┴─────────────────┘

Common Ports to Know

Port	Protocol	Used For
80	HTTP	Unencrypted web traffic
443	HTTPS	Encrypted web traffic
22	SSH	Secure shell / remote login
5432	PostgreSQL	Database connections
3306	MySQL	Database connections
6379	Redis	Cache / message broker
3000	Custom (Node.js convention)	Local dev servers

---

Previous: — Next: Lesson 1.2 — Network Types: LAN, WAN, and the Internet →

---

This is Lesson 1.1 of the Networking Interview Prep Course — 8 chapters, 32 lessons.