Top 50 Computer Networks Interview Questions (2026)

A computer network is a set of devices connected so they can share data and resources. The connection can be wired or wireless, and the devices range from two laptops to millions of machines on the internet.

Networks let devices exchange messages, share files and printers, and reach services like websites and email. They're organized in layers so each concern, the physical link, addressing, routing, and the application, can be handled separately.

They're networks classified by geographic size. A LAN (Local Area Network) covers a small area like a home, office, or building. A MAN (Metropolitan Area Network) spans a city or campus. A WAN (Wide Area Network) covers large distances, potentially countries; the internet is the largest WAN.

The practical difference is scale and ownership: a LAN is usually owned by one organization and is fast and cheap over short distances, while a WAN links separate networks over long distances, often over links you lease rather than own.

From bottom to top the seven layers are physical, data link, network, transport, session, presentation, and application. Each layer handles one job and passes data to the next, so a change at one layer doesn't force changes everywhere else and each can be reasoned about on its own.

Physical moves raw bits, data link frames them and handles MAC addressing, network routes packets by IP, transport gives end-to-end delivery (TCP or UDP), session manages dialogs, presentation handles formatting and encryption, and application is where protocols like HTTP live.

OSI is a seven-layer reference model built for teaching and for reasoning about where a problem lives. TCP/IP is a four-layer model that the actual internet runs on, so it maps directly to real protocols.

TCP/IP combines OSI's physical and data link into one link layer, and it merges session, presentation, and application into a single application layer. Use OSI to explain and locate problems; TCP/IP is the stack that's really implemented.

TCP is connection-oriented and reliable: it sets up a connection with a handshake, numbers and acknowledges bytes, retransmits what's lost, and delivers data in order. That reliability adds overhead and latency, since every segment has to be tracked and confirmed before the stream is considered complete.

UDP is connectionless and unreliable by design: it just sends datagrams with no handshake, no acknowledgment, and no ordering. That makes it fast and lightweight, which is why real-time video, voice, gaming, and DNS lookups often use UDP where a lost packet matters less than speed.

An IP address is a numeric label that identifies a device on a network so packets can be routed to it. IPv4 addresses are 32 bits, written as four decimal octets like 192.168.1.10, giving about 4.3 billion addresses.

IPv6 uses 128-bit addresses written in hexadecimal, giving a practically unlimited pool, which is why it exists: IPv4 ran out. IPv6 also simplifies the header and builds in features that were add-ons in IPv4. Both still coexist today.

A public IP is globally routable on the internet and must be unique. A private IP comes from reserved ranges (like 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) used inside local networks and is not routable on the public internet.

Many devices on a home or office LAN share one public IP using NAT: the router translates private addresses to the single public one on the way out. That's why your laptop's 192.168.x.x address is private while the internet sees your router's public address.

A subnet mask splits an IP address into a network portion and a host portion. The bits set to 1 mark the network part; the bits set to 0 mark the host part. For 255.255.255.0, the first three octets are the network and the last is the host.

Its job is to let a device decide whether a destination is on the same local network (deliver directly) or on a different one (send to the router). CIDR notation like /24 is just a shorthand for how many leading bits are the network part.

DNS (Domain Name System) is the internet's directory: it translates human-readable names like example.com into the IP addresses machines use to connect. Without it, you'd have to remember numeric addresses for every site, and any server changing its IP would break every link pointing at it.

It's a distributed hierarchy of servers, so no single machine holds every name. When you look up a name, the resolution walks from a root server to the top-level domain server to the domain's authoritative server, and results get cached along the way to keep it fast.

DHCP (Dynamic Host Configuration Protocol) automatically assigns IP configuration to devices when they join a network: an IP address, subnet mask, default gateway, and DNS servers. Without it, every device would need manual configuration, which doesn't scale past a handful of machines and invites duplicate-address mistakes.

When a device connects, it broadcasts a request, a DHCP server offers an address from its pool, the device accepts, and the server leases it for a set time. The classic sequence is discover, offer, request, acknowledge, often called DORA.

HTTP is the protocol browsers and servers use to exchange web pages, and it sends data in plaintext. HTTPS is HTTP running over TLS, so the connection is encrypted, the data can't be read or tampered with in transit, and the server's identity is verified with a certificate.

HTTP uses port 80, HTTPS uses port 443. The MDN overview of HTTP is the standard reference here. In practice everything uses HTTPS now, because plaintext HTTP leaks credentials and content to anyone on the path.

