Computer Networking — Complete Concept

Reference

Full content coverage for interview preparation

How to use this document

Same approach as the AI reference: full content, not just checklist fragments, structured the
way an undergrad Networking course actually builds — from the layered model that
organizes everything, down through each layer, then across the cross-cutting topics
(security-over-network, addressing, performance) that interviewers love to pivot into. Read
once top to bottom, then use as a drilling reference.

Part 1: The Layered Model — Why Everything Else Makes Sense

If you only internalize one structural idea from this whole document, make it this one,
because almost every networking question you’ll be asked is really “which layer does this
belong to, and what does that layer guarantee.”

1.1 Why Layering Exists

Networking is broken into layers so that each layer solves one problem and hides its
complexity from the layers above and below it. A web developer writing HTTP requests
doesn’t need to know how bits travel across a copper wire — that separation of concerns is
the entire point of the model. Each layer only talks to the layer directly above and below it,
using a well-defined interface.

1.2 The OSI Model (7 layers) — top to bottom

Layer Name What it does Example protocols/units

Interfaces directly with user-

7 Application HTTP, FTP, SMTP, DNS
facing software

SSL/TLS (often folded here

 6 Presentation Data translation, encryption, or into Application), JPEG,
compression ASCII

Establishes, manages, terminates

5 Session sessions/dialogues between APIs, sockets (conceptually)
apps

End-to-end delivery, reliability, TCP, UDP (unit:

4 Transport
flow/congestion control segment/datagram)

Logical addressing and routing IP, ICMP, routers (unit:

3 Network
across networks packet)

Node-to-node delivery within the

Ethernet, MAC addresses,
2 Data Link same network, physical
switches (unit: frame)
addressing

Raw bit transmission over Cables, radio signals, hubs

1 Physical
physical medium (unit: bit)

Mnemonic (top to bottom): “All People Seem To Need Data Processing.” Know it both
directions — bottom-to-top is often how it’s asked (“Please Do Not Throw Sausage Pizza
Away”).

1.3 The TCP/IP Model (4 layers) — the practically-used model

TCP/IP Layer Roughly maps to OSI layers

Application 7, 6, 5 (Application, Presentation, Session)

Transport 4 (Transport)

Internet 3 (Network)

Network Access (Link) 2, 1 (Data Link, Physical)

Why two models exist: OSI is the theoretical/teaching reference model (comprehensive,
precise separation); TCP/IP is the model the actual internet is built on and predates OSI’s
formalization in practical deployment. Interviewers may ask you to map one to the other —
practice going both directions.

1.4 Encapsulation and Decapsulation

As data moves down the stack (sender side), each layer wraps the data from the layer
above with its own header (and sometimes trailer) — this is encapsulation. As data moves
up the stack (receiver side), each layer strips off its corresponding header — this is
decapsulation.

Concretely: an HTTP message (Application) gets wrapped in a TCP header (Transport) →

becomes a segment. That segment gets wrapped in an IP header (Network) → becomes a
packet. That packet gets wrapped in a MAC/Ethernet header (Data Link) → becomes a
frame. The frame is transmitted as raw bits (Physical).

Terminology by layer (memorize this — it signals precision when you use the right
term):

Transport layer unit → segment (TCP) or datagram (UDP)

Network layer unit → packet

Data Link layer unit → frame

Physical layer unit → bit

Part 2: Physical & Data Link Layer

2.1 Physical Layer

Concerned purely with transmitting raw bits over a physical medium (copper, fiber,
radio).

Deals with voltage levels, signal timing, physical topology (bus, star, ring, mesh), and
transmission modes:

Simplex — one direction only

Half-duplex — both directions, but not simultaneously

Full-duplex — both directions simultaneously (standard for most modern links)

2.2 Data Link Layer — Core Job

Provides node-to-node (hop-to-hop, not end-to-end) delivery within the same local
network, and handles:

Framing — organizing bits into manageable frames with headers/trailers

Physical (MAC) addressing — every network interface has a unique MAC address (48-
bit, e.g., 00:1A:2B:3C:4D:5E ) burned into hardware, used for local delivery
 Error detection — typically via checksums or CRC (Cyclic Redundancy Check), added
