Networking

The whole web runs on one simple pattern: one machine asks, another machine answers.

The machine doing the asking is the client — your browser, on your laptop or phone. The machine doing the answering is the server. A server isn't anything exotic: it's just a computer that can take in a request, do some processing, and send back data. Your own laptop can be a server — the catch is reliability. It shuts down, has limited RAM/CPU/storage, and can't handle thousands of people at once. So real websites run on dedicated, high-end machines that stay on 24/7 and are always connected to the internet.

• The first response is HTML. Hit flipkart.com and the very first thing the server sends back is an HTML document — the skeleton of the page. The browser reads it and knows how to structure everything.
• HTML, CSS, JS each have a job. HTML is the structure the browser natively understands, CSS is the look and feel, and JavaScript is the interactivity.
• The HTML points to more files. Inside that first HTML are references to CSS, JS, and images. The browser sees them and goes back to fetch each one — more requests, more responses.
• The Network tab shows it all. Every request your browser makes (and the response it gets) appears in DevTools → Network — the single best place to watch this loop happen.

A domain name is the human name; an IP address is the actual location. You always need the location to deliver anything.

For two devices to talk over the internet, each needs a unique IP address — a numeric address like 152.222.122.2. Think of it as the precise street address of a machine. Anything on the internet you want to reach needs its own IP so you can find it.

But nobody remembers numbers like that — we remember google.com, amazon.com. Those memorable names are domain names. The problem: a name alone gets you nowhere, the same way handing a postman only a person's name gets your parcel nowhere — he needs the specific address. So something has to translate the name into an IP before any real request can be sent. That translator is DNS.

DNS (Domain Name System) is the lookup service that turns a domain name into the IP address behind it.

When you type google.com, your request reaches a special server called a DNS server. Your machine essentially asks: "What's the IP address for google.com?" DNS is like a giant phone book — look up the name, get back the number.

A domain name isn't one flat label — it's a hierarchy, and DNS resolves it by drilling down level by level, the way you'd route a government complaint to the right department, then the right desk. There are far too many domains in the world to keep in one flat list, so the lookup is distributed across layers of servers.

• Root — the implied dot at the very end; the top of the tree, the starting point of every lookup.
• Top-level domain (TLD) — .com, .org, .in, .gov. Tells DNS which broad zone to dig into.
• Second-level domain — the organization itself: google, microsoft.
• Third-level / subdomain — www, sales, mail. A finer slice within that org.

Between your device and the wider internet sits a chain of equipment whose only job is to get your request out and the response back.

Wiring every laptop directly to every other laptop with cables would be a network hell — connecting just 8 machines would need a tangle of wires. So the real internet is a smart mix of wired and wireless links arranged in layers.

In a multi-floor building, one central router feeds LAN/fiber cables up to a router on each floor, and each broadcasts Wi-Fi locally — that's how everyone gets a strong signal instead of one weak router covering everything. Zoom out further: your whole neighborhood usually has a central hub that takes one fiber line from the ISP and distributes it.

The high-level journey, in order

"The server" is rarely one machine — it's racks of computers in a data center, connected to you by very real, very physical cables.

Billions of people use Google, Facebook, Microsoft. One machine can't serve that load, so big services run data centers: large rooms full of CPUs, RAM, storage, and power backup — no monitors, just compute. Inside, many machines map to the IPs you reach, and extra layers (like load balancers) decide which machine handles each request.

A single server also does more than dump files — it runs application code (Node.js/Express, Java servlets). When you hit a path like /engineer/chirag, the developer's code on that machine decides what to return for that exact route.

Why wires, not satellites

If the server is on the other side of the planet, how does data cross oceans? Satellites are wireless and roughly 22,000 miles up — slow over that distance and easily disrupted by weather, so not reliable for everyday traffic. Instead, the world is connected by undersea optical-fiber cables laid across the ocean floor, carrying data at close to the speed of light. That's why a page from another continent loads in a blink.

ISPs come in tiers, and the data they move travels as small numbered packets — not one big block.

A cross-country request hops local → regional → global ISP, across the ocean, then global → regional → local on the far side to reach the server — many hops each way.