A hub is a dumb repeater at the physical layer: it copies every incoming frame out of every other port, which wastes bandwidth and causes collisions. A switch works at the data link layer: it learns MAC addresses and forwards a frame only to the port where its destination lives.

A router works at the network layer: it connects different networks and forwards packets between them based on IP addresses, choosing a path toward the destination. In short: hub floods, switch forwards within a network by MAC, router routes between networks by IP.

A MAC address is a hardware identifier burned into a network interface, unique to that device, and used for delivery on the local network segment at the data link layer. An IP address is a logical address at the network layer, used to route packets across networks and it can change depending on the network you join.

The analogy: the IP address is like the street address that gets a letter to the right building across the world, while the MAC address is like the specific mailbox that gets it to the right device on the final local hop. ARP is what links the two.

A protocol is an agreed set of rules for how devices format, transmit, and interpret data so they can communicate. Both sides follow the same rules, which is what lets machines from different vendors talk to each other.

Protocols define things like message format, the order of exchanges, error handling, and addressing. Examples by layer: Ethernet at the link layer, IP at the network layer, TCP and UDP at the transport layer, and HTTP, DNS, and SMTP at the application layer.

They're the same data described at different layers, each wrapping the one above it. A segment is the transport-layer unit (TCP segment or UDP datagram). Wrap it with an IP header and it's a packet at the network layer. Wrap that with a link-layer header and trailer and it's a frame on the wire.

This wrapping is called encapsulation: as data goes down the stack, each layer adds its own header; as it goes up on the receiving side, each layer strips its header off. Using the right term for the right layer signals you actually understand the model.

Bandwidth is how much data a link can carry per unit of time, measured in bits per second. Latency is how long a single bit takes to travel from source to destination, measured in milliseconds. They're independent: a link can be high-bandwidth but high-latency.

The common analogy is a highway: bandwidth is how many lanes it has (how much can flow at once), while latency is how long the drive takes end to end. A satellite link can move lots of data (high bandwidth) yet feel slow because each bit travels a long way (high latency).

Topology is the shape of how devices are connected. Star connects every device to a central switch or hub, which is the standard for modern LANs because one failed link only drops one device. Bus runs everything on one shared cable, mesh links devices directly to many others, and ring passes traffic around a loop.

Each trades cost against resilience. Star is cheap and easy to troubleshoot but depends on the central device. Mesh is expensive to wire but survives many link failures, which is why the internet's backbone is roughly a partial mesh. Bus and ring are mostly historical now.

These describe how many recipients a message targets. Unicast is one sender to one receiver, the normal case for most traffic like loading a web page. Broadcast is one sender to every device on the local network, which is how ARP and some discovery protocols work.

Multicast is one sender to a specific group of interested receivers, which is far more efficient than broadcasting to everyone when only some devices care. Streaming a video feed to many subscribers at once is a classic multicast use. Broadcast doesn't cross routers; it stays inside the local segment.

Mapping protocols to layers is a standard drill, so it helps to have a few anchors ready. the question needs to see you a protocol name connects to the job its layer does, not just recite a list. Getting a couple wrong signals shaky fundamentals.

The reliable anchors: Ethernet and ARP at the data link layer, IP and ICMP at the network layer, TCP and UDP at the transport layer, and HTTP, DNS, SMTP, and FTP up at the application layer. When unsure, reason from the job: if it addresses hosts across networks it's layer 3, if it delivers end to end it's layer 4.

It's how TCP opens a reliable connection. The client sends a SYN with its initial sequence number. The server replies with a SYN-ACK: its own SYN plus an acknowledgment of the client's. The client sends a final ACK, and the connection is established so data can flow.

The point of the exchange is that both sides agree on starting sequence numbers and confirm each other can send and receive. Closing the connection uses a similar FIN/ACK exchange, usually described as a four-way handshake.

Subnetting divides a larger network into smaller ones by borrowing bits from the host portion of an address to create more network segments. The subnet mask (or CIDR prefix like /26) decides how many bits are network and how many are host, which sets how many subnets and how many hosts per subnet you get.

We subnet to reduce broadcast traffic, improve security by isolating segments, and use address space efficiently instead of wasting a huge flat range. For example, a /24 has 256 addresses; splitting it into four /26 subnets gives four segments of 64 addresses each.

First the resolver checks caches: the browser, the OS, then the configured DNS resolver. On a miss, the recursive resolver walks the hierarchy: it asks a root server, which points to the top-level domain server (like .com), which points to the domain's authoritative name server, which returns the actual IP.

