Networking Fundamentals and Protocols Questions

Direct answer
Encapsulation is the process of wrapping data in a new header (and sometimes trailer) as it moves down the protocol stack, and stripping those headers back off as it moves up the stack on the receiving side. Each layer only understands its own header; it treats everything handed to it by the layer above as an opaque payload.

Structured elaboration
Follow a browser's HTTP request to a web server, header by header, going down the sender's stack:

1. Application layer: the browser produces an HTTP request (method, path, headers, body).
2. Transport layer: TCP wraps that request in a TCP segment, adding a header with source port, destination port, sequence number, acknowledgment number, and flags. The whole HTTP request becomes the segment's payload.
3. Network layer: IP wraps the TCP segment in an IP packet, adding a header with the source IP address and destination IP address. The TCP segment becomes the packet's payload.
4. Data link layer: Ethernet wraps the IP packet in a frame, adding a header with the source MAC address and destination MAC address (and a trailer with a frame check sequence for error detection). The IP packet becomes the frame's payload.
5. Physical layer: the frame is converted to bits and transmitted as electrical, optical, or radio signals.

On the receiving side, decapsulation runs in exactly the reverse order: the physical layer recovers bits into a frame, the data link layer strips the Ethernet header/trailer and hands the IP packet up, the network layer strips the IP header and hands the TCP segment up, the transport layer strips the TCP header and hands the HTTP request up, and the application layer finally sees the original request.

