Computer Networks and Cloud Computing

You open a UPI app, tap a contact, type ₹500, enter your UPI PIN, and before you've even locked your phone again, the screen says "Payment Successful." In that brief window, a request has left your phone, crossed your mobile carrier's network, found its way across the open internet, been authenticated, routed through the National Payments Corporation of India's switch, triggered a debit at your bank and a credit at the recipient's, and returned a confirmation, all the way back to your screen. None of this happens on a single machine sitting under someone's desk. It happens because of two things working together: a computer network that can move a small amount of data reliably across thousands of kilometres, and cloud computing, the way modern organisations rent computing power instead of owning it. This chapter builds both from the ground up, using that one payment as the thread that ties every idea back together.

Packets, Not Pipes: How Data Actually Moves

Before the internet, long-distance communication meant the telephone network, which used circuit switching: when you dialled a number, the exchange reserved a dedicated electrical path between your phone and the other end for the entire call. That path was yours alone even during the silences, and keeping idle capacity in reserve for every possible call was expensive.

Computer networks solve the same problem differently, using packet switching. Your payment request is broken into small chunks called packets, each carrying a header (source address, destination address, a sequence number, and some control information) and a payload, a fragment of the actual data. Packets from thousands of unrelated conversations — someone's video call, another person's Instagram scroll, your payment request — share the same physical cables and routers, interleaved with each other. Each packet is routed independently and can take a different path to the same destination depending on which links are least congested at that instant; the destination reassembles them in order using their sequence numbers. This is why the internet can serve enormous numbers of simultaneous users on infrastructure that no single user could justify owning outright: nobody reserves a dedicated wire, so the same fibre-optic cable carries a huge number of independent streams at once.

The Layered Model: OSI and TCP/IP

Building a global network out of packet switching creates an obvious problem: the engineer designing fibre-optic hardware should not need to understand your payment app, and the developer writing your payment app should not need to know whether the bytes travel over Wi-Fi, a mobile tower, or a submarine cable. Networking solves this with a protocol stack organised into layers, where each layer only talks to the layers directly above and below it, and each layer's job is independent of how the others are implemented.

The reference model taught worldwide is the seven-layer OSI model (Open Systems Interconnection), read from the application a user touches down to the physical wire:

• Layer 7 (Application): the protocols your software actually speaks, such as HTTP or a banking API.
• Layer 6 (Presentation): formatting, compression, and encryption of the data.
• Layer 5 (Session): setting up, maintaining, and tearing down a conversation between two programs.
• Layer 4 (Transport): end-to-end delivery between two processes, handled by TCP or UDP.
• Layer 3 (Network): routing packets between different networks using IP addresses.
• Layer 2 (Data Link): delivering a frame across one local link using hardware (MAC) addresses.
• Layer 1 (Physical): the actual voltages, light pulses, or radio waves on the wire or airwaves.

