136 Networks Interview Questions and Answers (2026)

The OSI model breaks communication into 7 layers, each with a defined responsibility, so a problem or protocol can be isolated to one layer. From bottom to top: Physical, Data Link, Network, Transport, Session, Presentation, Application.

• L1 Physical: Raw bits over a medium; e.g. Ethernet physical, cables, radio.

• L2 Data Link: Framing and MAC addressing on a local link; e.g. Ethernet, PPP, ARP.

• L3 Network: Logical addressing and routing between networks; e.g. IP, ICMP.

• L4 Transport: End-to-end delivery, ports, reliability; e.g. TCP, UDP.

• L5 Session: Establishes/maintains sessions; e.g. NetBIOS, RPC.

• L6 Presentation: Encoding, encryption, compression; e.g. TLS, JPEG, ASCII.

• L7 Application: Interfaces the user/app sees; e.g. HTTP, DNS, SMTP.

They are the same data described as protocol data units (PDUs) at different layers: a segment is the Transport-layer unit, a packet is the Network-layer unit, and a frame is the Data Link-layer unit. As data goes down the stack, each layer wraps the one above.

• Segment (Layer 4, Transport): App data + TCP header (ports, sequence/ack numbers). A UDP unit is often called a datagram.

• Packet (Layer 3, Network): Segment + IP header (source/destination IP addresses); this is what gets routed across networks.

• Frame (Layer 2, Data Link): Packet + MAC header and trailer (FCS); this travels one hop across a local link.

• Nesting relationship: A frame carries a packet, which carries a segment, which carries the data: pure encapsulation.

A network request has a clear lifecycle: locate the server, connect, (optionally) secure, exchange request and response, then reuse or close the connection. It's the full path of setup, transfer, and teardown.

1. Name resolution: Client resolves the hostname to an IP via DNS.

2. Connection setup: TCP 3-way handshake (SYN/SYN-ACK/ACK) creates a reliable channel; TLS handshake follows if HTTPS.

3. Request: Client sends its request (method, path, headers, body) which is encapsulated and routed hop by hop to the server.

4. Server processing: Server parses the request, runs application logic (DB queries, etc.), and builds a response.

5. Response: Server returns status, headers, and body; client processes it.

6. Connection teardown or reuse: Keep-alive reuses the connection; otherwise a FIN/ACK exchange closes it.

They operate at increasing layers and get progressively smarter: a hub blindly repeats bits (L1), a switch forwards frames by MAC address (L2), and a router forwards packets between networks by IP address (L3).

• Hub (Layer 1): Repeats incoming signals out every other port; no addressing, so all ports share one collision domain and one broadcast domain. Largely obsolete.

• Switch (Layer 2): Learns MAC addresses into a table and forwards frames only to the correct port. Each port is its own collision domain; still one broadcast domain (per VLAN).

• Router (Layer 3): Connects different networks, forwarding packets by IP using a routing table. Each interface is a separate broadcast domain, and it enables NAT and inter-network routing.

A switch is a Layer 2 device that forwards frames using MAC addresses within a LAN; a router is a Layer 3 device that forwards packets between different networks using IP addresses.

• Switch (Layer 2, Data Link):

  • Reads destination MAC addresses and builds a MAC-address table to forward frames only out the correct port.

  • Connects devices inside the same network/subnet; does not cross network boundaries.

• Router (Layer 3, Network):

  • Reads destination IP addresses and uses a routing table to choose the best path between networks.

  • Connects different networks (e.g. LAN to the internet) and defines broadcast domain boundaries.

• Key distinction: A switch separates collision domains but forwards broadcasts; a router separates broadcast domains and makes inter-network decisions.

The OSI model is a 7-layer conceptual framework describing how data moves from an application down to physical bits and back up. A switch typically operates at Layer 2 (Data Link) and a router at Layer 3 (Network), because that is where MAC-based and IP-based forwarding decisions naturally live.

• The 7 layers (top to bottom):

  1. Application: user-facing protocols (HTTP, DNS, SMTP).

  2. Presentation: encoding, encryption, compression.

  3. Session: establishing/managing dialogs between hosts.

  4. Transport: end-to-end delivery, ports, reliability (TCP, UDP).

  5. Network: logical addressing and routing (IP).

  6. Data Link: framing and MAC addressing on a link (Ethernet).

  7. Physical: raw bits over the medium (cables, signals).

• Switch operates at Layer 2: It forwards frames using MAC addresses, the Data Link layer's addressing scheme.

• Router operates at Layer 3: It forwards packets using IP addresses, the Network layer's job, to route between networks.

• Memory aid: "All People Seem To Need Data Processing" (Application down to Physical).

Duplex describes the direction of data flow on a link: full-duplex allows sending and receiving simultaneously, while half-duplex allows only one direction at a time.

• Half-duplex:

  • One direction at a time; the device must take turns sending and receiving (like a walkie-talkie).

  • Shared medium means collisions are possible, so CSMA/CD is needed (e.g. old Ethernet hubs).

• Full-duplex:

  • Simultaneous send and receive over separate paths (like a phone call).

  • No collisions on the link, so effective throughput roughly doubles (modern switched Ethernet).

• Practical note: A switch port connected to one device runs full-duplex; a hub forces half-duplex because the medium is shared.

A modem (modulator-demodulator) converts between your ISP's analog/line-encoded signal and the digital data your equipment understands; it bridges your network to the internet, which a router alone cannot do.

• What a modem does:

  • Modulates outgoing digital data onto the ISP medium (cable, DSL, fiber) and demodulates incoming signals back to digital.

  • Provides the actual connection to the ISP and typically your public IP.

• What a router does instead:

  • Routes IP packets between networks and shares one connection among many devices (usually via NAT).

  • Has no ability to talk to the ISP's physical line on its own.

• Key difference: The modem is the gateway to the ISP; the router distributes and directs traffic behind it. Home "gateway" boxes combine both.

A NIC is the hardware (built-in or add-on) that physically connects a device to a network and gives it a unique MAC address. It operates primarily at Layer 1 (Physical) and Layer 2 (Data Link).

• Layer 1 (Physical) role: Transmits and receives the raw electrical/optical/radio signals on the medium.

• Layer 2 (Data Link) role: Builds and reads Ethernet frames and carries the burned-in MAC address used for local addressing.

• Other functions:

  • Handles framing, error checking (CRC/FCS), and duplex/speed negotiation.

  • Can be wired (Ethernet) or wireless (Wi-Fi); each has its own MAC.

All three connect network segments, but they operate at different layers and get progressively smarter: a repeater regenerates signals (Layer 1), a bridge forwards frames between two segments using MAC addresses (Layer 2), and a switch is essentially a multi-port bridge with hardware forwarding (Layer 2).

• Repeater (Layer 1): Amplifies/regenerates the signal to extend distance; no addressing awareness, blindly repeats everything (including noise and collisions).

• Bridge (Layer 2):

  • Connects two segments and uses a MAC table to decide whether to forward or filter a frame, splitting collision domains.

  • Typically few ports and software-based forwarding.

• Switch (Layer 2):

  • A many-port bridge doing forwarding in hardware (ASIC); each port is its own collision domain.

  • Enables full-duplex per port and high throughput.

• Summary: Repeater = extend, bridge = filter/forward frames, switch = do it fast on many ports.

These four terms classify networks by geographic scope, from a single person's devices up to networks spanning continents.

• PAN (Personal Area Network):

  • Smallest scope: devices around one person (a few meters), often via Bluetooth or USB.

  • Example: phone paired with earbuds and a smartwatch.

• LAN (Local Area Network):

  • A single building or campus, privately owned, high speed (1-10 Gbps) and low latency.

  • Uses Ethernet and Wi-Fi; you own the infrastructure.

• MAN (Metropolitan Area Network):

  • Spans a city or metro area, larger than a LAN but smaller than a WAN.

  • Often connects multiple LANs; example: a city government linking its offices.

• WAN (Wide Area Network):

  • Largest scope: cities, countries, continents; the Internet is the ultimate WAN.

  • Relies on leased lines/carriers, so higher latency and typically lower per-link speed than a LAN.

• Key axes to remember: geographic size, ownership, speed, and latency.

In client-server, dedicated servers provide resources to requesting clients; in peer-to-peer (P2P), every node acts as both client and server, sharing resources directly with no central authority.

• Client-server:

  • Centralized: clients request, a server responds (web, email, databases).

  • Easier to secure, manage, and back up centrally.

  • Weakness: the server is a single point of failure and a scaling bottleneck (cost grows with load).

• Peer-to-peer:

  • Decentralized: each peer both consumes and provides (BitTorrent, blockchain).

  • Scales and self-heals well: more peers add capacity and there's no single failure point.

  • Weakness: harder to secure, manage, and guarantee data consistency/availability.

• Tradeoff summary: client-server trades resilience for control; P2P trades control for resilience and scale.

Topology describes how nodes are physically or logically connected; the four classic layouts trade off cost, fault tolerance, and performance differently.

• Star:

  • All nodes connect to a central device (switch/hub); dominant in modern LANs.

  • Pro: easy to add/remove nodes, one link failure isolates one node. Con: the central device is a single point of failure.

• Bus:

  • All nodes share one backbone cable.

  • Pro: cheap, little cabling. Con: a break in the backbone downs everyone; collisions limit performance.

• Ring:

  • Each node connects to two neighbors, data circulates around the loop.

  • Pro: predictable performance (token passing). Con: a single break can break the ring (mitigated by dual rings).

• Mesh:

  • Nodes interconnect with many/all others (full mesh = every pair connected).

  • Pro: highly fault tolerant, multiple paths. Con: expensive, cabling grows as n(n-1)/2; used for backbones/critical links.

• Bottom line: star wins for LANs on manageability; mesh wins on resilience at high cost.

A MAC address is a 48-bit (6-byte) hardware identifier, usually written as six hex octets. Its first half is the OUI (Organizationally Unique Identifier) assigned to the manufacturer, and the second half is a device-specific serial portion, together making it globally unique.

• Structure:

  • 48 bits split into two 24-bit halves: OUI (first 3 bytes) + NIC-specific (last 3 bytes).

  • Example: 00:1A:2B is the OUI, 3C:4D:5E identifies the specific interface.