Data travels in packets

The response doesn't ship as one assembled blob, the way a parcel doesn't fly back as one giant box. It's broken into many small data packets that each take whatever route is available, then get reassembled at your local ISP and handed to you. This is why a flaky connection can leave you with a half-finished result — e.g. a payment stuck on "still processing" when some packets are lost.

The fastest request is the one you never have to make. Before going to a server, the browser checks a series of caches in order, stopping the moment it finds a usable copy.

1. Browser HTTP cache — does the browser already have this resource/IP cached?
2. Service worker cache — a script that can intercept requests and answer from its own cache.
3. Operating system — checks the OS hosts file (you can map e.g. google.com → localhost:3000 for local dev).
4. Router — modern routers cache domain → IP mappings (why "restart your router" sometimes refreshes things).
5. ISP — ISPs cache aggressively too, at a much larger scale.

What you see in the Network tab

• 304 Not Modified — the browser asked the server, the server said "nothing changed, reuse what you have." No new data transferred.
• 200 (from service worker) — the response came from the service worker, not the network. This can return data in ~1–2 ms — impossibly fast for a real server round trip, which is the whole point of caching.
• (from disk cache) — served straight from the browser's on-disk cache.

Before any real page data moves, the client and server do two quick "handshakes" to set up a reliable, secure connection.

Why the first 14 KB matters

HTTP responses don't all arrive at once — they grow in chunks (roughly 14 KB, then ~28 KB, then ~56 KB …). That very first ~14 KB is special: if the critical HTML/CSS needed to show something fits inside it, the page can render meaningful content in a single round trip, and perceived performance jumps.

Google and Netflix don't accept the slow default path — they physically move data closer to you and cut out hops.

Both are the same idea: shorten the conversation. Put data physically nearer the user so fewer hops and less distance stand between request and response.

Domain names and ownership aren't a free-for-all — specific authorities set the rules and keep the records.

Once the files arrive, the browser runs a fixed, ordered pipeline to turn HTML, CSS, and JS into the picture on screen — one of the most-asked frontend system-design topics.

At a high level there are four phases: load the needed data, execute scripts, render the content, and paint the final result. Two facts shape everything:

• DOM tree — HTML parsed into a tree of nodes (html → head/body → div/p/span …).
• CSSOM — all CSS rules parsed into a parallel tree; conflicts resolved by specificity and inheritance (visible in DevTools → Computed).
• JavaScript execution — runs on a single main thread: parse (blocking), build an AST, compile to bytecode, then execute.
• Render tree — DOM and CSSOM merged; hidden/non-visible nodes dropped; final styles applied.
• Layout — compute the geometry: how many boxes, what size, where each sits (the floor plan).
• Paint — fill in pixels: colors, fonts, borders, backgrounds (tiles and paint go on).
• Composite — stack the layers by z-index — popups and overlays on top, hidden things behind (the furniture goes in last).

These are the two transport "roads" every higher-level protocol drives on. Almost every networking interview comes back to this distinction, so anchor it first.

TCP (Transmission Control Protocol) is the reliable road. Before sending anything it does a three-way handshake: the client sends a SYN ("I want to talk, are you ready?"), the server replies SYN-ACK ("yes, and here's a sequence number to use"), the client sends ACK ("got it"). That sequence number is the key idea: it lets TCP detect a missing packet and resend it, so no data is lost and everything arrives in order.

UDP (User Datagram Protocol) is the fast road. No handshake, no sequence tracking — it just starts firing packets. If some get lost, UDP doesn't care and won't resend. You trade guaranteed delivery for raw speed and low latency.

HTTP (HyperText Transfer Protocol) is the "mother tongue" browsers and servers use to exchange web pages and resources.

HTTP defines the structure of a request and a response — what you ask for, how the server answers, how the data is shaped. Think of it like the signs and directions on a highway: the road (TCP) carries you, but HTTP tells you how to use it to reach the right place. It runs on top of a TCP connection: open the connection, make a request, get the response.

