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.

A strong answer is:

“Networking interviews test whether I understand how data moves from application to wire and can use that model to explain protocols, make design trade-offs, and isolate failures layer by layer.”

What interviewers are testing: Whether you understand that interview depth changes by role and seniority—basic screens test protocol vocabulary, while advanced loops test packet flow, failure isolation, performance, and architecture trade-offs.

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.

A strong answer is:

“Basic networking interviews test whether I understand layers, addressing, TCP/UDP, DNS, and HTTP. Advanced interviews add protocol behavior, routing, load balancing, performance, and structured troubleshooting.”

Networking interviews vary by company and role—there is no universal loop duration. Common question types include:

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

A strong answer is:

“I expect a mix of conceptual questions, packet-flow walkthroughs, troubleshooting scenarios, design questions, and command-line diagnostics. I prepare both the protocol explanation and how I would isolate a failure in practice.”

The example below transfers data with curl over HTTP(S); the curl command is a quick reference for flags and syntax.

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

A strong answer is:

I'd build hands-on drills each week, explain answers aloud, and close every technical card with one sentence I could say in the room.

What interviewers are testing: Whether you can connect networking fundamentals to real application failures such as API latency, DNS errors, connection timeouts, TLS failures, and load-balancer issues without assuming every problem belongs to the application code.

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 strong answer is:

“Software engineers don't need routing-engineer depth, but they do need to understand DNS, TCP, TLS, HTTP, ports, timeouts, and load balancers because those directly affect distributed applications and production debugging.”

What interviewers are testing: Whether you can define a network beyond “connected computers” by mentioning addressing, protocols, communication paths, and the layered model that lets applications exchange data.

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.

What interviewers are testing: Whether you have a layer model you can actually use to place protocols and narrow failures—not merely whether you memorized seven layer names.

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.

What interviewers are testing: Whether you understand that OSI is mainly a conceptual troubleshooting model while TCP/IP describes the practical protocol stack used by the Internet, and can map the layers between them.

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.

What interviewers are testing: Whether you can explain encapsulation and decapsulation with correct definitions and one concrete example.

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. For IPv4, routers may fragment oversized packets when fragmentation is permitted. IPv6 routers do not fragment in transit—the sender handles fragmentation using Path MTU discovery. Modern hosts try to avoid fragmentation through PMTU discovery and TCP MSS negotiation, though MSS alone does not guarantee no fragmentation across the complete 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.

What interviewers are testing: Whether you understand how transport-layer ports let multiple services and connections share a host, and can distinguish an IP address, port, socket endpoint, and connection.

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

A network endpoint can be identified by IP address + port + transport protocol. A TCP connection is distinguished by its source and destination IP/port pair—the common 5-tuple: source IP, source port, destination IP, destination port, and protocol.

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.

What interviewers are testing: Whether you contrast ipv4 and ipv6 — basics with when each wins—not parallel definitions.

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 uses 32-bit addresses and often relies on NAT because address space is limited. IPv6 uses 128-bit addresses, greatly expands the address space, and supports more direct end-to-end addressing. IPv4 loopback is 127.0.0.1; IPv6 loopback is ::1.”

What interviewers are testing: Whether you subnet and route without conflating IP reachability with DNS.

Subnetting divides IP address space into smaller IP networks. On Ethernet networks, each IP subnet is commonly mapped to a separate VLAN or other L2 broadcast domain.

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:

“A /24 means 24 network bits and 8 host bits, giving 256 IPv4 addresses. In a conventional subnet, network and broadcast consume two addresses, leaving 254 assignable addresses.”

What interviewers are testing: Whether you understand local L2 delivery versus routed L3 delivery, including why a host ARPs for a local peer but uses the default gateway's MAC for a remote destination.

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.

What interviewers are testing: Whether you understand what network configuration DHCP supplies, the DORA exchange, and what breaks when address, gateway, or DNS configuration is wrong.

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.

What interviewers are testing: Whether you can explain icmp and ping — what do they test with correct definitions and one concrete example.

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 ICMP reachability and RTT. Success proves an IP path responds to ICMP, but not that TCP 443 or the application works. Failure may mean routing trouble, a down host, or simply that ICMP is filtered.”