The resolver caches the answer with a TTL so repeat lookups are instant until it expires. This hierarchy and caching is what makes DNS scale to the whole internet without any single server knowing every name.

The browser resolves the domain to an IP via DNS, then opens a TCP connection to the server (a three-way handshake), and for HTTPS performs a TLS handshake to set up encryption. Then it sends an HTTP request, usually a GET for the page.

The server responds with HTML, and the browser parses it, discovers linked assets (CSS, JavaScript, images), fetches those over more requests, builds the DOM and render tree, and paints the page. Under the hood, IP routing moves every one of those packets across networks to the server and back.

NAT (Network Address Translation) rewrites IP addresses as packets pass through a router. The most common form maps many private addresses on a LAN to one public address, tracking connections so replies get back to the right internal device.

It exists mainly to conserve scarce IPv4 addresses: a whole home or office shares one public IP. A side effect is a basic layer of privacy and isolation, since internal addresses aren't directly reachable from outside, though NAT isn't a real firewall.

Flow control protects the receiver: it stops a fast sender from overwhelming a slow receiver's buffer, managed with the receiver's advertised window. Congestion control protects the network: it stops senders from overwhelming the links and routers between them.

They solve different problems with different signals. Flow control uses the receive window the receiver advertises. Congestion control uses algorithms like slow start and congestion avoidance that react to signs of loss or delay in the network, adjusting how much the sender puts in flight.

The router looks at the packet's destination IP and consults its routing table, which lists networks and the next hop to reach each. It picks the most specific matching route (longest prefix match) and forwards the packet to that next hop, decrementing the TTL as it goes.

Routing tables are built either statically (an admin configures routes) or dynamically with routing protocols. If no route matches, the packet goes to the default route (the gateway of last resort), and if even that's missing, it's dropped.

OSPF (Open Shortest Path First) is an interior gateway protocol: it routes within a single organization's network (an autonomous system), building a map of the topology and computing shortest paths. It converges fast and reacts to link changes inside your network.

BGP (Border Gateway Protocol) is the exterior protocol that routes between autonomous systems, and it's what stitches the whole internet together. BGP chooses paths based on policy and the sequence of networks a route passes through, not just shortest distance, because it deals with business relationships between providers.

A port is a number that identifies a specific service or process on a device, so one machine with one IP can run many services at once (web on 443, SSH on 22, DNS on 53). The transport layer uses ports to deliver data to the right application.

A socket is the combination of an IP address and a port, plus the protocol, that identifies one endpoint of a connection. A TCP connection is uniquely identified by the four-tuple of source IP, source port, destination IP, and destination port.

A handful of well-known ports come up constantly, so it's worth having them memorized cold. They span the application-layer services you interact with every day, from web traffic to remote login to name resolution to sending mail, and each one identifies a specific service on a host.

Interviewers sometimes rapid-fire these to check your fluency, so know at least HTTP, HTTPS, SSH, DNS, and SMTP without hesitation.

The UDP header is tiny, just source port, destination port, length, and checksum, eight bytes total. That's all UDP needs because it doesn't track connections or guarantee delivery, so there's nothing to record between packets and no state to carry from one datagram to the next.

The TCP header is larger (20 bytes minimum) because it carries what reliability needs: sequence and acknowledgment numbers for ordering and retransmission, a window size for flow control, and control flags like SYN, ACK, and FIN for connection state. The header size difference is a direct reflection of what each protocol promises.

ICMP (Internet Control Message Protocol) carries control and error messages for IP, like 'destination unreachable' or 'time exceeded'. It's not for carrying application data; it's how the network reports problems back to senders and answers the diagnostic probes that tools like ping and traceroute rely on.

Ping sends ICMP echo requests and times the echo replies to measure reachability and round-trip time. Traceroute sends packets with increasing TTL values: each router that decrements TTL to zero returns an ICMP time-exceeded message, which reveals each hop along the path.

ARP (Address Resolution Protocol) finds the MAC address for a known IP on the local network. When a device wants to send to a local IP but doesn't know its MAC, it broadcasts an ARP request asking who has that IP; the owner replies with its MAC address.

The result is cached in an ARP table for a while so the device doesn't ask again for every packet. ARP only works within a single local network segment; to reach a device on another network, the sender uses ARP to find the router's MAC, and the router takes it from there.

A collision domain is the set of devices whose frames can collide on a shared medium. Hubs put everything in one collision domain; switches break it up because each switch port is its own collision domain, which is why switches replaced hubs.

