Computer Networks

DNS resolves the name to an address, TCP connects, TLS negotiates if it is HTTPS, an HTTP request goes out, the response comes back, and the browser renders it.

The steps worth naming: the browser checks its own and the OS cache before asking a resolver; the TCP handshake is three packets; TLS adds its own round trips; the server replies with a status and a body; then the browser parses HTML, discovers CSS and JavaScript, and fetches those too. Each of those is a place latency comes from.

What it is really testing. Breadth and ordering. This is the single most-asked networking question because it lets the interviewer follow up on whichever step they care about.

TCP guarantees delivery and order at the cost of latency; UDP just sends and lets you deal with loss.

TCP sets up a connection, numbers its packets, acknowledges them and retransmits what goes missing. For a file, that is exactly right. For a live call, retransmitting a packet from two seconds ago is worse than losing it, which is why voice, video and games use UDP - and often rebuild a little reliability on top.

What it is really testing. Whether you can name a case where guaranteed delivery is wrong. "TCP is reliable so it is better" is the answer the question is designed to catch.

SYN from the client, SYN-ACK from the server, ACK from the client - and only then does data flow.

It exists so both sides agree they can hear each other and exchange starting sequence numbers. The practical consequence is a full round trip before any data moves, and HTTPS adds more for TLS - which is why connection reuse and keep-alive matter so much on a page that fetches thirty files.

What it is really testing. Whether you know it costs a round trip. The three packet names are easy; the latency consequence is the useful part.

Turns a name into an IP address, through a chain of caches and servers.

Browser cache, then OS cache, then your configured resolver, then - if nobody knows - the root servers, the top-level domain servers and finally the domain's own authoritative server. Results are cached for the TTL, which is why a DNS change does not take effect everywhere at once.

What it is really testing. Whether you understand TTL and caching. "I changed the record and it still goes to the old server" is a real support ticket, and this is its answer.

Encryption, integrity and server identity, through TLS.

All three matter and people usually name only the first. Encryption stops reading, integrity stops silent tampering in transit, and the certificate is what tells you the server really is the one the name claims. Without that last one, encryption alone would just mean a private conversation with an impostor.

What it is really testing. Whether you name identity. The certificate half is what makes the whole thing work, and it is the half most candidates leave out.

2xx worked, 3xx go somewhere else, 4xx the client got it wrong, 5xx the server broke.

Have a few specifics ready: 301 permanent and 302 temporary, which matters for SEO and for caching; 401 means not authenticated and 403 means authenticated but not allowed; 404 missing; 500 an unhandled error; 502 and 504 a bad gateway or timeout, meaning the problem is behind a proxy.

What it is really testing. The 401 versus 403 distinction, and 301 versus 302. Those two pairs are where the follow-up almost always goes.

Physical, data link, network, transport, session, presentation, application.

The practical use is placing a fault: a cable is layer 1, a MAC address is layer 2, an IP address and routing are layer 3, TCP and ports are layer 4, and HTTP is layer 7. Real stacks follow the simpler four-layer TCP/IP model, and saying so is a good sign rather than a bad one.

What it is really testing. Whether you can place a protocol on a layer. The recital is worth little; "that is a layer 4 problem, not a layer 7 one" is worth a lot.

A MAC address identifies a network card on the local link; an IP address identifies a host on the wider network and is what routing uses.

The MAC is assigned by the manufacturer and never leaves the local segment - every hop rewrites it. The IP stays the same end to end, which is what makes routing possible. ARP is the translation between them, and knowing its name is usually enough.

What it is really testing. Whether you know the MAC does not survive a hop. That single fact shows you understand what routing is doing.

A router rewriting private addresses to one public address, so many devices can share it.

It is the reason your laptop has a 192.168 address and the internet sees your router's. The router keeps a table of which internal connection each outgoing port belongs to, so replies get back to the right machine. The consequence is that inbound connections do not work without port forwarding.

What it is really testing. Whether you know why incoming connections fail. That is the problem NAT actually causes people, and the reason the question is asked.

GET asks for something and should change nothing; POST submits something and is expected to change state.

Because GET is meant to be safe and idempotent, it gets cached, logged with its query string, bookmarked and prefetched. Putting a delete behind a GET is how a crawler wipes your data. POST is none of those things, which is also why the browser warns before re-submitting one.

What it is really testing. Whether you say idempotent, and whether you can name the crawler disaster. "POST hides the parameters" is the weak answer - it is not a security feature.

One end of a connection, identified by an IP address and a port.

A connection is really a pair of them, and the four values - source address, source port, destination address, destination port - are what make it unique. That is how one server on port 443 keeps thousands of simultaneous clients apart: the client port differs each time.

What it is really testing. Whether you can explain how one port serves many clients. It is a common misconception that a port can only hold one connection.

Latency is how long one thing takes to arrive; bandwidth is how much can arrive per second.

They are independent, and confusing them wastes money. A satellite link can have enormous bandwidth and terrible latency. Adding bandwidth does nothing for a page that makes forty sequential requests - that is a latency problem, fixed by making fewer round trips, not by a bigger pipe.

What it is really testing. Whether you know which one a slow web page usually suffers from. It is nearly always latency, and nearly always answered as bandwidth.