as a trailer, to detect (not usually correct) transmission errors

Media access control — deciding who gets to transmit when multiple devices share a
medium

2.3 MAC Sublayer and Access Control

CSMA/CD (Carrier Sense Multiple Access with Collision Detection) — classic Ethernet
approach: listen before sending, detect collisions if they happen, back off and retry.
Largely historical now that switched full-duplex Ethernet avoids collisions altogether, but
still a standard concept to know.

CSMA/CA (Collision Avoidance) — used in WiFi (802.11), since wireless collision

detection is unreliable (a sender can’t easily listen while transmitting on the same
channel); instead it tries to avoid collisions proactively (random backoff before sending).

2.4 Switches vs Hubs vs Bridges

Hub: pure physical-layer device — broadcasts incoming signal to every port, no
intelligence, causes unnecessary traffic and collision domains.

Bridge: connects two LAN segments, operates at Data Link layer, makes forwarding
decisions based on MAC addresses (a simple 2-port precursor to switches).

Switch: multi-port bridge — learns which MAC addresses are on which port (via a MAC
address table) and forwards frames only to the relevant port, rather than broadcasting
to all — this is why switches dramatically reduce unnecessary traffic compared to hubs.

2.5 Address Resolution Protocol (ARP)

The bridge between Network layer (IP addresses) and Data Link layer (MAC addresses):
given a known IP address on the local network, ARP discovers the corresponding MAC
address, since Data Link layer delivery ultimately needs a MAC address, not an IP
address, to actually deliver a frame.

ARP process: broadcast an ARP request (“who has IP X.X.X.X?”) to the local network;
the device with that IP responds with its MAC address; the result is cached (ARP table)
to avoid repeating the lookup for every packet.

Part 3: Network Layer

3.1 Core Job of the Network Layer

Provides logical addressing (IP addresses) and routing — getting a packet from source to
destination potentially across many intermediate networks, unlike the Data Link layer’s
single-hop scope.

3.2 IP Addressing

IPv4

32-bit address, written as four decimal octets (e.g., [Link] ), each octet 0–255.

Total address space: 2^32 ≈ 4.3 billion addresses — the core reason IPv4 exhaustion
became a real problem as internet-connected devices multiplied.

Address classes (historical, but still asked):

Class A: [Link] – [Link] (large networks, first bit is 0)

Class B: [Link] – [Link] (medium networks)

Class C: [Link] – [Link] (small networks, most common for LANs)

Class D: [Link] – [Link] (multicast)

Class E: reserved for experimental use

Private IP ranges (non-routable on the public internet, used behind NAT):

[Link] – [Link]

[Link] – [Link]

[Link] – [Link]

Subnetting and CIDR

Subnet mask: determines which portion of an IP address is the network part vs the host
part (e.g., [Link] means the first 3 octets are network, last is host).

CIDR (Classless Inter-Domain Routing) notation: [Link]/24 — the /24 means

the first 24 bits are the network portion, leaving 8 bits (256 addresses, 254 usable) for
hosts. CIDR replaced the rigid class system with flexible-length prefixes, making
address allocation far more efficient.

Why subnetting matters: breaking a large network into smaller subnets reduces
broadcast traffic, improves security/isolation, and allows more efficient address
allocation.
 Be ready for a basic subnetting calculation if pushed to a board: given an IP and a CIDR
prefix, identify the network address, broadcast address, and usable host range.

IPv6

128-bit address, written in 8 groups of hexadecimal separated by colons (e.g.,

2001:0db8:85a3:0000:0000:8a2e:0370:7334 ).

Address space: 2^128 — astronomically larger than IPv4, designed to make exhaustion a
non-issue for the foreseeable future.

Why adoption has been slow: requires infrastructure upgrades across ISPs, hardware,
and software; backward incompatibility with IPv4 means dual-stack or translation
mechanisms are needed during the long transition; NAT (below) extended IPv4’s usable
lifespan and reduced urgency.

Simplified header compared to IPv4 (some fields removed/optional), built-in support for
features IPv4 needed extensions for (e.g., IPsec was originally mandatory in IPv6
design).

3.3 NAT (Network Address Translation)

