| OSI model | 7 layers: Physical, Data Link, Network, Transport, Session, Presentation, Application |
| TCP handshake | 3-way: SYN → SYN-ACK → ACK, then data flows |
| Common ports | HTTP 80, HTTPS 443, SSH 22, DNS 53, MySQL 3306, PostgreSQL 5432, Redis 6379 |
| Private IP ranges (RFC 1918) | 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 |
| Ethernet MTU | 1500 bytes payload (standard); jumbo frames up to ~9000 bytes |
| Loopback address | 127.0.0.1 (IPv4), ::1 (IPv6) — always routes to the local host |
| /24 subnet | 256 total addresses, 254 usable hosts (network + broadcast reserved) |
| TCP vs UDP | TCP: reliable, ordered, connection-oriented. UDP: fast, connectionless, no delivery guarantee |
Computer Networks Interview Questions & Answers
Q1. What is the OSI model and why was it created?
A: The OSI (Open Systems Interconnection) model is a conceptual seven-layer framework that standardizes how network communication is broken into independent responsibilities, from raw signaling up to application data. It was created so vendors could build interoperable hardware and software without each layer needing to know the internals of the others. In practice, engineers use it as a shared vocabulary for troubleshooting ("is this a Layer 2 or Layer 3 problem?") more than as a literal implementation blueprint.
Q2. What are the seven OSI layers, from bottom to top?
A: 1) Physical — raw bits over cables/radio; 2) Data Link — framing and MAC addressing on a local segment; 3) Network — logical addressing (IP) and routing between networks; 4) Transport — end-to-end delivery, ports, TCP/UDP; 5) Session — establishing and managing communication sessions; 6) Presentation — data translation, encryption, compression; 7) Application — the protocols applications actually speak, like HTTP and DNS. A common mnemonic is "Please Do Not Throw Sausage Pizza Away."
Q3. What is the TCP/IP model and how many layers does it have?
A: The TCP/IP (or Internet Protocol Suite) model is the practical, four-layer model the real internet is built on: Link, Internet, Transport, and Application. It merges OSI's Session, Presentation, and Application layers into a single Application layer, and its Link layer covers OSI's Physical and Data Link together. Unlike OSI, TCP/IP was designed from working protocols rather than as a theoretical standard first, which is why it is the model actual implementations follow.
Q4. How does the TCP/IP model map onto the OSI model?
A: TCP/IP's Application layer covers OSI layers 5-7 (Session, Presentation, Application); TCP/IP's Transport layer maps directly to OSI layer 4; TCP/IP's Internet layer maps to OSI layer 3 (Network); and TCP/IP's Link layer covers OSI layers 1-2 (Physical and Data Link). Interviewers often ask this mapping to confirm you understand that OSI is a teaching/reference model while TCP/IP is the model actually implemented in every network stack.
Q5. What happens at the Physical layer (Layer 1)?
A: The Physical layer defines how raw bits are transmitted as electrical signals, light pulses, or radio waves across a physical medium — copper cable, fiber, or wireless spectrum. It covers connectors, voltage levels, pin layouts, and bit-rate timing, with no concept of addressing or meaning; it just moves 0s and 1s. Devices operating purely at this layer include hubs, repeaters, and cables themselves.
Q6. What is the Data Link layer (Layer 2) responsible for?
A: The Data Link layer packages bits into frames, adds source and destination MAC (hardware) addresses, and handles error detection (via frame check sequences) and media access control on a local network segment. It is split conceptually into the LLC (Logical Link Control) and MAC (Media Access Control) sublayers. Switches operate at this layer, forwarding frames based on MAC addresses rather than IP addresses.
Q7. What is the Network layer (Layer 3) responsible for?
A: The Network layer handles logical addressing (IP addresses) and routing — determining the best path for a packet to travel from source to destination across multiple interconnected networks. Routers operate here, using routing tables to forward packets hop by hop. Protocols like IP, ICMP, and OSPF live at this layer.
Q8. What is the Transport layer (Layer 4) responsible for?
A: The Transport layer provides end-to-end communication between processes on different hosts, using port numbers to distinguish applications. TCP adds reliability, ordering, and flow/congestion control on top of the Network layer's best-effort delivery; UDP simply adds ports and an optional checksum without reliability guarantees. This is the layer where a backend developer's mental model of "a connection" really lives.
Q9. What do the Session, Presentation, and Application layers (5-7) do, and why are they merged in TCP/IP?
A: The Session layer manages establishing, maintaining, and tearing down a logical communication session between two endpoints; the Presentation layer translates data formats, handles encryption (like TLS) and compression; the Application layer is where user-facing protocols like HTTP, SMTP, and DNS operate. TCP/IP merges all three into one Application layer because, in practice, sockets and libraries (or the application protocol itself, like TLS-over-TCP) handle session and presentation concerns rather than the operating system's network stack enforcing separate layers.
Q10. What is encapsulation and decapsulation in networking?
A: Encapsulation is the process of wrapping data with a header (and sometimes a trailer) as it moves down the layers on the sending side — application data becomes a TCP segment, which becomes an IP packet, which becomes an Ethernet frame, which becomes bits. Decapsulation is the reverse on the receiving side: each layer strips its own header and passes the payload up to the next layer. This layered wrapping/unwrapping is what lets each layer stay ignorant of the layers above and below it.
Q11. What is a PDU (Protocol Data Unit), and how does its name change per layer?
A: A PDU is the unit of data at a given layer, and it's renamed as it's encapsulated: at the Transport layer it's a "segment" (TCP) or "datagram" (UDP); at the Network layer it's a "packet"; at the Data Link layer it's a "frame"; at the Physical layer it's just "bits." Knowing this vocabulary lets you precisely say "the router drops the packet" versus "the switch drops the frame" instead of using "packet" generically for everything.
Application data
-> [TCP header | data] Segment (Transport)
-> [IP header | TCP segment] Packet (Network)
-> [Ethernet header | IP packet | FCS] Frame (Data Link)
-> 0101100111000... Bits (Physical)Q12. Why does a backend developer need to understand the OSI model when debugging production issues?
A: Symptoms map to specific layers: a cable unplugged or NIC down is Layer 1; a duplicate MAC or VLAN misconfiguration is Layer 2; "no route to host" or a bad security group is Layer 3; "connection refused" versus a hung socket is Layer 4; a 502 from a reverse proxy versus a malformed JSON body is Layer 7. Isolating which layer a fault sits at (using tools like ping, traceroute, curl, and tcpdump in that order) is far faster than guessing at the application code first.
Q13. What is the difference between a switch and a router?
A: A switch operates at Layer 2, forwarding frames within a single local network based on MAC addresses; it connects devices on the same broadcast domain. A router operates at Layer 3, forwarding packets between different networks based on IP addresses, and it is what connects your LAN to the internet or connects separate subnets. Most modern "Layer 3 switches" blur this by doing both jobs in one device, but conceptually the distinction is local switching versus inter-network routing.
Q14. What is a hub, and why is it considered obsolete compared to a switch?
A: A hub is a dumb Layer 1 device that repeats every incoming electrical signal out to all other ports, with no awareness of addresses — every device on a hub shares one collision domain and one bandwidth pool. A switch instead learns which MAC address lives on which port and forwards frames only to the relevant port, giving each connection its own effective bandwidth and eliminating unnecessary collisions. Hubs have essentially disappeared from production networks in favor of switches.
Q15. How does a switch learn MAC addresses (the MAC address / CAM table)?
A: When a frame arrives, the switch records the source MAC address and the port it arrived on in its MAC address table (also called a CAM table). For outbound frames, it looks up the destination MAC in that table and forwards only to the matching port; if the destination is unknown, it floods the frame out every port except the one it arrived on (an "unknown unicast flood"). This self-learning behavior means switches require no manual configuration to build efficient forwarding.
Q16. What is the difference between a broadcast domain and a collision domain?
A: A collision domain is a set of devices where simultaneous transmissions can collide — each switch port is its own collision domain on modern full-duplex networks, effectively eliminating collisions. A broadcast domain is a set of devices that all receive a Layer 2 broadcast frame (destination MAC FF:FF:FF:FF:FF:FF) — a switch does not break up a broadcast domain, but a router (or VLAN boundary) does. This is why large flat Layer 2 networks eventually need segmentation to avoid broadcast storms.
Q17. What is a VLAN and why do engineers segment networks with it?
A: A VLAN (Virtual LAN) logically partitions a single physical switch infrastructure into multiple isolated broadcast domains, as if they were separate physical networks, using tags (802.1Q) on frames to identify which VLAN they belong to. Teams use VLANs to isolate traffic by function or security tier (e.g., a database VLAN separate from a public-facing web VLAN) without needing separate physical switches, reducing broadcast traffic and improving security boundaries.
Q18. What is the difference between Layer 2 switching and Layer 3 switching?
A: Layer 2 switching forwards frames purely based on MAC addresses within the same subnet/VLAN — fast, hardware-based, but limited to one broadcast domain. Layer 3 switching adds IP-aware forwarding (inter-VLAN routing) directly in switch hardware using application-specific chips, letting a single device route between VLANs at near wire speed instead of sending that traffic out to a separate router. Data centers commonly use Layer 3 switches as the backbone precisely to avoid a router becoming a bottleneck.
Q19. How does a router determine the next hop for a packet?
A: A router consults its routing table and applies longest-prefix match: among all entries whose network address matches the packet's destination IP, it picks the one with the most specific (longest) subnet mask. That entry specifies the next-hop IP and outgoing interface. If no match is found, the router uses a default route (0.0.0.0/0) if configured, or drops the packet and returns an ICMP "destination unreachable."
Q20. What is a default gateway?
A: A default gateway is the router address a host sends traffic to when the destination IP is outside its own local subnet. The host compares the destination address against its own subnet mask; if it's not local, the packet is forwarded to the default gateway's MAC address (resolved via ARP) for onward routing. Misconfigured default gateways are a very common cause of "my host can reach local machines but not the internet" tickets.
Q21. What is the difference between static and dynamic routing?
A: Static routes are manually configured by an administrator and never change unless someone edits them — simple and predictable, but they don't adapt to topology changes or failures. Dynamic routing uses protocols (like OSPF or BGP) where routers automatically exchange reachability information and recompute paths when links go down. Small or highly controlled networks (like a single VPC route table) often use static routes; large, redundant networks need dynamic routing for resilience.
Q22. At a high level, what do OSPF and BGP do, and how do they differ?
A: OSPF (Open Shortest Path First) is an interior gateway protocol used within a single organization's network; it builds a full topology map via link-state advertisements and computes shortest paths using Dijkstra's algorithm. BGP (Border Gateway Protocol) is the exterior/inter-domain protocol that glues the entire internet together, exchanging reachability information between autonomous systems (ISPs, cloud providers) based on path attributes and policy rather than pure shortest-path — it's what lets your cloud provider's IP range be reachable from anywhere in the world.
Q23. What is an IP address, and what is the difference between IPv4 and IPv6?
A: An IP address is a numeric identifier assigned to a device on a network, used for routing packets to it. IPv4 addresses are 32 bits, written as four dotted decimal octets (e.g., 192.168.1.10), giving about 4.3 billion possible addresses — now largely exhausted. IPv6 addresses are 128 bits, written as eight groups of hexadecimal digits (e.g., 2001:db8::1), providing an effectively inexhaustible address space and built-in support for features IPv4 needed extensions for, like auto-configuration.
Q24. What is the structure of an IPv4 address — network portion versus host portion?
A: Every IPv4 address is split by its subnet mask into a network portion (identifying which subnet the address belongs to) and a host portion (identifying the specific device within that subnet). For example, in 192.168.1.10/24, the first 24 bits (192.168.1) are the network portion and the last 8 bits (.10) are the host portion. Two hosts can only communicate directly at Layer 2 if they share the same network portion; otherwise traffic must be routed.
Q25. What is a subnet mask, and what does it actually do?
A: A subnet mask is a 32-bit value (like 255.255.255.0) that, when bitwise-ANDed with an IP address, tells you which bits represent the network portion versus the host portion. A "1" bit in the mask means "this bit is part of the network"; a "0" bit means "this bit identifies the host." It's how a device decides, for any destination IP, whether that destination is on its local network or needs to go through a router.
Q26. What is CIDR notation, and what does a value like /24 mean?
A: CIDR (Classless Inter-Domain Routing) notation expresses a subnet mask as a slash followed by the number of leading "1" bits, replacing the older rigid Class A/B/C system. A /24 means the first 24 bits are the network portion (mask 255.255.255.0), leaving 8 bits (256 addresses) for hosts. CIDR lets networks be sized to actual need — a /28 (16 addresses) for a small subnet, a /16 (65,536 addresses) for a large one — instead of being locked into fixed class boundaries.
Q27. How do you calculate the number of usable hosts in a given subnet?
A: The total number of addresses in a subnet is 2 raised to the number of host bits (32 minus the prefix length). Usable hosts is that total minus 2, because the first address is reserved as the network address and the last is reserved as the broadcast address. A /24 has 8 host bits → 256 total → 254 usable; a /30 has 2 host bits → 4 total → 2 usable, which is exactly enough for a point-to-point link between two routers.
int usableHosts(int prefixLength) {
int hostBits = 32 - prefixLength;
long total = 1L << hostBits; // 2^hostBits
return (int) Math.max(total - 2, 0); // minus network + broadcast
}
// usableHosts(24) -> 254
// usableHosts(30) -> 2
// usableHosts(31) -> 0 (point-to-point links use RFC 3021 to get 2 usable here)Q28. How do you determine the network address and broadcast address for a subnet like 192.168.1.77/26?
A: A /26 has 6 host bits, giving blocks of 64 addresses (256/4). The subnets are 192.168.1.0, .64, .128, and .192. Since .77 falls between .64 and .127, the network address is 192.168.1.64 and the broadcast address is 192.168.1.127 (the last address in that block), leaving .65 through .126 as the 62 usable host addresses.
// 192.168.1.77 /26 (host bits = 6, block size = 256/2^2 = 64)
// Subnets: .0, .64, .128, .192
// 77 falls in the .64 block:
int blockSize = 64;
int networkStart = (77 / blockSize) * blockSize; // 64
int broadcast = networkStart + blockSize - 1; // 127
// Network: 192.168.1.64
// Broadcast: 192.168.1.127
// Usable: 192.168.1.65 - 192.168.1.126 (62 hosts)Q29. What are the private IP address ranges defined by RFC 1918?
A: RFC 1918 reserves three ranges for private, non-internet-routable use: 10.0.0.0/8 (10.0.0.0 - 10.255.255.255, a full Class A block), 172.16.0.0/12 (172.16.0.0 - 172.31.255.255), and 192.168.0.0/16 (192.168.0.0 - 192.168.255.255). Any organization can reuse these ranges internally without conflict because routers on the public internet are configured to never forward traffic for them — this is also why NAT is required for private hosts to reach the internet.
Q30. What is the difference between a public and a private IP address?
A: A public IP address is globally unique and routable across the internet — assigned by an ISP or cloud provider and registered under an autonomous system. A private IP address (from an RFC 1918 range) is only meaningful within its local network and is not routed on the public internet; devices with private IPs reach the internet via NAT at the network's edge. Cloud VPCs typically assign private IPs to instances and attach a public IP (or NAT gateway) only where internet reachability is actually needed.
Q31. What is subnetting and why is it done?
A: Subnetting is dividing a larger IP network into smaller, logically separate sub-networks by borrowing bits from the host portion to extend the network prefix. It's done to reduce broadcast domain size, improve security by isolating tiers (public web subnet vs. private database subnet), match address allocation to actual need instead of wasting a huge block on a small network, and enable clean routing policies between segments — exactly how cloud VPCs are laid out across availability zones.
Q32. Walk through subnetting a /24 into four equal /26 subnets.
A: Splitting a /24 into four equal parts means borrowing 2 additional bits (2² = 4), moving from /24 to /26. Each resulting subnet has 64 addresses (62 usable). Given 192.168.10.0/24, the four /26 subnets are 192.168.10.0/26, 192.168.10.64/26, 192.168.10.128/26, and 192.168.10.192/26 — a common pattern for splitting one VPC CIDR block across public, private, and database tiers.
// 192.168.10.0/24 split into 4 x /26 (borrow 2 bits: 24 -> 26)
// Subnet 1: 192.168.10.0/26 hosts .1 - .62
// Subnet 2: 192.168.10.64/26 hosts .65 - .126
// Subnet 3: 192.168.10.128/26 hosts .129 - .190
// Subnet 4: 192.168.10.192/26 hosts .193 - .254Q33. What is VLSM (Variable Length Subnet Masking)?
A: VLSM allows a network to be subdivided into subnets of different sizes rather than forcing every subnet to be the same size, by applying different prefix lengths to different portions of the address space. For example, a /24 could be split into one /25 for a large subnet, a /27 for a medium one, and a /30 for a point-to-point router link — matching each subnet's size to its actual host count instead of wasting addresses on uniformly sized blocks.
Q34. What is supernetting / route aggregation (CIDR aggregation)?
A: Supernetting is the reverse of subnetting: combining multiple contiguous smaller networks into a single, larger routing announcement using a shorter prefix. For example, four contiguous /24 networks (203.0.4.0 through 203.0.7.0) can be aggregated into a single 203.0.4.0/22 route. This dramatically reduces the number of entries an internet backbone router needs in its routing table, which is essential for internet-scale routing to remain feasible.
Q35. What is the loopback address, and what is it used for?
A: 127.0.0.1 (and the whole 127.0.0.0/8 block in IPv4; ::1 in IPv6) always refers to the local machine itself — traffic sent there never leaves the host's network stack. It's used to test that a local network stack works, to run services only accessible from the same machine (e.g., a local dev database), and as the address a backend developer uses when running localhost:8080 during development.
Q36. What is link-local addressing (169.254.x.x / APIPA)?
A: Link-local addresses (169.254.0.0/16 in IPv4, fe80::/10 in IPv6) are auto-assigned by a device when it can't reach a DHCP server, allowing basic communication with other devices on the same physical segment but not routing beyond it. Seeing a 169.254.x.x address on a machine is a strong signal of a DHCP failure — the device gave up waiting for an address and self-assigned one (APIPA, Automatic Private IP Addressing) as a fallback.
Q37. What is IPv6, and why was it introduced?
A: IPv6 is the successor to IPv4, using 128-bit addresses instead of 32-bit ones, primarily to solve IPv4 address exhaustion — the roughly 4.3 billion IPv4 addresses were not enough for a world of billions of connected devices. Beyond the larger address space, IPv6 simplifies header processing, removes the need for NAT in most designs (every device can get a globally unique address), and adds built-in support for stateless address auto-configuration (SLAAC) and mandatory IPsec support in the original spec.
Q38. How does IPv6 addressing differ structurally from IPv4?
A: An IPv6 address is written as eight groups of four hexadecimal digits separated by colons (e.g., 2001:0db8:0000:0000:0000:ff00:0042:8329), which can be abbreviated by omitting leading zeros in each group and collapsing one run of consecutive all-zero groups with a double colon (::) — shortening the example to 2001:db8::ff00:42:8329. Unlike IPv4's class-based history, IPv6 was designed CIDR-first, and typical allocations give an organization a /48 or /56, with /64 as the standard subnet size for a single LAN segment.
Q39. What is dual-stack networking?
A: Dual-stack means a device or network runs both IPv4 and IPv6 simultaneously, with each protocol operating independently — a host gets both an IPv4 and an IPv6 address, and applications can use whichever is available (often preferring IPv6 when both work, per "Happy Eyeballs" algorithms in modern OSes). It's the dominant migration strategy today because it lets networks support IPv6 clients without breaking compatibility for the large amount of IPv4-only infrastructure still in production.
Q40. Given an IP address and a subnet mask, how do you programmatically determine which subnet the address belongs to?
A: Convert the IP address and the mask to their 32-bit integer representations, then perform a bitwise AND between them — the result is the network address of the subnet that IP belongs to. Two addresses are in the same subnet if and only if applying this AND with the shared mask produces the same result for both.
import java.net.InetAddress;
import java.nio.ByteBuffer;
boolean sameSubnet(String ip1, String ip2, int prefixLength) throws Exception {
int mask = prefixLength == 0 ? 0 : (int) (0xFFFFFFFFL << (32 - prefixLength));
int a = ByteBuffer.wrap(InetAddress.getByName(ip1).getAddress()).getInt();
int b = ByteBuffer.wrap(InetAddress.getByName(ip2).getAddress()).getInt();
return (a & mask) == (b & mask);
}
// sameSubnet("192.168.1.10", "192.168.1.200", 24) -> true
// sameSubnet("192.168.1.10", "192.168.2.10", 24) -> falseQ41. What is ARP, and what problem does it solve?
A: ARP (Address Resolution Protocol) maps a known IP address to the corresponding MAC (hardware) address on a local network segment. It exists because Layer 2 switches forward frames based on MAC addresses, but applications and routing decisions work in terms of IP addresses — ARP is the bridge that lets a host figure out "what MAC address do I send this frame to in order to reach this IP?" before it can actually transmit anything on the local wire.
Q42. How does the ARP request/reply process work?
A: When a host needs the MAC address for an IP it hasn't cached, it broadcasts an ARP request ("who has 192.168.1.5? tell 192.168.1.10") to the entire local network (destination MAC FF:FF:FF:FF:FF:FF). The device that owns that IP responds directly with a unicast ARP reply containing its MAC address. The requester then caches this mapping and can send the actual data frame directly to that MAC.
Q43. What is an ARP cache/table, and why does it matter for performance?
A: An ARP cache is a table on each host and router storing recently resolved IP-to-MAC mappings, with entries typically expiring after a few minutes. Without this cache, every single packet would require a fresh broadcast ARP lookup, adding latency and broadcast traffic; the cache means resolution only happens occasionally per destination. Stale or poisoned entries in this cache are a common source of intermittent "can't reach this host" issues after a device's MAC address changes (e.g., a failed-over load balancer).
Q44. What is ARP spoofing/poisoning, and why is it a security risk?
A: ARP spoofing is when an attacker sends forged ARP replies claiming their own MAC address corresponds to another device's IP (often the default gateway), causing victims to send traffic to the attacker instead of the real destination. Because ARP has no built-in authentication, any device on the local segment can lie about IP-to-MAC mappings, enabling man-in-the-middle attacks, traffic interception, or denial of service. Mitigations include dynamic ARP inspection on switches, static ARP entries for critical infrastructure, and network segmentation.
Q45. What is gratuitous ARP?
A: A gratuitous ARP is an ARP announcement a device sends unprompted (not in response to a request), broadcasting "this IP now belongs to this MAC address" to proactively update everyone's ARP cache. It's used when a device's IP or MAC changes (e.g., a NIC swap), or critically during failover in high-availability setups (like VRRP or keepalived) — when a standby server takes over a virtual IP, it sends a gratuitous ARP so the network immediately redirects traffic to it instead of the failed primary.
Q46. Does ARP work across routers/subnets? Why or why not?
A: No — ARP is strictly a Layer 2, local-segment protocol; ARP broadcasts do not cross routers, because routers don't forward Layer 2 broadcast traffic between subnets. When a host needs to reach an IP outside its own subnet, it doesn't ARP for that remote IP at all — it ARPs for its default gateway's MAC address and sends the frame there, and the gateway handles onward routing (and its own ARP resolution) from that point.
Q47. What is NAT, and why is it used?
A: NAT (Network Address Translation) rewrites the source (and/or destination) IP address — and often port — of packets as they cross a network boundary, typically translating private internal addresses to a public address for internet access. It was originally a stopgap for IPv4 address exhaustion, letting an entire private network share a small number of (or a single) public IP, and it remains standard practice today for both address conservation and as an implicit layer of network isolation.
Q48. What is the difference between static NAT, dynamic NAT, and PAT (NAT overload)?
A: Static NAT maps one private IP to one dedicated public IP permanently — used when a specific internal server must always be reachable at the same public address. Dynamic NAT maps private IPs to public IPs from a shared pool on a first-come basis, still one-to-one at any given time. PAT (Port Address Translation, also called NAT overload) is what most home and office routers actually use: many private IPs share a single public IP, disambiguated by translating each connection to a unique source port, which is why one public IP can serve an entire office.
Q49. How does NAT (PAT) enable multiple devices to share one public IP?
A: The NAT device maintains a translation table keyed by the internal (private IP, private port) pair, mapping each to a unique (public IP, translated port) pair. When a reply comes back addressed to that translated port, the NAT device looks up the table and rewrites the destination back to the correct internal host and port before forwarding it inward. Because there are up to ~64,000 usable ports, one public IP can theoretically support tens of thousands of simultaneous outbound connections across many internal devices.
Q50. What problems does NAT create for peer-to-peer connections and inbound services?
A: NAT is inherently asymmetric: it works well for outbound connections initiated from inside (the translation table entry is created automatically), but an unsolicited inbound connection has no existing table entry to match against, so it's dropped by default. This breaks direct peer-to-peer scenarios (two NAT'd hosts trying to connect to each other) and means any service that must accept inbound connections from the internet (like a web server) needs explicit port forwarding or a public-facing load balancer in front of it.
Q51. What is port forwarding, and when would you use it?
A: Port forwarding is a static NAT rule that says "any inbound traffic to the router's public IP on port X should be forwarded to internal IP Y on port Z," effectively poking a permanent hole through NAT for a specific service. It's used to expose a self-hosted service (like SSH or a game server) behind a home router to the internet. In production cloud environments, this pattern is usually replaced by a load balancer or reverse proxy sitting at the network edge instead of forwarding directly to one internal host.
Q52. How does NAT interact with stateful firewalls and connection tracking?
A: NAT and stateful firewalls both rely on the same underlying mechanism: a connection tracking table that records active flows (by source/destination IP and port). The firewall uses this table to allow return traffic for connections it saw initiated outbound while blocking unsolicited inbound traffic; NAT uses the same table to know how to translate return traffic back to the right internal host. In practice, most NAT gateways and stateful firewalls are the same device, which is why "NAT gateway" and "firewall" behaviors are so often bundled together at a network edge.
Q53. Why can NAT complicate debugging distributed systems, particularly around client IP visibility?
A: Because NAT rewrites the source IP, a server behind NAT (or one being accessed by clients behind NAT/load balancers) often sees the NAT device's IP instead of the true originating client IP, which breaks IP-based logging, rate limiting, and geolocation unless the original IP is preserved elsewhere. This is why HTTP proxies and load balancers add headers like X-Forwarded-For to carry the real client IP forward, and why backend services must be explicitly configured to trust and parse that header from a known proxy rather than trusting the raw socket's remote address.
Q54. What is NAT traversal, and what role do STUN/TURN play (e.g., for WebRTC)?
A: NAT traversal refers to techniques that let two NAT'd peers establish a direct connection despite NAT's default behavior of blocking unsolicited inbound traffic. STUN (Session Traversal Utilities for NAT) helps a client discover its own public IP/port as seen from outside, often enabling a direct connection via "hole punching" when both NATs are cooperative. TURN (Traversal Using Relays around NAT) is the fallback when direct connection isn't possible — it relays all traffic through a public server, trading extra latency and bandwidth cost for guaranteed connectivity, which is why WebRTC applications configure both.
Q55. What is a network socket?
A: A socket is the operating system's abstraction for one endpoint of a bidirectional network communication channel, identified by a combination of protocol, local IP, local port, remote IP, and remote port (for a connected TCP socket) or just local IP and port (for a listening/UDP socket). Applications read and write to a socket much like a file descriptor, while the OS kernel handles the actual packet construction, transmission, and reassembly underneath.
Q56. What is a port number, and what is its valid range?
A: A port number is a 16-bit value (0-65535) that identifies a specific process or service on a host, allowing a single IP address to support many simultaneous network conversations. Ports 0-1023 are "well-known" ports reserved for standard services and typically require elevated privileges to bind on Unix-like systems; 1024-49151 are "registered" ports for specific applications; 49152-65535 are "dynamic/ephemeral" ports, commonly assigned automatically as the client side of an outbound connection.
Q57. What are some common well-known port numbers a backend developer should recognize?
A: HTTP uses 80, HTTPS uses 443, SSH uses 22, DNS uses 53, SMTP uses 25, and common data-layer defaults include MySQL 3306, PostgreSQL 5432, MongoDB 27017, Redis 6379, and Kafka 9092. Recognizing these instantly helps when reading a netstat/ss output, a firewall rule, or a connection string, and spotting an unexpected port is often the first clue in a security review.
Port Service
22 SSH
25 SMTP
53 DNS
80 HTTP
443 HTTPS
3306 MySQL
5432 PostgreSQL
6379 Redis
9092 Kafka
27017 MongoDBQ58. How do you create a basic TCP server socket in Java?
A: Java's ServerSocket binds to a local port and listens for incoming TCP connections; calling accept() blocks until a client connects and returns a new Socket representing that specific connection, distinct from the listening socket itself. Each accepted connection is typically handed off to its own thread (or an async handler) so the server can keep accepting new connections concurrently.
try (ServerSocket serverSocket = new ServerSocket(8080)) {
System.out.println("Listening on port 8080...");
while (true) {
Socket client = serverSocket.accept(); // blocks until a connection arrives
new Thread(() -> handleClient(client)).start();
}
}
void handleClient(Socket client) {
try (client;
BufferedReader in = new BufferedReader(new InputStreamReader(client.getInputStream()));
PrintWriter out = new PrintWriter(client.getOutputStream(), true)) {
out.println("Hello, " + client.getInetAddress());
} catch (IOException e) {
e.printStackTrace();
}
}Q59. How do you create a TCP client socket in Java?
A: Java's Socket class, given a host and port, performs DNS resolution (if needed) and the TCP three-way handshake as part of construction, returning a connected socket you can read from and write to via its input/output streams. The try-with-resources pattern ensures the socket is closed (sending a FIN) even if an exception occurs during the exchange.
try (Socket socket = new Socket("api.example.com", 8080);
PrintWriter out = new PrintWriter(socket.getOutputStream(), true);
BufferedReader in = new BufferedReader(new InputStreamReader(socket.getInputStream()))) {
out.println("GET /health HTTP/1.1");
String response = in.readLine();
System.out.println("Server said: " + response);
} catch (UnknownHostException e) {
System.err.println("DNS resolution failed: " + e.getMessage());
} catch (IOException e) {
System.err.println("Connection failed: " + e.getMessage());
}Q60. What uniquely identifies a single TCP connection (the socket 4-tuple)?
A: A TCP connection is uniquely identified by the 4-tuple: (source IP, source port, destination IP, destination port). This is why a single server listening on one port (say, 443) can serve thousands of simultaneous distinct client connections — each client's unique source IP/port combination, paired with the server's fixed IP/port, makes every connection's 4-tuple unique even though the destination side never changes.
Q61. How can a server handle thousands of concurrent connections on the same listening port?
A: The listening port itself isn't "used up" per connection — the OS demultiplexes incoming packets using the full 4-tuple, not just the destination port, so each client's distinct source IP/port creates a logically separate connection even though they all arrive at the same server port. The practical limit on concurrent connections is usually available file descriptors, memory per connection, and thread/event-loop capacity, not the port number itself.
Q62. What is a socket's backlog, and how does it relate to the accept queue?
A: The backlog is the maximum number of fully-established (post-handshake) connections that can wait in the kernel's accept queue before the application calls accept() to pull them off. If incoming connections complete their handshake faster than the application accepts them and the queue fills up, the OS drops or refuses further SYNs, causing clients to see connection timeouts or resets — a common hidden cause of intermittent connection failures under load spikes.
// Second constructor argument is the backlog size
ServerSocket serverSocket = new ServerSocket(8080, 512);Q63. What do bind(), listen(), and accept() conceptually do in socket programming?
A: bind() associates a socket with a specific local IP address and port. listen() marks a bound socket as passive, ready to accept incoming connections, and sets the backlog size. accept() blocks (or returns asynchronously) until a client's connection completes its handshake, then returns a brand-new socket dedicated to that specific client, leaving the original listening socket free to accept further connections. Java's ServerSocket constructor performs the bind and listen steps together, and accept() maps directly to the underlying syscall.
Q64. What is SO_REUSEADDR, and why is it useful?
A: By default, after a socket closes, the OS keeps its local address/port in a TIME_WAIT-like reserved state for a period to safely handle any delayed packets, which can prevent immediately rebinding to the same port (a common annoyance when restarting a server during development or deployment). Setting SO_REUSEADDR tells the OS to allow rebinding to that address/port even while it's technically still in this transitional state, which is why most production server frameworks enable it by default.
ServerSocket serverSocket = new ServerSocket();
serverSocket.setReuseAddress(true);
serverSocket.bind(new InetSocketAddress(8080));Q65. How do you set a socket read timeout in Java, and why does it matter?
A: Without a timeout, a blocking read call can hang indefinitely if the remote side stops responding without closing the connection — a silent failure mode that can exhaust threads in a production service under a slow or malicious peer. Socket.setSoTimeout(millis) causes any blocking read to throw a SocketTimeoutException after that many milliseconds of inactivity, letting the application fail fast and free the resource instead of hanging forever.
Socket socket = new Socket("api.example.com", 443);
socket.setSoTimeout(5000); // throw SocketTimeoutException after 5s of no data
try {
int b = socket.getInputStream().read();
} catch (SocketTimeoutException e) {
System.err.println("Read timed out — remote peer is unresponsive");
}Q66. What is a UDP socket, and how does Java's DatagramSocket differ from Socket?
A: Unlike TCP's Socket, which represents a connected stream between two specific endpoints, Java's DatagramSocket is connectionless — each send()/receive() call carries its own destination address inside a DatagramPacket, and a single DatagramSocket can exchange packets with many different remote addresses without ever "connecting." There's no handshake, no guaranteed delivery, and no ordering — the application is responsible for anything beyond best-effort delivery it needs.
try (DatagramSocket socket = new DatagramSocket()) {
byte[] data = "ping".getBytes();
InetAddress address = InetAddress.getByName("metrics.example.com");
DatagramPacket packet = new DatagramPacket(data, data.length, address, 8125);
socket.send(packet); // fire-and-forget, no delivery guarantee
}Q67. What is the fundamental difference between TCP and UDP?
A: TCP is connection-oriented and reliable — it establishes a connection via a handshake, guarantees ordered and complete delivery through acknowledgments and retransmission, and applies flow/congestion control. UDP is connectionless and unreliable — it sends independent datagrams with no handshake, no acknowledgments, and no guarantee of delivery, ordering, or duplicate protection. The trade-off is TCP's reliability comes with more overhead and latency, while UDP's simplicity trades reliability for speed and lower overhead.
Q68. Why is TCP called "connection-oriented" and UDP called "connectionless"?
A: TCP requires an explicit setup phase (the three-way handshake) before any data flows, establishing shared state (sequence numbers, window sizes) between both endpoints, and an explicit teardown phase when done — this shared state is the "connection." UDP has no such state: each datagram is sent independently with just a source/destination address and port, with no memory of prior packets, no setup, and no teardown — every packet stands entirely on its own.
Q69. How does TCP guarantee reliable, ordered delivery?
A: Every byte in a TCP stream is assigned a sequence number; the receiver sends acknowledgments (ACKs) indicating the highest contiguous byte received, and the sender retransmits any segment not acknowledged within a timeout. The receiver buffers out-of-order segments and reassembles them into the correct order using their sequence numbers before delivering data to the application, so the application always sees a clean, ordered byte stream regardless of how packets actually arrived over the network.
Q70. What key fields does a TCP segment header contain?
A: Key fields include source and destination port, sequence number and acknowledgment number (for ordering and reliability), control flags (SYN, ACK, FIN, RST, PSH, URG), window size (for flow control), and a checksum (for error detection). The header is at least 20 bytes, notably heavier than UDP's fixed 8-byte header, reflecting all the extra state TCP tracks to provide its guarantees.
Q71. What does a UDP datagram header look like, and why is it so much smaller than TCP's?
A: A UDP header is a fixed 8 bytes: source port, destination port, length, and checksum — nothing else, because UDP tracks no connection state, no sequence numbers, and no acknowledgments. This minimal overhead is exactly why UDP is preferred for latency-sensitive or high-volume traffic like DNS queries, video streaming, and metrics — every byte and every round-trip of TCP's setup/reliability machinery is avoided.
Q72. When would a backend service choose UDP over TCP?
A: UDP is preferred when low latency matters more than guaranteed delivery, or when the application implements its own reliability logic tailored to its needs: DNS (short request/reply, retries are cheap), real-time video/voice (a late or lost frame is worse than a dropped one), online gaming (state updates are frequently superseded anyway), and metrics/telemetry emission (losing an occasional data point is acceptable, and you don't want a slow network to back up your application). TCP remains the default for anything requiring complete, ordered, reliable data — APIs, file transfers, database connections.
Q73. What is head-of-line blocking in TCP, and why does it matter for HTTP?
A: Because TCP guarantees strictly ordered delivery, if an early segment is lost, the receiver's OS buffers any later segments that already arrived but cannot deliver them to the application until the missing earlier segment is retransmitted and received — later data is "blocked" behind the lost earlier data. This matters for HTTP/1.1, where multiple requests sharing one TCP connection get stuck behind a single lost packet even if their responses are otherwise ready, which is part of why HTTP/2 multiplexing and HTTP/3 (built on UDP/QUIC) were developed to reduce this bottleneck.
Q74. What is TCP flow control, and how does the sliding window work?
A: Flow control prevents a fast sender from overwhelming a slow receiver's buffer. Each TCP ACK includes a "window size" value advertising how many more bytes the receiver is currently willing to buffer; the sender is only allowed to have that many unacknowledged bytes in flight at once. As the receiver's application consumes buffered data, the window grows again, and the sender can send more — the window effectively "slides" forward as data is acknowledged and consumed.
Q75. What is Nagle's algorithm, and why might a low-latency API disable it with TCP_NODELAY?
A: Nagle's algorithm buffers small outgoing TCP segments and delays sending them briefly, hoping to coalesce them with more data into fewer, larger packets — reducing overhead for chatty applications sending many tiny writes. But this delay (up to the receiver's ACK, often tens of milliseconds) is harmful for latency-sensitive request/response protocols where every millisecond counts, so such applications set TCP_NODELAY to disable Nagle's algorithm and send data immediately, accepting slightly more per-packet overhead in exchange for lower latency.
Socket socket = new Socket("api.example.com", 443);
socket.setTcpNoDelay(true); // disable Nagle's algorithm — send immediatelyQ76. What does the checksum in TCP/UDP headers protect against?
A: The checksum is a simple error-detection value computed over the header and data (plus a pseudo-header including source/destination IPs) that lets the receiver detect if a segment was corrupted in transit — for example, due to a flipped bit from electrical noise. It is not cryptographically secure and cannot detect all possible corruption or any deliberate tampering; that's what TLS's integrity protection (a MAC) is for at a higher layer. On a checksum mismatch, TCP silently drops the segment as if it never arrived, relying on the normal retransmission mechanism to recover it.
Q77. Walk through the TCP three-way handshake step by step.
A: 1) The client sends a SYN segment with an initial sequence number, requesting a connection. 2) The server responds with a SYN-ACK, acknowledging the client's sequence number and sending its own initial sequence number. 3) The client responds with an ACK, acknowledging the server's sequence number. After this exchange, both sides have confirmed they can send and receive, and the connection is considered established — data can now flow in both directions.
Client Server
|------ SYN (seq=x) -------->|
|<--- SYN-ACK (seq=y,ack=x+1)-|
|------ ACK (ack=y+1) ------>|
| |
|<===== connection ready =====>|Q78. What do the SYN, ACK, FIN, and RST TCP flags mean?
A: SYN ("synchronize") initiates a connection and proposes an initial sequence number. ACK ("acknowledge") confirms receipt of data up to a given sequence number, and is set on nearly every segment after the handshake. FIN ("finish") signals that the sender has no more data to send and wants to gracefully close its side of the connection. RST ("reset") abruptly terminates a connection, typically sent when a segment arrives for a connection that doesn't exist (e.g., no process listening on that port) or after an unrecoverable error — it's why "connection refused" happens instantly rather than timing out.
Q79. How does TCP connection termination work (the four-way close)?
A: Either side can initiate closing: it sends a FIN, and the other side ACKs it — but because TCP is full-duplex, the other side's stream may still have data to send, so it sends its own FIN separately once it's also done, which the original side ACKs. This gives four total segments (FIN, ACK, FIN, ACK) rather than a single combined step, though the middle ACK and FIN are sometimes combined into one segment in practice.
Client Server
|------ FIN -------------->| client done sending
|<----- ACK ----------------|
|<----- FIN -----------------| server done sending
|------ ACK -------------->|
| (connection closed) |Q80. What is the TIME_WAIT state, and why does it exist?
A: After actively closing a connection (sending the final ACK), the closing side enters TIME_WAIT for a period (commonly 2x the maximum segment lifetime, e.g., 60-120 seconds) instead of immediately freeing the connection's resources. This exists to absorb any delayed or duplicate packets still in flight from the old connection and to ensure the final ACK is properly received (retransmitting it if a duplicate FIN arrives), preventing those stray packets from being misinterpreted by a new connection that happens to reuse the same port.
Q81. What is a half-open connection, and how can it cause issues in production?
A: A half-open connection occurs when one side believes a TCP connection is still active while the other side has silently gone away (crashed, lost power, or had its network path cut) without sending a proper FIN or RST — no packets are exchanged, so neither the OS nor the application notices anything is wrong until a write is attempted or a timeout expires. This is a classic cause of connections in a pool appearing healthy but hanging on first use after a server restart or network partition, which is why TCP keep-alive and application-level heartbeats/timeouts matter.
Q82. What is connection pooling, and why does it matter for backend services talking to databases/APIs?
A: Connection pooling maintains a set of already-established TCP connections (already past the handshake, and for databases, already authenticated) that application code borrows and returns instead of opening a fresh connection per request. This avoids paying the handshake round-trip (and TLS handshake, and authentication) cost repeatedly, which matters enormously under load — a database that has to renegotiate a new TCP+TLS connection for every single query would be dramatically slower and could exhaust the database's own connection limits.
Q83. What is the difference between TCP keep-alive and HTTP keep-alive (persistent connections)?
A: TCP keep-alive is a low-level OS feature that periodically sends empty probe segments on an otherwise idle connection to detect if the peer is still reachable, closing the connection if probes go unanswered — it operates below the application entirely. HTTP keep-alive (persistent connections) is an application-layer convention where a client and server agree to reuse the same underlying TCP connection for multiple HTTP requests/responses instead of opening a new connection per request, which is the default behavior in HTTP/1.1 and a major performance win for REST APIs with many sequential calls to the same host.
Q84. What happens at the TCP level when a client sends a request but the server process has crashed?
A: If the server's OS is still running but no process is listening on that port, the OS itself immediately responds with a TCP RST, and the client sees an instant "connection refused." If the entire server machine is unreachable (powered off, network partition, security group blocking the port), there's no RST at all — the client's SYN goes unanswered and it eventually times out, which typically takes much longer (often tens of seconds) than a refused connection. Distinguishing these two failure modes quickly is a key production debugging skill.
Q85. What is TCP congestion control, and why is it needed?
A: Congestion control is TCP's mechanism for limiting how much data a sender puts into the network based on inferred network capacity, distinct from flow control (which is about the receiver's buffer). It's needed because the internet is a shared resource — if every sender transmitted as fast as possible regardless of network conditions, routers' queues would overflow, causing widespread packet loss and effectively collapsing throughput for everyone ("congestion collapse"), a real problem observed in the early internet before these algorithms were standardized.
Q86. What is TCP slow start?
A: Slow start is how a new (or recently idle) TCP connection ramps up its sending rate: it begins with a small congestion window (cwnd, often 1-10 segments) and roughly doubles it every round-trip as ACKs confirm successful delivery, growing exponentially until it either hits a threshold (ssthresh) or experiences packet loss. This cautious ramp-up avoids blasting an unknown network path with a full-speed burst that could immediately overwhelm it, while still reaching reasonable throughput within just a few round-trips.
// Simplified slow-start cwnd growth (in segments), doubling each RTT
RTT 1: cwnd = 1
RTT 2: cwnd = 2
RTT 3: cwnd = 4
RTT 4: cwnd = 8
RTT 5: cwnd = 16 // continues until ssthresh or a loss eventQ87. What is congestion avoidance (AIMD)?
A: Once the congestion window passes the slow-start threshold, TCP switches to congestion avoidance, using AIMD (Additive Increase, Multiplicative Decrease): the window grows by roughly one segment per round-trip (linear, cautious growth) as long as acknowledgments keep arriving, but is slashed by half immediately upon detecting loss. This sawtooth pattern — slow linear growth punctuated by sharp halving — is TCP's way of continuously probing for more available bandwidth while backing off quickly and decisively when it finds the network's limit.
Q88. What is the difference between flow control and congestion control?
A: Flow control protects the receiver — it limits the sender based on how much buffer space the receiving application currently has available, using the advertised window size. Congestion control protects the network itself — it limits the sender based on inferred network capacity (packet loss and delay), using the congestion window. The sender's actual allowed send rate at any moment is the minimum of these two independently computed limits.
Q89. What causes a TCP retransmission, and what is RTO?
A: A retransmission happens when the sender concludes a segment was lost — either because an expected ACK never arrived before the Retransmission Timeout (RTO) expired, or because it received duplicate ACKs (typically three) indicating the receiver saw later data but is still waiting for an earlier segment (triggering fast retransmit). RTO is dynamically calculated from measured round-trip times and their variance (via an algorithm like Jacobson/Karels), and it grows (exponential backoff) on repeated timeouts to avoid hammering an already-struggling network path.
Q90. Why can aggressive client-side retries amplify congestion in a distributed system (retry storms)?
A: If a downstream service becomes slow or starts failing under load, and many upstream clients retry immediately (and repeatedly) without backoff, the retries themselves add load on top of an already-struggling service, worsening the very condition causing the failures — a positive feedback loop known as a retry storm. Mitigations include exponential backoff with jitter (spreading retries out in time), circuit breakers (stopping retries entirely once failure rates are high), and retry budgets, all of which mirror TCP's own philosophy of backing off under detected congestion rather than pushing harder.
Q91. What is a firewall, and what does it fundamentally do?
A: A firewall is a network security device or software layer that inspects traffic crossing a boundary and allows or blocks it based on a configured rule set, typically matching on source/destination IP, port, and protocol. It enforces the principle of least privilege at the network level — only traffic explicitly permitted is allowed through, and everything else is dropped or rejected by default in a well-configured setup.
Q92. What is the difference between a stateless and a stateful firewall?
A: A stateless firewall evaluates every packet independently against its rule set with no memory of prior packets — you must explicitly allow both the outbound request and the inbound reply as separate rules. A stateful firewall tracks active connections (via a connection table) and automatically allows return traffic for connections it saw legitimately initiated, so you typically only need to write a rule for the initiating direction. Stateful firewalls are more common and easier to reason about in modern setups (like AWS security groups) because of this automatic return-traffic handling.
# Stateful firewall example (iptables) — allow established/related
# return traffic automatically, only rule needed for new connections:
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -m state --state NEW -j ACCEPT
iptables -A INPUT -j DROPQ93. What is the difference between a security group and a network ACL in cloud environments like AWS?
A: A security group is a stateful firewall attached at the instance/resource level — you only write allow rules (no explicit deny), and return traffic is automatically permitted. A network ACL (NACL) is a stateless firewall applied at the subnet level, evaluated in numbered order, and requires explicit allow rules for both inbound and outbound directions since it has no connection awareness. Most designs rely primarily on security groups for fine-grained per-resource control, using NACLs sparingly as a broader subnet-level safety net.
Q94. What is a Web Application Firewall (WAF), and how does it differ from a network firewall?
A: A traditional network firewall operates at Layers 3-4, filtering based on IP addresses, ports, and protocols — it has no understanding of HTTP content. A WAF operates at Layer 7, inspecting the actual HTTP request/response content to detect and block application-level attacks like SQL injection, cross-site scripting, and malicious payloads, based on request patterns rather than just network addressing. They're complementary — a network firewall controls what can reach your application at all, while a WAF scrutinizes what those permitted requests actually contain.
Q95. What is the difference between an ingress rule and an egress rule?
A: An ingress rule controls inbound traffic — what's allowed to reach a resource from outside. An egress rule controls outbound traffic — what a resource is allowed to initiate connections to. Many security-conscious architectures restrict egress as tightly as ingress (a "default deny outbound" posture), because an attacker who compromises a server internally still needs outbound connectivity to exfiltrate data or reach a command-and-control server, and restrictive egress rules can block that even after a breach.
Q96. How do firewalls factor into designing a secure microservices architecture?
A: A well-designed microservices network applies least-privilege firewall rules between every tier: only the load balancer's security group is open to the internet on 443; only application services can reach the database's security group on its port; internal service-to-service calls are restricted to the specific ports and source security groups that legitimately need them, rather than opening broad internal ranges. This limits the blast radius if any single service is compromised — an attacker in a web tier instance can't casually reach the database tier unless a rule explicitly permits it.
Q97. What is a VPN, and how does it work conceptually?
A: A VPN (Virtual Private Network) creates an encrypted tunnel over an untrusted network (like the public internet), making traffic between two endpoints appear as if it's traveling over a private, secure link even though it's physically crossing shared infrastructure. It works by encapsulating original packets inside an encrypted outer packet (using protocols like IPsec or WireGuard), which is decrypted and unwrapped only at the tunnel's other endpoint, keeping the payload confidential and tamper-evident to anyone observing the path in between.
Q98. What is the difference between a site-to-site VPN and a client (remote-access) VPN?
A: A site-to-site VPN permanently connects two entire networks (e.g., an on-premises data center and a cloud VPC) through a tunnel between two gateway devices, letting all devices on both sides communicate as if on one network without individual configuration. A client (remote-access) VPN connects a single device (like an employee's laptop) to a private network on demand, typically via client software authenticating the user before granting tunnel access — this is the type used for "connect to the office network from home."
Q99. What is a VPN tunnel, and how does encapsulation/encryption apply to it?
A: A VPN tunnel wraps each original packet inside a new outer packet: the original packet (with its original private source/destination) becomes the encrypted payload, and the outer packet is addressed between the two VPN endpoints' public IPs. Intermediate routers on the public internet only ever see the outer, encrypted envelope — they can't read the original addresses or payload, which is what provides confidentiality even though the traffic is physically transiting shared, untrusted infrastructure.
Q100. Why might a backend team use a VPN to access a private database or VPC?
A: Production databases and internal services are typically placed in private subnets with no direct internet route at all, specifically so they can't be reached or attacked from the public internet regardless of credentials. A VPN gives authorized engineers a secure, authenticated path into that private network for legitimate administrative access (running migrations, debugging, connecting a local tool to a private database), without ever exposing the database itself to the public internet through a port-forwarding rule.
Q101. What is a bastion host / jump box, and how does it relate to VPN access?
A: A bastion host is a single, tightly locked-down, heavily monitored server that sits at the edge of a private network and is the only entry point permitted to then reach other internal machines via SSH or similar — engineers connect to the bastion first, then hop from it into the private network. It's an alternative (or complement) to a full VPN: rather than opening a whole private network to a device once connected, a bastion narrows the exposed attack surface to a single hardened, auditable chokepoint.
Q102. What is a network topology, and what are the common types?
A: Network topology describes how devices are physically or logically interconnected. Common types include bus (all devices share a single central cable — largely obsolete), star (all devices connect to a central switch/hub — the standard for modern LANs), ring (each device connects to exactly two neighbors, forming a loop), mesh (devices have multiple direct interconnections for redundancy), and hybrid (a combination, like the spine-leaf design common in data centers).
Q103. What is a star topology, and why is it standard in modern LANs?
A: In a star topology, every device connects individually to a central switch rather than to each other directly. It's dominant today because a single cable failure only isolates one device rather than disrupting the whole network (unlike a shared bus or ring), it's easy to add or remove devices without affecting others, and centralized switches make monitoring, management, and troubleshooting far simpler than distributed wiring schemes.
Q104. What is a mesh topology, and when is it used?
A: In a full mesh, every device has a direct connection to every other device, maximizing redundancy — no single link failure isolates any device, since traffic can reroute around it. In a partial mesh, only some devices have multiple direct links. Mesh designs are used where redundancy and resilience justify the cost and complexity, such as core network backbones, data center fabrics, and some wireless mesh networks — the trade-off is that connection count grows quadratically with device count, making full mesh impractical beyond a modest number of nodes.
Q105. What is spine-leaf topology in a data center, and why did it replace traditional 3-tier designs?
A: Spine-leaf is a two-tier design where every leaf switch (connected to servers) connects to every spine switch, and spine switches never connect directly to each other — meaning any server-to-server path is always exactly two hops (leaf-spine-leaf), giving predictable, low latency. It replaced older 3-tier (core-aggregation-access) designs because modern data centers have far more east-west (server-to-server) traffic than north-south (client-to-server) traffic, and spine-leaf's consistent hop count and easy horizontal scaling (add more spines for more capacity) suit that pattern much better than a hierarchical tree optimized for north-south flows.
Q106. What is a single point of failure, and how does topology choice affect it?
A: A single point of failure is any component whose failure alone can take down the whole system or a disproportionate part of it — a single switch in a naive star topology, for instance, or a single link in a ring. Redundant topologies (mesh, spine-leaf, dual-homed connections) eliminate single points of failure by ensuring multiple independent paths exist between any two points, so no one component's failure fully disconnects the network — a core principle behind highly available system design at every layer, not just networking.
Q107. How does network topology relate to designing highly available distributed systems (e.g., multi-AZ deployments)?
A: Cloud regions are physically divided into availability zones (AZs) — separate data centers with independent power, cooling, and networking, connected by high-bandwidth low-latency links, deliberately mirroring a resilient topology at the infrastructure level. Deploying a distributed system across multiple AZs (with load balancers and database replicas spanning zones) means a single AZ's failure — the cloud equivalent of one node in a mesh going down — doesn't take the whole system offline, directly applying the topology principle of "no single point of failure" to application architecture.
Q108. What is latency?
A: Latency is the time delay for data to travel from source to destination — commonly measured as round-trip time (RTT) for a request and its response. It's dominated by propagation delay (limited by the speed of light over distance), processing delay at each hop, queuing delay when links are congested, and, for TCP, the extra round-trips needed for the handshake and TLS negotiation before any actual data is even sent.
Q109. What is bandwidth?
A: Bandwidth is the theoretical maximum data transfer capacity of a network link, usually measured in bits per second (Mbps, Gbps). It describes how much data a connection could carry under ideal conditions — a 1 Gbps link can theoretically move 1 gigabit of data per second — but it says nothing about how quickly any individual piece of data arrives, which is what latency measures instead.
Q110. What is throughput, and how does it differ from bandwidth?
A: Throughput is the actual amount of data successfully transferred over a link in practice, which is always less than or equal to the theoretical bandwidth due to protocol overhead, retransmissions, congestion, and application-level bottlenecks. Bandwidth is the ceiling; throughput is what you actually get — a 1 Gbps link (bandwidth) might only sustain 700 Mbps of real application throughput once headers, ACKs, and occasional retransmits are accounted for.
Q111. What is the bandwidth-delay product, and why does it matter for TCP window sizing?
A: The bandwidth-delay product (bandwidth × round-trip time) represents how many bytes can be "in flight" on a link at any moment before the first byte's acknowledgment could possibly return. If TCP's window size is smaller than this product, the sender is forced to pause waiting for ACKs even though the link has spare capacity, capping throughput well below the link's actual bandwidth — this is exactly why high-bandwidth, high-latency links ("long fat networks," like transcontinental connections) need TCP window scaling to achieve their full theoretical throughput.
Q112. What is jitter?
A: Jitter is the variation in latency over time — even if average latency is low, packets arriving with wildly inconsistent delays (one at 20ms, the next at 200ms) can be worse for real-time applications than a slightly higher but consistent latency. It matters most for live audio/video and gaming, where receiving buffers must be sized to absorb jitter, and excessive jitter causes audible/visible stutter even when average bandwidth and latency both look fine on paper.
Q113. Why can increasing bandwidth fail to fix a slow, chatty REST API?
A: If an application's slowness comes from making many sequential small requests (each paying a full round-trip of latency, TLS negotiation, and possibly a fresh TCP handshake) rather than from moving large volumes of data, the bottleneck is latency-bound, not bandwidth-bound — adding more bandwidth does nothing to shorten the number of round-trips required. The fix is reducing round-trips (batching requests, using persistent/multiplexed connections, caching, or moving computation closer to the data) rather than buying a bigger network pipe.
Q114. What is a forward proxy, and what problem does it solve?
A: A forward proxy sits between clients and the wider internet, forwarding client requests onward on their behalf — the destination server sees the proxy's IP, not the original client's. It's used for centralized outbound access control (blocking/allowing sites for a corporate network), caching frequently requested content to save bandwidth, and anonymizing the client's identity from the destination server. From the server's perspective, it looks like the proxy itself made the request.
Q115. What is a reverse proxy, and what problem does it solve?
A: A reverse proxy sits in front of one or more backend servers, receiving client requests and forwarding them to the appropriate backend — from the client's perspective, it looks like they're talking directly to a single server, even though multiple servers may be handling requests behind it. It's used to centralize TLS termination, load balance across multiple backend instances, cache responses, and hide internal architecture details (backend hostnames, ports, and topology) from external clients.
Q116. What are common reverse proxy use cases in a backend architecture?
A: Load balancing (distributing requests across multiple identical backend instances), TLS/SSL termination (decrypting HTTPS once at the edge so backend services can speak plain HTTP internally, simplifying certificate management), response caching (serving repeated requests without hitting the backend), request routing (sending /api/* to one service and /static/* to another), rate limiting, and compression. Nginx, HAProxy, and Envoy are common tools used specifically for this role.
Q117. What is the difference between a load balancer and a reverse proxy?
A: The terms overlap significantly, but conceptually a load balancer's core job is distributing traffic across multiple backend instances (which can happen at Layer 4, based purely on IP/port, or Layer 7, based on HTTP content), while a reverse proxy's defining trait is forwarding requests on behalf of clients to backends while presenting a unified front — which often includes load balancing as one of its features, alongside caching, TLS termination, and routing. In practice, most production reverse proxies (Nginx, Envoy) and load balancers (AWS ALB) do both jobs simultaneously.
Q118. How does an API gateway relate to a reverse proxy in a microservices architecture?
A: An API gateway is a specialized reverse proxy purpose-built for microservices: beyond basic routing and TLS termination, it typically adds authentication/authorization enforcement, request/response transformation, per-client rate limiting, request aggregation (fanning one client call out to multiple internal services), and API versioning — centralizing cross-cutting concerns that would otherwise need to be duplicated in every individual microservice.
Q119. What is TLS termination, and why is it often done at the proxy layer?
A: TLS termination means decrypting incoming HTTPS traffic at the reverse proxy/load balancer, so traffic between the proxy and backend services can flow as plain HTTP within a trusted internal network, rather than every individual backend service managing its own TLS certificates and encryption overhead. This centralizes certificate management and renewal in one place, reduces CPU overhead on backend application servers, and simplifies internal debugging (you can inspect plaintext internal traffic), at the cost of that internal segment needing to be genuinely trusted/isolated network.
Q120. What does a basic Nginx reverse proxy configuration for a backend API look like?
A: A minimal reverse proxy block listens on a public port, terminates TLS, and forwards requests to an internal backend address, while forwarding headers so the backend can still see the original client's information. The proxy_pass directive is what actually forwards the request onward.
server {
listen 443 ssl;
server_name api.example.com;
ssl_certificate /etc/ssl/certs/api.example.com.crt;
ssl_certificate_key /etc/ssl/private/api.example.com.key;
location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}Q121. What is DNS, and how does a DNS lookup work end to end?
A: DNS (Domain Name System) translates human-readable hostnames into IP addresses. A lookup typically checks the local OS cache first, then queries a configured recursive resolver, which — if it doesn't have a cached answer — walks the hierarchy: asking a root server for the TLD (.com) nameserver, then the TLD server for the authoritative nameserver of the specific domain, then that authoritative server for the actual record, caching the answer at each level along the way for future queries.
$ dig api.example.com +short
203.0.113.42
$ dig api.example.com
;; ANSWER SECTION:
api.example.com. 300 IN A 203.0.113.42
;; Query time: 24 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)Q122. What role does DNS caching and TTL play in backend performance and deployments?
A: Each DNS record has a TTL (time-to-live) specifying how long resolvers may cache it before re-querying; a longer TTL reduces lookup latency and load on nameservers, while a shorter TTL lets changes (like a failover to a new IP) propagate faster. This is a real operational trade-off during deployments — if you plan to change a DNS-based endpoint (like during a blue-green cutover), you generally lower the TTL well in advance so old, stale cached records expire quickly once you actually make the switch.
Q123. Why does HTTP keep-alive matter specifically for REST API performance?
A: Without keep-alive, every single HTTP request would require its own fresh TCP handshake (and TLS handshake, for HTTPS) before any actual request data is even sent — for a REST client making many sequential calls, this overhead can dwarf the actual request/response time. Keeping the underlying TCP connection open and reusing it across requests amortizes that setup cost across many requests, which is why virtually every production HTTP client library defaults to connection pooling with keep-alive enabled.
Q124. What happens during the TLS/SSL handshake, at a high level, and why does it add latency?
A: The client and server exchange supported cipher suites and TLS versions, the server presents its certificate (which the client validates against a trusted CA chain), they perform a key exchange to derive shared symmetric encryption keys, and then both sides confirm the handshake is complete before any application data flows encrypted. Modern TLS 1.3 reduced this to one round-trip (down from two in TLS 1.2), but it's still additional round-trip(s) layered on top of the TCP handshake's own round-trip — which is why connection reuse and session resumption matter so much for HTTPS performance.
$ openssl s_client -connect api.example.com:443 -brief
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Verification: OK
Server Temp Key: X25519, 253 bitsQ125. What is HTTP/2 multiplexing, and how does it address TCP head-of-line blocking?
A: HTTP/2 allows multiple independent request/response exchanges to share a single TCP connection concurrently, interleaved as small frames rather than requiring one request to fully complete before the next begins (as HTTP/1.1 pipelining effectively required in practice). This eliminates HTTP-level head-of-line blocking between different requests, but a single lost TCP packet still blocks all the multiplexed streams sharing that one TCP connection, because TCP's own ordering guarantee applies to the whole connection — a limitation HTTP/3, built on UDP-based QUIC with independent per-stream loss recovery, addresses more completely.
Q126. What is a CDN, and how does it reduce latency?
A: A CDN (Content Delivery Network) caches content across many geographically distributed edge servers, so a request is served from a location physically close to the requesting client instead of always traveling to a single origin server, directly reducing propagation delay. Beyond static assets, modern CDNs also often provide edge compute, DDoS protection, and can even reduce origin load and improve perceived API latency by proxying and connection-pooling the "long haul" leg back to the origin on the requester's behalf.
Q127. How would you diagnose "connection refused" versus "connection timed out" in a Java backend?
A: A ConnectException: Connection refused means a TCP RST came back quickly — the target host is reachable at the network level, but nothing is listening on that port (wrong port, service crashed, or not yet started). A SocketTimeoutException (or a hang until the OS-level connect timeout) means no response came back at all — typically a firewall/security group silently dropping the SYN, a wrong IP, or the host being genuinely unreachable. Distinguishing these tells you immediately whether to look at "is the service running and bound to the right port" versus "is there a network/firewall path at all."
try {
Socket socket = new Socket();
socket.connect(new InetSocketAddress("db.internal", 5432), 3000);
} catch (ConnectException e) {
// Fast failure: host reachable, nothing listening on that port
log.error("Port closed or service down: {}", e.getMessage());
} catch (SocketTimeoutException e) {
// No response at all: firewall drop, bad route, or host down
log.error("Network unreachable or blocked: {}", e.getMessage());
}Q128. What networking concepts matter most when designing a REST API for a distributed system?
A: Understanding connection reuse (keep-alive, pooling) to avoid paying handshake costs repeatedly; designing for latency (minimizing round-trips, favoring batched/GraphQL-style calls over N+1 chatty patterns) over raw bandwidth; timeout and retry strategy (with backoff and jitter) to avoid retry storms during downstream degradation; knowing where TLS termination and load balancing happen in your topology; and correctly propagating and trusting client-identifying headers (like X-Forwarded-For) through any proxies or NAT layers in the path. These fundamentals directly shape reliability and latency far more than most application-level code changes.
Post a Comment
Add