Computer Networks Interview Questions

"From the bottom, OSI has physical, which is the signal on the wire or radio, then data link, which moves frames between machines on the same network using MAC addresses, like Ethernet or Wi-Fi. Network is IP and routing between networks. Transport is TCP and UDP, which give you ports and, for TCP, reliability. Then session, presentation and application on top. The TCP/IP model is simpler: link, internet, transport and application. It folds session and presentation into the application layer, because in practice things like encryption and session handling live inside the application or a library like TLS. I mostly use the layers when debugging. If I can ping a server but the web page fails, layers one to three are fine and I look at transport or application instead."

"A hub is the simplest. It works at layer one and just repeats whatever comes in on one port out of every other port, so everyone sees everything and collisions are common. A switch works at layer two. It watches the source MAC address of each frame and builds a table of which address is on which port, so it can send a frame only to the right port. If it doesn't know the destination yet, it floods the frame, and broadcasts still go everywhere. A router works at layer three. It connects separate networks, looks at the destination IP address, checks its routing table and sends the packet towards the next hop. That's also where broadcasts stop, so a router splits a network into separate broadcast domains."

"TCP sets up a connection first, numbers every byte, acknowledges what arrives and resends what's lost, so the application gets a reliable, in-order stream. It also slows down when the receiver or the network is overloaded. UDP just sends independent datagrams. There's no handshake, no retransmission and no ordering, so it's lighter, but the application has to cope with loss itself. The way I decide is to ask whether late data is still useful. For a file download, a web page or a database query, every byte matters, so TCP. For a voice or video call, or a multiplayer game, a packet that arrives half a second late is useless, so UDP is better and the app just carries on. DNS lookups use UDP too, because a tiny question and answer doesn't need a connection."

"The client sends a SYN carrying a starting sequence number, say X. The server replies with a SYN-ACK: it acknowledges X plus one, and it sends its own starting number, Y. Then the client sends an ACK for Y plus one, and the connection is open in both directions. The reason it's three and not two is that TCP is two independent byte streams, one each way, and each side needs to choose a sequence number and know the other side got it. With only two messages, the server would never learn whether the client received its number. The third step also protects against an old, delayed SYN from a previous connection turning up and making the server open a connection nobody wants, because the client doesn't recognise it and answers with a reset instead of a confirmation."

"Closing is usually four segments, because each direction shuts separately. One side sends a FIN, the other acknowledges it, and when that side is also done it sends its own FIN, which gets acknowledged too. The side that sent the first FIN then sits in TIME_WAIT for twice the maximum segment lifetime. That wait is on purpose: if the final ACK got lost, the other side will resend its FIN and we can answer, and any stray packets from the old connection expire before the same address and port pair gets reused. You see thousands of them when something opens a new connection per request and closes it straight away, which can use up ephemeral ports on a client. The fix is usually connection reuse through keep-alive or a pool. If I see lots of CLOSE_WAIT instead, that's different: it means our application got the FIN but never closed its socket, which is a bug in our code."

"Flow control is about the receiver. Every ACK carries a receive window, which says how much more data the receiver can buffer right now. If the application on the other end is slow to read, that window shrinks, even to zero, and the sender has to wait. Congestion control is about the network in between. The receiver might have plenty of room, but a router along the path might be overloaded. So the sender keeps its own congestion window. It starts small and roughly doubles each round trip in slow start, then after a threshold grows slowly, and when it sees loss it cuts the window back. The amount in flight at any moment is the smaller of the two windows. So one guards the other machine, the other guards everyone sharing the path."

"It starts with sequence numbers. TCP numbers every byte it sends, so the receiver always knows where a segment belongs. If segments arrive out of order, it holds them in a buffer and only hands data to the application once the gap is filled. Duplicates are easy to spot and throw away. The receiver sends acknowledgements saying the next byte it's expecting, and those are cumulative. On the sender side, anything not acknowledged within a timeout gets sent again. There's also a faster path: if the sender gets three duplicate ACKs for the same number, it assumes that one segment was lost and resends it without waiting for the timer. And every segment carries a checksum, so a corrupted one is just dropped and handled like any other loss."

"The port only says which service on the machine should get the traffic. The server has one listening socket bound to port 443. Each time a client connects, accept hands back a brand new socket just for that connection, and they all share local port 443. What makes each one unique is the full tuple: the protocol, the client's IP and port, and the server's IP and port. The client's side uses an ephemeral port that its operating system picks, so even two browser tabs on the same laptop come in on different source ports and look like different connections. That's why the limit on connections to a server is really memory and file descriptors, not the number of ports."