A broadcast domain is the set of devices that receive each other's broadcast frames. A switch forwards broadcasts to all its ports, so a plain switched network is one broadcast domain. Routers and VLANs are what separate broadcast domains, which is one reason we subnet and use VLANs.

TLS sets up an encrypted, authenticated connection before any HTTP data flows. The client and server agree on a protocol version and cipher, the server presents its certificate so the client can verify its identity against a trusted authority, and they exchange keying material to derive a shared session key.

Once the handshake finishes, both sides use fast symmetric encryption with that session key for the actual data. Modern TLS uses key exchange methods that give forward secrecy, so capturing traffic today and stealing the server's key later still can't decrypt past sessions.

HTTP itself is stateless: each request stands alone and the server remembers nothing between them. Cookies bridge that gap. The server sends a Set-Cookie header, the browser stores it, and it attaches the cookie on every later request to the same site, so the server can recognize a returning user.

A typical login stores a session ID in a cookie; the server keeps the real session data server-side, keyed by that ID. Flags matter for safety: HttpOnly hides the cookie from JavaScript, Secure sends it only over HTTPS, and SameSite limits cross-site sending to blunt CSRF.

GET requests a resource and puts its parameters in the URL query string, so it should only read data, never change it. Because GET is safe and idempotent, browsers and caches can repeat it freely and it shows up in history and logs.

POST sends data in the request body to create or change something on the server, so it's not idempotent: submitting twice can create two records, which is why browsers warn before resending a POST. The rule of thumb is GET to read, POST (or PUT/PATCH/DELETE) to write.

TCP keeps a congestion window that limits how much unacknowledged data is in flight. It starts small and uses slow start, doubling the window each round trip until it hits a threshold or sees loss. After that it shifts to congestion avoidance, growing the window slowly and linearly to probe for more capacity gently.

When loss signals congestion, classic TCP cuts the window (fast retransmit and fast recovery for a single loss, a larger cut for a timeout). Newer algorithms like CUBIC scale better on high-bandwidth links, and BBR models bandwidth and round-trip time directly instead of treating loss as the only congestion signal.

HTTP/1.1 sends one request at a time per connection and suffers head-of-line blocking, so browsers open many connections to work around it. HTTP/2 multiplexes many streams over one TCP connection and adds header compression, but a single lost TCP packet still stalls all streams because TCP delivers in order.

HTTP/3 moves off TCP onto QUIC, which runs over UDP and handles streams independently, so one lost packet only blocks its own stream, not the others. QUIC also folds the TLS handshake into the connection setup, cutting round trips. The through-line is each version attacking head-of-line blocking at a lower layer.

A load balancer spreads incoming traffic across a pool of backend servers and removes unhealthy ones via health checks, so no single server is overwhelmed and one failure doesn't take the service down. It's the front door that makes horizontal scaling and zero-downtime deploys possible.

Layer 4 load balancing routes by IP and port without inspecting the payload, so it's fast and protocol-agnostic. Layer 7 load balancing understands the application protocol (HTTP), so it can route by URL path, host, or headers, terminate TLS, and do content-based decisions, at the cost of more processing per request.

A CDN (Content Delivery Network) is a fleet of servers spread across many locations that cache and serve content close to users. When someone requests an asset, they're routed to a nearby edge server instead of the distant origin, which cuts latency and offloads traffic from the origin.