• Significance of the OUI:

  • Assigned by the IEEE to vendors, so it identifies the manufacturer of the NIC.

  • Guarantees uniqueness: vendors only assign each serial portion once within their OUI.

• Two special bits in the first octet:

  • I/G bit: unicast vs multicast address.

  • U/L bit: globally unique (burned-in) vs locally administered (e.g. randomized/spoofed).

TCP is a connection-oriented, reliable, ordered byte stream; UDP is a connectionless, best-effort datagram service. Choose TCP when correctness and completeness matter, UDP when low latency and low overhead matter more than guaranteed delivery.

• TCP:

  • Establishes a connection (three-way handshake) before sending.

  • Reliable and ordered: sequence numbers, ACKs, and retransmission recover lost or reordered data.

  • Flow control and congestion control adapt the send rate to the receiver and network.

  • Higher overhead and latency (larger header, handshakes, retransmit waits).

• UDP:

  • No connection, no ACKs: just fire datagrams (8-byte header).

  • No delivery, ordering, or duplicate guarantees; the app handles what it needs.

  • Low latency and supports one-to-many (broadcast/multicast).

• When to choose:

  • TCP: web (HTTP), file transfer, email, anything where every byte must arrive intact.

  • UDP: real-time voice/video, gaming, DNS queries, telemetry where speed beats perfection.

A socket is the endpoint an application uses to send and receive data over the network: it's the OS abstraction that ties a communication channel to your program. A full connection endpoint is identified by an IP address plus a port, and the socket is the programmable handle to that endpoint.

• IP address: Identifies the host (which machine) on the network.

• Port: A 16-bit number identifying which process/service on that host (e.g. 80 for HTTP).

• Socket:

  • The endpoint = IP + port + protocol; the API handle your code reads/writes through.

  • A TCP connection is uniquely identified by a 4-tuple: source IP, source port, destination IP, destination port.

• Relationship:

  • IP gets you to the machine, port gets you to the process, and the socket is how the application actually plugs into that address:port to exchange data.

  • One server port can hold many client connections at once because each is a distinct 4-tuple.

Well-known ports (0 to 1023) are reserved for standard services so clients know where to reach them by default. They are treated specially because binding to them typically requires elevated privileges, preventing ordinary users from impersonating core services.

• Common well-known ports:

  • 20/21 FTP, 22 SSH, 23 Telnet, 25 SMTP, 53 DNS, 80 HTTP, 443 HTTPS.

  • 110 POP3, 143 IMAP, 123 NTP, 67/68 DHCP.

• Port ranges (IANA): 0 to 1023 well-known, 1024 to 49151 registered, 49152 to 65535 dynamic/ephemeral (used by clients).

• Why below 1024 is privileged: On Unix-like systems, binding a port under 1024 requires root or a capability like CAP_NET_BIND_SERVICE, so a random user can't run a fake web/mail server on the standard port.

A connection-oriented protocol establishes a session (handshake) before data flows and tears it down afterward, giving ordered, reliable delivery; a connectionless protocol just sends independent packets with no setup, trading guarantees for lower overhead and latency.

• Connection-oriented (e.g. TCP):

  • Three-way handshake sets up state before data; connection closed explicitly.

  • Provides reliability, in-order delivery, flow control, and congestion control.

  • More overhead and setup latency; good for file transfer, web, email.

• Connectionless (e.g. UDP):

  • No handshake or shared state; each datagram is routed independently.

  • No delivery/order guarantees, but low latency and overhead.

  • Good for real-time media, DNS, gaming where speed beats perfect reliability.

• Key trade-off: reliability and ordering versus latency and simplicity.

The three-way handshake establishes a connection by exchanging and acknowledging initial sequence numbers in both directions. Three steps are needed because each side must both send its sequence number and confirm it received the other's; two steps could only synchronize one direction.

• The three steps:

  1. Client sends SYN with its initial sequence number (ISN_c).

  2. Server replies SYN-ACK: acks ISN_c and sends its own ISN_s.

  3. Client sends ACK of ISN_s; connection is established.

• Why two isn't enough:

  • Both directions need synchronized sequence numbers; two steps only confirm one side's ISN.

  • The third ACK confirms the server's ISN was received, so both ends agree the connection is live.

• What it protects against:

  • Rejects delayed/duplicate old SYNs from a previous connection: the mismatched sequence number is caught.

  • Random ISNs also make sequence-number spoofing harder.

A public IP is globally routable and unique on the internet, while a private IP (from the RFC 1918 ranges) is reusable inside private networks and not routable on the public internet. They communicate through NAT, which translates private addresses to a public one at the router.

• Public IP: Globally unique, assigned by ISPs/registries, reachable from anywhere on the internet.

• Private IP (RFC 1918):

  • Reserved ranges: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16.

  • Reusable across many networks; internet routers drop them.

• How they communicate: NAT:

  • The gateway rewrites the private source IP to its public IP on outbound packets (usually PAT/NAT overload, tracking ports).

  • It keeps a translation table to map return traffic back to the correct internal host.

  • Inbound connections need explicit port forwarding since private hosts aren't directly addressable.

Both describe where the network prefix ends and the host portion begins. A subnet mask does this as a dotted-decimal bit pattern; CIDR notation is the compact form that just states the number of prefix bits, enabling flexible, class-free address allocation.

• Purpose of the mask: Splits an address into network and host parts so devices can tell local from remote and networks can be subdivided.

• CIDR notation: Appends the prefix length, e.g. 192.168.1.0/24 means 24 network bits, equivalent to mask 255.255.255.0.

• Why CIDR matters:

  • Replaces rigid classful (A/B/C) allocation with arbitrary prefix lengths, reducing address waste.

  • Enables route aggregation (supernetting): many prefixes summarized as one, shrinking routing tables.

• Sizing: Host count is roughly 2^(32 - prefix) minus network and broadcast addresses (for IPv4).

TTL is an 8-bit field in the IPv4 header that limits how many hops a packet can traverse: each router that forwards it decrements the value by one, and when it hits zero the packet is discarded to prevent it looping forever.

• Purpose: loop prevention: Without a hop limit, a routing loop would circulate a packet endlessly and congest the network.

• How it decrements: Each router subtracts 1 before forwarding; it is a hop count, not literally seconds.

• When it reaches zero: The router drops the packet and typically sends an ICMP Time Exceeded message back to the source.

• Practical use: traceroute: Sends packets with increasing TTL (1, 2, 3...) so each hop returns an ICMP error, revealing the path.

• IPv6 equivalent: The same idea is called Hop Limit.

A router looks at a packet's destination IP and searches its routing table for the matching route, using the longest prefix match to pick the most specific one, then forwards the packet out the associated interface toward the next hop.

• The routing table: A set of entries mapping destination prefixes (e.g. 10.0.0.0/8) to a next-hop IP and outgoing interface.

• Longest prefix match: If several routes match, the one with the most specific (longest) prefix wins, e.g. /24 beats /16.

• Default route: 0.0.0.0/0 catches anything with no more specific match (typically the path to the upstream/Internet).

• Where routes come from: Directly connected networks, static routes, or dynamic protocols (OSPF, BGP); metrics/administrative distance break ties.

• Hop-by-hop forwarding: Each router only decides the next hop; the packet is re-evaluated at every router until it reaches the destination network.

A default gateway is the router interface a host sends packets to when the destination is not on its own subnet: it's the exit door from the local network to everywhere else.

• How the host decides: The host ANDs the destination IP with its subnet mask; if the result matches its own subnet, it delivers locally, otherwise it forwards to the default gateway.

• Layer 2 vs Layer 3 addressing: The packet keeps the final destination IP, but the Ethernet frame is addressed to the gateway's MAC (found via ARP).

• What the gateway does: It rewrites the L2 header and routes the packet toward the destination, hop by hop, using its own routing table.

• Configuration: Set statically or via DHCP; it appears in the host's routing table as the route to 0.0.0.0/0 (the default route).

• Without one, a host can only reach devices on its own subnet.

SSH (Secure Shell) is an application-layer protocol that provides an encrypted, authenticated channel over an insecure network, most commonly for remote command-line login and secure file transfer. It runs over TCP port 22.

• What it provides:

  • Confidentiality and integrity: all traffic (including passwords) is encrypted, replacing insecure Telnet/rlogin.

  • Authentication: server identity via host keys, client via password or public-key pairs.

• Beyond a shell:

  • Carries other protocols: SFTP and scp for files.

  • Port forwarding/tunneling to secure arbitrary TCP connections, plus X11 forwarding.

• How it secures the session: A key exchange (e.g. Diffie-Hellman) establishes shared session keys, then symmetric encryption protects the channel.

Telnet is an early protocol for remote command-line access to a device over TCP port 23. It's considered insecure because it transmits everything, including credentials, in plaintext, so SSH has replaced it.

• How Telnet works:

  • Opens an interactive terminal session to a remote host on TCP 23.

  • No encryption and no strong authentication built in.

• Why it's insecure:

  • Plaintext: usernames, passwords, and commands travel unencrypted, so anyone sniffing the link can read them.

  • No integrity or server authentication: vulnerable to eavesdropping and man-in-the-middle tampering.

• Why SSH is preferred:

  • Runs on TCP 22 with encrypted sessions.

  • Provides strong authentication (passwords or key pairs) and server host-key verification.

  • Ensures confidentiality and integrity of all traffic.

• Telnet still appears for testing raw TCP ports (e.g. connecting to port 80 to check a service).

DNS records are typed entries in a zone that tell resolvers how to handle a name. The most common ones map names to addresses, to other names, to mail servers, and to arbitrary text.

• A: Maps a hostname to an IPv4 address.

• AAAA: Maps a hostname to an IPv6 address.

• CNAME: Aliases one name to another canonical name that is then resolved.

• MX: Specifies the mail server(s) for a domain, with a priority value (lower = preferred).

• TXT: Holds arbitrary text, commonly used for SPF, DKIM, DMARC, and domain-ownership verification.

• Also worth knowing: NS (delegates a zone to nameservers), SOA (zone authority info), PTR (reverse IP-to-name lookups).