"In my final-year project I built a small chat app with a Python server and several clients talking over raw TCP sockets. It worked perfectly on my laptop, but when we tested across the college network, messages sometimes arrived glued together, or one message came in two pieces. That surprised me, because I thought each send would arrive as one receive. That's when I really understood that TCP is a byte stream, not a message stream. It guarantees the bytes arrive in order, but not where one message ends. I fixed it by adding framing: every message started with a four-byte length, and the receiver read exactly that many bytes before handling it. After that it was solid. It also made me appreciate why protocols like HTTP spend so much effort defining where a message starts and stops."

"I'd start by asking what latency we measured and where it goes, because the answer usually isn't TCP itself. Inside a data centre, a round trip is tiny, and if we reuse connections through keep-alive or a pool, the handshake cost mostly disappears. The time normally goes to serialisation, queueing or the database. Then I'd lay out the cost. Our calls need every byte, in order, so with UDP we'd have to rebuild acknowledgements, retransmission, ordering and congestion control ourselves, and a home-made version is usually slower and buggier than TCP under load. I'd suggest we first measure, then try connection reuse and fewer round trips. If there's a real case, like streaming metrics where losing a sample is fine, UDP makes sense for that path. And if head-of-line blocking is the actual problem, a protocol like QUIC gives most of the benefit without inventing our own."

"An IPv4 address is 32 bits, written as four numbers from zero to 255. The slash number says how many of those bits belong to the network. So 10.20.0.0/16 means the first 16 bits, 10.20, are fixed and the last 16 bits are for hosts, which gives 65,536 addresses, from 10.20.0.0 to 10.20.255.255. The private ranges are 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. Anyone can use them inside their own network and they aren't routed on the public internet. They exist because there were never enough public IPv4 addresses for every device, so homes and companies use private addresses inside and share a few public ones through NAT at the edge."

"A /26 means 26 network bits, so 24 of them fill the first three octets and two more bits go into the last octet. Two bits in the last octet is 128 plus 64, so the mask is 255.255.255.192. The quickest trick is block size: 256 minus 192 is 64, so this network is split into blocks starting at 0, 64, 128 and 192. The host's last octet is 77, which sits in the block from 64 to 127. So the network address is 192.168.10.64, the broadcast is 192.168.10.127, and the usable hosts run from .65 to .126. That's 64 addresses in the block minus the network and broadcast, so 62 usable hosts."

"I'd treat an IPv4 address as a single 32-bit number. First I split the dotted string into four parts and shift them into one integer, so the first octet sits in the top eight bits. For the CIDR block I split off the prefix length and build a mask with that many ones at the top, which is all ones shifted left by 32 minus the prefix, cut back to 32 bits. Then the check is one line: the address ANDed with the mask must equal the network ANDed with the mask. I'd test the edges. A /32 must only match the exact address, and a /0 must match everything, which works here because shifting by 32 and masking gives zero. In real code I'd validate each octet is between zero and 255, or just use the standard ipaddress module."

"The address is 128 bits written in hex groups, and the space is so big that every device can have a globally unique address, so NAT isn't needed to save addresses. That changes security thinking, because the firewall has to do the job NAT was doing by accident. There's no broadcast in IPv6. Finding a neighbour's MAC address uses Neighbor Discovery over multicast instead of ARP. Hosts can build their own address from the prefix the router advertises, which is called stateless autoconfiguration, or use DHCPv6. The header is a simpler fixed size with optional extension headers, it drops the header checksum, and routers no longer fragment packets; the sender has to discover the path MTU and size packets itself. In practice most networks run both stacks side by side for a long time."

"First the browser checks its own cache, then the operating system checks its cache and the hosts file. If there's nothing, the laptop sends one query to its configured recursive resolver, usually run by the network or a public DNS provider, and says, please give me the final answer. If that resolver doesn't have it cached, it does the walking. It asks a root server, which doesn't know the address but says, here are the servers for .com. It asks a .com server, which says, here are the authoritative name servers for example.com. Then it asks one of those, which returns the A record for shop.example.com, or AAAA for IPv6. The resolver sends that back to my laptop and caches it for the record's TTL, so the next person asking gets it straight away."

"The browser parses the URL: scheme https, host example.com, default port 443, path slash. It needs an IP, so it checks its caches and then asks DNS. To send anything off my network, my laptop needs the router's MAC address, which it gets through ARP if it isn't cached. Then it opens a TCP connection to port 443 with the three-way handshake, and on top of that runs a TLS handshake to agree keys and check the server's certificate. Now it sends an encrypted HTTP GET with a Host header. That request might hit a CDN edge or a load balancer first, which passes it to an application server, and the response comes back as HTML. The browser parses it, finds CSS, scripts and images, fetches those, usually reusing the same connection, then builds the page and paints it. If the site supports HTTP/3, the connection runs over QUIC on UDP instead."