Worked example
Concretely, by the time the original HTTP request bytes reach the wire, they are surrounded by four layers of header (ignoring the physical layer, which isn't a header at all): [Ethernet header][IP header][TCP header][HTTP request bytes][Ethernet trailer]. Each intermediate device on the path (a switch, a router) only needs to look at the headers relevant to its own layer: a switch reads the Ethernet header to decide which port to forward the frame out of; a router strips the Ethernet framing entirely, reads the IP header to decide the next hop, and re-wraps the same IP packet in a NEW Ethernet frame addressed to the next hop's MAC address. The TCP header and the HTTP payload never change as the packet crosses the network; only the Layer 2 framing gets rewritten at each hop.

Trade-offs & pitfalls
The most common confusion is expecting the MAC addresses in the Ethernet header to stay constant end-to-end, they don't. Only the IP addresses (Network layer) stay constant from source to destination; the MAC addresses (Data Link layer) change at every hop, because Ethernet framing is only meaningful on a single link, not across the whole path.

Direct answer
The TCP/IP (Internet) model has four layers: Link, Internet, Transport, and Application. It maps onto the seven-layer OSI model by collapsing OSI's bottom two layers into "Link" and its top three into "Application."

Structured elaboration

Both models describe the same reality; they just carve it up at different granularity. OSI was designed as a general, vendor-neutral reference standard, drawn up before the protocols that would actually win were finalized, so it separates concerns the real internet protocol suite never bothered to split (nothing on the modern internet implements a distinct Session or Presentation layer as its own protocol). TCP/IP is the model that grew directly out of the protocols that were actually built and deployed, so it only has as many layers as the real stack needs to describe.

Worked example
Take a single HTTPS request. In TCP/IP terms: Application layer is HTTPS/TLS+HTTP, Transport is TCP, Internet is IP, Link is Ethernet or Wi-Fi. In OSI terms, the same request spans Layer 7 (HTTP semantics), arguably Layer 6 (TLS's encryption/format role, though in practice TLS libraries sit logically between transport and application), Layer 4 (TCP), Layer 3 (IP), and Layers 2/1 (the local network technology). Neither model is "more correct"; TCP/IP is more useful for describing what's actually running, OSI is more useful for a shared vocabulary when discussing where a NEW piece of functionality should live.

Trade-offs & pitfalls
A common mistake is treating the OSI-to-TCP/IP mapping as one-to-one instead of many-to-one. Session and Presentation don't disappear in TCP/IP, they're just not modeled as distinct layers because no widely deployed protocol maps cleanly onto only one of them. When someone asks "what OSI layer does TLS operate at," the honest answer is "it doesn't map cleanly, and that's expected," not a forced single number.

Direct answer
TCP is connection-oriented and guarantees reliable, in-order delivery with built-in flow and congestion control, at the cost of handshake setup latency and head-of-line blocking; UDP is connectionless, with no delivery guarantees, ordering, or congestion control, trading reliability for minimal overhead and lower latency. The right choice depends on whether the application can tolerate loss and reordering itself, or needs the transport layer to handle it.

Structured elaboration

Two examples per protocol: TCP is the right choice for a database connection or a file transfer, where losing or reordering even one byte silently would corrupt the result, and the application has no interest in reimplementing reliability itself. UDP is the right choice for live video/voice calls or DNS queries, where a single lost or late packet is better DISCARDED and moved past (an old, out-of-order audio frame is useless once its playback moment has passed) than retransmitted at the cost of added latency that would make the whole stream feel laggy.

Worked example
A scenario where building custom reliability ON TOP of UDP beats plain TCP: a real-time multiplayer game sending frequent position updates. TCP's strict in-order delivery means a single lost packet blocks EVERY later packet from being delivered to the application until the lost one is retransmitted and received (head-of-line blocking), even if those later packets contain fresher, more relevant position data. Building a thin reliability layer over UDP lets the application decide per-message whether it's worth retransmitting (a player's current position, three updates old, usually isn't worth retransmitting, a newer update has probably already superseded it) rather than being forced into strict in-order delivery for data where "newest wins" matters more than "nothing lost."

Trade-offs & pitfalls
A common mistake is treating "TCP is reliable, UDP isn't" as the END of the analysis; the real question is whether your application's OWN definition of correctness matches TCP's specific guarantees (strict ordering, full reliability) or would be better served by a custom scheme that's more permissive in exactly the ways TCP is rigid. Building your own reliability on UDP is real engineering work (implementing retransmission, sequencing, and congestion awareness yourself), not a shortcut, it's justified specifically when TCP's guarantees don't match what the application actually needs.

Direct answer
A port is a 16-bit number identifying an endpoint on a host; a socket is the (IP address, port, protocol) combination that uniquely names one endpoint; and a connection (the 4-tuple, or 5-tuple if you count the protocol) is the full pairing of BOTH endpoints' sockets, source IP, source port, destination IP, destination port. Many clients can share the same server port because what actually distinguishes their traffic is the FULL 4-tuple, not the destination port alone.

Structured elaboration
Port ranges are conventionally split three ways: well-known ports (0-1023, traditionally requiring elevated privilege to bind on Unix-like systems, and reserved by convention for standard services like 443 for HTTPS), registered ports (1024-49151, registered with IANA for specific applications but not privileged), and ephemeral (or dynamic/private) ports (49152-65535 by IANA convention, though many OSes use a wider practical range), which the OS assigns automatically to the CLIENT side of an outgoing connection.

A server listening on port 443 can serve thousands of simultaneous clients because the SERVER's port (443) is only ONE piece of what identifies each connection; every incoming connection also carries a distinct client IP and, typically, a distinct client-side ephemeral port, so the full 4-tuple (client IP, client port, server IP, server port) is what the OS actually uses to demultiplex incoming packets to the right connection, even though the server-side half of that tuple (server IP and port) is identical across all of them.

Worked example
Two different clients, 203.0.113.5 and 203.0.113.9, can both have simultaneous connections to a web server at 198.51.100.1:443. Client A's connection might use ephemeral port 51000 and client B's might use 51000 too (a coincidence, since each client picks its own ephemeral ports independently), yet the server has no trouble distinguishing them, because the full 4-tuples are different: (203.0.113.5, 51000, 198.51.100.1, 443) versus (203.0.113.9, 51000, 198.51.100.1, 443). If client A instead opens a SECOND connection to the same server, its OS will typically pick a DIFFERENT ephemeral port for that second connection (since a client can't have two identical 4-tuples open at once to the same destination), giving something like (203.0.113.5, 51001, 198.51.100.1, 443).

Trade-offs & pitfalls
NAT changes what a receiver actually observes on the wire: a device behind a NAT gateway sharing one public IP will have its ephemeral port REWRITTEN by the NAT device (Port Address Translation) so that multiple internal hosts sharing the same public IP can still be distinguished by the server, meaning the source port a server sees is often not the port the ORIGINAL client actually used, a common source of confusion when correlating server-side logs against client-side application behavior.

Direct answer

HTTP/1.1 sends one request at a time per TCP connection (browsers open around 6 parallel connections per host to fake concurrency), and every request resends its headers as plain text. HTTP/2 multiplexes many requests over one TCP connection as interleaved binary frames, and compresses headers with HPACK so repeated values are not resent in full. That is why HTTP/2 speeds up a page with many small requests with zero code changes.

Structured elaboration

HTTP/1.1: one request in flight per connection at a time; pipelining exists in the spec but is rarely used, since a slow response at the front blocks everything queued behind it.
HTTP/2: one connection carries multiple streams as binary frames tagged with a stream ID, so a slow response on one stream does not block a fast one on another; HPACK's shared table sends a repeated header value in full once, then references it cheaply after.

Worked example

A page needs 20 same-origin requests, each with about 500 bytes of headers that barely change. HTTP/1.1 with 6 parallel connections needs 4 waves (6, 6, 6, then 2), resending the full ~500 bytes each time: 20 times 500 equals 10,000 bytes. HTTP/2 sends all 20 at once; if only the first pays the full ~500 bytes and the other 19 change ~15 bytes each (19 times 15 equals 285), total header bytes drop to about 785.

Trade-offs and pitfalls

• HTTP/2 only fixes head-of-line blocking at the HTTP layer; one TCP connection still delivers bytes in order, so one lost segment stalls every stream (HTTP/3/QUIC fixes this with per-stream delivery over UDP).
• It does not help a page bottlenecked by one large, slow request, and some older CDNs still lack clean HTTP/2 support.

What the interviewer probes next

Expect a follow-up on why HTTP/2 still suffers head-of-line blocking at the TCP layer, and what HTTP/3 changes about that.