An NS record delegates a zone by naming its authoritative name servers, while a TXT record holds arbitrary text used mainly for verification and email policy.

• NS records:

  • List the authoritative name servers for a domain or subdomain (e.g. ns1.example.com).

  • They drive delegation: the parent zone's NS records tell resolvers where to go next in the hierarchy.

• TXT records:

  • Store free-form text; widely used for machine-readable policy.

  • Email authentication: SPF, DKIM keys, and DMARC policies all live in TXT records.

  • Domain ownership verification for services (e.g. proving you control a domain to Google or a CA).

The Host header tells the server which domain the request is for, enabling many sites (virtual hosts) to share one IP address; it became mandatory in HTTP/1.1.

• Virtual hosting: One server/IP can host example.com and other.com; the Host header lets the server route to the right site.

• Why it's required in HTTP/1.1: The request line usually carries only the path, not the domain, so without Host the server couldn't disambiguate; a missing header yields 400 Bad Request.

• Related uses:

  • Reverse proxies and load balancers route by Host; note TLS uses SNI to pick the certificate before the header is even readable.

  • In HTTP/2 it is superseded by the :authority pseudo-header.

HTTP status codes are grouped into five classes by their leading digit, each signaling a category of outcome from informational through server error.

• 1xx Informational: Request received, processing continues. Example: 100 Continue (client may send the body).

• 2xx Success: Request succeeded. Example: 200 OK, or 201 Created after a resource is made.

• 3xx Redirection: Further action needed to complete. Example: 301 Moved Permanently, 304 Not Modified (use cache).

• 4xx Client Error: The request was malformed or unauthorized. Example: 404 Not Found, 401 Unauthorized.

• 5xx Server Error: The server failed to fulfill a valid request. Example: 500 Internal Server Error, 503 Service Unavailable.

An HTTP request is plain text (in HTTP/1.1) made of three parts in order: a request line, a set of headers, and an optional body separated from the headers by a blank line.

• Request line: Three tokens: method, request target (path + query), and HTTP version, e.g. GET /users?id=5 HTTP/1.1.

• Headers:

  • Key-value metadata, one per line (Host, Content-Type, Authorization).

  • Host is mandatory in HTTP/1.1 (enables virtual hosting).

• Blank line: A single empty line (CRLF) marks the end of headers and start of the body.

• Body: Optional payload for methods like POST/PUT; its size/format come from Content-Length or Transfer-Encoding and Content-Type.

A Certificate Authority is a trusted third party that vouches for identity by signing digital certificates; a certificate binds a public key to an identity (like a domain name) so clients can trust they're talking to the real server.

• Digital certificate: An X.509 document holding the subject's public key, identity (domain), validity dates, and the CA's digital signature.

• Role of the CA:

  • Verifies the applicant actually controls the identity, then signs the certificate with the CA's private key.

  • That signature is what makes the certificate trustworthy.

• Chain of trust:

  • Browsers/OSes ship a set of trusted root CA public keys; a server cert chains up through intermediates to a trusted root.

  • The client verifies each signature in the chain up to a root it already trusts.

• What it prevents: An attacker can present a public key, but without a valid CA signature for that domain the client rejects it, blocking impersonation.

Latency and throughput are related but independent: latency is delay, throughput is rate. You absolutely can have high throughput with high latency, because throughput depends on how much data is in flight, not just how fast one packet arrives.

• They measure different things: Latency = time for data to arrive; throughput = volume delivered per second.

• High latency + high throughput is possible:

  • A satellite link may have 600 ms RTT yet carry gigabits per second, like a slow but very wide conveyor belt.

  • The key is keeping enough data in flight (see bandwidth-delay product) to fill the pipe.

• When latency caps throughput: For window-limited or request/response protocols, throughput ≈ window size ÷ RTT, so higher latency directly lowers effective throughput unless the window grows.

• Analogy: Latency is how long the trip takes; throughput is how many lanes of traffic flow at once.

Bandwidth is the theoretical maximum capacity of a link, throughput is the actual data rate achieved in practice, and latency is the delay before data arrives. Bandwidth is the ceiling, throughput is reality, and latency is timing.

• Bandwidth: Maximum possible bits per second a link can carry; a fixed property of the medium/provisioning.

• Throughput: Real rate of successful delivery, always ≤ bandwidth, reduced by protocol overhead, congestion, retransmissions, and latency.

• Latency: Delay for data to travel across the network; independent of capacity.

• Analogy (a pipe): Bandwidth is the pipe's diameter, throughput is how much water actually flows, and latency is how long it takes the first drop to reach the end.

Both sit between clients and servers, but they act on behalf of opposite ends: a forward proxy represents the clients reaching out to the internet, while a reverse proxy represents the servers that clients reach. A reverse proxy is the one used to protect a web server.

• Forward proxy (client-side):

  • Sits in front of clients on a private network; the origin server sees the proxy, not the real client.

  • Used for outbound control: content filtering, caching, anonymity, bypassing geo-restrictions.

• Reverse proxy (server-side):

  • Sits in front of servers; the client thinks it is talking to the real server but hits the proxy.

  • Used for load balancing, TLS termination, caching, and hiding the origin's IP and topology.

• Which protects a web server: the reverse proxy: It shields origin IPs, absorbs DDoS/rate-limits, and centralizes auth/WAF filtering (e.g. nginx, HAProxy, Cloudflare).

ping tests reachability and latency by sending ICMP Echo Request packets and timing the matching Echo Replies. It uses the ICMP protocol, which operates at Layer 3 (the Network layer).

• Mechanism:

  • Sends ICMP Echo Request (type 8); a reachable host answers with Echo Reply (type 0).

  • Measures round-trip time and detects loss over repeated probes.

• Protocol and layer:

  • Uses ICMP, carried directly inside IP with no TCP/UDP port, so there are no transport ports involved.

  • ICMP is a Layer 3 (Network layer) protocol.

• Caveat: many firewalls block ICMP, so no reply does not always mean the host is truly down.

Typing a URL triggers a chain of steps: resolve the name to an IP, open a transport connection, secure it, send an HTTP request, receive the response, then parse and render. The networking core is DNS lookup, TCP handshake, TLS handshake, and HTTP exchange.

1. URL parsing and cache check: Browser splits the URL into scheme, host, path; checks HSTS and its own cache before touching the network.

2. DNS resolution: Resolve hostname to IP: browser cache, OS cache, then a recursive resolver querying root, TLD, and authoritative servers (mostly UDP:53).

3. ARP + routing: OS finds the next hop via the routing table and uses ARP to get the MAC of the gateway on the local link.

4. TCP 3-way handshake: SYN, SYN-ACK, ACK establishes a reliable connection to port 443 (or 80).

5. TLS handshake (HTTPS): Negotiates cipher, validates the server certificate, and derives session keys so traffic is encrypted.

6. HTTP request/response: Browser sends GET with headers; server responds with a status code and the HTML body.

7. Rendering begins: Browser parses HTML into the DOM, fetches sub-resources (CSS, JS, images) over more requests, and paints the page.

Encapsulation is the sender wrapping data in a new header (and sometimes trailer) at each layer as it moves down the stack; decapsulation is the receiver stripping those headers layer by layer on the way up. Each layer adds only what its peer layer needs.

• Encapsulation (top to bottom, on the sender):

  1. Application data is handed to Transport, which adds a TCP/UDP header (ports, seq numbers): a segment.

  2. Network adds an IP header (source/dest IP): a packet.

  3. Data Link adds a header + trailer (MAC addresses, FCS): a frame.

  4. Physical transmits the frame as bits (electrical, optical, or radio signals).

• Decapsulation (bottom to top, on the receiver): Each layer reads and removes its own header, uses it to decide handling, and passes the payload up until the app gets the original data.

• Key idea: each layer only understands its own header: The payload from the layer above is treated as opaque data, which is what makes the layered model modular.

OSI is a 7-layer conceptual reference model; TCP/IP is a 4-layer practical model that describes how the internet actually works. We use OSI to teach and troubleshoot, and TCP/IP because it maps to the protocols we really run.

• Layer count and mapping:

  • TCP/IP collapses OSI's Application, Presentation, and Session into one Application layer, and Physical + Data Link into one Link (Network Access) layer.

  • Transport and Network map roughly one-to-one.

• Purpose:

  • OSI is prescriptive/theoretical: a vendor-neutral framework designed before its protocols.

  • TCP/IP is descriptive: built around protocols that already worked (IP, TCP).

• Why keep both:

  • OSI's granularity gives a common vocabulary for troubleshooting ("it's a Layer 2 issue").

  • TCP/IP reflects reality, so it's what implementations and RFCs follow.

A collision domain is the set of devices whose frames can collide on a shared medium; a broadcast domain is the set of devices that receive one another's broadcast frames. Switches shrink collision domains, and routers bound broadcast domains.

• Collision domain:

  • Where two transmissions can interfere (relevant to half-duplex/CSMA-CD).

  • A hub keeps all ports in one collision domain; each switch port is its own, so modern full-duplex links effectively eliminate collisions.

• Broadcast domain:

  • Where a broadcast (e.g. ARP, DHCP discover) reaches every device.

  • Hubs and switches forward broadcasts, so they stay one domain; a router (or VLAN) creates a boundary.

• Device summary: Hub: 1 collision, 1 broadcast domain. Switch: many collision, 1 broadcast domain. Router: separates both.

These are four ways to address the destination of a packet, differing by how many receivers a single transmission targets and how the network selects them.

• Unicast: one-to-one: A single sender to a single, specific destination address. The most common form (e.g. a web request).

• Broadcast: one-to-all: Delivered to every host on the local segment/subnet (e.g. ARP requests, 255.255.255.255). IPv4 only; IPv6 dropped it in favor of multicast.

• Multicast: one-to-many (subscribed): Delivered only to hosts that joined a group (e.g. streaming, routing protocols like OSPF). Efficient: sender transmits once, network replicates as needed.

• Anycast: one-to-nearest: Many hosts share one address; routing delivers to the topologically closest one. Used by DNS root servers and CDNs for locality and load balancing.