• Used everywhere in browsing. Loading a page, fetching images, calling an API — standard web communication is HTTP.
• Classic HTTP = one connection per request. In the basic model, each new request opens a fresh TCP connection. (Newer versions reuse connections.)
• It sits above the transport layer. HTTP doesn't move bytes itself — TCP does. HTTP just defines the conversation.

HTTPS is plain HTTP plus encryption, so no one in the middle can read your data.

Almost everything is identical to HTTP, with one addition: after the TCP connection, it does an extra SSL/TLS handshake. The server shares a public key; the client uses it to encrypt data, and a session key is established. From then on, both sides encrypt before sending and decrypt on arrival. Anyone who intercepts a packet in between sees only scrambled bytes.

• The "s" is security. When the URL starts with https, that TLS handshake is happening under the hood.
• Two-way encryption. Server encrypts its responses; client encrypts its requests.
• Hard to steal data. Even if a packet is intercepted, it can't be read without the keys.

HTTP/3 is a modern version of HTTP that runs on UDP instead of TCP, trading TCP's handshake overhead for raw speed.

Where classic HTTP leans on TCP's reliability (and its slower setup), HTTP/3 uses QUIC, which is built on UDP. It starts sending data with far less back-and-forth, and adds its own mechanisms to stay reliable on top of UDP. This is heavily used at scale by Google and YouTube.

WebSocket keeps a single connection open so client and server can send messages to each other anytime — no new request needed each time.

Normal HTTP is one-shot: the client asks, the server answers, done. That's wrong for live features. WebSocket fixes it with an upgrade: the connection starts as HTTP, then upgrades to a WebSocket (ws) connection using the 101 Switching Protocols status code. After that, it's a full-duplex, long-lasting line — either side can push data whenever it wants, with no repeated connection setup.

• Full-duplex — client and server can both send simultaneously over one connection.
• Long-lasting — one persistent connection, instead of opening a new one per message.
• Where it's used — live chat, live data streaming, analytics dashboards, YouTube comments/likes — anything real-time.

Two special-purpose protocols: one to push email, one to move large files.

The whole chapter in one table — what each protocol is, what it rides on, and when to reach for it.

REST exists because we stopped cramming everything into one program. Understanding the split explains why an API is even needed.

Picture a restaurant (our running analogy): there's the dining area where customers sit and order (the front end / client) and the kitchen where food is prepared (the back end / server). As the business grew, keeping everything in one place stopped scaling — so the parts got separated.

Beyond three, an n-tier setup has the back end calling other services (payments, search, etc.). The point: once client and server are separate machines, something must carry messages between them in a structured way — that's the API.

REST is a standard for representing and transferring data between web services, layered on top of HTTP.

• API (Application Programming Interface) — the general idea of letting two programs communicate, even in different languages.
• REST (REpresentational State Transfer) — one popular kind of API. It decides how the data is represented in transfer. Alternatives exist: GraphQL, gRPC, tRPC.
• HTTP underneath — REST doesn't move bytes itself; it leverages HTTP as the foundation for the communication.

REST is everywhere because it's simple, stateless, and inherits a lot of power from HTTP for free.

Every REST message — in both directions — has three parts. Learn these and the rest is detail.

Anything coming from the client lives in the request object; anything sent back lives in the response object. In DevTools → Network you can see all of it: request URL, request headers, response headers, status code, and the body (with a separate Payload tab when you send data).

A domain only gets you to the server. The URL carries the rest: which code to run, and what extra info to pass.

• Scheme — http or https (secure). Says which protocol to use.
• Host — reaches the right server. Made of subdomain (www, course…) + domain name (engineerchirag) + TLD (.in, .com).
• Path / route — digs into the server to the exact code to run. Can be a real folder structure or (usually) a dynamic route, e.g. Flipkart's /search.
• Query params — extra info after ?, as key=value pairs joined by &. Passed into the server function.
• Fragment / hash — after #. Used for scroll-to-section links and front-end (hash) routing. Critical: the hash is never sent to the server — so server telemetry won't see it, and hash routers can surprise you.

The method tells the server what action you intend. The four core actions form CRUD: Create, Read, Update, Delete.

Other methods worth knowing