What interviewers are testing: Whether you understand the service each transport provides and can choose between TCP's reliable ordered byte stream and UDP's best-effort datagrams based on application requirements.

Choose TCP when correctness matters; UDP when the application benefits from datagrams, low protocol overhead, or application-controlled reliability/order rather than TCP's built-in reliable byte stream.

A strong answer is:

“TCP gives me a reliable ordered byte stream with flow and congestion control. UDP gives independent datagrams without built-in delivery or ordering guarantees, so I use it when the application or higher-level protocol wants different reliability behavior.”

What interviewers are testing: Whether you understand why TCP needs SYN/SYN-ACK/ACK to establish bidirectional connection state and synchronize initial sequence numbers before application data flows.

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.

What interviewers are testing: Whether you understand that TCP is full duplex, so each direction closes independently, and can explain FIN/ACK, TIME_WAIT, and how an RST differs from a graceful close.

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. The endpoint performing the active close typically enters TIME_WAIT, allowing old duplicate segments to expire and ensuring the final ACK can be retransmitted if necessary—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.

What interviewers are testing: Whether you can separate reliability, flow control, and congestion control instead of treating them as one generic “TCP is reliable” feature.

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, ACKs, checksums, and retransmission provide reliable ordered delivery; receive windows provide flow control, while congestion-control algorithms reduce sending rate when the network shows congestion.”

What interviewers are testing: Whether you explain why udp-based transports common for dns and real-time media with cause and consequence—not 'because best practice'.

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

DNS (port 53):

• Traditional DNS used a 512-byte UDP message limit; modern DNS commonly uses EDNS(0) for larger UDP responses, with TCP fallback when required.
• Normal queries often use UDP; TCP is not only for zone transfers (AXFR)—ordinary queries can use TCP when responses are large or truncated.
• If a UDP response is lost, the resolver retries—application-level reliability is enough for many lookups.

Real-time media (VoIP, WebRTC, gaming):

• A lost video frame from two seconds ago may no longer be useful—waiting for retransmission can add latency and disrupt real-time playback.
• Codecs and jitter buffers conceal occasional loss.

HTTP video streaming (Netflix/YouTube-style) commonly uses HTTP over TCP or QUIC, not classic UDP media transport.

A strong answer is:

DNS often uses UDP with EDNS for larger responses and TCP fallback when needed; real-time media prefers UDP drops over TCP retransmits; HTTP streaming usually rides TCP or QUIC—not the same model as VoIP.

What interviewers are testing: Whether you can explain http request-response cycle with correct definitions and one concrete example.

HTTP is an application-layer request-response protocol. HTTP/1.1 and HTTP/2 normally run over TCP, while HTTP/3 runs over QUIC.

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 an application-layer request-response protocol. HTTP/1.1 and HTTP/2 normally use TCP, while HTTP/3 uses QUIC; methods and status codes define the application semantics independently of the transport.”

What interviewers are testing: Whether you contrast http and https — tls role with when each wins—not parallel definitions.

TLS provides:

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

TLS typically runs above TCP and below application protocols such as HTTP. In OSI teaching diagrams it is often associated with the presentation/session area, but the mapping is approximate.

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.

What interviewers are testing: Whether you can explain tls 1.3 handshake — simplified with correct definitions and one concrete example.

Modern TLS 1.3 reduces round trips:

1. ClientHello sends supported algorithms and key share.
2. ServerHello chooses parameters and completes the key agreement.
3. The server sends its certificate and proof of identity in encrypted handshake messages.
4. Both sides derive traffic keys and exchange Finished messages.
5. Application data follows.

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

TLS 1.3 is the modern version candidates should understand, while TLS 1.2 remains relevant in existing systems.

A strong answer is:

“TLS 1.3 usually establishes fresh keys in one round trip. The client and server negotiate keys, the client validates the server certificate, both confirm the handshake, and encrypted application traffic begins.”

What interviewers are testing: Whether you contrast http/1.1 and http/2 vs http/3 with when each wins—not parallel definitions.

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 streams over one TCP connection, so TCP packet loss can stall multiple streams. HTTP/3 runs over QUIC, which provides independent streams, integrated TLS, and connection migration.”

What interviewers are testing: Whether you can explain common http status codes for interviews with correct definitions and one concrete example.

A strong answer is:

“I use status codes to narrow the failure. A 4xx usually points toward the request, authentication, or resource, while a 5xx points toward server-side processing. A 502 specifically suggests that a gateway or proxy had trouble with its upstream response.”

What interviewers are testing: Whether you can trace a hostname lookup through caches, recursive resolution, root/TLD delegation, and the authoritative server—and distinguish DNS failure from IP connectivity failure.

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 — confirms that the host's configured name-resolution path returned an address.

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.

What interviewers are testing: Whether you can explain dns caching and ttl with correct definitions and one concrete example.

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

During DNS changes, recursive resolvers and clients may continue using cached old records until their TTLs expire. Lower the TTL sufficiently before a planned migration when faster cutover matters.

Negative caching stores NXDOMAIN temporarily.

A strong answer is:

“TTL balances resolver load against change agility. Before a planned migration I may lower it in advance, because caches can continue serving the old answer until the previous TTL expires.”

What interviewers are testing: Whether you define nat (network address translation) with mechanism and implications—not a one-line buzzword.

NAT translates addresses between networks. In IPv4 it commonly lets multiple hosts using private RFC1918 addresses share one or more public addresses. NAT changes end-to-end addressing, but it is not a substitute for firewall policy.

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

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.

What interviewers are testing: Whether you define a cdn and why use one with mechanism and implications—not a one-line buzzword.

A Content Delivery Network (CDN) uses geographically distributed edge locations to serve or cache content closer 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:

“A CDN serves cacheable content from edge locations closer to users, reducing latency and origin load. Traffic can be steered through DNS, Anycast, or provider-specific routing, while cache keys and TTLs determine what can be served from the edge.”

What interviewers are testing: Whether you understand that CORS is a browser-enforced cross-origin read policy controlled by HTTP response headers, not a network firewall or server-side authorization mechanism.

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.

What interviewers are testing: Whether you contrast router and switch with when each wins—not parallel definitions.

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

Switch behavior:

• Learns MAC → port mappings from source addresses in incoming frames.
• Forwards known unicast frames to the learned destination port. If the destination MAC is unknown, the switch typically floods the frame within that VLAN until it learns the destination.
• 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.

What interviewers are testing: Whether you contrast static and dynamic routing with when each wins—not parallel definitions.

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 fit small predictable networks. Dynamic protocols adapt when topology changes—OSPF is common inside an organization, while BGP exchanges reachability between autonomous systems and underpins Internet routing.”

What interviewers are testing: Whether you can choose the load-balancing layer based on what information the balancer needs to inspect—connections and ports at L4 versus HTTP paths, hosts, headers, and cookies at L7.

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.

What interviewers are testing: Whether you can explain firewall and security groups with correct definitions and one concrete example.

Firewalls filter traffic by rules:

Stateful firewall tracks connections—return traffic allowed automatically.

In AWS, security groups are stateful controls associated with network interfaces/resources, while network ACLs are stateless controls applied at the subnet boundary.

A strong answer is:

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

What interviewers are testing: Whether you contrast vpn and site-to-site vs remote access with when each wins—not parallel definitions.

VPN encrypts traffic over untrusted networks.

VPN technologies include IPsec, WireGuard, OpenVPN, and TLS-based VPN solutions. An ordinary HTTPS connection also uses TLS, but it protects one application's HTTP traffic rather than automatically creating a general network tunnel.

A strong answer is:

“A remote-access VPN connects an individual device to a private network, while site-to-site VPNs connect networks such as a branch and headquarters. VPNs may use IPsec, WireGuard, OpenVPN, or TLS-based tunneling depending on the design.”

What interviewers are testing: Whether you can explain traceroute / mtr — what do they show with correct definitions and one concrete example.

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

Traceroute shows the sequence of responding hops and approximate RTTs along the path. It can help identify where routing or latency appears to change, but missing or slow responses from an intermediate hop do not by themselves prove that hop is dropping forwarded traffic.

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

Layered toolkit:

A strong answer is:

“Traceroute shows the responding hops along a path and helps me identify where latency or reachability appears to change. I verify suspected packet loss end-to-end because intermediate routers may rate-limit traceroute responses.”