A Layer 2 switch forwards frames using only MAC addresses within a single network, while a Layer 3 switch adds routing capability, forwarding packets between VLANs/subnets using IP addresses at hardware speed.

• Layer 2 switch:

  • Uses a MAC-address table; cannot route between subnets and needs a router for inter-VLAN traffic.

  • Operates only within broadcast/VLAN domains.

• Layer 3 switch:

  • Combines switching plus routing: maintains a routing table and performs inter-VLAN routing in hardware (ASIC).

  • Much faster than a traditional router for internal traffic, but usually lacks WAN interfaces and advanced routing features.

• When to use which: Layer 2 for simple access/edge connectivity; Layer 3 for fast routing between many internal VLANs in a campus/data center core.

It uses ARP (Address Resolution Protocol) to map a known IP address to its MAC address: the sender broadcasts a question and the owner of that IP replies with its MAC.

• Trigger:

  • Host A wants to send to IP of Host B on the same subnet but doesn't know B's MAC.

  • It first checks its local ARP cache; if missing, it starts ARP.

• ARP request (broadcast):

  • A sends a frame to destination MAC ff:ff:ff:ff:ff:ff asking "who has IP x.x.x.x?"

  • Every host on the segment receives it; only B matches.

• ARP reply (unicast): B responds directly to A with "IP x.x.x.x is at MAC yy:yy:...".

• Caching: A stores the mapping in its ARP cache (with a timeout) so it doesn't ask again for every packet.

• Note: ARP is IPv4/Layer 2 only; IPv6 uses NDP (Neighbor Discovery) instead.

We need both because they operate at different layers and solve different problems: MAC addresses deliver frames on a local link (Layer 2), while IP addresses enable routing across networks (Layer 3). Neither alone gives global, scalable, end-to-end delivery.

• MAC address (physical, Layer 2):

  • Flat, burned-in identifier for local delivery within one link/segment.

  • Not routable: there's no hierarchy, so routers couldn't scale to find a MAC across the Internet.

• IP address (logical, Layer 3):

  • Hierarchical and location-based, so routers aggregate routes and forward across networks.

  • But a router still needs a MAC to hand the frame to the actual next-hop device on the wire.

• Could you use only one?:

  • Only MAC: works on a single LAN but can't scale globally (no routing hierarchy).

  • Only IP: IPs can be reassigned and don't identify the physical NIC; hardware still needs a stable local address, and layering lets each layer change independently.

• The handoff: IP gets a packet to the right network end to end; MAC (via ARP) delivers it hop by hop on each link.

A VLAN (Virtual LAN) is a logical grouping of ports/devices into separate broadcast domains on the same physical switch(es), so you can segment a network at Layer 2 without adding hardware.

• What it does:

  • Splits one switch into multiple isolated broadcast domains; each VLAN behaves like a separate LAN.

  • Devices in different VLANs can't reach each other at Layer 2; they need a router or Layer 3 switch (inter-VLAN routing).

• Why it helps:

  • Reduces broadcast traffic by shrinking each broadcast domain.

  • Improves security/isolation (e.g., separate guest, voice, and internal traffic).

  • Groups logically (by department/function) regardless of physical location.

• How it's implemented: Each VLAN has an ID; frames carry it via 802.1Q tags when crossing trunk links between switches.

Trunking is carrying traffic from multiple VLANs over a single link between switches (or a switch and a router), using 802.1Q to tag each frame with its VLAN ID so the other end knows which VLAN it belongs to.

• The problem it solves: Without trunking you'd need one physical cable per VLAN between switches; that doesn't scale.

• How 802.1Q tagging works:

  • Inserts a 4-byte tag into the Ethernet frame containing the 12-bit VLAN ID (up to 4094 VLANs).

  • The receiving switch reads the tag, forwards the frame within the correct VLAN, then strips the tag before sending to an access (untagged) port.

• Access vs trunk ports:

  • Access port: belongs to one VLAN, sends untagged frames to end devices.

  • Trunk port: carries many tagged VLANs between infrastructure devices.

• Native VLAN: One VLAN on the trunk sent untagged; must match on both ends or traffic misroutes.

Both are media-access methods for shared channels, but CSMA/CD (Collision Detection) detects collisions after they happen on a wire, while CSMA/CA (Collision Avoidance) tries to prevent them because wireless nodes can't reliably detect collisions.

• CSMA/CD (wired Ethernet):

  • A station listens, transmits, and keeps listening: if it senses another signal it detects the collision, sends a jam signal, and backs off (binary exponential backoff).

  • Works on wire because a node can transmit and monitor the shared medium simultaneously to hear a garbled signal.

• CSMA/CA (Wi-Fi):

  • A wireless radio generally can't listen while transmitting, so collisions can't be reliably detected: it avoids them instead.

  • Uses random backoff before sending, and optionally RTS/CTS handshaking plus link-layer ACKs to confirm delivery.

• Why the split:

  • The hidden-node problem: two stations may not hear each other but both reach the access point, so avoidance and acknowledgment matter more than detection.

  • Note: modern switched full-duplex Ethernet has no collisions, so CSMA/CD is effectively obsolete there.

The sender computes a small check value from the frame's bits and appends it; the receiver recomputes it over the received data and compares. If they differ, the frame was corrupted in transit and is discarded (error detection, not correction).