• HEAD — like GET but returns only headers, no body. Used to check if headers changed without fetching data.
• OPTIONS — a security preflight: before a cross-origin request, the browser asks "am I allowed?" This underpins CORS.
• CONNECT — establishes a connection ahead of time so a later request skips the handshake and is faster.
• TRACE — diagnostic; echoes the request for debugging. Kept to dev only — it can leak server info, so disable in production.

URL & body conventions per method

The same path can serve different methods — /todos handles GET (read all) and POST (create) at once. That reuse is a hallmark of REST.

Express is a minimal framework on top of Node.js. With a few lines you get a working REST API. Here's the whole CRUD flow.

// index.js — set "type":"module" in package.json to use import
import express from 'express';
import bodyParser from 'body-parser';

const app = express();
const PORT = 5111;

app.use(bodyParser.json());   // parse JSON body for every request
let todos = [
  { id: 1, title: 'task one', completed: false },
  { id: 2, title: 'task two', completed: true },
];

// READ all
app.get('/todos', (req, res) => res.json(todos));

// CREATE
app.post('/todos', (req, res) => {
  todos.push(req.body);
  res.status(201).json({ message: 'New todo added' });
});

// UPDATE (PUT) — id from URL param
app.put('/todos/:id', (req, res) => {
  const id = req.params.id;
  const i = todos.findIndex(t => t.id == id);
  if (i === -1) return res.status(400).json({ message: 'Todo id does not exist' });
  todos[i] = { ...req.body, id };
  res.json({ message: 'Todo updated successfully' });
});

// DELETE — id from URL param
app.delete('/todos/:id', (req, res) => {
  const i = todos.findIndex(t => t.id == req.params.id);
  if (i !== -1) todos.splice(i, 1);
  res.json({ message: 'Todo deleted successfully' });
});

app.listen(PORT, () => console.log(`Server running at port ${PORT}`));

• Setup — npm init creates package.json; npm i express body-parser installs dependencies; npm i nodemon auto-restarts on file changes.
• A route = path + callback — app.get('/todos', (req, res) => {...}): run this function when someone hits that path with that method.
• Body parsing — data travels over the wire serialized (stringified). body-parser as middleware turns req.body back into a usable object for every request.
• Test with Postman — the browser can only send GET easily; Postman lets you send POST/PUT/DELETE with a JSON body, or use curl.

Headers are key-value metadata attached to requests and responses — auth, content type, caching, and more. You don't memorize them all; you stay aware of what's possible.

The status code tells you the outcome — success, redirect, your mistake, or the server's. Returning the right one (not 200 for everything) is what makes an API usable, grouped into five families: 1xx keep going, 2xx success, 3xx redirection, 4xx your error, 5xx the server's error.

Our restaurant owner is going global and needs continents, countries, and languages on screen. In REST, that's three endpoints and three round trips, often returning more than needed.

Why "graph"? Real data is connected: a continent has countries, a country has languages; a social post has likes, friends, friends-of-friends. Data naturally forms a graph, and GraphQL lets you query that graph in a structured, typed way.

You write a query that mirrors the shape you want; the response comes back in that exact shape. (Apollo Studio / a GraphQL playground is the equivalent of Postman here.)

# client query — ask for exactly these fields, nested
query {
  continents { name countries { name languages { name } } }
}

// response — same shape you asked for
{
  "data": {
    "continents": [
      { "name": "Africa",
        "countries": [
          { "name": "Angola",
            "languages": [{ "name": "Portuguese" }] }
        ] }
    ]
  }
}

One request returns the full nested hierarchy — continents → their countries → their languages — no client-side merging needed.

GraphQL was open-sourced by Facebook (built 2012, public 2015). Its power comes from giving the client control and being strongly typed end to end.

A top interview question. Neither "wins" outright — they trade off, and many apps use both.

• Same HTTP underneath. Status codes, request/response, headers — those come from HTTP, not REST. GraphQL uses them too; it just adds power on top. (GraphQL calls are almost always POST.)
• REST isn't going away. Millions of REST services exist; you'll consume both. GraphQL is the rapidly growing newer option.

Four terms unlock GraphQL. The schema (written in SDL, the Schema Definition Language) declares the shape; resolvers provide the data.