What interviewers are testing: Whether you can connect DNS, routing, transport, TLS, HTTP, server processing, and browser rendering into one ordered end-to-end flow without mixing the responsibilities of each layer.

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 (HTTP/1.1 and HTTP/2)
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, discover CSS/JS/images, reuse cached DNS/connections where possible or establish additional connections as needed, then build and render the page

This TCP → TLS sequence describes HTTPS over HTTP/1.1 or HTTP/2. With HTTP/3, the browser establishes QUIC over UDP, and TLS 1.3 is integrated into the QUIC connection setup rather than using a separate TCP connection.

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

A strong answer is:

“I walk DNS → transport setup → HTTP → server processing → response → browser rendering. For HTTP/1.1 or HTTP/2 that transport setup is TCP plus TLS for HTTPS; HTTP/3 uses QUIC with TLS integrated into the connection.”

What interviewers are testing: Your ordered scenario response—verify first, prove root cause, then prevent recurrence.

Structured flow (state assumptions). Confirm resolver answers early with the dig command before you treat an outage as an application failure.

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. HTTPS transport — use curl -v; HTTP/1.1/2 normally use TCP 443, while HTTP/3 uses QUIC over UDP 443 when negotiated
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 the failure layer by layer—DNS first, then transport reachability to HTTPS, then TLS/QUIC setup, then the HTTP response and upstream application—while checking whether the failure is global, regional, or client-specific.”

What interviewers are testing: Your step-by-step response to intermittent packet loss — symptoms—what you verify first and how you prove the fix.

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: Use mtr or traceroute to compare successive hops. Loss shown only at one intermediate router may simply mean that router rate-limits diagnostic responses. Loss that continues through subsequent hops and reaches the destination is much stronger evidence of real forwarding loss.
3. Layer isolation: Compare Wi-Fi vs wired; swap cable; test from another VLAN.
4. Capture: tcpdump command or Wireshark—retransmits ([TCP Retransmission]), duplicate ACKs, high RTT spikes.
5. Counters: Interface counters, switch/NIC error counters.

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:

“I baseline loss and RTT, compare wired versus wireless paths, and use mtr to see whether apparent loss persists through later hops to the destination. If necessary, I capture TCP retransmissions and inspect interface or switch error counters before tuning the transport.”

What interviewers are testing: Whether you contrast websockets and http — when use with when each wins—not parallel definitions.

HTTP uses a request-response model: the client sends a request and the server sends a response. Connections may be reused, and newer HTTP versions change how requests are multiplexed and transported. For live updates, naive approaches fail:

WebSocket handshake — the classic HTTP/1.1 flow works as follows:

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.

WebSockets can also be bootstrapped over newer HTTP versions using extended CONNECT mechanisms, but the HTTP/1.1 Upgrade flow is the interview baseline most candidates should know.

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: WebSocket fleets usually need shared pub/sub or distributed state for cross-instance messaging. Session affinity may help when application state remains local or on reconnect, but an established WebSocket is already pinned to the backend that accepted the upgrade—sticky routing is not required simply to keep that connection alive. 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; I use shared pub/sub for cross-instance messaging and affinity only when local state requires it.

What interviewers are testing: Whether you recognize that DDoS mitigation must happen at multiple layers and that volumetric attacks require upstream/edge capacity rather than only application-side rate limiting.

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.

What interviewers are testing: Whether you can explain quic and why it matters in 2026 with correct definitions and one concrete example.

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.

What interviewers are testing: Whether you can explain using osi layers in interview answers with correct definitions and one concrete example.

Map symptoms to layers:

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

A strong answer is:

“I use OSI layers to choose the next test rather than declaring root cause from one symptom. A timeout, refusal, TLS failure, and HTTP error each narrow the investigation differently.”

What interviewers are testing: Whether you can explain how do sockets relate to the os and network stack with correct definitions and one concrete example.

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.

What interviewers are testing: Whether you understand that TCP keepalive, HTTP connection reuse, and application heartbeats solve different liveness and connection-management problems at different layers.

Candidates often confuse these—HTTP persistent connections do not replace TCP keepalive or WebSocket heartbeats for detecting half-open connections behind NATs and load balancers.

A strong answer is:

TCP keepalive probes idle transport connections; HTTP keep-alive reuses TCP for multiple requests; WebSocket heartbeats are application-level liveness—I use the right layer for the failure mode I'm trying to detect.