• Checksum (e.g. Internet checksum):

  • Treats data as integers and sums them (one's-complement addition), storing the result.

  • Cheap but weak: can miss reordered bytes or certain multi-bit errors.

• CRC (Cyclic Redundancy Check):

  • Treats the frame as a big binary polynomial and divides it by a fixed generator polynomial; the remainder is the CRC (the FCS in Ethernet).

  • Receiver divides the whole received frame including CRC: a zero remainder means no detected error.

  • Much stronger: reliably catches all burst errors up to the CRC length and most random errors, which is why the data-link layer prefers it.

• Key limitation: These only detect errors; recovery (retransmission) is left to higher layers or link protocols.

An Ethernet frame wraps the payload with addressing, type, and error-check fields so switches can forward it and receivers can validate it. The core is destination MAC, source MAC, type/length, payload, and a trailing CRC.

• Preamble + SFD (7 + 1 bytes): Bit pattern for clock synchronization; the Start Frame Delimiter marks where the frame begins (not counted as frame data).

• Destination MAC (6 bytes): Who receives the frame (unicast, multicast, or broadcast FF:FF:FF:FF:FF:FF).

• Source MAC (6 bytes): The sender's hardware address.

• EtherType / Length (2 bytes): Values ≥ 0x0600 name the upper protocol (e.g. 0x0800 IPv4, 0x0806 ARP); smaller values mean length.

• Payload (46–1500 bytes): The encapsulated packet; padded to 46 bytes minimum to meet frame size rules.

• FCS / CRC (4 bytes): Frame Check Sequence used by the receiver to detect corruption.

You choose UDP for real-time apps (voice, video, gaming, live streaming) because late data is useless: retransmitting a dropped audio packet would only arrive after the moment it was needed, so it's better to skip it and stay current. In return you give up TCP's built-in reliability machinery.

• Why UDP fits real-time:

  • No retransmission waits or head-of-line blocking, so latency and jitter stay low.

  • A lost frame of audio/video is tolerable; a stalled stream is not.

• Reliability features you lose:

  • Guaranteed delivery: dropped datagrams are gone, no ACK/retransmit.

  • Ordering: datagrams can arrive out of sequence.

  • Duplicate detection: copies can arrive.

  • Flow and congestion control: UDP won't back off on its own, so the app must avoid flooding the network.

• Practical note: Real apps rebuild the pieces they need at the application layer (sequence numbers, jitter buffers, forward error correction), as protocols like RTP and QUIC do.

Multiplexing gathers data from many application sockets on the sending host and bundles it into segments for the network; demultiplexing does the reverse, delivering each incoming segment to the correct socket on the receiving host. Port numbers are the key that ties a segment to its socket.

• Multiplexing (send side): Takes data from multiple sockets, adds transport headers (including source/destination ports), and hands segments to the network layer.

• Demultiplexing (receive side): Uses header fields to steer each arriving segment to the right socket.

• How ports identify sockets:

  • UDP demux uses a 2-tuple: destination IP and destination port. Segments to the same port land in the same socket.

  • TCP demux uses a 4-tuple: source IP, source port, dest IP, dest port. So many connections to port 80 map to distinct sockets.

• This is what lets one host run a browser, email client, and SSH at once over a single IP.

The sliding window is TCP's mechanism for allowing multiple bytes to be in flight at once (rather than stop-and-wait), while still bounding how much unacknowledged data exists. It directly implements flow control: the window size is set by the receiver's advertised buffer space.

• What 'sliding' means: The sender may transmit any bytes within the window without waiting for each ACK. As ACKs arrive, the window's left edge advances (slides), freeing room to send new bytes.

• Relation to flow control:

  • The receiver advertises rwnd (free buffer space) in every ACK. The sender's outstanding data can't exceed it, so a slow receiver naturally throttles the sender.

  • If the receiver's buffer fills, it advertises a window of 0, pausing the sender until space frees up.

• Why it matters: Keeping many bytes in flight fills the pipe and boosts throughput; stop-and-wait would waste a full round-trip per segment.

TCP delivers a reliable, ordered byte stream over an unreliable network by numbering every byte, acknowledging what's received, and retransmitting anything that isn't acknowledged in time. Sequence numbers let the receiver order and dedupe data; ACKs tell the sender what arrived.

• Sequence numbers:

  • Each segment carries the sequence number of its first byte, so the receiver can reassemble data in order and discard duplicates.

  • Initial sequence numbers are chosen (not always 0) during the handshake for safety.

• Acknowledgments:

  • ACKs are cumulative: the ACK number is the next byte expected, confirming all prior bytes arrived contiguously.

  • Selective acknowledgment (SACK) can additionally report out-of-order blocks so only true gaps are resent.

• Detecting and recovering loss:

  • A retransmission timer (RTO, based on measured RTT) fires if an ACK doesn't arrive in time.

  • Three duplicate ACKs trigger fast retransmit before the timer expires.

• Also uses a checksum to detect corruption; corrupted segments are dropped and eventually retransmitted.

Slow start is the opening phase of TCP congestion control where the sender begins conservatively and increases its congestion window exponentially each RTT until it detects congestion or reaches a threshold. Despite the name, it ramps up fast; it's 'slow' only because it starts small rather than blasting at full rate.

• How it works:

  • Begins with a small initial cwnd (commonly around 10 segments in modern stacks).

  • Each ACK increases cwnd, so it roughly doubles every round-trip: exponential growth.

  • Continues until cwnd reaches ssthresh (then switches to congestion avoidance) or a loss occurs.

• Why it's used:

  • A new connection has no idea of available bandwidth; sending at full speed immediately could flood routers and cause loss.

  • Exponential probing quickly discovers capacity while keeping the initial burst safe.

• When it recurs: Also re-entered after a timeout, where cwnd resets to 1 and ssthresh is set to half the window at the time of loss.

Flow control protects the receiver from being overwhelmed, while congestion control protects the network from being overwhelmed. Slow Start is the phase where TCP probes available bandwidth by growing its sending window exponentially until it hits a threshold or detects loss.

• Flow control (receiver-driven):

  • The receiver advertises a receive window (rwnd) in every ACK based on its buffer space.

  • Sender never sends more unacked data than rwnd; prevents fast sender / slow receiver overflow.

• Congestion control (network-driven):

  • Sender maintains a congestion window (cwnd) inferred from loss/ACK signals, not advertised by anyone.

  • Actual sending limit is min(cwnd, rwnd).

• Slow Start mechanics:

  • Start with a small cwnd (e.g. a few MSS) and increase by 1 MSS per ACK.

  • This roughly doubles cwnd every RTT: exponential growth despite the name.

  • Continues until cwnd reaches ssthresh, then switches to linear (congestion avoidance), or until loss occurs.

Packet loss comes mainly from congestion (router queues overflow) but also from transmission errors and hardware/routing faults. TCP treats loss as its primary congestion signal and responds by retransmitting the data and shrinking its congestion window.

• Causes of loss:

  • Congestion: buffers full at a bottleneck router, so packets are dropped (tail drop or AQM like RED).

  • Bit errors: corrupted frames fail checksums and are discarded (common on wireless links).

  • Faults: link failures, routing changes, or misconfiguration.

• How TCP reacts:

  • Retransmits the lost data (via RTO timeout or fast retransmit on 3 dup ACKs).

  • Timeout: severe signal, cwnd collapses to 1 MSS, Slow Start restarts.

  • Triple dup ACK: milder, halve cwnd and enter fast recovery.

• The caveat: TCP assumes loss = congestion, so on lossy wireless links it can needlessly throttle throughput even when there's no congestion.

Closing needs 4 steps because a TCP connection is full-duplex: each direction must be shut down independently. The three-step open can combine SYN+ACK into one segment, but at close one side may still have data to send, so its FIN and the peer's ACK are usually separate messages. TIME_WAIT is the state the active closer sits in after its final ACK to ensure a clean shutdown.

• The four steps:

  1. Side A sends FIN (I'm done sending).

  2. Side B ACKs that FIN.

  3. Side B sends its own FIN when it finishes sending.

  4. Side A ACKs it.

• Why not 3:

  • B's ACK and B's FIN usually can't be merged because B may still have data in flight (half-close).

  • If B has nothing to send, they can coalesce, effectively making it 3.

• TIME_WAIT state:

  • The active closer waits ~2*MSL (max segment lifetime) after the final ACK.

  • Ensures the final ACK reaches the peer (can retransmit if lost) and lets old duplicate segments die before the port is reused.

RTT is the time for a packet to travel to the destination and for its acknowledgment to return. It directly sets the cost of TCP's handshake, because connection setup requires round trips before any data flows.

• Definition: Sender to receiver plus receiver back to sender, dominated by propagation distance, queuing, and processing delay.

• Handshake cost: The TCP three-way handshake takes ~1 RTT before data can be sent; add TLS and it becomes 2 to 3 RTT total.

• High RTT hurts short connections most: On a 200 ms link, setup alone can add hundreds of milliseconds regardless of bandwidth.

• Mitigations: Connection reuse/keep-alive, TLS session resumption, TCP Fast Open, and QUIC's 0-RTT/1-RTT setup all cut round trips.

The three-way handshake synchronizes sequence numbers and confirms both sides can send and receive before data flows. If the final ACK is lost, the server retransmits its SYN-ACK until it's acknowledged, so the connection still recovers.

1. SYN: client sends SYN with its initial sequence number, moving to SYN_SENT.

2. SYN-ACK: server replies with SYN+ACK (its own ISN plus ack of the client's), entering SYN_RECEIVED.

3. ACK: client acknowledges the server's SYN; both sides reach ESTABLISHED.

• If the final ACK is lost:

  • The client thinks the connection is established; the server is still in SYN_RECEIVED.

  • The server's retransmission timer fires and it resends the SYN-ACK.

  • The client responds with the ACK again (or its first data segment carries the ack), completing setup.

  • If the client immediately sends data, that data's ACK field also confirms the server's SYN, so recovery is seamless.

A subnet mask marks which bits of an IP address are the network prefix versus the host portion. A router (or host) applies it with a bitwise AND to both the destination and its own network to decide whether the destination is local or must be sent to a gateway.

• What the mask encodes: Contiguous 1s mark the network bits, 0s mark host bits (e.g. 255.255.255.0 = /24).

• The decision: bitwise AND:

  • AND the destination IP with the mask to get its network address; AND the local IP with the mask for the local network.

  • If the two network addresses match, the destination is on the local subnet.

• Local vs routed:

  • Same network: deliver directly on the LAN (ARP for the MAC, send the frame).

  • Different network: forward to the default gateway/next hop for external routing.

Fragmentation splits an IP packet into smaller pieces when it is larger than a link's MTU (Maximum Transmission Unit); the pieces travel independently and are reassembled only at the final destination using header fields that mark their order and grouping.

• Why it happens: A packet larger than the outgoing link's MTU (e.g. 1500 bytes on Ethernet) must be broken up to fit.

• Header fields that make it work:

  • Identification: same value on all fragments of one original packet.

  • Fragment Offset: position of this fragment's data in the original.

  • MF (More Fragments) flag: set on all but the last fragment.

• Reassembly at the destination: The receiver buffers fragments and rebuilds the packet; if any fragment is lost, the entire packet is discarded.

• Why it's undesirable:

  • Loss amplification: one dropped fragment forces retransmission of the whole packet.

  • Overhead and reassembly cost, plus firewalls/NAT often mishandle or drop fragments.

• Modern avoidance: IPv4 uses Path MTU Discovery (set DF flag) to size packets to the smallest link; IPv6 forbids router fragmentation entirely, so only the sender fragments.

A /26 has 62 usable host addresses. The /26 leaves 6 host bits, giving 2^6 = 64 total addresses, minus 2 reserved (network and broadcast).

• Count the host bits: IPv4 is 32 bits; /26 uses 26 for the network, leaving 32 - 26 = 6 host bits.

• Total addresses: 2^6 = 64 addresses in the block.

• Subtract the reserved two: The all-zeros host is the network address and the all-ones host is the broadcast address, so 64 - 2 = 62 usable.

• General formula: Usable hosts = 2^(32 - prefix) - 2.

• Note: The subnet mask for /26 is 255.255.255.192.

Circuit switching reserves a dedicated end-to-end path for the whole session, while packet switching chops data into independently routed packets that share links on demand. The modern Internet uses packet switching because it is far more efficient and resilient for bursty data traffic.

• Circuit switching:

  • A fixed path with reserved bandwidth is set up before data flows (classic telephone network).

  • Guaranteed capacity and constant delay, but the circuit is wasted when idle.

• Packet switching:

  • Data is split into packets, each carrying a destination address and routed independently (store-and-forward).

  • Links are shared statistically, so idle capacity is reused by others.

• Why the Internet chose packet switching:

  • Efficiency: bursty traffic doesn't tie up idle bandwidth.

  • Resilience: packets reroute around failed links with no fixed circuit to lose.

  • Scalability and cost: no per-connection state reserved in the core.

• Trade-off: Variable delay and possible congestion/loss, so quality guarantees need extra mechanisms (QoS, buffering).

Static routing means an administrator manually configures routes; dynamic routing lets routers discover and advertise routes automatically via a protocol. Use static for small, stable networks and dynamic for larger or changing ones.

• Static routing:

  • Routes are hand-entered and never change unless edited; no protocol overhead and fully predictable.

  • No automatic failover: if a link dies, traffic blackholes until someone updates the table.

  • Good for stub networks, default routes, and small setups.

• Dynamic routing:

  • Routers exchange reachability info (RIP, OSPF, BGP) and recompute paths when topology changes.

  • Scales and self-heals, at the cost of CPU, memory, and bandwidth for protocol traffic.

  • Good for large or redundant networks where manual upkeep is impractical.

• Common practice: mix both, e.g. a static default route plus dynamic routing internally.

SMTP sends and relays mail between servers; IMAP and POP3 retrieve mail from a server to a client, but IMAP keeps messages on the server and syncs across devices while POP3 typically downloads and removes them.

• SMTP (sending): Push protocol for submitting and relaying mail server-to-server; ports 25 (relay), 587 (submission), 465 (implicit TLS).

• POP3 (retrieval, download model):

  • Downloads messages to one device and usually deletes them from the server; little server-side state.

  • Ports 110 (plain), 995 (TLS); simple, good for single-device or offline use.

• IMAP (retrieval, sync model):

  • Messages stay on the server; clients see synchronized folders, flags, and read state across devices.

  • Ports 143 (plain), 993 (TLS); the modern default for multi-device access.

• Key contrast: SMTP moves mail toward its destination, POP3/IMAP pull it to the reader.

FTP transfers files in plaintext over its own protocol; SFTP transfers files securely as a subsystem of SSH. Separately, active vs passive FTP describes which side opens the data connection: the server (active) or the client (passive).

• FTP vs SFTP:

  • FTP: no encryption, uses two channels (control on port 21, separate data channel); credentials and data travel in the clear.

  • SFTP: runs over SSH (port 22), single encrypted channel; not related to FTPS, which is FTP wrapped in TLS.

• Active FTP: Client sends its port via PORT; the server opens the data connection back to the client, which client-side firewalls/NAT often block.

• Passive FTP: Client sends PASV; the server opens a data port and the client initiates both connections, which is firewall/NAT friendly.

NTP (Network Time Protocol) synchronizes the clocks of devices across a network to a common, accurate time reference. Consistent time matters because many security, logging, and coordination functions break when clocks drift apart.

• How it works:

  • Hierarchical strata: stratum 0 is a reference clock (GPS/atomic), stratum 1 servers sync to it, lower strata sync down the chain.

  • Uses UDP port 123 and timestamp exchanges to estimate and correct for network delay and offset.

• Why synchronization matters:

  • Log correlation: comparing events across systems during troubleshooting or forensics requires aligned timestamps.

  • Security: certificate validity, Kerberos tickets, and TOTP tokens fail if clocks skew too far.

  • Distributed systems: databases and transactions depend on ordered, consistent time.

SNMP (Simple Network Management Protocol) is an application-layer protocol for monitoring and managing network devices (routers, switches, servers, printers) by collecting and organizing information about them.

• Core components:

  • Manager: the NMS (Network Management System) that polls devices and displays data.

  • Agent: software on the managed device that exposes its state.

  • MIB (Management Information Base): a hierarchical database of manageable objects, each identified by an OID (Object Identifier).

• Operations:

  • GET/GETNEXT/GETBULK: manager reads values from the agent.

  • SET: manager writes/changes a value on the device.

  • TRAP/INFORM: agent asynchronously notifies the manager of events (e.g. link down); INFORM is acknowledged.

• Ports and transport: Uses UDP: 161 for queries, 162 for traps.

• Versions and security: v1/v2c use plaintext community strings (weak); v3 adds authentication and encryption.

• Typical use: polling interface counters, CPU/memory, uptime for dashboards and alerting.

DHCP (Dynamic Host Configuration Protocol) automatically assigns IP addresses and network configuration to clients. The exchange follows the DORA sequence: Discover, Offer, Request, Acknowledge.

1. Discover: Client has no IP, so it broadcasts a DHCPDISCOVER to find available servers (source 0.0.0.0, destination 255.255.255.255).

2. Offer: One or more servers reply with a DHCPOFFER proposing an IP, subnet mask, gateway, DNS, and lease time.

3. Request: Client broadcasts a DHCPREQUEST accepting one offer (identifying the chosen server), which also signals rejection to the others.

4. Acknowledge: Server sends DHCPACK confirming the lease; the client configures its interface and may run an ARP check to confirm the address is unused.

5. Extras:

   • Uses UDP ports 67 (server) and 68 (client).

   • Leases are renewed at ~50% lifetime (T1) directly with the server; a DHCP relay forwards broadcasts across subnets.

DNS resolution translates a hostname into an IP address through a chain of servers. The key distinction is who does the work: a recursive query asks a resolver to do everything and return the final answer, while an iterative query returns the best referral so the asker keeps chasing it.

• Recursive query:

  • The client asks the resolver: "give me the final answer, don't refer me elsewhere."

  • The resolver takes full responsibility for finding it (or returning an error).

• Iterative query:

  • Each queried server returns either the answer or a referral to a server closer to the answer.

  • The asker itself follows each referral step by step.

• How they combine in practice:

  • Your stub resolver sends a recursive query to a recursive resolver (e.g. ISP or 8.8.8.8).

  • That resolver then performs iterative queries to root, TLD, and authoritative servers on your behalf, caching results along the way.

All three map a name to a destination, but at different levels: an A record points a name directly to an IP, a CNAME aliases one name to another name, and an ALIAS (provider-specific) behaves like a CNAME but is legal at the zone apex.

• A record:

  • Maps a hostname to an IPv4 address (AAAA for IPv6).

  • Use when you have a fixed IP to point at.

• CNAME record:

  • Aliases one name to another canonical name, which is then resolved.

  • Use for pointing subdomains at a shared target (e.g. a CDN hostname) so IP changes don't need edits.

  • Cannot coexist with other records for the same name, and cannot be used at the zone apex (root domain).

• ALIAS record:

  • A DNS-provider feature that acts like a CNAME but resolves to an A record at query time.

  • Use at the apex (e.g. example.com) where a CNAME is illegal but you still want to point at a hostname.

• Rule of thumb: fixed IP, use A; alias a subdomain, use CNAME; alias the root domain, use ALIAS.

A recursive DNS lookup walks outward from local caches to the authoritative nameserver, checking each cache first and querying the DNS hierarchy only when nothing is cached. The recursive resolver does the heavy lifting and caches the result.

1. Browser cache: The browser checks its own recent DNS cache; if the name is there and unexpired, resolution stops.

2. OS/stub resolver cache: The operating system checks its cache and the hosts file.

3. Recursive resolver: The stub sends a recursive query to the configured resolver (ISP or public); it returns any cached answer immediately.

4. Root nameserver: If uncached, the resolver asks a root server, which refers it to the correct TLD server (e.g. .com).

5. TLD nameserver: The TLD server refers the resolver to the authoritative nameserver for the domain.

6. Authoritative nameserver: Returns the actual record (e.g. the A record IP) for the hostname.

7. Return and cache: The resolver caches the answer per its TTL and returns it to the client, which also caches it, so future lookups are faster.

DNS caching stores resolved records at resolvers, OSes, and browsers so repeated lookups skip the full hierarchy; the TTL (time-to-live) on each record tells caches how many seconds to keep it before re-querying.

• How caching works:

  • Each answer carries a TTL; caches serve it directly until the TTL expires, then discard and re-resolve.

  • Caching happens at multiple layers: browser, OS stub resolver, and the recursive resolver (e.g. your ISP or 8.8.8.8).

• Long TTL:

  • Pros: fewer queries, lower latency, less load on authoritative servers.

  • Cons: slow to propagate changes; a moved IP may be stale in caches for the whole TTL.

• Short TTL:

  • Pros: fast propagation, useful for failover and frequently changing records.

  • Cons: more queries, higher latency, more load.

• Practical pattern: lower the TTL before a planned migration, then raise it again once stable.

DNS resolution walks a hierarchy from most general to most specific: root servers point to TLD servers, TLD servers point to the authoritative server for a domain, and the authoritative server holds the actual records.

• Root servers:

  • The top of the tree (the . zone); 13 logical root server addresses served via anycast worldwide.

  • They don't know your domain: they refer the resolver to the correct TLD server.

• TLD servers:

  • Manage a top-level domain like .com or .org.

  • Return the NS records pointing to the domain's authoritative servers.

• Authoritative servers: Hold the real records (A, AAAA, MX, etc.) for a specific domain and give the definitive answer.

• The recursive resolver: Not part of the hierarchy but does the legwork: it queries root, then TLD, then authoritative on the client's behalf and caches results.

A PTR record maps an IP address back to a hostname, the reverse of an A record; reverse DNS lookup queries these PTR records to answer "what name owns this IP?"

• How it's stored:

  • PTR records live under a special reverse zone: in-addr.arpa for IPv4 and ip6.arpa for IPv6.

  • The IP is reversed in the query, e.g. 1.2.3.4 becomes 4.3.2.1.in-addr.arpa.

• Common uses:

  • Email anti-spam: mail servers check that a sending IP's PTR matches its forward record (FCrDNS) to gauge legitimacy.

  • Logging and diagnostics: turning IPs into readable hostnames in traceroute, logs, and monitoring.

• Control: the IP owner (often the ISP), not the domain owner, controls the reverse zone.

Round-robin DNS returns multiple IP addresses for one hostname and rotates their order per response, so different clients connect to different servers, spreading load with no dedicated load balancer.

• Mechanism:

  • The zone has several A/AAAA records for the same name; the authoritative server cycles which IP appears first each query.

  • Clients typically use the first IP returned, so requests fan out across servers.

• Limitations:

  • No health awareness: a dead server's IP is still handed out until the record is manually removed.

  • Caching skews distribution: resolvers cache one answer for the TTL, so it isn't truly even.

  • No session affinity and coarse control compared to a real L4/L7 load balancer.

• Best used as a simple, cheap distribution layer, often combined with lower TTLs or smarter balancers.

A WebSocket connection starts as a normal HTTP GET carrying an Upgrade: websocket header; if the server agrees with a 101 Switching Protocols response, the same TCP connection is repurposed into a full-duplex, bidirectional message channel that is no longer HTTP.

• The handshake:

  • Client sends GET with Upgrade: websocket, Connection: Upgrade, and a random Sec-WebSocket-Key.

  • Server replies 101 Switching Protocols with Sec-WebSocket-Accept (a hash of the key), confirming the switch.

• After upgrade vs HTTP keep-alive:

  • HTTP persistent connection: still request/response; the server only speaks when the client asks, one exchange at a time.

  • WebSocket: full-duplex; either side can send anytime, independently, with no request/response pairing.

  • The wire format changes: framed WebSocket messages replace HTTP messages, with far less per-message overhead than headers.

HTTP is stateless, so cookies add state via headers: the server sends a Set-Cookie header, and the browser echoes it back on every subsequent matching request in a Cookie header, letting the server recognize the client.

• The exchange:

  • Server response: Set-Cookie: sessionId=abc123 instructs the browser to store the key-value pair.

  • Client request: browser automatically adds Cookie: sessionId=abc123 to future requests to that domain/path.

  • Typically the cookie holds only a session ID; real state lives server-side keyed by that ID.

• Attributes that control behavior:

  • Expires/Max-Age: lifetime; without them it's a session cookie cleared on browser close.

  • Domain and Path: scope of which requests include the cookie.

  • Secure (HTTPS only), HttpOnly (hidden from JS, mitigates XSS), and SameSite (CSRF protection).

Each version tackles the previous one's biggest bottleneck: HTTP/1.1 fixed connection reuse but suffered head-of-line blocking, HTTP/2 added multiplexing over one TCP connection, and HTTP/3 replaced TCP with QUIC over UDP to remove transport-level blocking.

• HTTP/1.1 (1997): text protocol, persistent connections:

  • Adds keep-alive and pipelining, but responses must return in order, so one slow response blocks the rest (head-of-line blocking).

  • Browsers work around this by opening ~6 parallel TCP connections per host.

• HTTP/2 (2015): binary, multiplexed:

  • Many concurrent streams over a single TCP connection, plus header compression (HPACK) and server push.

  • Removes HTTP-level HOL blocking, but TCP-level blocking remains: a lost packet stalls all streams.

• HTTP/3 (2022): QUIC over UDP:

  • Streams are independent at the transport layer, so packet loss on one stream doesn't block others.

  • Integrates TLS 1.3 into the handshake (faster connection setup) and supports connection migration across IP changes.

• The driving theme: eliminate head-of-line blocking at successively lower layers (application, then transport).

REST is typically text-based JSON over HTTP/1.1 with request/response semantics, while gRPC uses binary Protobuf over HTTP/2, enabling multiplexed streaming and much smaller, faster messages.

• Transport and framing: gRPC mandates HTTP/2, gaining multiplexing and bidirectional streaming; REST commonly runs on HTTP/1.1.

• Payload format: gRPC uses Protocol Buffers (compact binary, schema-defined); REST usually uses human-readable JSON.

• Contract: gRPC has a strict .proto contract with code generation; REST is looser (often OpenAPI documented).

• Communication patterns: gRPC supports unary, server-streaming, client-streaming, and bidirectional streaming; REST is fundamentally request/response.

• Reach and tradeoffs: REST is universally browser- and cache-friendly; gRPC needs a proxy (gRPC-Web) in browsers but excels for internal service-to-service calls.

HTTP/1.1 is a text protocol that serializes responses over a connection, while HTTP/2 is binary and multiplexes many concurrent streams over one TCP connection so requests no longer wait in line.

• Key differences:

  • HTTP/1.1 is text-based and one-response-at-a-time per connection; HTTP/2 is binary-framed.

  • HTTP/2 adds header compression (HPACK), stream prioritization, and server push.

• How multiplexing works:

  • Each request/response is a logical stream with a unique ID; data is split into small binary frames tagged with that stream ID.

  • Frames from many streams are interleaved on one connection and reassembled by ID at the other end.

  • This removes application-layer head-of-line blocking and the need for ~6 parallel connections per host.

• Limitation: It still runs on TCP, so a lost packet stalls all streams (TCP-level HOL blocking) until retransmission, which HTTP/3 solves.

WebSockets provide a persistent, full-duplex TCP connection between client and server, established by starting as an ordinary HTTP request that is then "upgraded" to the WebSocket protocol.

• The Upgrade handshake:

  • Client sends a normal HTTP GET with Upgrade: websocket, Connection: Upgrade, and a random Sec-WebSocket-Key.

  • Server replies 101 Switching Protocols with a Sec-WebSocket-Accept derived from the key (proving it understood the request).

• After the handshake:

  • The same TCP connection stays open and switches to the WebSocket wire protocol (binary framing), no longer HTTP.

  • Both sides can send messages any time (full-duplex), without the request/response round-trip.

• Why it matters: Ideal for low-latency bidirectional data (chat, live trading, multiplayer games); reuses port 443/80 so it passes through firewalls and proxies.

All three push server updates to clients, but they differ in directionality and transport: Long Polling reuses HTTP request/response, SSE is a one-way server-to-client stream, and WebSockets are full-duplex over a persistent connection.

• Long Polling:

  • Client sends a request; server holds it open until data is available, then responds and the client immediately re-requests.

  • Works everywhere but has per-request overhead and higher latency; a fallback more than a first choice.

• Server-Sent Events (SSE):

  • One long-lived HTTP response streaming text/event-stream; server-to-client only, with built-in auto-reconnect and event IDs.

  • Great for feeds, notifications, live scores; simple and works over plain HTTP.

• WebSockets:

  • Full-duplex, low-latency, binary or text; both sides push freely after the upgrade handshake.

  • Best for chat, gaming, collaborative editing where the client also sends frequently.

• Choosing: Server-to-client only: SSE. True bidirectional/low latency: WebSockets. Legacy compatibility with no streaming support: Long Polling.

301 signals a permanent redirect (clients and caches should remember it and update links), while 302/307 are temporary. The key modern distinction is that 307 guarantees the HTTP method is preserved, whereas older 301/302 handling often changed POST to GET.

• 301 Moved Permanently:

  • Resource has a new permanent URL; browsers cache it aggressively and search engines transfer ranking to the new location.

  • Because it's cached, future requests may skip the old URL entirely, so use it only when the move is truly permanent.

• 302 Found (temporary):

  • Original URL is still canonical; not cached by default.

  • Historically clients often rewrote POST to GET on redirect, which was ambiguous.

• 307 Temporary Redirect:

  • Same intent as 302 but strictly preserves the method and body, so a POST stays a POST.

  • (308 is the permanent, method-preserving counterpart of 301.)

• At the protocol level: All send a Location header with the target URL; the differences are cacheability and whether the method is preserved.

A safe method promises not to change server state (read-only); an idempotent method promises the same end state no matter how many identical requests are sent. They are related but distinct properties defined by the HTTP spec.

• Safe:

  • The request has no intended side effects on the server: GET, HEAD, OPTIONS.

  • Enables safe caching, prefetching, and retries by intermediaries.

• Idempotent:

  • Sending the request N times leaves the resource in the same state as sending it once: GET, HEAD, PUT, DELETE, OPTIONS.

  • Note the response can differ (e.g. second DELETE returns 404), but the resource state does not.

• How they relate:

  • Every safe method is idempotent, but not every idempotent method is safe (PUT/DELETE change state yet are idempotent).

  • POST is neither: two identical POSTs typically create two resources.

• Why it matters: Clients, proxies, and load balancers can safely retry idempotent requests on timeout without risk of duplicate effects.

Connection: keep-alive tells the peer to keep the underlying TCP connection open after a response so it can be reused for further requests, avoiding a new TCP (and TLS) handshake each time.

• The problem it solves: Opening a TCP connection costs a round-trip (three-way handshake), plus more for TLS; doing it per request is expensive.

• Effect on TCP:

  • The socket stays open and is reused for subsequent requests, amortizing handshake cost and letting TCP's congestion window stay warmed up.

  • Connections are held for a timeout / max-requests window, then closed.

• Version differences:

  • In HTTP/1.0 connections closed by default; Connection: keep-alive opted in.

  • In HTTP/1.1 persistent connections are the default; Connection: close opts out.

• Caveat: It's still one request at a time per connection (serialized); true concurrency needs multiple connections (HTTP/1.1) or multiplexing (HTTP/2+).

TLS uses asymmetric (public/private key) cryptography only during the handshake to authenticate the server and securely establish a shared secret, then switches to fast symmetric encryption for the actual data. It's a hybrid: asymmetric for setup, symmetric for bulk.

• Why hybrid: Asymmetric crypto is secure for exchanging keys but slow; symmetric crypto is fast but needs both sides to share a secret first.

• Handshake (asymmetric part):

  • Server sends its certificate; client validates it against a trusted CA.

  • Both sides use asymmetric keys (typically ephemeral Diffie-Hellman, ECDHE) to agree on a shared session key without ever sending it in the clear.

  • The certificate's key pair authenticates the server (proves it owns the private key).

• Session (symmetric part): All application data is encrypted with the derived symmetric session key (e.g. AES-GCM), which is fast.

• Forward secrecy: Ephemeral DH keys mean each session's secret is unique, so compromising the server's long-term key later can't decrypt past traffic.

A Man-in-the-Middle attacker secretly relays and possibly alters traffic between two parties who believe they're talking directly. On an unencrypted network this is trivial because there's no authentication or confidentiality; TLS/SSL stops it by encrypting the channel and cryptographically verifying the server's identity.

• How the attack works unencrypted:

  • The attacker positions between client and server (ARP spoofing, rogue Wi-Fi, DNS spoofing).

  • Since plaintext HTTP has no identity check, the attacker reads and modifies requests/responses invisibly (steal cookies, inject content).

• How TLS prevents it:

  • Authentication: the server presents a CA-signed certificate for its domain; a MitM can't forge a valid signature, so the client rejects the fake.

  • Confidentiality: data is symmetrically encrypted, so intercepted traffic is unreadable.

  • Integrity: message authentication (AEAD/MAC) detects any tampering in transit.

• Remaining gaps: If a user ignores certificate warnings or a rogue/compromised CA issues a valid cert, MitM is still possible; mitigations include HSTS and certificate pinning.

TLS termination means the load balancer decrypts incoming HTTPS traffic, does the TLS handshake on behalf of the backend, and forwards plaintext (or re-encrypted) HTTP to internal servers: it centralizes cryptography at the edge.

• What it does:

  • The client's TLS session ends ("terminates") at the load balancer, which holds the certificates and private keys.

  • Traffic to backends travels as plain HTTP over the trusted internal network.

• Why it's used:

  • Offloads expensive crypto from application servers, freeing their CPU.

  • Centralizes certificate management and rotation in one place.

  • Lets the LB inspect and route on Layer 7 data (paths, headers, cookies) that would otherwise be encrypted.

• Trade-off and alternatives:

  • Backend hop is unencrypted, so it must be a trusted segment.

  • TLS re-encryption (termination then a new TLS leg to the backend) or TLS passthrough (LB forwards encrypted bytes untouched) are used when end-to-end encryption is required.

A VPN builds a secure tunnel by encapsulating your original IP packets inside new encrypted packets addressed to the VPN server: the public internet only sees the encrypted outer packet, while the inner packet is decrypted and forwarded at the other end.

• Encapsulation (the "tunnel"):

  • The client wraps each original packet in a new outer packet destined for the VPN gateway (a packet-inside-a-packet).

  • Intermediate routers only see and route the outer header, hiding source/destination and payload.

• Encryption and integrity: The inner packet is encrypted (confidentiality) and authenticated (integrity/anti-tamper), typically via IPsec, WireGuard, or OpenVPN (TLS-based).

• Authentication and key exchange: Both endpoints authenticate (certificates, pre-shared keys, or credentials) and negotiate session keys before data flows.

• Net effect: The remote client appears to be on the private network, and eavesdroppers on the path see only encrypted traffic to the VPN endpoint.

HTTPS is HTTP running over a TLS session: after the TCP connection, a TLS handshake authenticates the server and negotiates a shared symmetric key, and all subsequent HTTP is encrypted with that key.

• Setup order:

  1. TCP three-way handshake establishes the transport connection.

  2. TLS handshake negotiates crypto and keys on top of it.

  3. Encrypted HTTP request/response exchange begins.

• What the TLS handshake accomplishes:

  • Negotiation: client and server agree on TLS version and a cipher suite (ClientHello/ServerHello).

  • Authentication: server presents its certificate; the client validates the chain up to a trusted CA and checks the hostname.

  • Key exchange: both derive a shared secret via ephemeral Diffie-Hellman (ECDHE) for forward secrecy.

  • Finished: both send a MAC over the handshake to confirm nothing was tampered with, then switch to symmetric encryption.

• After the handshake, a fast symmetric cipher (e.g. AES-GCM) protects the actual data.

TLS uses both: asymmetric encryption during the handshake to authenticate and securely establish a shared key, then symmetric encryption for the bulk data transfer because it is far faster.

• Asymmetric (public/private key pair):

  • Used only in the handshake: the server's certificate key authenticates it, and signatures/key exchange establish the session secret.

  • Strong for identity and key setup, but computationally expensive, so it isn't used for the whole session.

• Symmetric (one shared secret key):

  • Used for all application data after the handshake (e.g. AES-GCM, ChaCha20-Poly1305).

  • Much faster and hardware-accelerated, ideal for high-throughput bulk encryption.

• Why the hybrid: Asymmetric solves the key distribution problem (how to agree on a secret over an open channel); symmetric provides efficient ongoing encryption once that secret is shared.

A stateful firewall tracks the full context of each connection in a state table and judges packets by whether they belong to a known flow; a stateless firewall inspects each packet in isolation against static rules with no memory of what came before.

• Stateless (packet-filtering):

  • Matches each packet independently on fields like source/destination IP, port, and protocol.

  • Has no idea if a reply packet corresponds to a request you sent, so admins must open rules in both directions.

  • Fast and low-memory, but easier to trick with crafted packets (e.g. spoofed ACK packets).

• Stateful:

  • Maintains a connection/state table recording each flow's endpoints, ports, sequence numbers, and TCP state.

  • Return traffic for an established, allowed connection is admitted automatically without an explicit inbound rule.

  • Drops packets that claim to be part of a connection the table has never seen.

• Trade-off: Stateful gives tighter security and simpler rules but uses memory per connection (a target for state-exhaustion attacks); stateless is lighter but blunter.

A DMZ is a separate, semi-trusted network segment that sits between the untrusted internet and the trusted internal network, hosting the public-facing services so that a breach there does not directly expose internal systems.

• What lives in it: Servers that must be reachable from outside: web servers, mail relays, DNS, reverse proxies, VPN endpoints.

• How it's isolated:

  • Firewall rules allow the internet to reach only the DMZ, and allow the DMZ to reach the internal network only in tightly restricted ways (often not at all initiating inbound).

  • Often built with two firewalls (external and internal) or one firewall with three interfaces.

• Why use one:

  • Defense in depth: if a public server is compromised, the attacker is still trapped in the DMZ and faces another firewall before reaching sensitive internal data.

  • Lets you expose services publicly while keeping the internal LAN unreachable from the internet.

In a Man-in-the-Middle attack the attacker secretly positions themselves in the communication path between two parties, relaying (and possibly altering) traffic while each side believes it is talking directly to the other.

• Getting into the path: Common techniques: ARP spoofing on a LAN, rogue Wi-Fi access points, DNS spoofing, or DHCP/router manipulation to become the default gateway.

• What happens once in the middle:

  • The attacker forwards packets between victim and destination so communication still works (staying stealthy) while capturing everything.

  • They can eavesdrop, inject, or modify data, and attempt to strip or downgrade encryption (e.g. SSL stripping).

• Why it's dangerous: Credentials, session tokens, and sensitive data over unencrypted or poorly-validated channels are exposed.

• Defenses: Strong TLS with proper certificate validation, HSTS, certificate pinning, and mutual authentication make relayed traffic useless or detectable.

ARP spoofing is an attack on a local network where the attacker sends forged ARP replies to map their own MAC address to another host's IP (often the gateway's), so victims send their traffic to the attacker instead of the real destination.

• Why it works: ARP has no authentication: hosts cache whatever ARP reply they receive, even unsolicited ones (gratuitous ARP).

• The attack:

  • Attacker tells the victim that the gateway's IP is at the attacker's MAC, and tells the gateway that the victim's IP is at the attacker's MAC.

  • Both ARP caches are poisoned, so traffic between victim and gateway flows through the attacker.

• What the attacker can do: Set up a MITM: sniff, modify, or drop packets; if they forward traffic, the victim notices nothing.

• Defenses: Dynamic ARP Inspection on switches, static ARP entries for critical hosts, DHCP snooping, and encryption so intercepted traffic is unusable.

A DDoS (Distributed Denial of Service) attack uses many compromised or coordinated sources (a botnet) to overwhelm a target's resources so legitimate users can't reach it; the categories differ by which layer and resource they exhaust.

• Volumetric attacks:

  • Goal: saturate the target's bandwidth, measured in bits per second.

  • Examples: UDP floods, ICMP floods, DNS/NTP amplification (small request, huge reflected reply).

• Protocol attacks:

  • Goal: exhaust state/connection resources on servers or network gear, measured in packets per second.

  • Examples: SYN floods, fragmented packet attacks, Ping of Death; they consume firewall/load-balancer state.

• Application-layer (Layer 7) attacks:

  • Goal: exhaust server-side processing with requests that look legitimate, measured in requests per second.

  • Examples: HTTP floods, Slowloris (holding connections open); low bandwidth but expensive to serve (DB queries, rendering).

• Key contrast: Volumetric and protocol attacks are big and blunt (easier to detect); Layer 7 attacks are subtle and mimic real users, so they are harder to filter.

Packet sniffing is the interception and logging of network traffic by capturing packets as they pass a network interface, done legitimately for troubleshooting or maliciously to steal data.

• How capture works: The NIC is put in promiscuous mode (or monitor mode for Wi-Fi) so it accepts frames not addressed to it, and a tool like Wireshark or tcpdump records them.

• Where you can capture:

  • On a hub, all traffic is broadcast to every port, so everyone sees everything.

  • On a switch, you normally see only your own traffic, so an attacker uses ARP spoofing, MAC flooding, or a legitimate SPAN/mirror port to see more.

• What's exposed: Unencrypted protocols reveal credentials and content; encrypted traffic (TLS) shows metadata but not payloads.

• Defense: Encrypt everything end to end, use switched networks with port security, and segment sensitive traffic.

Latency is the delay for data to travel one way (or round trip), throughput is how much data actually moves per second, and jitter is the variation in latency between packets. Real-time apps like VoIP care most about low latency and jitter; bulk downloads care most about throughput.

• Latency: Time delay for a packet to reach its destination, measured in milliseconds.

• Throughput: Actual rate of successful data delivery, usually less than the raw bandwidth due to overhead, loss, and congestion.

• Jitter: Variance in packet arrival timing; steady latency means low jitter even if latency is high.

• VoIP (real-time): Sensitive to latency and jitter: high latency makes conversation awkward, jitter causes choppy or robotic audio. Needs little bandwidth.

• File download (bulk): Cares about throughput: high latency or jitter only affects total time slightly, since data is buffered and reassembled, not played in real time.

RTT is the time for a packet to travel to a destination and for its acknowledgment to return; jitter is the variation in one-way delay from packet to packet. High jitter hurts real-time media because packets that carry audio/video must arrive at a steady cadence to be played back smoothly.

• Round Trip Time (RTT): Full there-and-back delay; drives TCP timeouts, congestion window growth, and perceived responsiveness.

• Jitter: Inconsistency in inter-packet arrival times, caused by variable queuing, routing, or congestion along the path.

• Why jitter hurts real-time media:

  • Audio/video must play at a fixed rate; if packets arrive unevenly, gaps produce dropouts, robotic voice, or frozen frames.

  • Receivers use a jitter buffer to smooth arrivals, but that adds latency, and packets arriving after their playback deadline are simply discarded.

• Trade-off: A bigger jitter buffer masks more jitter but increases delay, so real-time apps balance the two.

Physical distance adds propagation delay: signals travel at roughly two-thirds the speed of light in fiber, so farther endpoints mean higher RTT. This is critical for TCP because many of its mechanisms are clocked by RTT, so distance directly limits performance and responsiveness.

• Distance drives propagation delay: About 5 microseconds per km in fiber each way; a transcontinental or intercontinental path can add tens to hundreds of ms of RTT that no bandwidth upgrade removes.

• TCP is RTT-clocked:

  • The 3-way handshake and TLS setup each cost round trips before any data flows, so long RTT slows connection startup.

  • Slow start and congestion control grow the window per RTT, so high RTT means it takes much longer to ramp up to full speed.

  • Throughput is window ÷ RTT, so larger distance lowers achievable throughput unless the window scales.

• Mitigations: CDNs and edge servers place content physically closer; connection reuse and TCP window scaling reduce the RTT penalty.

QoS is a set of techniques that manage network resources to give certain traffic preferential treatment, ensuring latency-sensitive or high-priority flows (like voice) get bandwidth, low delay, and low loss even when the network is congested. It's about prioritization and controlled fairness, not creating extra capacity.

• Classification and marking: Traffic is identified (by port, app, or flow) and tagged, e.g. the DSCP field in the IP header or 802.1p at layer 2, so downstream devices know its priority.

• Queuing and scheduling: Priority queuing and weighted fair queuing serve high-priority queues first or give them a guaranteed share of the link.

• Traffic shaping and policing: Shaping buffers and smooths bursts to a rate; policing drops or remarks traffic that exceeds its allowance.

• Congestion avoidance: Mechanisms like WRED drop packets selectively before queues fill, protecting priority flows.

• Models: DiffServ marks per-packet classes for scalable per-hop treatment; IntServ reserves resources end-to-end (via RSVP) but scales poorly.