Why NAT is needed: allows many devices on a private network (private IP addresses) to
share a single public IP address when communicating with the outside internet — this
was the primary practical mitigation for IPv4 address exhaustion, and also provides a
layer of network isolation/security (internal addresses aren’t directly reachable from
outside).

How it works: the NAT device (typically a router) maintains a translation table mapping
internal (private IP, port) pairs to the single external (public IP, port) — when a response
comes back, NAT looks up the table to know which internal device to forward it to.

Types of NAT:

Static NAT — one-to-one fixed mapping between a private and public IP

Dynamic NAT — maps a private IP to any available address from a pool of public IPs

PAT (Port Address Translation), aka NAT overload — the most common real-world
case (what most home routers do): many private IPs share a single public IP,
distinguished by port numbers

NAT’s downsides (a natural “what’s the catch” follow-up): breaks true end-to-end
connectivity (an external host can’t directly initiate a connection to an internal device
without additional configuration like port forwarding), complicates some peer-to-peer
 and VoIP protocols that expect direct addressability, adds a point of state/complexity in
the network.

3.4 Routing
Routing = the process of selecting a path for packets across networks, performed by
routers using routing tables.

Static routing: manually configured routes — simple, predictable, but doesn’t adapt to
network changes and doesn’t scale well.

Dynamic routing: routers exchange information automatically and adapt to topology

changes, using routing protocols:

Distance-vector protocols (e.g., RIP) — routers share their entire routing table with
neighbors periodically; each router computes shortest paths based on hop count.
Simple but slower to converge and prone to routing loops without safeguards.

Link-state protocols (e.g., OSPF) — routers share information about their direct
links with all routers in the network (not just neighbors), and each router
independently computes shortest paths using a complete map — generally faster
convergence and more scalable than distance-vector.

Dijkstra’s algorithm connection: link-state routing protocols like OSPF use Dijkstra’s
shortest-path algorithm internally to compute optimal routes from the full topology map
— this directly connects back to your AI/search prep (UCS/A* with h(n)=0), since it’s the
same underlying algorithm applied in a networking context.

3.5 ICMP (Internet Control Message Protocol)

Used for network diagnostics and error reporting, not for carrying application data.

Ping uses ICMP Echo Request/Reply to test reachability and measure round-trip time.

Traceroute uses ICMP (or UDP, depending on implementation) with incrementing TTL
(Time To Live) values to discover the path packets take, one hop at a time.

Part 4: Transport Layer — TCP vs UDP (the highest-yield

section)

4.1 The Core Job of the Transport Layer

Provides end-to-end communication between processes (not just machines — this is why
port numbers exist, to identify which application on a machine a segment is for), sitting
above the Network layer’s machine-to-machine delivery.

4.2 TCP (Transmission Control Protocol)

Full form: Transmission Control Protocol

Core properties:

Connection-oriented: a connection must be explicitly established before data transfer

(via the three-way handshake) and torn down afterward.

Reliable: guarantees delivery via acknowledgments and retransmission — if a segment

is lost, TCP detects and resends it.

Ordered: segments are sequenced and reassembled in the correct order at the receiver,
even if they arrive out of order over the network.

Flow control: prevents a fast sender from overwhelming a slow receiver.

Congestion control: prevents the sender from overwhelming the network itself (distinct
from flow control, which protects the receiver specifically).

The Three-Way Handshake (connection establishment)

1. SYN — client sends a segment with the SYN flag set, proposing an initial sequence
number

2. SYN-ACK — server responds with SYN+ACK, acknowledging the client’s sequence

number and proposing its own

3. ACK — client acknowledges the server’s sequence number

After this, the connection is established and data transfer begins. This handshake is what
makes TCP “connection-oriented” — both sides confirm mutual readiness and agree on
starting sequence numbers before any data flows.

Four-Way Termination (connection teardown)

1. Initiator sends FIN (no more data to send)

2. Receiver sends ACK (acknowledging the FIN)

3. Receiver sends its own FIN (when it’s also done)

4. Initiator sends ACK (acknowledging the second FIN)

Why four steps instead of two: TCP connections are full-duplex, so each direction of the
connection needs to be closed independently — one side can stop sending while still
receiving.