A resolver's four arguments

• parent — the parent object in the graph (e.g. the book, when resolving its author). Key for nested relationships.
• args — arguments/filters the client passed (e.g. an id).
• context — shared data across all resolvers in one request (e.g. the logged-in user, DB connection).
• info — metadata about the query execution (field, path …). Rarely needed early on.

A books-and-authors API. The schema declares types + relationships; resolvers fetch the data, including resolving relationships via the parent argument.

// typeDefs.js — schema in SDL
const typeDefs = `#graphql
  type Author { id: ID!, name: String!, books: [Book] }
  type Book   { id: ID!, title: String!, publishedYear: Int, author: Author }

  type Query {
    authors: [Author]      # list of authors
    books: [Book]          # list of books
  }
  type Mutation {
    addBook(title: String!, authorId: ID!, publishedYear: Int): Book
  }
`;
export default typeDefs;

// resolvers.js — functions that supply the data
const resolvers = {
  Query: {
    authors: () => data.authors,
    books:   () => data.books,
  },
  // relationship resolvers use the `parent` arg
  Book: {
    author: (parent) => data.authors.find(a => a.id === parent.authorId),
  },
  Author: {
    books: (parent) => data.books.filter(b => parent.bookIds.includes(b.id)),
  },
  Mutation: {
    addBook: (parent, args) => {
      const newBook = { id: data.books.length + 1, ...args };
      data.books.push(newBook);
      return newBook;
    },
  },
};
export default resolvers;

// index.js — start a standalone Apollo server
import { ApolloServer } from '@apollo/server';
import { startStandaloneServer } from '@apollo/server/standalone';
import typeDefs from './typeDefs.js';
import resolvers from './resolvers.js';

const server = new ApolloServer({ typeDefs, resolvers });
const { url } = await startStandaloneServer(server, { listen: { port: 4001 } });
console.log(`Server ready at ${url}`);

• Apollo Server needs two things — typeDefs (the schema, including Query & Mutation) and resolvers (the implementations). The standalone server bridges to an Express/HTTP server internally.
• Relationship resolving — Book.author and Author.books aren't in the raw data; resolvers use the parent object's authorId/bookIds to look them up, so nested queries return real data instead of null.
• Gotcha from the build — a field defined in a resolver but not in the schema (or a case mismatch like Author vs author) throws "defined in resolver but not in schema." Schema and resolver field names must match exactly.

Under the hood it's just a POST with a stringified query. You can use plain fetch, or a library like Apollo Client for superpowers.

// plain fetch — no library needed
fetch('http://localhost:4001/', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    query: `{ books { id title author { name } } }`,
  }),
})
  .then(res => res.json())
  .then(data => console.log(data));

• The request body carries query (stringified), optional variables (filters/args), and an optional operationName (a label for debugging).
• Apollo Client — a wrapper giving caching and React hooks: useQuery (read) and useMutation (write) return loading, error, and data states. Wrap the app in <ApolloProvider> to use hooks.
• Other client libs — urql, Relay (Facebook), graphql-request, graphql-ws. Server libs include Apollo Server, GraphQL Yoga, Mercurius.

A Remote Procedure Call lets you execute a function that lives on a remote machine as if you'd called it locally.

Normally, machine A asks machine B for data through an exposed API. With RPC, machine A (the client) calls a function written on machine B (the server) directly — you invoke a remote function from your own code as though it were defined right there.

gRPC is Google's open-source framework that implements this. Google didn't invent RPC; gRPC is the framework that drives RPC communication using Protocol Buffers over HTTP/2, with built-in support for load balancing, tracing, health checking, and authentication.

The call passes through stubs and runtimes on both sides, which handle interfaces, serialization, and transport — so your code just calls a function.

• Stub — the generated interface (like a GraphQL schema or TypeScript types) that knows the method signatures.
• RPC runtime — handles the actual transport between machines.
• The round trip — client function → client stub → client runtime → (HTTP/2, binary) → server runtime → server stub → real function executes → result serialized back the same path.

Protobuf is gRPC's data format and interface definition language (IDL) — the equivalent of JSON for REST, but binary and strongly typed.

