In this article
The layers and addressing
What are the layers of the Internet protocol model?
The Internet model splits the work of sending data into stacked layers. RFC 1122 (October 1989) specifies the requirements for hosts by protocol layer: the link layer, the Internet Protocol (IP) layer and the transport layer, with application protocols running above them. Interviewers often also ask for the Open Systems Interconnection (OSI) reference model (International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC) standard 7498-1, 1994), whose seven layers are, from one to seven: physical, data link, network, transport, session, presentation and application.
Why it is asked: it checks that you can place a protocol at a layer. Read the full explanation: RFC 1122.
What is the difference between TCP and UDP?
The Transmission Control Protocol (TCP) gives an ordered, reliable stream, and the User Datagram Protocol (UDP) sends single messages with no such promise. RFC 768 (August 1980) says that for UDP, delivery and duplicate protection are not assured, and that applications needing ordered reliable delivery of streams should use TCP. The UDP header is eight bytes, the minimum length RFC 768 allows.
Why it is asked: it is the standard test of transport-layer trade-offs. Read the full explanation: RFC 768.
Text description of the diagram
- Delivery and duplicate protection are not assured for UDP.
- A UDP header is eight bytes.
- TCP opens a connection with a three-way handshake.
What is a port number, and what are the well-known ports?
A port is a 16-bit number that, with the IP address, identifies one endpoint, so one host can run many services at once. RFC 6335 (August 2011) calls 0 to 1023 the System Ports, also known as the Well Known Ports; 1024 to 49151 are the User Ports and 49152 to 65535 the Dynamic Ports. Examples: 80 for the Hypertext Transfer Protocol (HTTP), 443 for HTTP Secure (HTTPS) (RFC 9110 sections 4.2.1 and 4.2.2), and 53 for the Domain Name System (DNS) (RFC 1035, November 1987).
Why it is asked: it tests whether you separate addressing a host from addressing a service. Read the full explanation: RFC 6335.
What is the difference between IPv4 and IPv6?
IPv6 widens addresses from 32 bits to 128 bits. RFC 8200 (July 2017) states the change directly. IPv4 has 4,294,967,296 possible addresses, and IPv6 has 2 to the power 128, about 3.4 times 10 to the power 381. IPv6 also requires every link to carry packets of at least 1280 octets, and only the source node fragments a packet.
Why it is asked: it separates address-space reasoning from memorised version trivia. Read the full explanation: RFC 8200.
What is a private IP address?
A private IP address is one reserved for use inside an organisation and not routed on the public Internet. RFC 1918 (February 1996) reserves three blocks: 10.0.0.0 to 10.255.255.255, 172.16.0.0 to 172.31.255.255 and 192.168.0.0 to 192.168.255.255. They hold 16,777,216, 1,048,576 and 65,536 addresses respectively1. Many hosts share one public address through network address translation.
Why it is asked: it leads naturally to network address translation. Read the full explanation: RFC 1918.
What is a subnet, and how many hosts fit in a /24 or a /26?
A subnet is a block of addresses sharing a prefix, written as an address and a prefix length in classless inter-domain routing (CIDR) notation (RFC 4632, August 2006, the current specification). Host bits = 32 minus the prefix; addresses = 2 to the power of the host bits; usable hosts = addresses minus 2 (network and broadcast). A /24 has 8 host bits: 256 addresses, 254 usable. A /26 has 6: 64 and 62. Blocks start at multiples of 64, so 192.168.1.77 falls in 192.168.1.64/26 (.64 to .127)1.
Why it is asked: it is the arithmetic every networking screen includes. Read the full explanation: RFC 4632.
Delivering packets on a local network
What is NAT, and why is it used?
Network address translation (NAT) rewrites addresses so that a private network can reach the outside through a few public ones. RFC 3022 (January 2001) describes Network Address Port Translation, which maps many private addresses and their TCP and UDP ports into one public address and its ports. It conserves addresses, and it breaks the end-to-end model because outsiders cannot open connections inward without extra configuration.
Why it is asked: it tests whether you know the cost as well as the benefit. Read the full explanation: RFC 3022.
What is ARP?
The Address Resolution Protocol (ARP) finds the hardware address that goes with an IP address on the same local network. RFC 826 (November 1982) defines a protocol for dynamically distributing the information needed to translate an address in a protocol's address space into a 48-bit Ethernet address. Hosts cache the answers so they do not ask for every packet.
Why it is asked: it checks the link between the data link layer (layer two) and the network layer (layer three). Read the full explanation: RFC 826.
How does DHCP give a device an address?
The Dynamic Host Configuration Protocol (DHCP) hands a joining device an address and settings through a four-message exchange. RFC 2131 (March 1997) defines eight message types, and the basic exchange uses four of the eight: DHCPDISCOVER, DHCPOFFER, DHCPREQUEST and DHCPACK (a DHCPNAK refuses the request). The client discovers servers, a server offers a configuration, the client requests one offer, and the server acknowledges it.
Why it is asked: it tests whether you know what happens before the first packet. Read the full explanation: RFC 2131.
What is the MTU, and what happens when a packet is larger?
The maximum transmission unit (MTU) is the largest packet a link carries; RFC 894 (April 1984) sets 1500 octets for Ethernet, leaving 1,460 TCP data bytes after minimum 20-byte IPv4 and TCP headers1. An IPv4 router may fragment an oversized packet (RFC 791), but if Don't Fragment is set it drops it and returns an Internet Control Message Protocol (ICMP) "fragmentation needed" message, which path MTU discovery uses (RFC 1191, November 1990). IPv6 routers never fragment: they drop it and send ICMPv6 Packet Too Big (RFC 8201, July 2017).
Why it is asked: it connects packet size to performance. Read the full explanation: RFC 894.
What does the time-to-live field do?
The time-to-live (TTL) field stops a packet from circulating forever. RFC 791 (September 1981) calls it an upper bound on how long an internet datagram may exist, set by the sender and reduced at the points along the route; when it reaches zero before delivery, the datagram is destroyed. A hop is one router the packet passes through. Route-tracing tools use this behaviour to discover each hop.
Why it is asked: it tests loop prevention. Read the full explanation: RFC 791.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →TCP in depth
How does the TCP three-way handshake work?
A TCP connection opens with three messages. RFC 9293 (August 2022) describes the exchange: the first peer sends a synchronise (SYN) message with an initial sequence number, the second replies with its own SYN and an acknowledgment of the first, and the first sends an acknowledgment of the second SYN. Only then does data flow.
Why it is asked: it is the most common transport question. Read the full explanation: RFC 9293.
What is TCP's time-wait state, and why does it exist?
Time-wait is the state in which the side that closed a connection first lingers before freeing it. RFC 9293 requires the wait to last twice the maximum segment lifespan (MSL), the longest time a segment may live in the network, and it takes the MSL to be 2 minutes, an engineering choice that may be changed, so the nominal wait is 4 minutes1. It lets late duplicate segments die out and makes sure the final acknowledgment arrives.
Why it is asked: it appears in debugging stories about exhausted ports. Read the full explanation: RFC 9293.
How does TCP flow control work?
Flow control keeps a fast sender from overrunning a slow receiver by advertising a receive window. In RFC 9293 the window field is 16 bits and tells the sender how many octets the receiver will accept, with window scaling to extend it. Throughput cannot exceed the window divided by the round-trip time. An unscaled window of 65,535 bytes at a 50-millisecond round trip gives 65,535 times 8 bits divided by the round-trip time of 50 milliseconds, near 10.49 megabits per second1.
Why it is asked: it links a header field to a performance ceiling. Read the full explanation: RFC 9293.
What is the difference between flow control and congestion control?
Flow control protects the receiver, while congestion control protects the network between the two. RFC 5681 (September 2009) defines TCP's four congestion control algorithms: slow start, congestion avoidance, fast retransmit and fast recovery. The sender limits its rate by both the receiver's window and its own estimate of what the path can carry.
Why it is asked: candidates often merge the two. Read the full explanation: RFC 5681.
Names, the web and security
What happens when you type a URL into a browser?
A secure web request over HTTP/1.1 or HTTP/2 passes through four protocols in order. A DNS lookup turns the host name into an IP address (zero round trips if cached), a TCP three-way handshake opens a connection (one round trip), a Transport Layer Security (TLS) 1.3 handshake secures it (one round trip), and HTTP carries the request and response (one round trip). HTTP/3 runs over QUIC (not an acronym), which carries the TLS 1.3 handshake inside its own, so connecting and securing take one round trip together.
Why it is asked: it is the classic end-to-end question and a test of breadth. Read the full explanation: RFC 1035, RFC 9001, RFC 9293, RFC 8446 and RFC 9110.
Step-by-step description
- DNS turns the name into an IP address.
- TCP opens a connection with three messages.
- TLS agrees keys and checks the server.
- HTTP sends the request and gets a response.
- DNS turns the name into an IP address.
- TCP opens the connection with a three-way handshake.
- TLS secures the connection before HTTP carries the request.
How does DNS resolve a name?
The Domain Name System (DNS) maps names to addresses through a hierarchy of name servers. RFC 1035 (November 1987) specifies port 53 over UDP, or TCP for larger messages. A recursive resolver walks the hierarchy: a root server points to the top-level domain (TLD) servers, which point to the domain's authoritative server. Each answer is cached for its time-to-live. A reply too big for UDP sets a truncation bit and the client retries over TCP; a DNS extension mechanism (RFC 6891, April 2013) raises the old 512-octet limit.
Why it is asked: it tests caching and the choice of transport. Read the full explanation: RFC 1035.
What is the difference between GET and POST, and what does idempotent mean?
GET asks for a representation and does not ask the server to change state; POST submits data for processing and may change state. RFC 9110 (June 2022) calls a method idempotent when several identical requests have the same effect on the server as one. PUT, DELETE and the safe methods (the read-only methods defined in RFC 9110) are idempotent. POST is not, which is why retrying a payment POST needs a deduplication key.
Why it is asked: it separates application programming interface (API) vocabulary from API design. Read the full explanation: RFC 9110.
What do the HTTP status code classes mean?
The first digit of an HTTP status code names its class. RFC 9110 defines 1xx as informational, 2xx as successful, 3xx as redirection, 4xx as client error and 5xx as server error. Most 4xx codes mean the request must change; 408 (RFC 9110 section 15.5.9) and 429 (RFC 6585, April 2012, too many requests) invite the same request again after a delay. A 5xx says the server failed and a retry may help.
Why it is asked: it checks that you can reason about retries. Read the full explanation: RFC 9110.
What does TLS provide?
Transport Layer Security (TLS) lets client and server applications communicate in a way designed to prevent eavesdropping, tampering and message forgery. That is the wording of the abstract of RFC 8446 (August 2018), which specifies version 1.3, obsoletes RFC 5246 (the TLS 1.2 specification) and adds requirements for TLS 1.2 implementations. Hypertext Transfer Protocol Secure (HTTPS) is HTTP carried over TLS. The server proves its identity with a certificate.
Why it is asked: it tests whether you can name the three protections. Read the full explanation: RFC 8446.
What is QUIC, and why does it run over UDP?
QUIC (RFC 9000, May 2021 says the name is not an acronym) is a multiplexed, secure transport protocol that carries its packets inside UDP datagrams. Many NATs and firewalls pass only TCP and UDP, so a new transport protocol would be blocked, while UDP traffic gets through. UDP also lets QUIC ship in user space, in an application's library, without waiting for operating-system kernels to change, while QUIC supplies its own reliability and protects its packets with keys from a TLS 1.3 handshake (RFC 9001, May 2021).
Why it is asked: it is the standard modern follow-up to a TCP question. Read the full explanation: RFC 9000.
Routing and troubleshooting
What is BGP?
The Border Gateway Protocol (BGP) is the routing protocol that connects independently run networks, called autonomous systems. RFC 4271 (January 2006) describes its primary function as exchanging network reachability information with other BGP systems. Because the information lists the autonomous systems a route crosses, routing loops can be pruned and policy applied.
Why it is asked: it separates internal from inter-network routing. Read the full explanation: RFC 4271.
What do ping and traceroute use?
Both use the Internet Control Message Protocol (ICMP). RFC 792 (September 1981) defines the Echo message, which a host answers with an Echo Reply, and that is what ping sends and waits for. It also defines the Time Exceeded message that a gateway may send to the source when it discards a datagram whose time-to-live reached zero. Traceroute sends packets with growing time-to-live values and reads each Time Exceeded reply to learn the router at each hop.
Why it is asked: it tests whether you understand the time-to-live field from the outside. Read the full explanation: RFC 792.
How to prepare with these questions
Be able to trace one request end to end, from name lookup to response, and to do subnet and window arithmetic by hand, as the entries above show. Practise explaining each protocol's cost and failure mode in two sentences. Then pair this page with coding interview questions, system design practice and the sibling list of computer networks interview questions, because networking shows up inside design questions.
Networking numbers worth memorising
The standards supply the inputs (prefix lengths, header sizes, window size and the 2-minute MSL); the results below were computed from them. The 50-millisecond round trip and the 1 gigabit per second link are illustrative inputs chosen for the example, not figures from a standard.
| Fact | Value |
|---|---|
| Addresses in a /24 and usable hosts | 256 and 254 |
| Addresses in a /26 and usable hosts | 64 and 62 |
| Addresses in 10.0.0.0/8 | 16,777,216 |
| Addresses in 172.16.0.0/12 | 1,048,576 |
| Addresses in 192.168.0.0/16 | 65,536 |
| TCP data per Ethernet frame, minimum headers | 1,460 bytes |
| Time-wait with a 2-minute MSL | 4 minutes |
| Throughput cap, 65,535-byte window, 50-millisecond round trip | 10.49 megabits per second |
| Window to fill an illustrative 1 gigabit per second link at 50 milliseconds | 6,250,000 bytes |
The last row is about 95 times the unscaled window, which is why window scaling exists1. Behavioural rounds in the same loop ask a different set of questions; behavioral interviews and questions to ask the interviewer cover them, and large language model (LLM) inference shows the same bandwidth-and-latency reasoning applied to model serving.
- Place every protocol at a layer, and say what it promises and what it costs.
- TCP gives ordered reliable delivery after a three-way handshake; UDP gives neither, and the newer transport of RFC 9000 builds its own rules on UDP.
- Subnet and window arithmetic is short and exact, so do it by hand.
- An HTTPS request over TCP is DNS, then TCP, then TLS, then HTTP; HTTP/3 runs over QUIC, which folds the TLS 1.3 handshake into its own.
- Idempotent methods are safe to retry; POST is not.
Sources
- RFC 9293: Transmission Control Protocol (TCP) — IETF (Eddy, ed.), 1 Aug 2022
- RFC 768: User Datagram Protocol — RFC Editor / Network Working Group (Postel), 28 Aug 1980
- RFC 791: Internet Protocol — RFC Editor / Network Working Group (Postel), 1 Sep 1981
- RFC 8200: Internet Protocol, Version 6 (IPv6) Specification — IETF (Deering and Hinden), 1 Jul 2017
- RFC 1122: Requirements for Internet Hosts, Communication Layers — IETF (Braden, ed.), 1 Oct 1989
- RFC 1918: Address Allocation for Private Internets — IETF (Rekhter et al.), 1 Feb 1996
- RFC 4632: Classless Inter-domain Routing (CIDR) — IETF (Fuller and Li), 1 Aug 2006
- RFC 3022: Traditional IP Network Address Translator — IETF (Srisuresh and Egevang), 1 Jan 2001
- RFC 826: An Ethernet Address Resolution Protocol — RFC Editor / Network Working Group (Plummer), 1 Nov 1982
- RFC 2131: Dynamic Host Configuration Protocol — IETF (Droms), 1 Mar 1997
- RFC 894: A Standard for the Transmission of IP Datagrams over Ethernet Networks — RFC Editor / Network Working Group (Hornig), 1 Apr 1984
- RFC 5681: TCP Congestion Control — IETF (Allman, Paxson, Blanton), 1 Sep 2009
- RFC 1035: Domain Names, Implementation and Specification — IETF (Mockapetris), 1 Nov 1987
- RFC 9110: HTTP Semantics — IETF (Fielding, Nottingham, Reschke, eds.), 1 Jun 2022
- RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3 — IETF (Rescorla), 1 Aug 2018
- RFC 9001: Using TLS to Secure QUIC — IETF (Thomson and Turner, eds.), 1 May 2021
- RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport — IETF (Iyengar and Thomson, eds.), 1 May 2021
- RFC 4271: A Border Gateway Protocol 4 (BGP-4) — IETF (Rekhter, Li, Hares, eds.), 1 Jan 2006
- RFC 1191: Path MTU Discovery — IETF (Mogul and Deering), 1 Nov 1990
- RFC 8201: Path MTU Discovery for IP version 6 — IETF (McCann, Deering, Mogul, Hinden, eds.), 1 Jul 2017
- RFC 6585: Additional HTTP Status Codes — IETF (Nottingham and Fielding), 1 Apr 2012
- RFC 5246: TLS Protocol Version 1.2 — IETF (Dierks and Rescorla), 1 Aug 2008
- RFC 6891: Extension Mechanisms for DNS (EDNS(0)) — IETF (Damas, Graff, Vixie), 1 Apr 2013
- RFC 792: Internet Control Message Protocol — RFC Editor / Network Working Group (Postel), 1 Sep 1981
- ISO/IEC 7498-1:1994 Open Systems Interconnection, Basic Reference Model — ISO/IEC, 15 Nov 1994
- RFC 6335: Service Name and Transport Protocol Port Number Registry Procedures — IETF (Cotton et al.), 1 Aug 2011