How TCP Detects Lost Data (the exact question your seniors were asked)

Every byte of data is associated with a sequence number.

The receiver sends back acknowledgment (ACK) numbers indicating the next
expected sequence number.

The sender maintains a timeout (RTO — Retransmission Timeout); if an ACK isn’t

received within that window, the sender assumes the segment was lost and retransmits
it.

Duplicate ACKs / Fast Retransmit: if the receiver gets segments out of order (implying
an earlier segment is missing), it repeatedly sends an ACK for the last correctly-received
in-order segment. If the sender sees enough duplicate ACKs (conventionally 3), it
retransmits immediately without waiting for the full timeout — a faster recovery
mechanism than waiting on RTO alone.

Checksum: detects corrupted (not just lost) data — a checksum field in the TCP header
lets the receiver verify segment integrity and discard corrupted segments (which then
simply go unacknowledged, triggering the same retransmission process as a lost
segment).

Flow Control — Sliding Window

The receiver advertises a window size (how much unacknowledged data it’s willing to
buffer), and the sender is not allowed to have more than that amount of data “in flight”
(sent but unacknowledged) at once.

This window can shrink or grow dynamically as the receiver’s buffer availability changes
— directly preventing a fast sender from overwhelming a slow receiver’s buffer.

Congestion Control (conceptual)

Slow start: begin with a small congestion window, and grow it (typically exponentially at
first) as ACKs confirm successful delivery — cautious ramp-up rather than blasting at
full speed immediately.

Congestion avoidance: after reaching a threshold, growth slows to linear increase,

being more conservative to avoid overwhelming the network.

On detecting loss (interpreted as a congestion signal), TCP reduces its sending rate —
the general philosophy is “probe gently, back off aggressively on trouble.”
4.3 UDP (User Datagram Protocol)
Full form: User Datagram Protocol

Core properties:

Connectionless: no handshake, no established session — segments (called datagrams)

are simply sent.

Unreliable: no acknowledgment, no retransmission — if a datagram is lost, UDP does

nothing about it; that’s left to the application layer if it cares.

Unordered: no sequencing guarantee — datagrams can arrive out of order and UDP
won’t reorder them.

No flow or congestion control: sends as fast as the application hands it data.

Minimal header overhead: UDP’s header is much smaller/simpler than TCP’s (no
sequence numbers, no window size, no connection state) — this is the direct mechanical
reason UDP is faster: less per-packet overhead and no handshake delay before data
starts flowing.

4.4 TCP vs UDP — Direct Comparison (near-guaranteed question)

Aspect TCP UDP

Connection-oriented
Connection Connectionless
(handshake)

Reliability Reliable (ACK + retransmit) Unreliable (no guarantee)

Ordering Guaranteed in-order delivery No ordering guarantee

Slower (overhead of
Speed Faster (minimal overhead)
guarantees)

Flow/congestion
Yes No
control

Header size Larger (~20 bytes minimum) Smaller (8 bytes)

Data integrity matters more Speed matters more than perfect

Use case
than speed delivery

When UDP is preferred over TCP — the direct answer to the “when” follow-up: real-time
applications where a late-arriving retransmission is worse than a small amount of data loss
— video calls, live streaming, online gaming, VoIP, and DNS lookups (where the overhead of
a handshake for a single quick query would be wasteful, and the application can simply retry
if needed).

One clean UDP example: DNS queries — a single request/response exchange, so the
connection-setup overhead of TCP would roughly double the cost of every lookup for little
benefit; if a DNS query is lost, the resolver just retries. (Video streaming and VoIP are
equally valid examples — have one crisp example memorized rather than listing many.)

“Extra offerings” of TCP (a paraphrased question your seniors got): reliability

(ACK/retransmission), ordering, flow control, congestion control — essentially, everything
UDP explicitly lacks. Frame your answer as this direct contrast.

4.5 Port Numbers

Identify which process/application on a host a segment is destined for — this is what
makes Transport-layer delivery end-to-end between processes, not just machines.

Well-known ports (0–1023): standardized for common services — HTTP=80,

HTTPS=443, FTP=21, SSH=22, DNS=53, SMTP=25.