• IDL — you define the interface (services, methods, message shapes) in a .proto file, the way JSON has a structure or GraphQL has a schema. Current version: proto3.
• Binary on the wire — unlike REST's text JSON, protobuf serializes to binary, which is smaller and faster to encode/decode.
• Serialize / deserialize in any language — protobuf provides the encode/decode methods for every language, so you're not tied to JS's JSON.stringify.
• Code generation — from one .proto file, gRPC generates compatible client and server code for any language.

gRPC requires HTTP/2, which brings real performance wins — and unlocks streaming in multiple directions.

Like a GraphQL schema, the .proto declares the service's methods (rpc) and the message shapes. A customer CRUD example:

syntax = "proto3";

service CustomerService {
  rpc GetAll (Empty)              returns (CustomerList);
  rpc Get    (CustomerRequestId)  returns (Customer);
  rpc Insert (Customer)           returns (Customer);
  rpc Update (Customer)           returns (Customer);
  rpc Remove (CustomerRequestId)  returns (Empty);
}

message Empty {}

message CustomerRequestId { string id = 1; }

message Customer {
  string id      = 1;
  string name    = 2;
  int32  age     = 3;
  string address = 4;
}

message CustomerList { repeated Customer customers = 1; }

• service groups the rpc methods; each declares its request and response message types.
• message defines a custom type. Scalar types include string, int32, bool.
• The field numbers (= 1, = 2 …) are sequence tags used by serialization for ordering and backward/forward compatibility. Never change an existing number once in production — only add new ones.
• repeated means "a list of" — repeated Customer is an array of customers.

A realistic setup: a gRPC server holds the functions; a gRPC client calls them; and an Express server exposes them to the browser as REST (since browsers can't speak gRPC directly).

// server.js — the gRPC server (uses @grpc/grpc-js for JavaScript)
const grpc = require('@grpc/grpc-js');
const protoLoader = require('@grpc/proto-loader');

const packageDef = protoLoader.loadSync('customers.proto', { keepCase: true });
const proto = grpc.loadPackageDefinition(packageDef);

const customers = [
  { id: '1', name: 'Chirag', age: 30, address: 'Bangalore' },
  { id: '2', name: 'Akshay', age: 28, address: 'Uttarakhand' },
];

const server = new grpc.Server();
server.addService(proto.CustomerService.service, {
  GetAll: (call, callback) => callback(null, { customers }),
  Get: (call, callback) => {
    const c = customers.find(x => x.id === call.request.id);
    callback(null, c);
  },
  // Insert, Update, Remove — plain JS on the array (or a DB call)
});
server.bindAsync('127.0.0.1:30043',
  grpc.ServerCredentials.createInsecure(),
  () => console.log('gRPC server started'));

// client.js — load the same proto, create a client stub
const grpc = require('@grpc/grpc-js');
const protoLoader = require('@grpc/proto-loader');
const proto = grpc.loadPackageDefinition(
  protoLoader.loadSync('customers.proto', { keepCase: true }));

const client = new proto.CustomerService(
  'localhost:30043', grpc.credentials.createInsecure());
module.exports = client;

// express bridge — expose gRPC methods to the browser as REST
app.get('/', (req, res) => {
  client.GetAll({}, (err, data) => {
    if (err) return res.status(500).send(err);
    res.send(data.customers);
  });
});

• Two libraries — @grpc/grpc-js (the JS-specific gRPC bundle) and @grpc/proto-loader (loads the .proto and builds definitions).
• Server — load the proto, create new grpc.Server(), addService with method implementations (call, callback), then bindAsync to a port.
• Client — load the same proto, instantiate the service stub pointed at the server's address; now client.GetAll(...) etc. invoke the remote functions.
• Express bridge — the browser hits REST endpoints; the handler calls the gRPC client internally and returns the result.
• Gotcha from the build — the generic grpc package doesn't work in JS; use @grpc/grpc-js, and bind with bindAsync + grpc.credentials.createInsecure() on the client.

The comparison interviewers love. gRPC trades human-readability and browser-friendliness for raw speed and strong typing.

When to reach for gRPC, and what it costs you.