Cloud Computing and IoT are Computer Networks topics that interviewers regularly reach for, while UGC NET CS, IBPS SO IT, and teaching-recruitment CS papers can test them through definitions and small numericals. Many candidates prepare buzzword lists and miss questions that a two-line calculation would solve. The three calculations that close that gap are transfer time over a fixed uplink, per-message telemetry overhead, and a control loop's round-trip latency budget.
Cloud computing in network terms
Cloud computing provides on-demand network access to a shared pool of configurable compute, storage, and networking resources. They can be provisioned and released quickly with little manual management. Access still depends on DNS and HTTP, the machinery covered in Application Layer Protocols: DNS and HTTP.
Five characteristics define the model:
On-demand self-service: users provision resources without provider staff.
Broad network access: standard network mechanisms expose services.
Resource pooling: shared infrastructure serves isolated tenants.
Rapid elasticity: capacity grows or shrinks with demand.
Measured service: usage is monitored and metered.
Virtualisation enables this pooling. A hypervisor divides hardware into isolated virtual machines. Type 1 runs directly on hardware; type 2 runs above a host OS. Containers are lighter because isolated applications share the host kernel instead of carrying separate guest operating systems.
Cloud service and deployment models
Service models form a responsibility ladder. The distinction is where management passes from provider to customer.
Model | Provider supplies | Customer manages |
|---|---|---|
IaaS | Virtual compute, storage, and network | Operating system, applications, and data |
PaaS | Infrastructure, operating system, and managed runtime | Applications and data |
SaaS | Finished network application | Use, configuration, and entered data |
This boundary produces MSQ traps. Under PaaS, the provider patches the OS; the customer manages applications and data.
Deployment is a separate grid. A public cloud uses shared provider infrastructure. A private cloud serves one organisation. A hybrid cloud connects private and public environments with workload or data portability. A community cloud serves organisations with a common concern.
Every model still rides TCP/IP paths, so the behaviour in TCP vs UDP: Transport Layer Explained remains fundamental.
Worked example 1: network bandwidth as the cloud bottleneck
An organisation must move 500 GB to a cloud region over a dedicated 100 Mbps uplink. Using decimal network units:
Data = 500 × 8 = 4,000 gigabits = 4 × 10^12 bits.
Rate = 100 Mbps = 10^8 bits per second.
Time = (4 × 10^12) ÷ 10^8 = 40,000 seconds.
That is 11 hours, 6 minutes, 40 seconds, roughly 11 hours 7 minutes.
At an effective 20 Mbps, time = (4 × 10^12) ÷ (2 × 10^7) = 200,000 seconds = 55 hours, 33 minutes, 20 seconds, about 2 days 8 hours.
A couriered disk arriving in 24 hours has effective throughput (4 × 10^12) ÷ 86,400, about 46.3 Mbps. The 100 Mbps upload finishes first, but the disk beats the 20 Mbps path. Bulk migration is bandwidth arithmetic; latency is irrelevant to this throughput-dominated comparison.
IoT architecture and its constrained protocol stack
IoT connects constrained sensors and actuators to collect data and act on it. Its three-layer architecture has a perception layer for sensing, a network layer for transport through gateways, and an application layer for services and analytics. A five-layer variant adds middleware and business layers.
The protocol pairings matter more than the expansions:
MQTT is publish-subscribe messaging over TCP. A broker connects publishers and subscribers. QoS levels are 0 (at most once), 1 (at least once), and 2 (exactly once); its default port is 1883.
CoAP is IETF’s REST-like request-response protocol over UDP for constrained nodes; its default port is 5683.
6LoWPAN compresses IPv6 headers for IEEE 802.15.4 networks.
Zigbee, BLE, and LoRaWAN offer different range, rate, and energy trade-offs.
The one-mark pair is MQTT/TCP and CoAP/UDP. HTTP can carry IoT traffic, but its metadata is often heavy for tiny, frequent sensor readings.
Worked example 2: MQTT versus HTTP overhead
A sensor publishes a 12-byte reading every 10 seconds, or 86,400 ÷ 10 = 8,640 messages daily. Count only application-layer bytes; TCP/IP headers sit under both alternatives.
MQTT PUBLISH uses a 2-byte fixed header, 10-byte topic, and 12-byte payload: 2 + 10 + 12 = 24 bytes. Daily traffic = 8,640 × 24 = 207,360 bytes, which is 202.5 KiB.
The simplified HTTP POST has roughly 300 bytes of request line and headers plus 12 bytes of payload, or 312 bytes. Daily traffic = 8,640 × 312 = 2,695,680 bytes, about 2.6 MiB. Since 312 ÷ 24 = 13, HTTP carries 13 times the application-layer bytes here.
MQTT has not compressed the reading. Its persistent brokered session avoids repeated request metadata, fitting telemetry; request-response remains useful for control queries.
Worked example 3: edge computing as a latency budget
Edge computing moves processing near devices, such as to a gateway or base station. Fog computing is the layered form between edge and cloud. Both reduce latency and backhaul traffic.
A control loop must react within 20 ms. Its cloud path takes 2 ms sensor-to-gateway, 50 ms gateway-to-cloud, 1 ms processing, then 50 ms and 2 ms back.
Cloud total = 2 + 50 + 1 + 50 + 2 = 105 ms. It misses by 85 ms and takes 5.25 times the budget. At the gateway, edge total = 2 + 1 + 2 = 5 ms, leaving 20 − 5 = 15 ms spare.
Bandwidth cannot remove remote propagation delay. Latency-critical loops must terminate near devices.
Cloud and IoT traps that cost easy marks
Mapping MQTT to UDP. Students equate lightweight with UDP and tick a false option. Memorise MQTT/TCP and CoAP/UDP; MQTT’s QoS levels build on ordered delivery.
Confusing elasticity with scalability, or IaaS with PaaS. Acronyms blur without the responsibility ladder. Elasticity grows and shrinks capacity with load; service models move the management boundary.
Treating latency as a bandwidth problem. Migration is throughput-dominated; the control loop is distance-dominated. Bandwidth accelerates bulk transfer but cannot fit a 50 ms propagation leg inside a 20 ms deadline.
How exams test Cloud Computing and IoT
A GATE-style question can wrap transmission-time or latency arithmetic in a cloud scenario, but the formulas remain standard Computer Networks. For the GATE CS syllabus scope and paper pattern, the authority is the official GATE website run by that year’s organising institute.
UGC NET CS, IBPS SO IT, and PGT or TGT CS papers commonly use definitions, match-the-following items, or MSQs. Interviews turn the facts into a design prompt: choose a telemetry protocol and justify overhead and latency.
Rehearse the calculations until unit conversions are automatic. Then drill the Computer Networks MCQ hub and practise topic-wise tests under time.
The short version and next step
Remember five anchors: five cloud characteristics and two model grids; 40,000 seconds for the transfer; MQTT/TCP and CoAP/UDP; 24 B versus 312 B per sensor message; and 105 ms cloud versus 5 ms edge latency.
For Computer Networks from fundamentals to exam applications, use Zero to Hero, Complete CS Course. To practise under time, use the GATE Test Series, Mocks and Topic-wise Tests.