Registered ports (1024–49151) and dynamic/ephemeral ports (49152–65535) —

used for client-side temporary connections.

A full connection is uniquely identified by the tuple (source IP, source port, destination
IP, destination port, protocol) — this is what allows a server to handle many
simultaneous connections from different clients (or even the same client) without
confusion.

Part 5: Application Layer

5.1 DNS (Domain Name System)

Translates human-readable domain names (e.g., [Link] ) into IP addresses, since
machines route based on IP, not names.

Basic lookup flow: client queries a resolver (often provided by the ISP or a public
service) → resolver queries a root server → directed to the appropriate TLD (Top-Level
Domain) server (e.g., for .com ) → directed to the authoritative name server for the
specific domain → returns the actual IP address.

Caching: results are cached at multiple levels (browser, OS, resolver) with a TTL (Time
To Live) to avoid repeating this full lookup chain for every request — this is a direct
 efficiency mechanism worth mentioning if asked “how is DNS made fast in practice.”

DNS itself commonly uses UDP (port 53) for its lightweight query/response pattern — a
nice natural link back to the “when is UDP preferred” discussion above — though it falls
back to TCP for larger responses (e.g., zone transfers).

5.2 DHCP (Dynamic Host Configuration Protocol)

Automatically assigns IP addresses (and other configuration like subnet mask, default
gateway, DNS server) to devices joining a network, removing the need for manual static
configuration on every device.

DORA process:

1. Discover — client broadcasts a request looking for a DHCP server

2. Offer — server responds with an offered IP address and configuration

3. Request — client formally requests the offered address (also broadcast, so other
DHCP servers know their offers weren’t taken)

4. Acknowledge — server confirms, finalizing the lease

Lease time: assigned addresses are leased, not permanent — the client must
periodically renew before the lease expires, or the address can be reclaimed and
reassigned to another device.

Static vs dynamic assignment tradeoff: static IPs are predictable (useful for servers,
printers) but require manual management and don’t scale; dynamic (DHCP) assignment
is low-maintenance and scales well but addresses can change over time, which is why
servers typically still use static or DHCP-reserved addresses.

5.3 HTTP / HTTPS

HTTP (HyperText Transfer Protocol): request/response protocol underlying web
communication. Client sends a request (method + URL + headers + optional body),
server sends a response (status code + headers + body).

Common HTTP methods: GET (retrieve), POST (submit/create), PUT (update/replace),

DELETE (remove).

Common status codes: 200 (OK), 301/302 (redirect), 404 (not found), 500 (internal
server error) — know at least these four as the most commonly referenced.

HTTPS: HTTP layered over TLS/SSL encryption. Adds:

Encryption — data in transit can’t be read by an eavesdropper

 Authentication — certificates verify the server is who it claims to be (issued by a
trusted Certificate Authority)

Integrity — data can’t be tampered with in transit without detection

This is a natural bridge point into the Security section below — HTTPS is the concrete,
everyday example of asymmetric encryption + certificates + hashing all working
together.

5.4 Email Protocols (brief, lower priority but good to have)

SMTP (Simple Mail Transfer Protocol) — sending mail between servers.

IMAP/POP3 — retrieving mail from a mail server to a client (IMAP keeps mail synced on
the server, POP3 typically downloads and can remove it from the server).

5.5 FTP (File Transfer Protocol)

Used for transferring files between client and server; notably uses two separate
connections — one for control (commands), one for actual data transfer — a distinctive
architectural detail worth knowing if asked to contrast it with HTTP’s single-connection-
per-request model.

Part 6: Multiplexing

6.1 Frequency Division Multiplexing (FDM)

The available bandwidth is divided into separate, non-overlapping frequency bands,
and each signal/channel is assigned its own band, transmitted simultaneously.

Guard bands: small unused frequency gaps left between adjacent channels to prevent
interference/crosstalk between them — a necessary overhead cost of FDM.

Real-world example: traditional radio and cable TV, where different stations/channels
occupy different frequency ranges simultaneously.

6.2 Time Division Multiplexing (TDM)

All signals share the same frequency band but take turns transmitting in assigned time
slots, cycling through each channel in sequence.

Synchronization requirement: because channels are distinguished purely by when