In practice, almost nothing you use implements all seven layers as separate pieces of software. The internet actually runs on the simpler TCP/IP model, which compresses this into four layers: Application (merging OSI's Application, Presentation, and Session), Transport, Internet (equivalent to OSI's Network layer), and Link (merging OSI's Data Link and Physical). When engineers say "Layer 3" or "Layer 7" in casual conversation, they are almost always borrowing OSI's numbering as shared vocabulary, even though the software underneath is organised around TCP/IP's four layers.

IP Addresses and Subnetting: A Worked Example

Every device directly reachable on the internet needs an IP address: under IPv4, a 32-bit number usually written as four decimal numbers separated by dots, such as 192.168.10.1, where each number ranges from 0 to 255. An IP address splits into a network portion and a host portion. CIDR notation (Classless Inter-Domain Routing) writes this split as a slash followed by the number of bits dedicated to the network, so 192.168.10.0/24 means the first 24 bits identify the network and the remaining 8 bits identify individual hosts within it.

Suppose an EdTech company in Bengaluru is wiring up its office and has been assigned the private block 192.168.10.0/24 for four teams (Admissions, Labs, Faculty, and Admin), and wants each team on its own subnet, so that a problem on one team's network cannot spill over into the others. With 8 host bits, a /24 network holds 2⁸ = 256 addresses, of which 254 are usable: the first address in any block names the network itself, and the last is reserved as the broadcast address. Splitting one /24 into four equal pieces means borrowing 2 bits from the host portion, since 2² = 4, which shrinks each piece to a /26 with only 6 host bits left: 2⁶ = 64 addresses per subnet, 62 of them usable. The Python standard library will do this arithmetic for you:

import ipaddress

office = ipaddress.ip_network("192.168.10.0/24")
print("total addresses:", office.num_addresses)      # 256

teams = ["Admissions", "Labs", "Faculty", "Admin"]
for team, subnet in zip(teams, office.subnets(new_prefix=26)):
    hosts = list(subnet.hosts())
    print(team, "->", subnet, "usable:", hosts[0], "to", hosts[-1])

Tracing it by hand confirms what the code prints. The first subnet, 192.168.10.0/26, covers addresses .0 through .63, with .1 to .62 usable and .63 reserved as its broadcast address. The next block starts immediately after: 192.168.10.64/26 covers .64 to .127, usable .65 to .126. Then 192.168.10.128/26 covers .128 to .191, usable .129 to .190. Finally 192.168.10.192/26 covers .192 to .255, usable .193 to .254. Four teams, four independent subnets, carved out of one address block using nothing but binary arithmetic. This is exactly what a router's subnet mask is doing every time it decides whether a destination address is "local" or needs to be routed elsewhere.

TCP and UDP: Two Ways to Deliver a Packet

Layer 4 offers two very different delivery contracts. TCP (Transmission Control Protocol) is connection-oriented and reliable: before any data flows, the two ends perform a three-way handshake to agree on starting sequence numbers, and from then on every packet is acknowledged, lost packets are retransmitted, and data is reassembled in the exact order it was sent. Concretely, if the client picks an initial sequence number of 5000 and the server picks 9000, the handshake looks like this:

client -> server   SYN      seq=5000
server -> client   SYN-ACK  seq=9000  ack=5001
client -> server   ACK      seq=5001  ack=9001

Each side acknowledges the other's sequence number plus one, confirming "I received your starting point and I'm ready." Only after this exchange does actual application data, your payment request, start flowing. This reliability has a cost: acknowledgments and retransmissions take time and bandwidth, which is why TCP is used wherever correctness matters more than raw speed: payments, file downloads, web pages, anything where a missing or reordered byte would break the result.

UDP (User Datagram Protocol) skips all of that. There is no handshake, no acknowledgment, and no guarantee a packet arrives at all, let alone in order. This sounds like a defect until you consider a video call or a live cricket score ticking over: if one video frame or one score-update packet is lost, resending it three seconds later is worse than useless, because by the time it arrives the moment has passed, so the application is better off dropping it and moving to the next one. UDP's low overhead is also why DNS queries, discussed next, typically use it: a lost query is simply retried by the application in the rare case it fails, and paying TCP's connection-setup cost for one small request would be wasteful.

HTTP and HTTPS: The Language of the Web

HTTP (HyperText Transfer Protocol) is the application-layer protocol a browser or app uses to ask a server for something and get a structured answer back. A request names a method, a path, and a set of headers; a response carries a status code, its own headers, and usually a body:

GET /v1/trains/availability?from=NDLS&to=BCT&date=2026-08-25 HTTP/1.1
Host: api.aicomputerinstitute.com
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json

{"from": "NDLS", "to": "BCT", "available_seats": 42, "class": "3A"}

The method describes intent: GET retrieves data without changing anything on the server, POST submits new data such as placing an order or initiating a payment, PUT and PATCH update an existing resource, and DELETE removes one. The status code tells the client what happened without it having to parse the body: codes in the 200s mean success (200 OK, 201 Created), 300s mean redirection, 400s mean the client made a mistake (404 Not Found, 401 Unauthorized for a missing or invalid login), and 500s mean the server itself failed (503 Service Unavailable when it is overloaded).

Plain HTTP sends all of this as readable text, which means anyone controlling a router or Wi-Fi hotspot between you and the server can read or alter it. HTTPS wraps HTTP inside TLS (Transport Layer Security), which fixes this in three steps: the server presents a digital certificate, issued by a trusted Certificate Authority, proving it genuinely controls the domain it claims to; the two sides use that certificate to agree on a shared secret key without ever transmitting the key itself in the clear; and every byte of HTTP traffic after that is encrypted with fast symmetric encryption using that shared key. Modern TLS (version 1.3) does all of this in a single round trip, so the extra security costs almost nothing in perceived speed. A payment app that used plain HTTP would be broadcasting your UPI PIN to anyone listening on the same network, which is exactly why every payment API, without exception, runs over HTTPS.

DNS: The Internet's Directory Service

None of the previous sections work until a device knows which IP address to actually send packets to, and humans do not type IP addresses; they type domain names. The Domain Name System (DNS) is the distributed directory that turns a name like aicomputerinstitute.com into an address like 192.0.2.10 (deliberately drawn from the address range reserved for documentation, since a real, live IP would go stale in a textbook). A first-time lookup for an uncached domain is resolved in stages:

• Step 1: your device asks a recursive resolver, usually run by your ISP or a public one you have configured, for the address.
• Step 2: the resolver, holding no cached answer, asks one of the internet's root nameservers, which does not know the answer either but knows who handles the .com domain.
• Step 3: the resolver asks that .com top-level-domain nameserver, which does not know the final answer but knows which nameserver is authoritative for aicomputerinstitute.com specifically.
• Step 4: the resolver asks that authoritative nameserver directly, and finally receives the actual IP address.
• Step 5: the resolver caches the answer for a duration set by the domain's own TTL (time-to-live) value and returns it to your device, which can now open a connection.

Because of that caching step, this entire chain runs only on the first lookup; every subsequent request for the same domain, from you or from thousands of other users sharing the same resolver, is answered instantly from cache until the TTL expires. This is also why DNS typically rides on UDP rather than TCP: a single small query-and-response does not need TCP's connection-setup overhead, and if a query is lost, the resolver simply asks again.

From Wires to Warehouses: What Is Cloud Computing?

Everything so far explains how a packet finds its way to a destination address. What is actually sitting at that address? Two decades ago, the honest answer for most companies was a physical server, bought outright, sitting in a room the company itself cooled and secured, sized for its busiest expected day and idle the rest of the time. Buying that capacity meant a large upfront cost before a single customer arrived, and if the company guessed wrong about demand, it either wasted money on idle machines or ran out of capacity exactly when it mattered most.

Cloud computing replaces ownership with rental. Companies like Amazon (AWS), Microsoft (Azure), and Google (Google Cloud) built enormous data centres and now sell slices of that capacity by the hour, minute, or even the individual request, letting any developer provision a server in minutes instead of months and pay only for what they actually use. Cloud services are usually described in three layers, each handing the customer a different amount of control, and a different amount of responsibility, in exchange for convenience:

• IaaS (Infrastructure as a Service): the provider rents you raw virtual machines, storage, and networking; you install and manage the operating system and everything above it. Examples: AWS EC2, Azure Virtual Machines, Google Compute Engine.
• PaaS (Platform as a Service): the provider also manages the operating system and runtime; you simply hand over your application code and it runs. Examples: Google App Engine, AWS Elastic Beanstalk, Render.
• SaaS (Software as a Service): the provider manages the entire application; you use it through a browser or app without running any of it yourself. Examples: Gmail, Zoom, Google Docs.

A bank's payment API is typically built on IaaS or PaaS, since it needs custom code and tight control over security, while the same bank's internal team might rely on SaaS tools for email and video conferencing without ever touching the infrastructure behind them.

Elasticity: Load Balancers and Auto-Scaling

The property that makes cloud computing more than "someone else's data centre" is elasticity: capacity that grows and shrinks automatically with demand. Consider IRCTC's booking system in the minute Tatkal booking opens each morning, when traffic surges enormously within seconds and then tapers off. A fixed number of servers sized for that spike would sit mostly idle the rest of the day; a fixed number sized for the average load would collapse under the morning rush.

Cloud platforms solve this with two cooperating pieces. A load balancer sits in front of a pool of identical servers and distributes each incoming request across them. In its simplest form that means round-robin: request 1 goes to server A, request 2 to server B, request 3 to server C, and back to A again. It also runs health checks, so a server that stops responding is quietly removed from the pool until it recovers. Auto-scaling watches metrics such as CPU usage or requests-per-second against that pool and adds new servers automatically as load rises, then removes them once load falls, so the fleet is sized for the current second of demand rather than for the worst case or the average case. This is horizontal scaling (adding more machines) as opposed to vertical scaling, which means moving a workload to a single bigger machine; cloud elasticity is almost always horizontal, since a pool of many small, replaceable servers behind a load balancer is also far more resilient to any one machine failing.

Serverless Computing

Taking elasticity to its logical end point produces serverless computing, also called Function-as-a-Service (FaaS): the developer writes a single function, uploads it to a service like AWS Lambda, Google Cloud Functions, or Azure Functions, and the cloud provider handles everything else: provisioning a machine to run it, scaling from zero instances to thousands and back automatically, and billing only for the fractions of a second the function actually executed, rather than for a server sitting idle whether or not it is doing anything. This suits workloads that are naturally spiky and short-lived, such as resizing an uploaded profile photo or validating a single payment webhook, extremely well. It suits a workload that runs continuously and predictably, such as a busy database, far less well; for that, a normally provisioned server is usually cheaper and simpler.

Why India Needs Its Own Data Centres: A Latency Calculation

Elasticity solves the "how many servers" question. It does not solve a second, purely physical problem: where those servers should sit. Every network signal, however well engineered, is capped by the speed of light, and light travels roughly one-third slower through optical fibre than through a vacuum: about 200,000 kilometres per second, versus roughly 300,000 kilometres per second in a vacuum, because of the fibre's refractive index. That single number sets a hard physical floor under any request's round-trip time (RTT), no matter how good the software on either end is.

Take a request travelling from Mumbai to a data centre on the US east coast, roughly 13,000 kilometres away as the crow flies. The round trip covers that distance twice, there and back, so:

one-way distance        ~ 13,000 km
round-trip distance     ~ 26,000 km
speed of light in fibre ~ 200,000 km/s

round-trip time = distance / speed
                = 26,000 km / 200,000 km/s
                = 0.13 s
                = 130 milliseconds

That 130 ms is a floor, not a typical measurement: real submarine cables snake along continental shelves and cable-landing stations rather than flying in a straight line, and every router the packet passes through on the way adds its own small processing and queueing delay on top. The real number only ever gets worse than this calculation, never better. Now compare a request from Mumbai to a data centre that is also in Mumbai: the one-way distance is close to zero, so the physical floor on the round trip is close to zero too, and almost the entire time budget is available for actual computation instead of being spent on the packet simply travelling.

This is precisely why AWS operates data-centre regions in Mumbai and Hyderabad, Microsoft Azure operates regions in Pune, Chennai, and Mumbai, and Google Cloud operates regions in Mumbai and Delhi, rather than asking every Indian request to make the round trip calculated above. It also lines up with regulation: the Reserve Bank of India ruled in 2018 that data relating to payment transactions must be stored exclusively on servers located within India, which means a UPI payment was never going to be an application that could be served from Virginia even if latency were not a concern. Physics and policy point the same direction here, and the result is the same for both: keep the servers close to the users they serve.

Putting It All Together: The Full Path of a UPI Payment

Return to the payment from the opening of this chapter, now with every layer named. Tapping "Pay" triggers an HTTPS request from the app on your phone, already encrypted under TLS, so your UPI PIN never travels as plain text. The domain it is sent to was resolved to an IP address by DNS earlier, most likely served instantly from a cache built by thousands of other users' requests. A TCP three-way handshake, or more often a connection already kept open and reused from a moment ago, guarantees the request arrives complete and in order. IP routing carries the resulting packets across your carrier's network (Jio, Airtel, or another operator) and the wider internet, hop by hop, toward a data centre that, thanks to the latency calculation above, is very likely sitting in Mumbai or Hyderabad rather than another continent. There, a load balancer hands the request to one of many auto-scaled servers running your bank's payment API, built on cloud infrastructure rather than a single machine that could never survive a Tatkal-morning-style surge. NPCI's switch coordinates the message between your bank and the recipient's, each bank's own core system performs the actual debit and credit, and a response, 200 OK, transaction successful, retraces the same path back to your screen.

Every one of those steps existed before you tapped "Pay," and every one of them will run again the next time you do, and the time after that, for a payment, a video call, a cricket score refreshing mid-over, or a college portal you check for exam results. None of it is a black box any longer. The layers, the addresses, the handshakes, and the data centres are the plumbing underneath every piece of software you will ever build, and knowing exactly which pipe is slow, or which one just failed, is what turns a programmer who writes code into an engineer who can be trusted to run it at scale.

Think About It

Think about this: How would you explain computer networks and cloud computing to a friend who has never seen a computer? What real-world analogy would you use? Imagine you had to build a system using these concepts — what would be your first step? Try this: before moving on, write down three things you learned and one question you still have.

Key Takeaways — Summary and Recap

Let us recap what we covered: the core ideas behind computer networks and cloud computing, how they connect to real-world applications, and why they matter for your journey in computer science. Remember these key points as you move forward. For competitive exam preparation (CBSE, JEE, BITSAT), focus on understanding the WHY behind each concept, not just the WHAT.