"HTTP/1.1 keeps connections alive, but on one connection you effectively send one request and wait for its response before the next, so a slow response blocks everything behind it. Browsers work around that by opening several connections per host. HTTP/2 made the protocol binary and split it into streams, so many requests and responses can be interleaved on a single TCP connection, and it compresses headers, which repeat a lot. The problem it couldn't fix is at the TCP layer. TCP delivers bytes strictly in order, so if one packet is lost, every stream on that connection waits for the retransmission, even streams whose data already arrived. HTTP/3 solves that by running over QUIC, which sits on UDP and does its own reliability per stream, so a loss only stalls the stream it belongs to. QUIC also builds TLS 1.3 into its handshake, so setup is faster."

"That's DNS caching doing exactly what it's designed to do. Every resolver that looked up the old record keeps it until its TTL runs out, and if the TTL was a day, some users will see the old server for a day. Some applications and devices also cache lookups on their own and hold them longer. First I'd check the change itself is right by querying our authoritative name servers directly with dig, so I know it isn't a mistake on our side. Then I'd make sure nobody is harmed during the overlap. I'd keep the old server running and have it forward or proxy requests to the new one, especially anything that writes data, so users on the old address still get the right result. I'd watch the old server's traffic and switch it off only when it has dropped to nothing. For next time, I'd lower the TTL a day or two before the move, then raise it again afterwards."

"HTTPS is just HTTP running inside a TLS connection, normally on port 443. TLS gives three things. Confidentiality: everything, including the path, headers, cookies and body, is encrypted, so someone on the same Wi-Fi or an ISP in the middle can't read it. Integrity: every record is protected so any change in transit is detected and the connection fails. And authentication: the server shows a certificate for the domain signed by a trusted authority, so I know I'm talking to the real site and not an attacker in the middle. What it doesn't protect is also worth saying. An observer still sees which IP address I'm talking to and roughly how much data moves, and HTTPS says nothing about whether the site itself is honest or has bugs. A phishing site can have a perfectly valid certificate."

"In TLS 1.3, the client sends a ClientHello with the versions and cipher suites it supports and a Diffie-Hellman key share. The server picks the settings and replies with its own key share. From those two shares, both sides compute the same secret without ever sending it, and derive session keys. Because those key shares are fresh for every connection, stealing the server's private key later doesn't unlock old traffic, which is forward secrecy. Then the server sends its certificate and a signature over the handshake made with its private key. The browser checks that the certificate chains up to a trusted root, matches the domain and hasn't expired, and verifies the signature, which proves the server holds the private key. Both send Finished messages, and from then on data uses symmetric encryption like AES-GCM, because it's far faster than public-key crypto. TLS 1.2 took two round trips for this; 1.3 takes one."

"The laptop first compares the destination with its own address and subnet mask. For 192.168.1.20, it's on my subnet, so I can deliver directly, but Ethernet and Wi-Fi need a MAC address. So the laptop checks its ARP cache, and if it's empty it broadcasts an ARP request: who has 192.168.1.20, tell me. The machine with that IP replies directly with its MAC, the laptop caches it for a while, and sends the frame. For 8.8.8.8, the mask says it's not local, so I don't ARP for 8.8.8.8 at all. I ARP for my default gateway's IP instead, and send the frame to the router's MAC. The IP header still says 8.8.8.8 as the destination. At each hop, the MAC addresses change but the IP addresses stay the same, apart from NAT."

"That's DHCP, and the four steps are usually remembered as DORA. The phone has no IP yet, so it broadcasts a Discover message asking for any DHCP server. A server, often the router or a central server, replies with an Offer: an address it's willing to lend, plus settings. The phone then broadcasts a Request for that specific offer. It's a broadcast so that any other server that made an offer knows it wasn't picked. Finally the server sends an Acknowledge, and the phone configures itself. Besides the IP address, it gets the subnet mask, the default gateway, the DNS servers and a lease time. The address is only lent, so the phone renews the lease before it runs out, and if it leaves, the address goes back into the pool."

"When my laptop at 192.168.1.10 opens a connection from port 50000, the home router rewrites the source to its public IP and picks a free public port, say 61000. It writes that mapping into a table. When the reply comes back to the public IP on port 61000, the router looks it up, rewrites the destination back to 192.168.1.10 port 50000, and forwards it. Using ports like this is what lets many devices share one address; strictly it's called PAT or NAPT. Now if someone on the internet sends a new connection to my public IP, there's no mapping for it, so the router has nowhere to send it and drops it. That's why you need port forwarding to host a server at home. Mappings also expire when a connection sits idle, which is why long-lived connections often send keepalives."

