You are building real-time features for a web application and the interviewer probes your networking fundamentals across several layers of the stack. Answer the following, treating each as its own discussion. Be precise about *direction*, *protocol*, *latency*, and *operational impact* — vague hand-waving ("it's faster") will be pushed back on. ### Constraints & Assumptions - Modern evergreen browsers and a typical cloud deployment (load balancer / reverse proxy in front of stateless app servers). - "Real-time" here means low-latency server-to-client and/or client-to-server messaging, not strict hard-real-time guarantees. - Assume HTTPS everywhere; TLS is non-negotiable. - You should reason about behavior on both stable wired networks and lossy/mobile networks where relevant. ### Clarifying Questions to Ask - What is the messaging pattern: server→client only, client→server only, or truly bidirectional? - What is the expected concurrent connection count and message rate per client (sizing connection/memory budgets)? - Are there proxies, CDNs, or corporate firewalls in the path that might buffer responses, terminate idle connections, or block UDP? - What client platforms must be supported (browser only, native mobile, IoT), and is there a hard backward-compatibility floor? - What are the latency and delivery-guarantee requirements (best-effort vs. at-least-once with resume)? ### Part 1 **WebSocket vs. Server-Sent Events (SSE)** (and note where long polling fits). Compare them on: communication direction (uni-/bidirectional), transport/protocol and how the connection is established, browser/client support, reconnection behavior, scalability and load-balancer/proxy implications, and typical use cases. Conclude with a decision rule for choosing among the three. ```hint Frame the axis first The single biggest discriminator is **directionality**: is data flowing server→client only, or do you need the client to push messages too? Anchor the comparison there before talking transport. ``` ```hint Connection establishment Recall *how each starts*: WebSocket begins as an HTTP/1.1 request with an `Upgrade: websocket` handshake then switches protocols; SSE is just a long-lived HTTP response with `Content-Type: text/event-stream`. That difference drives the proxy/LB story. ``` ```hint Reconnection & ops Think about who owns reconnection logic (the browser's `EventSource` vs. your own client code) and what infrastructure has to change: sticky sessions, idle-timeout tuning, response buffering, and the need for a shared pub/sub fan-out layer when multiple app servers must reach one client. ``` #### What This Part Should Cover - Correct directionality and transport for each (full-duplex over a single TCP connection vs. unidirectional over plain HTTP). - The handshake/establishment mechanism and resulting proxy/load-balancer considerations. - Reconnection semantics (built-in `EventSource` auto-reconnect with `Last-Event-ID` vs. hand-rolled), and fan-out/sticky-session scaling concerns. - A defensible decision rule mapping each option to a use case, including where long polling is the right fallback. ### Part 2 **The OSI model.** Describe the purpose of each of the seven layers and give a common protocol or technology example for each. Then explain how the 7-layer OSI model maps onto the practical 4-layer TCP/IP model, and why engineers tend to reason in the latter. ```hint Mnemonic + anchor each layer to a protocol Walk L1→L7 and pin a concrete example to each (Ethernet PHY, MAC/Ethernet frames, IP, TCP/UDP, ...). Naming a protocol per layer is what shows you actually understand the layer's job. ``` ```hint The collapse The TCP/IP model collapses OSI's seven into four. Think about which OSI layers merge: physical+data-link, and especially session+presentation+application. ``` #### What This Part Should Cover - All seven layers named with their responsibility and a correct example protocol/technology per layer. - A correct OSI→TCP/IP mapping (Link ≈ L1–L2, Internet ≈ L3, Transport ≈ L4, Application ≈ L5–L7). - Awareness that OSI is primarily a teaching/diagnostic framework and that real stacks blur the boundaries (e.g., where TLS sits). ### Part 3 **TCP vs. QUIC.** Compare them on: where they run (kernel vs. user space), connection-establishment / handshake latency, TLS integration, multiplexing and head-of-line blocking, connection migration, and when QUIC is preferred (e.g., HTTP/3). Include the tradeoffs that argue *against* QUIC. ```hint Start from the substrate QUIC runs over **UDP** in user space, while TCP lives in the OS kernel. Nearly every QUIC advantage (faster iteration, integrated crypto, per-stream loss handling) traces back to those two facts — start there. ``` ```hint Head-of-line blocking — be specific about the layer HOL blocking exists at two layers. HTTP/2 removed *application*-layer HOL but still rides one TCP connection, so a single lost packet stalls *all* streams (transport HOL). Explain precisely how QUIC's per-stream design fixes the transport-layer case. ``` #### What This Part Should Cover - The user-space/UDP vs. kernel/TCP distinction and its consequences (deployability, iteration speed). - Handshake-latency comparison (TCP 3-way + separate TLS vs. QUIC's combined transport+TLS 1.3 handshake, incl. 0-RTT resumption) and the fact that TLS 1.3 is mandatory and built into QUIC. - Correct treatment of multiplexing and the transport-layer head-of-line-blocking difference between HTTP/2-over-TCP and HTTP/3-over-QUIC. - Connection migration via connection IDs, and the counterarguments (UDP CPU cost, middlebox/firewall blocking of UDP, observability challenges). ### What a Strong Answer Covers Across all three parts, a strong candidate consistently moves from *what* (mechanism/protocol) → *why* (latency, reliability, infra compatibility) → *when* (concrete use case), rather than reciting trivia. They are precise about which layer a behavior lives at (e.g., distinguishing transport- vs. application-layer head-of-line blocking, or where TLS sits), and they surface the operational and tradeoff angles — proxy/LB behavior, sticky sessions and fan-out, UDP blocking, kernel-vs-user-space deployability — not just the feature checklist. ### Follow-up Questions - For Part 1: a single app server can hold tens of thousands of WebSocket connections — how do you push a message to one user when their connection lives on a *different* server in the fleet? - For Part 2: where does TLS sit in the OSI model, and why is that placement genuinely debatable? - For Part 3: QUIC promises 0-RTT connection resumption — what security risk does 0-RTT data introduce, and how is it mitigated? - Across parts: a corporate firewall blocks UDP entirely. Which of these technologies still work, and what does the client/server do to degrade gracefully?