Computer Networks Interview Questions and Answers

Computer networks interviews test whether you understand how data moves across layers—from physical links to application protocols—and can reason about failures systematically.

Most networking screens start with what happens when you type a URL, TCP vs UDP, and DNS—then follow with layered debugging.

Basic questions (campus and screening):

• What is a computer network?
• LAN vs WAN
• OSI seven layers (names + one-line role)
• TCP vs UDP table
• What is DNS? What is HTTP vs HTTPS?

Advanced questions (product companies, SRE):

• TCP congestion control (slow start, cwnd)
• TLS 1.3 handshake RTT
• HTTP/2 multiplexing vs HTTP/3 QUIC
• Anycast, CDN edge caching
• L4 vs L7 load balancing trade-offs
• Intermittent packet loss diagnosis

Start with basic fluency; senior loops add scenario depth and trade-off language.

TakeUForward and Bosscoder-style lists emphasize explaining with diagrams aloud.

Run curl -v https://example.com and label each line with the layer it represents.

Yes—every distributed system depends on networks:

You do not need CCIE depth for most backend roles—you need clear layered explanations and debug vocabulary.

A computer network connects devices so they can exchange data using shared protocols and addressing.

Networks use layered protocols so applications do not manage raw bits on cables—the stack abstracts complexity.

A strong answer is:

A network is addressed devices plus agreed protocols—I distinguish LAN vs WAN and explain that layers let HTTP run without apps handling Ethernet frames.

Mnemonic: "All People Seem To Need Data Processing" (top-down) or reverse for bottom-up.

Interviews use OSI for precise vocabulary ("that's a layer 4 issue") even though TCP/IP is what runs on the internet.

A strong answer is:

OSI is a teaching model—I name the layer for each protocol: HTTP at application, TCP at transport, IP at network, Ethernet at data link.

TCP/IP is the practical internet stack; fewer layers, same concepts.

A strong answer is:

TCP/IP is the real internet model—four layers with TLS and HTTP grouped at application; I use OSI names when debugging layer by layer.

Encapsulation is the process of wrapping application data with protocol headers (and sometimes trailers) as it moves down the stack toward the wire. Decapsulation strips those headers up the stack at the receiver so each layer sees only its own PDU (Protocol Data Unit).

Example sending an HTTP GET:

On receive, the NIC delivers a frame → IP extracts packet → TCP reassembles segment → HTTP parses message.

MTU (Maximum Transmission Unit) caps payload size per link—Ethernet is often 1500 bytes. Larger IP packets fragment at routers; fragmentation hurts performance and complicates firewalls, so TCP uses MSS negotiation during handshake to avoid fragmentation on the path.

Interviewers want layered reasoning: "Where does TLS sit?" (between TCP and HTTP), "What does a switch read?" (Ethernet header, not HTTP body).

A strong answer is:

I describe encapsulation as headers added per layer down the stack—HTTP inside TCP inside IP inside Ethernet—and decapsulation as peeling headers up; I mention MTU and why fragmentation matters on real paths.

Ports (0–65535) identify applications/services on a host; IP identifies the host.

Socket = IP + port + protocol (e.g. 10.0.0.5:443 TCP).

Multiplexing lets many connections share one IP—web server handles thousands of (client_ip, ephemeral_port) pairs.

A strong answer is:

IP finds the machine; ports find the service—ephemeral ports on clients, well-known ports on servers like 443 for HTTPS.

IPv4 — 32-bit dotted decimal (192.168.1.10). IPv6 — 128-bit hex (2001:db8::1).

Private IPv4 ranges (RFC 1918): 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16—not routed on public internet.

A strong answer is:

IPv4 plus NAT dominates today; IPv6 removes NAT pressure—I know private ranges and that loopback is 127.0.0.1 for local tests like ping.

Subnetting splits networks into smaller broadcast domains.

Gateway (default route) — router IP to reach other subnets; on this host:

ip route show default

Typical output includes default via 192.168.0.1 dev eth0—traffic to non-local IPs goes there.

A strong answer is:

CIDR defines network size—I explain /24 as 254 usable hosts and point default route at the gateway for off-subnet traffic.

