Networking
Sockets, OSI and TCP/IP models, IP addressing, ports, TCP vs UDP, HTTP/HTTPS, and TLS handshake.
31 questions
JuniorTheoryVery commonWhat is a socket and what operations can you do with it?
What is a socket and what operations can you do with it?
Socket is an OS abstraction for one end of a bidirectional channel. TCP: socket() create; bind() attach to addr/port; server listen() + accept(); client connect(); send()/recv() for data; close() releases FD. UDP has no listen/accept/connect (optional); use sendto()/recvfrom() with explicit peer.
Common mistakes
- ✗Forgetting to call
bind()on the server beforelisten()— the OS won't know which port to listen on - ✗Treating
recv()return value as a null-terminated string —recvreturns byte count, not a C-string; always null-terminate manually or use the count - ✗Not setting
SO_REUSEADDRon the server socket — after restart the port stays in TIME_WAIT andbind()fails for ~2 minutes
Follow-up questions
- →What is the difference between a blocking and a non-blocking socket? How do you set a socket to non-blocking mode?
- →What is
select()/poll()/epoll()and why are they needed?
JuniorTheoryVery commonWhat is the difference between TCP and UDP? When to use UDP?
What is the difference between TCP and UDP? When to use UDP?
TCP: connection-oriented, reliable ordered delivery, flow+congestion control, 3-way handshake, 20+ B header. UDP: connectionless, best-effort, no ordering or retransmit, 8 B header, low latency. UDP when latency > reliability (games, VoIP, DNS), for reliability on top (QUIC/HTTP3), or broadcast/multicast. TCP for HTTP, files, email.
Common mistakes
- ✗Assuming UDP is always faster — the latency advantage only appears at high packet rates or with very small payloads; TCP can be equally fast for large bulk transfers
- ✗Thinking UDP is 'unreliable' and therefore useless — UDP forms the base of HTTP/3 (QUIC), which is reliable but faster than TCP for lossy networks
- ✗Using TCP for broadcast — TCP is strictly point-to-point; send UDP datagrams to the broadcast address (255.255.255.255) or a multicast group
Follow-up questions
- →What is QUIC and how does it provide reliability on top of UDP?
- →How does a DNS resolver decide when to use TCP instead of UDP?
MiddleTheoryVery commonDifference between HTTP and HTTPS.
Difference between HTTP and HTTPS.
HTTP (port 80) is plaintext — headers, cookies, body visible to any observer. HTTPS (port 443) is HTTP over TLS: confidentiality (encryption), integrity (MAC), authentication (server cert). Domain still visible via TLS SNI and DNS; only path, query, body are encrypted. HTTPS does not stop app-level attacks like XSS or SQLi.
Common mistakes
- ✗Assuming HTTPS means the site is safe/trustworthy — HTTPS only ensures the channel is encrypted; the server behind it can still be malicious or compromised
- ✗Sending sensitive data in URL query parameters over HTTPS — the URL may appear in server access logs, Referer headers, and browser history even when encrypted in transit
- ✗Not implementing HSTS — without
Strict-Transport-Security, browsers can be downgraded to HTTP on the first visit; HSTS forces HTTPS even before the first response
Follow-up questions
- →What is certificate pinning and what are its risks?
- →How does Let's Encrypt automate certificate issuance with the ACME protocol?
MiddleTheoryVery commonHow does the SSL/TLS handshake work?
How does the SSL/TLS handshake work?
TLS 1.3 (1-RTT): (1) Client → ClientHello + key_share + ciphers; (2) Server → ServerHello + key_share + Certificate + CertificateVerify + Finished; both derive session key from ephemeral DH; (3) Client → Finished, traffic encrypted. TLS 1.3 dropped RSA key exchange (forward secrecy mandatory). 0-RTT is replay-prone.
Common mistakes
- ✗Confusing SSL and TLS — SSL (2.0, 3.0) is deprecated and broken; the correct term is TLS; 'SSL certificate' is a legacy misnomer for an X.509 certificate
- ✗Using self-signed certificates in production without a trust chain — clients reject them unless you explicitly add the CA to the trust store; use a public CA (Let's Encrypt) instead
- ✗Not checking the CRL/OCSP revocation status — a compromised certificate remains trusted until its expiry unless revocation is checked
Follow-up questions
- →What is forward secrecy and why does TLS 1.3 make it mandatory?
- →How does mutual TLS (mTLS) differ from standard TLS and when is it used?
MiddleTheoryVery commonHow does the TCP three-way handshake work?
How does the TCP three-way handshake work?
1. SYN: client sends SYN with ISN_c. 2. SYN-ACK: server replies SYN+ACK, acks ISN_c+1, sends ISN_s. 3. ACK: client acks ISN_s+1; ESTABLISHED. Close is 4-way FIN (each side FIN + ACK). Active closer enters TIME_WAIT (2×MSL, ~60–120 s) so delayed duplicates can't corrupt a new connection on the same 5-tuple.
Common mistakes
- ✗Thinking TIME_WAIT is a bug — it is a deliberate protection mechanism; the real problem is port exhaustion from too many short-lived connections
- ✗Assuming the connection is ready to send data after the SYN is sent — data can only flow after the full 3-way exchange completes
- ✗Confusing sequence numbers and acknowledgement numbers — the ACK number is the next expected byte, not the last received byte
Follow-up questions
- →What is a SYN flood attack and how is it mitigated with SYN cookies?
- →How does TCP Fast Open (TFO) reduce connection latency?
JuniorTheoryCommonCompare HTTP methods (GET, POST, PUT, PATCH, DELETE) by safety and idempotency.
Compare HTTP methods (GET, POST, PUT, PATCH, DELETE) by safety and idempotency.
Safe (no state change): GET, HEAD, OPTIONS. Idempotent (repeating = single call effect): GET, HEAD, PUT, DELETE, OPTIONS. Not idempotent: POST (creates a new resource each time), PATCH (depends on the patch). So clients and proxies may safely retry idempotent requests on timeout.
Common mistakes
- ✗Using GET for actions that modify state — caches, prefetchers will misbehave
- ✗Making POST handlers idempotent without documenting it
- ✗Using PATCH for full replacement (which is what PUT is for)
Follow-up questions
- →How does a server convey idempotency keys to deduplicate POSTs?
- →Why should DELETE return 204 No Content typically?
JuniorTheoryCommonWhat is an IP address? IPv4 vs IPv6, subnet mask, memory size.
What is an IP address? IPv4 vs IPv6, subnet mask, memory size.
IP address identifies a host. IPv4: 32 bits (4 B), four octets like 192.168.1.1, ~4.3B addresses, exhausted. IPv6: 128 bits (16 B), eight hex groups like 2001:db8::1, ~3.4×10³⁸. Subnet mask /n in CIDR = n leading bits are network prefix. In C++: in_addr (4 B), in6_addr (16 B), used in sockaddr_in/sockaddr_in6.
Common mistakes
- ✗Treating IP addresses as 32-bit integers without considering byte order — use
htonl/ntohlto convert between host and network byte order (big-endian) - ✗Thinking ::1 is only a test address —
::1is the IPv6 loopback, equivalent to 127.0.0.1 - ✗Assuming 192.168.x.x is always private — 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 are all RFC 1918 private ranges
Follow-up questions
- →What is NAT and why is it used with IPv4?
- →How does
getaddrinfo()resolve a hostname to both IPv4 and IPv6 addresses?
JuniorTheoryCommonWhat is NAT and why do we need it in IPv4?
What is NAT and why do we need it in IPv4?
NAT maps many private IPs (10.x, 172.16.x, 192.168.x) to one public IP by rewriting source IP+port on outbound packets and tracking a connection table. Reasons: IPv4 scarcity plus perimeter-security side effect (no inbound without port forwarding). IPv6 removes NAT — every device gets a global address.
Common mistakes
- ✗Designing P2P apps assuming both peers can accept connections — NAT often blocks this
- ✗Trying to host servers behind home NAT without port forwarding
- ✗Confusing NAT (router) with PAT (port address translation, which is what most home routers actually do)
Follow-up questions
- →What is hole punching for NAT traversal?
- →Why does WebRTC need STUN/TURN servers?
JuniorTheoryCommonWhat is a port and how many are available?
What is a port and how many are available?
A port is a 16-bit number (0–65535), 65536 total, multiplexing traffic to processes. Ranges: 0–1023 well-known (HTTP 80, HTTPS 443, SSH 22, DNS 53), need root on Linux; 1024–49151 IANA-registered; 49152–65535 ephemeral (OS-assigned for outgoing). Connection = 5-tuple (proto, src IP, src port, dst IP, dst port).
Common mistakes
- ✗Thinking each port number can only be used by one connection — the 5-tuple defines a connection, so the same destination port can serve many simultaneous connections from different clients
- ✗Trying to bind to port < 1024 without elevated privileges on Linux — results in
EACCES; useCAP_NET_BIND_SERVICEcapability instead of running as root - ✗Confusing UDP and TCP port namespaces — they are independent; TCP port 80 and UDP port 80 are different sockets
Follow-up questions
- →What is
SO_REUSEPORTand how does it differ fromSO_REUSEADDR? - →How many simultaneous TCP connections can a server theoretically handle on a single port?
JuniorTheoryCommonWhat is serialization and why do networked systems need it?
What is serialization and why do networked systems need it?
Serialization converts in-memory objects into a byte stream for transmission or storage; deserialization is the reverse. Networked systems need it because raw memory layout is platform-specific (endianness, padding, pointers), so a portable wire format (JSON, Protobuf, MessagePack, CBOR) is required.
Common mistakes
- ✗Sending raw structs over the network — endianness, padding, and pointer values break interop between machines
- ✗Putting
std::stringorstd::vectordirectly on the wire — their layout is compiler-specific - ✗Skipping schema versioning — adding a field later breaks every old client that expected the prior layout
Follow-up questions
- →What is the trade-off between text formats (JSON) and binary formats (Protobuf, FlatBuffers)?
- →How do you evolve a Protobuf schema without breaking old clients?
MiddleTheoryCommonWhat is CORS and how does the preflight request work?
What is CORS and how does the preflight request work?
CORS relaxes the browser's Same-Origin Policy. Simple requests (GET/POST, safe headers) just check Access-Control-Allow-Origin on the response. Complex (custom headers, PUT, DELETE) trigger an OPTIONS preflight; server must allow origin/methods/headers. Browser-enforced only.
Common mistakes
- ✗Setting
Access-Control-Allow-Origin: *withAllow-Credentials: true— disallowed; must be explicit origin - ✗Forgetting to handle the OPTIONS preflight request on the server
- ✗Believing CORS prevents CSRF — it doesn't fully, use SameSite cookies / CSRF tokens
Follow-up questions
- →Why does Authorization header trigger preflight?
- →What is
Access-Control-Max-Agefor?
MiddleTheoryCommonHow does DNS resolution work end-to-end?
How does DNS resolution work end-to-end?
OS resolver checks /etc/hosts, then queries a recursive DNS server (e.g. 8.8.8.8, 1.1.1.1). The recursive walks root → TLD → authoritative and returns A/AAAA. Caches at every level (browser, OS, recursive) honour TTLs. DNS runs over UDP/53; DoT/DoH add TLS for privacy.
Common mistakes
- ✗Hardcoding IPs to skip DNS — breaks on infrastructure changes
- ✗Forgetting that
localhostresolution depends onnsswitch.conf/hosts - ✗Long DNS TTLs causing stale records during deploys
Follow-up questions
- →What's the difference between iterative and recursive DNS query?
- →Why does DNS use UDP and when does it fall back to TCP?
MiddleDesignCommonYou are choosing the communication style for a new service and comparing a REST API against the RPC framework gRPC. Explain how they differ in transport, serialization format, and interaction style (request/response vs streaming), and which kinds of system push you toward one over the other.
You are choosing the communication style for a new service and comparing a REST API against the RPC framework gRPC. Explain how they differ in transport, serialization format, and interaction style (request/response vs streaming), and which kinds of system push you toward one over the other.
REST uses HTTP/1.1 or HTTP/2 with JSON and resource URLs — browser-friendly, easy to debug. gRPC uses HTTP/2 with Protocol Buffers (binary, schema-defined), RPC methods, bidirectional streaming, generated stubs. Choose REST for public APIs and browsers; gRPC for internal microservices, low-latency polyglot, streaming.
Common mistakes
- ✗Choosing gRPC for a public browser API — gRPC-Web is needed and limited
- ✗Comparing JSON vs Protobuf without schema versioning strategy
- ✗Ignoring debug-ability — Protobuf payloads aren't human-readable
Follow-up questions
- →How does Protobuf handle backward compatibility?
- →What does HTTP/2 multiplexing buy gRPC?
MiddleTheoryCommonWhat are the main TCP flags (SYN, ACK, FIN, RST, PSH, URG) and what role does each play?
What are the main TCP flags (SYN, ACK, FIN, RST, PSH, URG) and what role does each play?
SYN opens a connection (initial handshake). ACK acknowledges received bytes (set on almost every segment). FIN gracefully shuts down one side. RST aborts the connection abruptly. PSH hints the receiver to deliver buffered data immediately (low-latency traffic). URG with urgent pointer marks out-of-band data, rarely used today.
Common mistakes
- ✗Confusing FIN and RST — FIN is graceful, RST is unilateral abort
- ✗Believing PSH actually flushes buffers in the kernel — it's a hint
- ✗Treating retransmissions as new SYNs
Follow-up questions
- →What is a half-closed connection?
- →Why is RST commonly seen on connection refused?
MiddleTheoryCommonHow does the WebSocket protocol upgrade from HTTP and what is it used for?
How does the WebSocket protocol upgrade from HTTP and what is it used for?
Client sends HTTP/1.1 GET with Upgrade: websocket, Connection: Upgrade, Sec-WebSocket-Key. Server replies 101 Switching Protocols with matching Sec-WebSocket-Accept. Same TCP is reused for full-duplex framed messages. Used for real-time chat, multiplayer, dashboards, push. Over TLS: port 443 with wss://.
Common mistakes
- ✗Forgetting to handle ping/pong frames — proxies kill idle connections
- ✗Not implementing reconnect with exponential backoff in clients
- ✗Trying to use HTTP/2's server push for streaming where WebSockets are simpler
Follow-up questions
- →How does HTTP/2 server-sent events differ from WebSocket?
- →Why does the WebSocket key use SHA-1 — is that secure?
SeniorDesignCommonAn application calls an HTTP API over the network. Walk through, end to end, everything the system does to deliver that request and return the response — from the application's call down through the operating system and network stack, across the physical network, to the server and back. Cover how the destination is resolved, how the connection and any encryption are established, how the data is wrapped as it descends the stack, and where intermediaries on the path get involved.
An application calls an HTTP API over the network. Walk through, end to end, everything the system does to deliver that request and return the response — from the application's call down through the operating system and network stack, across the physical network, to the server and back. Cover how the destination is resolved, how the connection and any encryption are established, how the data is wrapped as it descends the stack, and where intermediaries on the path get involved.
Request traverses: (1) app API call; (2) OS socket + TCP/IP stack; (3) DNS (cache → stub → recursive → authoritative); (4) TCP 3-way handshake; (5) TLS if HTTPS; (6) HTTP request; (7) ARP, routing, NAT, load balancer; (8) server processing; (9) response reverses. Encapsulation: HTTP body → TCP segment → IP packet → Ethernet frame.
Open full question →Common mistakes
- ✗Skipping DNS latency in estimates — a cold DNS lookup adds 20–200 ms; OS cache, browser cache, and EDNS0 TTL management are critical for performance
- ✗Not accounting for connection establishment cost — TCP + TLS adds 1.5–2 RTTs; connection pooling and keep-alive eliminate this overhead for subsequent requests
- ✗Ignoring the OS TCP buffer and Nagle's algorithm — small writes are coalesced by default;
TCP_NODELAYdisables Nagle for latency-sensitive protocols
Follow-up questions
- →At what point does ARP get involved, and how does it differ for a cross-subnet request?
- →How does a reverse proxy (nginx) change the request lifecycle compared to a direct connection?
JuniorTheoryOccasionalWhat does IPv6 fix that IPv4 has problems with?
What does IPv6 fix that IPv4 has problems with?
IPv6 has 128-bit addresses (vs 32-bit) — practically unlimited space, no NAT needed. Header is fixed-size, simpler (extension headers replace options). No router fragmentation — only sender via PMTUD. Built-in IPsec, SLAAC autoconfig, better multicast. Slow adoption is a coexistence issue (dual-stack, NAT64/DNS64), not technical.
Common mistakes
- ✗Hardcoding IPv4-only socket logic —
getaddrinforeturns either family - ✗Forgetting brackets around IPv6 in URLs:
http://[::1]:8080/ - ✗Assuming IPv4 mapped addresses (
::ffff:1.2.3.4) work everywhere
Follow-up questions
- →What is SLAAC and how does it differ from DHCPv6?
- →Why are there fewer ICMPv6 'unreachable' types than ICMP for IPv4?
JuniorTheoryOccasionalCompare the OSI and TCP/IP network models.
Compare the OSI and TCP/IP network models.
OSI is a 7-layer theoretical reference model (Physical, Data Link, Network, Transport, Session, Presentation, Application). TCP/IP has 4 layers: Network Access (≈L1+L2), Internet (L3 IP), Transport (L4 TCP/UDP), Application (≈L5–L7 HTTP/DNS). TCP/IP is what is actually implemented; OSI is used for teaching and diagnosing where a problem occurs.
Common mistakes
- ✗Confusing the TCP/IP 'Application' layer with OSI's Application layer — TCP/IP Application covers OSI L5+L6+L7
- ✗Placing TLS at L4 — TLS sits logically between L4 (TCP) and L7 (HTTP), often called L4.5 or described as 'on top of transport, below application'
- ✗Thinking ARP is a Layer 3 protocol — ARP operates at L2/L3 boundary; it maps L3 (IP) addresses to L2 (MAC) addresses
Follow-up questions
- →What happens at each layer when you send an HTTP request?
- →How does a switch differ from a router in terms of OSI layers?
MiddleTheoryOccasionalDescribe application-layer protocols (HTTP, FTP, DNS, WebSocket).
Describe application-layer protocols (HTTP, FTP, DNS, WebSocket).
HTTP/1.1: text over TCP, stateless, keep-alive. HTTP/2: binary framing, multiplexing, HPACK. HTTP/3: QUIC/UDP, no TCP head-of-line blocking. FTP: two TCP — control (21) + data (20); replaced by SFTP. DNS: names → IPs via UDP/53, TCP fallback; root → TLD → authoritative. WebSocket: HTTP upgrade to full-duplex framed channel.
Common mistakes
- ✗Thinking HTTP/2 solves all latency problems — multiplexing helps but TCP-level head-of-line blocking still exists; HTTP/3 (QUIC) solves this
- ✗Using FTP for secure file transfer — FTP sends credentials in plaintext; use SFTP (SSH-based) or FTPS (FTP + TLS) for security
- ✗Keeping WebSocket connections alive without heartbeats — NAT gateways and load balancers close idle connections; send application-level ping frames every 30-60 seconds
Follow-up questions
- →How does HTTP/2 header compression (HPACK) work and what is HPACK bombing?
- →What is the WebSocket upgrade handshake and what HTTP headers are involved?
MiddleTheoryOccasionalWhat are L4 vs L7 load balancers and how do they differ?
What are L4 vs L7 load balancers and how do they differ?
L4 (transport) routes by IP/port without inspecting the payload — fast and simple, doesn't terminate TLS (e.g. AWS NLB, IPVS). L7 (application) inspects HTTP headers, paths, and methods — supports routing rules, TLS termination, retries, and observability (e.g. AWS ALB, nginx, Envoy). L4 wins on throughput; L7 wins on flexibility.
Common mistakes
- ✗Trying to do canary routing on L4 — needs payload inspection
- ✗Putting an L7 LB in front for raw TCP traffic — wastes CPU on parsing
- ✗Forgetting that L7 sees plaintext — TLS termination happens there
Follow-up questions
- →How does consistent hashing improve L4 load balancing?
- →What is sticky session and when is it needed?
MiddleTheoryOccasionalWhat is serialization, and which C++ libraries are commonly used for it?
What is serialization, and which C++ libraries are commonly used for it?
Serialization converts an in-memory object graph into a byte stream for storage or transmission; deserialization restores it. Text formats (JSON, XML) are readable; binary formats (Protobuf, FlatBuffers, Cap'n Proto) are compact and fast. Common C++ libraries: nlohmann/json, Protobuf, cereal, Boost.Serialization.
Common mistakes
- ✗Serializing raw pointers — pointer values are address-space-specific; serialize the pointed-to data, not the address
- ✗Skipping schema versioning — adding a required Protobuf field breaks every existing reader; reserve field numbers and prefer optional fields
- ✗Choosing JSON for high-throughput RPC — parsing cost dominates at high RPS; binary formats are orders of magnitude faster
Follow-up questions
- →How does Protobuf maintain backwards compatibility through optional fields and reserved field numbers?
- →How does FlatBuffers' zero-copy design differ from Protobuf's classical parsing?
SeniorTheoryOccasionalHow do HTTP/2 and HTTP/3 differ from HTTP/1.1 at the transport level?
How do HTTP/2 and HTTP/3 differ from HTTP/1.1 at the transport level?
HTTP/2 multiplexes many streams over one TCP connection and compresses headers, but a lost packet still stalls every stream — TCP head-of-line blocking. HTTP/3 instead runs over QUIC on UDP, giving per-stream loss recovery and a faster combined transport-plus-TLS handshake.
Common mistakes
- ✗Believing
HTTP/2removes head-of-line blocking entirely — it only removes it at the HTTP layer, not atTCP - ✗Thinking
QUICis a transport sitting besideTCPrather than a protocol built onUDP - ✗Assuming
HTTP/3is always faster, ignoring that some networks throttle or blockUDP
Follow-up questions
- →Why does
QUICintegrate the TLS handshake into connection setup? - →What is connection migration in
QUICand why does it help mobile clients?
SeniorTheoryOccasionalWhat is RPC? Libraries and protocols.
What is RPC? Libraries and protocols.
RPC lets a program call a function on another process/machine as if local: stubs serialise arguments, send them over the network, and return the result. gRPC uses Protobuf+HTTP/2.
Common mistakes
- ✗Designing RPC like a local function call — network calls can fail, be slow, or be partially executed; always handle timeouts, retries, and idempotency
- ✗Not versioning the service interface — adding a required field to a Protobuf message breaks all existing clients
- ✗Using synchronous blocking RPC for all calls — for high-throughput services, streaming or async gRPC prevents thread exhaustion
Follow-up questions
- →How does gRPC handle service discovery and load balancing?
- →What is the difference between gRPC streaming and WebSocket?
SeniorTheoryOccasionalHow does TCP congestion control work, and how does it differ from flow control?
How does TCP congestion control work, and how does it differ from flow control?
Congestion control is the sender's reaction to network capacity: it grows cwnd exponentially in slow start, linearly in congestion avoidance, and shrinks it on loss. Flow control protects the receiver's buffer via the advertised window. The sender transmits at the minimum of the two windows.
Common mistakes
- ✗Conflating
cwnd(congestion window, sender-side estimate) withrwnd(receive window, advertised by receiver) - ✗Thinking slow start is slow — it ramps exponentially and is actually aggressive
- ✗Forgetting the sender transmits at min(
cwnd,rwnd), so either limit can dominate
Follow-up questions
- →What triggers the transition from slow start to congestion avoidance?
- →How do loss-based and delay-based algorithms like BBR differ?
SeniorTheoryOccasionalWalk through a TLS 1.3 handshake step by step.
Walk through a TLS 1.3 handshake step by step.
1) Client → ClientHello: ciphersuites, key shares (X25519/secp256r1), SNI. 2) Server → ServerHello, Certificate, CertificateVerify, Finished — under handshake keys. 3) Client verifies chain, sends Finished. 1-RTT; 0-RTT via session ticket. TLS 1.3 dropped RSA, MD5/SHA-1, compression, renegotiation.
Common mistakes
- ✗Confusing TLS 1.2 (2-RTT) with TLS 1.3 (1-RTT)
- ✗Using 0-RTT for non-idempotent requests — replay attack risk
- ✗Trusting the cert without OCSP/CRL revocation check
Follow-up questions
- →Why was RSA key exchange removed in TLS 1.3?
- →What is OCSP stapling?
JuniorTheoryRareWhat IPv4 address range is reserved for multicast?
What IPv4 address range is reserved for multicast?
The range 224.0.0.0/4 — from 224.0.0.0 to 239.255.255.255, historically «class D». Its defining bit pattern is the high four bits set to 1110. A destination address outside this block is unicast (or broadcast) and can never name a multicast group.
Common mistakes
- ✗Confusing the multicast block
224.0.0.0/4with the reserved «class E» block240.0.0.0/4 - ✗Thinking only
224.x.x.xis multicast — the block runs through all of239.255.255.255 - ✗Believing multicast is a header flag rather than encoded in the destination address itself
Follow-up questions
- →What is special about the link-local sub-range
224.0.0.0/24? - →How does an IPv4 multicast group address map onto an Ethernet MAC address?
MiddleTheoryRareWhat is MTU and how does fragmentation work in IPv4 vs IPv6?
What is MTU and how does fragmentation work in IPv4 vs IPv6?
MTU is the largest packet a link can carry without fragmentation (Ethernet ~1500 bytes). IPv4 routers may fragment oversized packets and the receiver reassembles; IPv6 forbids router fragmentation, so only the sender fragments after Path MTU Discovery via ICMP 'Packet Too Big'. Firewalls dropping ICMP break PMTUD, hence TCP MSS clamping.
Common mistakes
- ✗Blocking all ICMP at firewall and breaking PMTUD
- ✗Assuming MTU is always 1500 — VPNs/tunnels reduce it
- ✗Confusing MTU with MSS (MSS = MTU - IP - TCP headers)
Follow-up questions
- →How does TCP MSS clamping work and why is it sometimes needed?
- →What is jumbo frame and when is it useful?
MiddleTheoryRareHow does shutdown() differ from close() on a socket shared across fork()?
How does shutdown() differ from close() on a socket shared across fork()?
close() only drops one reference to the fd. After fork() both processes hold a reference, so a child's close() leaves the connection alive through the parent. shutdown() acts on the shared socket object itself — it ends a direction and can send a TCP FIN, visible to every process.
Common mistakes
- ✗Expecting a child's
close()to terminate the connection — it only drops the child's reference - ✗Swapping the two roles: thinking
shutdown()is the reference-counted call andclose()the global one - ✗Believing
shutdown()is process-local — it changes the shared socket and the peer sees the FIN
Follow-up questions
- →What do the
SHUT_RD,SHUT_WR, andSHUT_RDWRarguments toshutdown()each do? - →Why is
shutdown(SHUT_WR)the clean way to signal end-of-stream before reading the reply?
SeniorDesignRareYou must design a single server that sustains 100k concurrent client connections, most of them idle but long-lived. The naive thread-per-connection model collapses at this scale, so explain the I/O and concurrency model you would build instead, why it scales where the naive one does not, how many worker threads you would run relative to CPU cores, and which operating-system limits you would have to tune.
You must design a single server that sustains 100k concurrent client connections, most of them idle but long-lived. The naive thread-per-connection model collapses at this scale, so explain the I/O and concurrency model you would build instead, why it scales where the naive one does not, how many worker threads you would run relative to CPU cores, and which operating-system limits you would have to tune.
Drop thread-per-connection — 100k threads exhaust memory and the scheduler. Use event-driven I/O multiplexing (epoll/kqueue/IOCP) with non-blocking sockets, a small worker pool of about one thread per core, and O(1) readiness notification. This is the classic C10k/C10M problem.
Common mistakes
- ✗Reaching for
select()/poll()at scale — they areO(n)per call and cap out around 1024 fds - ✗Spawning unbounded threads, exhausting stack memory and drowning the scheduler in context switches
- ✗Forgetting to tune kernel limits —
ulimit -n, ephemeral port range, socket buffers
Follow-up questions
- →Why is
epolledge-triggered mode more efficient but trickier than level-triggered? - →How does
SO_REUSEPORThelp distribute accepts across worker threads?
SeniorTheoryRareWhat does TLS 1.3 change, and what is the risk of 0-RTT?
What does TLS 1.3 change, and what is the risk of 0-RTT?
TLS 1.3 cuts the handshake to one round trip, drops legacy ciphers and RSA key exchange, and mandates forward secrecy. 0-RTT lets a resumed session send application data in the first flight, but that early data is replayable — so it must carry only idempotent requests.
Common mistakes
- ✗Calling
0-RTTdata simply 'insecure' — it is encrypted, the specific problem is replayability - ✗Sending non-idempotent requests (e.g.
POSTthat mutates state) as0-RTTearly data - ✗Assuming
TLS 1.3resumption with0-RTTstill provides forward secrecy for the early data
Follow-up questions
- →How can a server mitigate
0-RTTreplay attacks at the application layer? - →Why did
TLS 1.3remove RSA key exchange in favor of ephemeral Diffie-Hellman?