they transmit, TDM requires tight timing coordination between sender and receiver to
know which time slot belongs to which channel — a requirement FDM doesn’t have,
 since FDM channels are always distinguishable by frequency regardless of timing.

Real-world example: traditional digital telephony (each call gets a repeating time slot
on a shared line).

6.3 Which Is Better?

There’s no universal answer — be ready to argue based on context rather than freeze on the
open-endedness:

FDM wastes some capacity to guard bands but doesn’t require tight synchronization,
and works naturally for continuous analog-style signals.

TDM uses bandwidth more efficiently (no wasted guard bands, especially suited to
digital data) but adds the complexity/cost of synchronization.

Modern digital systems generally favor TDM-family and statistical multiplexing

approaches for efficiency, but the honest answer is “it depends on the signal type and
system constraints” — defend whichever position you take with a concrete reason.

6.4 Other Multiplexing (brief awareness)

WDM (Wavelength Division Multiplexing): essentially FDM applied to fiber optics —
different wavelengths (colors) of light carry separate channels simultaneously through
the same fiber.

Statistical TDM: an efficiency improvement over fixed TDM — time slots are allocated
dynamically based on actual demand rather than fixed assignment, closer to how
modern packet-switched networks operate.

Part 7: Security Over Networks

This section is networking’s overlap with your security prep — worth having tightly
integrated since interviewers pivot between the two freely.

7.1 The CIA Triad (recap in networking context)

Confidentiality — preventing unauthorized parties from reading data in transit
(achieved via encryption)

Integrity — ensuring data isn’t tampered with in transit (achieved via

hashing/checksums, digital signatures)

Availability — ensuring network services remain accessible (threatened by attacks like

 DDoS, discussed below)

7.2 Encryption in Networking Context

Symmetric encryption (e.g., AES): same key used to encrypt and decrypt — fast,
efficient for bulk data, but requires securely sharing the key beforehand (the “key
distribution problem”).

Asymmetric encryption (public-key cryptography, e.g., RSA): uses a mathematically

linked key pair — a public key (freely shared) and a private key (kept secret). Data
encrypted with the public key can only be decrypted with the corresponding private key
(and vice versa, which is what enables digital signatures). Solves the key distribution
problem but is computationally much slower than symmetric encryption.

Hybrid encryption — what real systems (like TLS/HTTPS) actually use: asymmetric
encryption is used only briefly, during the initial handshake, to securely exchange a
temporary symmetric session key; the bulk of the actual data transfer then uses fast
symmetric encryption with that session key. This combines asymmetric encryption’s
key-distribution advantage with symmetric encryption’s speed advantage — a strong
answer if pushed past a basic asymmetric definition.

Hashing vs Encryption — a classic point of confusion worth being crisp about:

encryption is reversible (meant to be decrypted by someone with the right key);
hashing is one-way (meant to never be reversed) and is used for integrity verification
(e.g., verifying a file wasn’t altered) and password storage (storing a hash instead of the
actual password).

7.3 Digital Signatures and Certificates

Digital signature: the sender encrypts a hash of the message with their private key;
anyone with the sender’s public key can decrypt and compare it to their own hash of the
received message — if they match, this proves both integrity (message wasn’t altered)
and authenticity/non-repudiation (only the holder of the private key could have created
that signature).

Certificates (as in HTTPS): a trusted third party (Certificate Authority) vouches that a
given public key genuinely belongs to a given entity (e.g., a specific website) — this is
what lets your browser trust that the public key it receives during a TLS handshake
actually belongs to the website you intended to visit, not an impersonator.

7.4 Common Attack Types (one-sentence familiarity for each)

Phishing — tricking users into revealing sensitive information via deceptive
communication, typically not a purely technical network attack but a social-engineering
 one.

Man-in-the-Middle (MITM) — an attacker secretly intercepts (and potentially alters)

communication between two parties who believe they’re communicating directly with
each other; HTTPS/TLS is specifically designed to prevent this via certificate-based
authentication.

DoS/DDoS (Denial of Service / Distributed DoS) — overwhelming a target with traffic

(from one source or many distributed sources) to exhaust its resources and make it
unavailable to legitimate users — a direct attack on the “Availability” leg of the CIA triad.