ARP (Address Resolution Protocol) maps IP → MAC on the local LAN: "Who has 192.168.1.1?"

Remote IPs go to default gateway's MAC; routers forward by IP across hops.

A strong answer is:

IP routes globally; MAC delivers on the local Ethernet—ARP binds them on the LAN before frames leave the subnet.

Dynamic Host Configuration Protocol assigns IP configuration automatically:

DORA process: Discover, Offer, Request, Acknowledge.

Without DHCP, static config or IPv6 SLAAC may apply.

A strong answer is:

DHCP hands out IP, gateway, and DNS—when a laptop "just works" on Wi-Fi, DORA negotiated the lease.

ICMP (Internet Control Message Protocol) carries control messages at network layer—errors, echo request/reply.

ping sends ICMP Echo Request; success means reachability and round-trip time to an IP—not that a TCP service works.

On Ubuntu 25.04, loopback test:

PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.478 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.066 ms
--- 127.0.0.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss

Ping failure may mean host down, firewall blocking ICMP, or routing issue—does not diagnose port 443 closed.

A strong answer is:

Ping tests IP reachability via ICMP—a successful ping does not prove HTTPS works; failed ping suggests routing, firewall, or host down at L3.

Choose TCP when correctness matters; UDP when latency beats perfect delivery.

A strong answer is:

TCP for reliable byte streams—HTTP and APIs; UDP for low-latency DNS and media where app handles loss; I justify choice with reliability vs latency.

Establishes connection before data:

Why three steps: both sides agree on initial sequence numbers; prevents stale duplicate SYN from opening wrong connection.

SYN flood attacks exploit half-open connections—mitigated by SYN cookies, rate limits.

A strong answer is:

SYN, SYN-ACK, ACK synchronizes sequence numbers—I mention it before HTTP on port 443 and tie half-open states to SYN flood awareness.

Graceful close:

1. FIN from side A
2. ACK from side B
3. FIN from side B
4. ACK from side A

Either side can initiate. TIME_WAIT on closing side waits 2×MSL to handle late duplicates—many sockets in TIME_WAIT on busy servers.

RST aborts connection abruptly.

A strong answer is:

FIN/ACK exchange closes cleanly; TIME_WAIT prevents stray packets—I distinguish graceful close from RST reset on error.

Mechanisms:

Head-of-line blocking — lost TCP segment delays later data on same connection; HTTP/3 QUIC avoids this at transport level.

A strong answer is:

Sequence numbers plus ACKs and retransmit deliver reliable streams—congestion control shares bandwidth fairly; HoL blocking is why HTTP/3 moved to QUIC.

UDP fits workloads where speed and simplicity beat TCP's reliability guarantees.

DNS (port 53):

• Queries are tiny (often < 512 bytes); one question, one answer.
• A TCP handshake adds RTT before the first byte—wasteful for a 50 ms lookup.
• If UDP response is lost, the resolver retries with exponential backoff—application-level reliability is enough.
• TCP is still used for zone transfers (AXFR) where large, reliable transfers matter.

Live streaming and gaming:

• A lost video frame from two seconds ago is useless—retransmitting it increases buffer bloat and latency.
• Codecs and jitter buffers conceal occasional loss; players prefer smooth motion over perfect pixels.
• VoIP uses small UDP packets with FEC (forward error correction) instead of TCP retransmits.

QUIC (HTTP/3 base):

• Runs over UDP but implements selective reliability, 0-RTT resumption, and stream multiplexing without TCP head-of-line blocking.
• Encryption (TLS 1.3) is integrated from the first packet.

A strong answer is:

DNS uses UDP because queries are small and a TCP handshake wastes RTT—resolvers retry on loss; streaming and gaming prefer dropping stale frames over TCP retransmits that add delay; QUIC rebuilds reliability on UDP for HTTP/3 without head-of-line blocking.

HTTP (Hypertext Transfer Protocol) — application protocol, typically over TCP port 80.