It solves latency (physics: closer is faster), scale (the edge absorbs traffic spikes so the origin doesn't melt), and availability (content stays served even if the origin is busy). CDNs handle static assets well and increasingly cache dynamic content and run logic at the edge. The hard parts are cache invalidation and keeping cached content fresh.

A firewall controls traffic by matching packets against rules and allowing or dropping them, based on things like source and destination IP, port, and protocol. It's the boundary control between networks of different trust levels.

A stateless firewall evaluates each packet in isolation against its rules, with no memory of prior packets. A stateful firewall tracks active connections, so it can allow return traffic for a connection it already permitted without a separate rule, which is both more convenient and more secure. Modern next-generation firewalls add application-aware inspection on top.

A VPN (Virtual Private Network) creates an encrypted tunnel between a client and a VPN server over the public internet. Traffic inside the tunnel is encrypted and encapsulated, so anyone on the path sees only the outer packets to the VPN server, not the actual destinations or contents.

It's used to reach a private network remotely as if you were local (site-to-site or remote-access) and to shield traffic on untrusted networks. The trade-offs are the extra latency of routing through the VPN server and the trust you place in whoever runs it, since they can see your decrypted traffic at the exit.

The everyday set: A maps a name to an IPv4 address, AAAA to an IPv6 address, and CNAME aliases one name to another. MX names the mail servers for a domain, TXT holds arbitrary text often used for verification and email security (SPF, DKIM), and NS delegates a zone to its authoritative name servers.

Knowing these matters for real work: a misconfigured MX breaks email, a wrong CNAME or missing AAAA breaks reachability, and TXT records are where SPF, DKIM, and domain verification live. Each record also carries a TTL controlling how long resolvers cache it.

The recurring ones: a DDoS floods a target with traffic to exhaust its capacity, a man-in-the-middle intercepts traffic between two parties, DNS spoofing feeds a resolver false answers, and ARP spoofing poisons a local network's IP-to-MAC mapping to redirect traffic.

Defenses layer up: TLS everywhere defeats passive interception and detects tampering, DNSSEC signs DNS answers to block spoofing, rate limiting and upstream scrubbing absorb DDoS, and network segmentation plus monitoring limit the blast radius of a local attack. The principle is defense in depth, because any single control can be bypassed.

QUIC is a transport protocol built on UDP that underpins HTTP/3. It provides reliable, multiplexed, encrypted streams, essentially reimplementing TCP's reliability plus TLS's security in user space on top of UDP, which lets it evolve without waiting on operating-system kernel changes.

It was created to fix TCP's limits for the modern web: TCP's in-order delivery causes head-of-line blocking across independent streams, and its handshake plus a separate TLS handshake costs round trips. QUIC handles streams independently so one lost packet doesn't stall the rest, and it folds encryption into connection setup, cutting startup latency, with connection migration that survives a network change like Wi-Fi to cellular.

Start by cutting distance and round trips, because those dominate. Put content close to users with a CDN or edge nodes, reuse connections instead of opening new ones per request, and reduce the number of round trips (connection reuse, HTTP/2 or HTTP/3, TLS session resumption). Distance is bounded by the speed of light, so serving from nearby is the biggest lever.

Then trim the rest: compress responses, cache aggressively with sensible invalidation, batch small requests, and move work closer to the user or precompute it. Measure with real percentiles (p95, p99), not averages, because tail latency is what users actually feel, and one slow dependency or an extra handshake round trip is often the culprit.

A socket is the programming interface to the transport layer. A TCP server creates a socket, binds it to an address and port, listens, and accepts incoming connections, each accept returning a new socket for that client. The client creates a socket and connects to the server's address and port, then both read and write bytes over their sockets.

The key mental model is that a TCP connection is a byte stream, not messages, so the application must frame its own messages (length prefixes or delimiters) because reads can return partial or coalesced data. UDP sockets skip the connection setup and send discrete datagrams instead, which is why UDP code looks simpler but shifts reliability onto the application.

Clarify first: what protocol, are connections long-lived (like websockets) or short, what's the read/write pattern, and what latency does the business need. Then lay out the shape: stateless application servers behind load balancers so you scale horizontally, with connection state pushed into shared stores so any server can handle any request. For huge connection counts, use event-driven, non-blocking I/O (epoll-style) so one server holds many connections without a thread each.

Then handle the parts that don't scale by adding boxes: use a CDN and edge termination to keep long-haul traffic down, shard or replicate the data tier, add caching for hot reads, and spread across availability zones and regions for resilience. The structure that scores is clarify, scale stateless horizontally, offload state and connections, protect the data tier, each choice justified by the requirements you asked for.

Plain HTTP is request-response: the client asks, the server answers, and the connection is done. That's a poor fit for real-time updates, because the client has to keep polling to ask 'anything new yet?'. WebSockets fix that with a single long-lived, full-duplex connection where either side can send a message any time.

The connection starts as an HTTP request with an Upgrade header, then switches protocols and stays open. Reach for WebSockets when you need low-latency two-way updates: chat, live dashboards, collaborative editing, multiplayer games. For occasional server-to-client updates only, Server-Sent Events are a simpler one-way alternative.

Work up the stack so you isolate the layer instead of guessing. First confirm local connectivity: does the machine have a valid IP and can it reach its gateway. Then test DNS with nslookup or dig, because a name that won't resolve looks identical to a dead server from the browser.

If the name resolves, ping the IP and run traceroute to see whether packets reach the server and where they stop. Then test the application directly with curl to check the port, the TLS handshake, and the HTTP status code. Each step rules out one layer, so by the end you've located the fault rather than swapping parts at random.