SQL Injection — technically an application/database-layer attack rather than purely a

network one, but commonly raised in the same breath as network security; involves
injecting malicious SQL through unsanitized input fields. Defense: parameterized
queries/prepared statements.

Spoofing — falsifying source information (IP spoofing, ARP spoofing, DNS spoofing) to
impersonate a trusted entity.

Part 8: Wireless Networking (brief, secondary priority)

WiFi (802.11 family): uses CSMA/CA (see Part 2.3) rather than CSMA/CD, since
collision detection is unreliable on a shared wireless medium.

Access Point (AP): the device wireless clients connect through to reach the broader
network — functionally similar to a switch/hub role but for wireless clients.

SSID: the network name broadcast by an AP.

Basic security standards (know the progression, not deep mechanics): WEP (old,
broken) → WPA → WPA2 → WPA3 (current standard), each improving encryption and
authentication over the last.

Part 9: Performance & Reliability Concepts (cross-cutting)

Bandwidth vs Throughput vs Latency:

Bandwidth — the theoretical maximum data rate a link can support

Throughput — the actual achieved data rate, which is often lower than bandwidth
due to overhead, congestion, or errors

Latency — the time delay for data to travel from source to destination (distinct from
 bandwidth/throughput entirely — a high-bandwidth link can still have high latency,
e.g., satellite internet)

Jitter: variation in latency over time — particularly damaging for real-time applications
like video calls, which is part of why those applications favor UDP (a late, jitter-affected
retransmission is often worse than just dropping and moving on).

Packet loss: the percentage of packets that fail to arrive — TCP handles this via
retransmission (at a cost to speed); UDP-based real-time applications generally just
tolerate it up to a threshold.

Part 10: How This All Connects — The Big Picture

The same integrative habit from the AI document applies here: most networking questions
are really asking “which layer, and what does that layer guarantee that the others
don’t.”

Need raw bits to travel a wire? → Physical

Need to get a frame to the next physical hop on the same local network? → Data Link
(MAC addresses)

Need to get a packet across multiple networks to a distant machine? → Network (IP
addresses, routing)

Need reliable delivery to the correct process on that machine, or need raw speed
instead? → Transport (TCP vs UDP, port numbers)

Need to actually do something useful with that data? → Application (HTTP, DNS, DHCP,
etc.)

And the cross-cutting concerns — security, multiplexing, performance — sit across this
stack rather than at one layer, which is exactly why interviewers like pivoting into them after
a layer-specific question: they’re testing whether you see the stack as a coherent whole, not
memorized layer-by-layer trivia.

Quick Self-Test Checklist

Before your interview, you should be able to do all of the following without notes:

Recite all 7 OSI layers top to bottom (and bottom to top) and map them to the 4 TCP/IP
layers
 Explain encapsulation with the correct unit name at each layer (segment → packet →
frame → bit)

Compare TCP and UDP across connection, reliability, ordering, speed, and header
overhead — and justify why each difference exists mechanically, not just state it

Walk through the three-way handshake and four-way termination, explaining why
termination needs a fourth step

Explain exactly how TCP detects lost data (sequence numbers, ACKs, RTO, duplicate
ACKs/fast retransmit)

Explain why NAT is needed and name the three types (static, dynamic, PAT)

Explain the DORA process for DHCP from memory

Do a basic subnetting calculation given an IP + CIDR prefix

Explain the difference between symmetric, asymmetric, and hybrid encryption, and
where each is used in HTTPS specifically

State the difference between hashing and encryption clearly

Explain FDM vs TDM and defend a position on “which is better” with a concrete reason

Explain what a digital signature proves and how (private key encrypts hash → public key
verifies)

Notes on Scope
This document covers the full standard undergraduate Networking course arc — the layered
model, each layer’s core protocols and mechanics, addressing/subnetting, multiplexing, and
the security concepts that overlap with networking — not only the specific questions your
seniors happened to report. Deeper specializations (network programming/sockets code,
detailed routing protocol math, wireless PHY-layer depth) sit beyond this scope and are
lower-probability for a general lecturer viva; flag if you have specific reason to expect that
depth and this can be extended further.