GET /index.html HTTP/1.1
Host: example.com
User-Agent: curl/8.x
Accept: */*

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1256

<body>

Stateless — each request independent; cookies/sessions add state at application layer.

A strong answer is:

HTTP is request-response over TCP—methods express intent, Host header required in HTTP/1.1, stateless at protocol level with cookies for sessions.

TLS provides:

• Confidentiality — encrypted payload
• Integrity — tamper detection
• Authentication — certificate chain to trusted CA

TLS sits between TCP and HTTP (presentation/session in OSI terms).

A strong answer is:

HTTPS is HTTP inside TLS—I explain encryption, cert trust, and that browsers warn on invalid certificates before sending sensitive data.

Modern TLS 1.3 reduces round trips:

1. Client Hello — supported ciphers, key share
2. Server Hello — cert, chosen cipher, key share
3. Encrypted handshake — verify cert, derive session keys
4. Application data — HTTP inside encrypted channel

1-RTT full handshake common; 0-RTT resumption for returning clients (replay caveats).

Older TLS 1.2 needed more round trips—know 1.3 is current default in 2026.

A strong answer is:

TLS 1.3 negotiates keys in about one RTT—I describe cert validation and that session resumption cuts latency for repeat visitors.

HTTP/2 still suffers TCP-level head-of-line blocking if one packet lost.

HTTP/3 uses QUIC — encryption built-in, connection migration when IP changes (mobile Wi-Fi → LTE).

A strong answer is:

HTTP/2 multiplexes on one TCP connection; HTTP/3 uses QUIC on UDP to fix TCP HoL blocking and improve mobile handoffs—I mention which CDN/browser support implies in prod.

502 often means load balancer could not reach healthy backend—networking and app debug intersect.

A strong answer is:

I map codes to layer—404 is routing/resource, 502 is often LB-to-backend connectivity, 503 overload or maintenance.

Turning example.com → IP address:

1. Browser cache — recent lookups
2. OS resolver cache
3. Recursive resolver (ISP, 8.8.8.8, 1.1.1.1)
4. Root nameserver — points to TLD
5. TLD nameserver (.com)
6. Authoritative nameserver — final A/AAAA record

getent hosts google.com

Example resolved address: 142.250.183.142 — proves resolver path works on host.

Record types: A (IPv4), AAAA (IPv6), CNAME (alias), MX (mail), TXT (verification).

A strong answer is:

DNS walks cache then recursive resolver to authoritative server—I name record types and know TTL controls cache freshness on changes.

TTL (Time To Live) — seconds resolvers cache answers.

DNS propagation delays cutover during migrations—plan lower TTL before changing records.

Negative caching stores NXDOMAIN temporarily.

A strong answer is:

TTL balances performance and agility—I lower TTL before migrations and explain why users still hit old IPs until caches expire.

NAT maps private IPs to public IP(s) on router/firewall—conserves IPv4, hides internal topology.

Breaks end-to-end transparency—some protocols (SIP, FTP) need ALG helpers.

Kubernetes kube-proxy and cloud NAT gateways use same idea at scale—see Kubernetes networking.

A strong answer is:

NAT lets private RFC1918 hosts reach the internet via one public IP—I note inbound DNAT for port forwarding and that NAT complicates peer-to-peer without STUN/TURN.

Content Delivery Network — edge servers cache static assets geographically close to users.

Benefits:

• Lower latency (RTT to edge)
• Reduced origin load
• DDoS absorption at edge
• TLS termination at edge

Cache invalidation and cache keys (URL, headers, cookies) affect hit rate.

A strong answer is:

CDN moves bytes closer to users—I explain DNS directing to nearest PoP and cache TTL vs dynamic API bypass.

Cross-Origin Resource Sharing — browser security policy blocking JS from reading cross-origin responses unless server allows.

Server sends:

Access-Control-Allow-Origin: https://app.example.com

Preflight OPTIONS request for non-simple methods/headers.

Not a server firewall—browser enforcement of same-origin policy. Ties to front end interviews.

A strong answer is:

CORS is browser-side—API must emit Allow-Origin headers; preflight OPTIONS happens before POST with custom headers from another origin.

Both move traffic, but at different layers with different forwarding tables.

Switch behavior:

• Learns MAC → port mappings from source addresses in incoming frames.
• Forwards unicast only to the port where that MAC was seen—reduces collision domains vs hubs.
• Still one broadcast domain per VLAN (ARP, DHCP broadcasts reach all ports in the VLAN).

Router behavior:

• Maintains a routing table (static or dynamic via OSPF/BGP).
• Decrements TTL; drops or forwards based on longest-prefix match.
• Connects 192.168.1.0/24 to 10.0.0.0/8—hosts on different subnets need a default gateway (usually a router interface).

VLANs segment a physical switch into logical LANs. Inter-VLAN routing requires an L3 device—a router or L3 switch with SVIs (Switch Virtual Interfaces).

Interview scenario: "Two departments on one switch but isolated?" → VLANs + ACLs or separate VLANs routed through a firewall.

A strong answer is:

Switches forward frames by MAC inside a LAN; routers forward packets by IP between subnets—I use VLANs to segment broadcast domains on one switch and route between VLANs on an L3 device when departments must stay isolated.

Default route (0.0.0.0/0) — send unknown destinations to gateway.

BGP — inter-domain internet routing between autonomous systems—cloud anycast uses BGP announcements.

A strong answer is:

Static routes for simple sites; BGP runs the internet at scale—I know default route sends traffic to the ISP gateway.

Health checks — TCP connect vs HTTP GET /health.

Sticky sessions — same client to same backend via cookie or IP hash.

A strong answer is:

L4 balances connections fast; L7 routes on URL and headers—I pick L7 when canary or API versioning needs path rules.

Firewalls filter traffic by rules:

Stateful firewall tracks connections—return traffic allowed automatically.

Cloud security groups are host-level firewalls; NACLs subnet-level (AWS terminology)—defense in depth.

A strong answer is:

Deny by default, allow least privilege—I distinguish stateful rules (established return traffic) from stateless ACLs.

VPN encrypts traffic over untrusted networks.

Protocols: IPsec, WireGuard, OpenVPN.

TLS VPN (HTTPS) is different—browser to web app, not full network tunnel.

A strong answer is:

VPN extends private network over internet encrypted—I contrast full-tunnel remote access with TLS to a single web app.

Traceroute discovers path hops to destination using TTL expiration (ICMP or UDP probes).

Shows where latency jumps or packets stop—routing loop, firewall drop, or provider issue.

Pair with ping for reachability; curl -v for application layer.

Layered toolkit:

A strong answer is:

Traceroute locates which hop fails or adds latency—I never stop at ping alone for "site slow" reports.

End-to-end narrative interviewers love:

1. Parse URL — scheme, host, path, port default 443 for HTTPS
2. DNS lookup — A/AAAA record for host
3. TCP connect — SYN/SYN-ACK/ACK to server IP:443
4. TLS handshake — cert verify, session keys
5. HTTP request — GET path, Host header, HTTP/2 maybe multiplexed
6. Server process — web server → app → database if needed
7. Response — status, headers, body
8. Browser — parse HTML, fetch assets (more DNS+TCP+TLS), render

Mention caching at DNS, CDN, and browser HTTP cache.

A strong answer is:

I walk DNS → TCP → TLS → HTTP → server logic → response, naming layers and where caching short-circuits repeat visits.

Structured flow (state assumptions):

1. User scope — one user or everyone? DNS change recent?
2. DNS — dig example.com returns expected IP?
3. Network — ping / traceroute to IP (ICMP may be blocked)
4. TCP port — curl -v or nc -zv host 443
5. TLS — cert expired? wrong hostname?
6. HTTP — 502/503 from LB? app logs?
7. Recent changes — deploy, firewall, TTL

Avoid jumping to "database down" before proving reachability to load balancer.

A strong answer is:

I isolate layer by layer—DNS, then TCP 443, then TLS, then HTTP status—correlating with whether failure is global or regional.

Intermittent loss is harder than total outage—connections work but degrade unpredictably.

Symptoms by protocol:

Diagnostic flow:

1. Baseline: ping -c 20 host — watch for loss % and jitter (RTT variance).
2. Path: traceroute / mtr — loss at one hop vs end-to-end (last-hop loss often means congestion at destination).
3. Layer isolation: Compare Wi-Fi vs wired; swap cable; test from another VLAN.
4. Capture: tcpdump or Wireshark—retransmits ([TCP Retransmission]), duplicate ACKs, high RTT spikes.
5. Offload: Disable NIC LRO/GRO temporarily if checksum errors appear—rare but real on some drivers.

Common causes:

• Wi-Fi contention, roaming, or weak signal
• Duplex mismatch or failing cable (CRC errors on switch port counters)
• ISP peering congestion or bufferbloat on home router
• Oversubscribed VM host or microbursts in cloud

Mitigation: Fix physical/link layer first; apply QoS for voice; tune TCP only after ruling out L1/L2; for real-time UDP use jitter buffers and FEC.

A strong answer is:

Intermittent loss shows as TCP slowdowns and jittery RTT on ping—I isolate Wi-Fi vs wired, use mtr to see which hop drops packets, capture retransmits if needed, and fix the physical or congestion layer before tuning TCP.

HTTP/1.1 is request-response: the client opens a connection, sends a request, server replies, connection may close. For live updates, naive approaches fail:

WebSocket handshake:

1. Client sends HTTP Upgrade: websocket request.
2. Server responds 101 Switching Protocols.
3. Same TCP connection becomes a full-duplex, persistent binary/text channel—low framing overhead per message.

When to use WebSockets:

• Chat, collaborative editing, live dashboards
• Gaming or trading feeds needing bidirectional low latency
• Thousands of concurrent push clients after one upgrade

When HTTP is enough:

• REST CRUD, file upload/download, cacheable GETs
• Stateless APIs behind CDNs
• SSE (Server-Sent Events) for one-way server push over HTTP—simpler reconnection, works through many proxies, ideal for news feeds and log streams

Operational notes: WebSockets need sticky sessions or shared pub/sub (Redis) behind load balancers; idle timeouts and heartbeats prevent ghost connections.

A strong answer is:

HTTP fits request-response REST; WebSockets after a 101 upgrade give full-duplex push for chat and live dashboards—I pick SSE when only the server needs to push and proxies matter; I mention load-balancer stickiness for WebSocket farms.

Distributed Denial of Service — flood traffic exhausts bandwidth or server resources.

Mitigations:

Distinguish volumetric (bits) vs application-layer (expensive HTTP requests).

A strong answer is:

DDoS defense layers edge absorption, filtering, and app rate limits—I do not rely on a single firewall rule alone.

QUIC — transport on UDP combining:

• TLS 1.3 integrated (fewer round trips)
• Stream multiplexing without TCP HoL blocking
• Connection migration by connection ID
• Used by HTTP/3

Adoption growing on major browsers and CDNs—mention in senior full-stack loops.

A strong answer is:

QUIC is UDP-based transport with built-in TLS and smarter multiplexing—HTTP/3 adopts it to cut latency especially on lossy mobile networks.

Map symptoms to layers:

Shows disciplined, layer-by-layer reasoning interviewers expect when traffic fails.

A strong answer is:

I state the layer first—timeout vs refused vs cert error narrows blame before touching application code.

Socket API (BSD sockets) — OS interface apps use:

• socket() → bind() → listen() → accept() (server)
• connect() → send() / recv() (client)

Kernel implements TCP state machine; application blocks or uses non-blocking/async I/O.

Ties to operating system interviews — file descriptors, epoll, thread per connection vs event loop.

A strong answer is:

Sockets are the OS boundary to the network stack—I connect user-space HTTP servers to kernel TCP via accept/read/write and epoll for scale.

Checklist:

• OSI and TCP/IP — layer names and protocol mapping
• TCP vs UDP with examples
• Three-way handshake and four-way close
• DNS resolution chain and TTL
• URL to page full narrative
• HTTP vs HTTPS and TLS 1.3 at high level
• HTTP/2 vs HTTP/3 / QUIC awareness
• NAT, DHCP, ARP basics
• L4 vs L7 load balancing
• ping, traceroute, dig, curl -v toolkit
• One unreachable site debug story
• Operating system interviews for sockets and processes
• Kubernetes interviews for Service/Ingress networking
• Front end interviews for CORS and browser cache

A strong answer is:

I whiteboard URL flow weekly, run curl -v on a real site, and practice layered troubleshooting aloud until OSI becomes a habit not a mnemonic.