"The 10.1.0.0/16 route wins. The address matches all three, but a router always picks the longest matching prefix, because it's the most specific. The /8 would be used for something like 10.2.0.1, and the default route, 0.0.0.0/0, only catches what nothing else matches, usually meaning send it towards the internet. In general, when a packet arrives, the router reads the destination IP, does that lookup, and gets a next hop and an outgoing interface. It decrements the TTL, and if that hits zero it drops the packet and sends back an ICMP time exceeded message, which is exactly what traceroute relies on. Then it wraps the packet in a new frame for the next link. Routes get into the table by being directly connected, by someone adding them statically, or by a routing protocol like OSPF inside an organisation or BGP between networks on the internet."

"A layer 4 load balancer works on connections. It sees IPs and ports, picks a backend for each new TCP connection and passes the bytes through without understanding them. It's very fast and works for any protocol, but it can't route by URL, and every request on a long connection goes to the same backend. A layer 7 load balancer understands the application protocol, usually HTTP. It terminates the connection, often including TLS, reads each request, and can send slash api to one pool and slash images to another, add headers or retry a failed request elsewhere. It costs more CPU but gives far more control. For picking a backend, round robin and least connections are common, and hashing the client IP or a cookie gives stickiness. For health, it probes each backend on a schedule, like hitting a health endpoint, and after a few failures stops sending it traffic until it passes again."

"A CDN runs servers in many locations around the world. When a user asks for a file, the request goes to an edge near them instead of the origin. There are two common ways to get them there. With DNS steering, the site's hostname points to the CDN, and the CDN's DNS answers with an edge close to the user's resolver. With anycast, many locations announce the same IP address and internet routing naturally delivers the user to a nearby one. At the edge, if the file is cached, it's served straight away with a short round trip. If not, the edge fetches it from the origin once, then caches it for as long as the cache headers allow. The speed-up comes from shorter distance, reused warm connections back to the origin, and TLS finishing close to the user. The trade-off is freshness, so I prefer versioned file names for static assets over relying on purges."

"On a previous project our dashboard felt slow for users in other regions, even though the server logs said responses took a few milliseconds. I opened the browser's network waterfall from a test machine in one of those regions and saw that most of the time was connection setup, not the server: DNS, the TCP handshake and TLS, repeated for several different hostnames, each paying a long round trip to our only region. So I made two changes. We moved the static files behind a CDN, so they came from an edge close to the user, and we put the API behind the same hostname with keep-alive, so the browser reused one connection instead of opening new ones. Page load for those users dropped to roughly half, and we added the waterfall check to our release checklist so new third-party hosts didn't creep back in."

"Healthy servers plus one slow region tells me the problem is probably on the path, so I'd start by narrowing it. Is it every user there or only one internet provider? When did it start? Is it the whole page or only certain requests? Then I'd measure from that region, with real-user timing data if we have it, or a test machine or monitoring probe there, and break the time into DNS, connect, TLS and first byte. If DNS or the CDN is sending them to an edge on another continent, connect times will be high, and that's a configuration fix. If connect is fine but there's packet loss, a traceroute or mtr from there shows where on the path it starts, which often means a routing or peering change at a provider. While that's being fixed, I'd consider steering those users to a different edge or region, and I'd raise it with the CDN or network provider with the measurements attached."

"I work up the layers. First, ip addr, or ipconfig on Windows, to check I have a sensible address and gateway, then ping the gateway to confirm my local network works. Next, dig or nslookup on the hostname. If my answer differs from what colleagues get, it could be a stale cache, a hosts file entry or a different resolver, and that alone explains a lot. Then I test the path. Ping might be blocked by a firewall, so a failed ping isn't proof of anything, but traceroute shows where packets stop. To check the port itself, nc or telnet to port 443 tells me if a TCP connection opens. Finally curl with verbose output shows the TLS handshake, the certificate and the HTTP status. Whichever step first fails tells me which layer and who to talk to, whether that's my VPN, the DNS team or the service owners."

"At my last company, one service calling another would hang for about thirty seconds a few times a day, then fail with a timeout. It looked like the downstream service was freezing, but its logs showed the requests never arrived. I noticed the failures clustered on the first request after a quiet period. That pointed to idle connections. Our HTTP client kept pooled connections open indefinitely, but there was a firewall between the two networks that silently dropped idle connections after a set time. Our side still thought the connection was open, so the next request went into a dead connection and waited for the full timeout. I confirmed it with a packet capture showing retransmissions with no reply. The fix was to evict pooled connections before the firewall's idle limit and turn on TCP keepalive with an interval shorter than that limit. The hangs stopped completely, and I added the firewall's timeout to our service docs so the next team wouldn't rediscover it."