Networking Fundamentals and Protocols Questions

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
For large object-storage transfers, the levers worth investigating, roughly in order of impact, are: making sure window scaling and socket buffers are large enough for the path's bandwidth-delay product, enabling NIC-level offloads so the CPU isn't the bottleneck at high throughput, and deciding whether to use several parallel connections or one well-tuned connection based on whether the limiting factor is per-connection window size or something else entirely (like a single flow being unfairly rate-limited by a middlebox).

Structured elaboration
First, confirm the connection's window (after scaling) and OS socket buffers are large enough to cover the path's bandwidth-delay product, undersized buffers here silently cap throughput regardless of how good everything else is (this is the same BDP-sizing exercise as tuning any other high-bandwidth, high-latency transfer). Second, check NIC-level segmentation offloads: TSO/GSO let the OS hand large chunks of data to the NIC and have the NIC itself split them into wire-sized frames, and LRO does the reverse on receive, coalescing many small incoming frames before handing them to the OS; without these, the CPU has to do that segmentation/coalescing work itself, and at multi-gigabit throughput that CPU cost can become the actual bottleneck well before the network link itself is saturated. Third, decide on Nagle's algorithm (which delays sending small writes to coalesce them into fewer, larger segments): for large sequential transfers, Nagle is rarely the bottleneck since writes are already large, but for anything issuing many small writes interleaved with reads, disabling it (TCP_NODELAY) avoids needless latency.

Worked example
The parallel-versus-single-connection decision comes down to WHAT is actually being limited. If a single connection's throughput is capped by its own maximum achievable window (even after correct BDP-based tuning, some paths or middleboxes limit an individual flow's effective window more aggressively than the path's own capacity), opening several parallel connections lets the AGGREGATE throughput exceed what one connection alone could reach, effectively working around a per-flow limit by using multiple flows. But parallel connections add real complexity: more connection-management overhead, more complexity assembling the transferred object back together correctly if it's split across connections, and, on a link SHARED with other traffic, an unfair grab of a disproportionate share of available bandwidth compared to a well-behaved single flow. If the true bottleneck is the raw link capacity itself (not a per-flow cap), splitting into parallel connections doesn't help, and one well-tuned single connection is simpler and just as fast.

Trade-offs & pitfalls
It's tempting to reach for "just add more parallel connections" as a default fix for slow transfers, but that only helps when the limiting factor is genuinely per-connection (a window/RTT/middlebox constraint on a single flow), and on a genuinely bandwidth-saturated shared link, more parallel connections from one client mostly just take a larger, less fair share of that link away from other traffic rather than achieving any real net throughput gain.

Direct answer
QUIC achieves per-stream reliability and ordering without TCP's single shared sequence space by giving each logical stream its OWN independent sequence numbering and loss recovery, all multiplexed inside one UDP-based connection; a lost packet carrying data for stream A doesn't block already-arrived data for stream B from being delivered to the application, which is exactly the head-of-line blocking that a single TCP connection carrying multiple HTTP/2 streams suffers from.

Structured elaboration
Over plain TCP, HTTP/2 multiplexes many logical request/response streams onto ONE underlying TCP connection with ONE sequence-number space; TCP itself has no concept of "streams" at all, it just sees one ordered byte stream. If a single TCP segment is lost, TCP's in-order delivery guarantee means EVERY byte after that point, even bytes belonging to a completely different, otherwise-unaffected HTTP/2 stream, is held back until the lost segment is retransmitted and recovered. This is transport-level head-of-line blocking: the transport's OWN reliability guarantee (strict ordering) becomes a liability once a single connection is asked to carry multiple independent logical streams.

QUIC solves this by moving stream multiplexing INTO the transport layer itself, rather than layering it on top of a single ordered byte stream: each stream has its own sequence space and its own independent reliability/ordering guarantee, so a loss affecting one stream's data only blocks THAT stream's delivery, other streams' already-arrived data can be delivered to the application immediately, with no need to wait.

Worked example
Practically, building this on UDP (rather than trying to retrofit multi-stream awareness into TCP itself) was the pragmatic choice because TCP's behavior is deeply embedded in operating system kernels, network hardware, and middleboxes across the internet; changing TCP's fundamental semantics at that scale is far harder than building a new protocol on top of UDP, which is deliberately minimal and gives QUIC a mostly-blank slate to define its own semantics, while still being able to traverse the internet's existing UDP-forwarding infrastructure without needing every router and middlebox to understand the new protocol.

Trade-offs & pitfalls
This is a genuine, structural advantage for workloads with multiple independent logical streams sharing a connection (which is exactly the HTTP/2-and-later web-traffic pattern), but it isn't a free win for every workload: an application sending one single, purely sequential stream of data (like a straightforward large-file download) doesn't gain the same benefit from per-stream independence, since it only has one stream to begin with, the head-of-line-blocking problem QUIC solves specifically arises from MULTIPLE independent streams sharing one connection.

Direct answer
A duplicate ACK is the receiver re-acknowledging the same byte offset it already acknowledged, which happens when a later, out-of-order segment arrives before the one actually missing; three duplicate ACKs in a row is treated as strong enough evidence of real loss to trigger an immediate fast retransmit, without waiting for the slower retransmission timer.

Structured elaboration
Normally, each ACK acknowledges progressively more data as segments arrive in order. If segment N is lost but segment N+1 arrives (out of the expected order relative to what the receiver is still waiting for), the receiver can't advance its cumulative ACK past the end of segment N-1, so it re-sends an ACK for the SAME byte offset it already acknowledged, that's the duplicate ACK. One or two duplicate ACKs are common and unremarkable (ordinary, brief reordering happens on real networks); but THREE duplicate ACKs in a row is treated as a strong enough signal that data is genuinely missing (not just briefly reordered) to justify retransmitting immediately, well before the (much slower) retransmission timeout would otherwise fire.

Distinguishing genuine loss from simple reordering, in practice: sustained duplicate ACKs (three or more, continuing as MORE out-of-order segments keep arriving) point to real loss, since a purely reordering event typically self-resolves within one or two duplicate ACKs once the delayed segment catches up. A pattern of isolated single or double duplicate ACKs that stop on their own, with no retransmission ultimately needed, points to reordering rather than loss; TCP's own reordering-tolerance thresholds (adjacent to, but distinct from, PAWS: Protect Against Wrapped Sequence numbers) exist specifically to avoid triggering a fast retransmit on every minor reordering event.

Worked example
A sender transmits segments carrying bytes 1000-1500, 1500-2000, 2000-2500, and 2500-3000. If the segment carrying 1500-2000 is lost but the other three arrive, the receiver sends: ACK 1500 (for the first segment, normal), then ACK 1500 again upon receiving 2000-2500 (a duplicate, since 1500-2000 is still missing), then ACK 1500 again upon receiving 2500-3000 (a second duplicate). On the THIRD duplicate ACK for 1500, the sender's fast retransmit fires and it resends the 1500-2000 segment immediately, rather than waiting for its retransmission timer (which, per the RTO calculation, could be tens to hundreds of milliseconds longer) to expire.

Trade-offs & pitfalls
The right mitigation depends entirely on which cause is confirmed: if it's genuine loss, the useful levers are addressing the actual loss source (a congested link, a flaky physical connection) or, at the transport layer, ensuring SACK (Selective Acknowledgment) is enabled so only the truly missing segment gets resent. If it's reordering (for instance, from a load balancer or ECMP path hashing packets across multiple physical paths with slightly different latencies), the fix is architectural (favor flow-based hashing that keeps a single connection's packets on one path) rather than anything TCP-level, since TCP is already tolerating ordinary reordering correctly; treating a reordering pattern as loss and "fixing" the transport layer for it addresses the wrong layer.

Direct answer
TCP Fast Open (TFO) lets a client include application data directly in its SYN packet on a REPEAT connection to a server it has connected to before, skipping the usual "wait for the handshake to finish before sending anything" round trip; the risk is that some middleboxes, built assuming a SYN never carries a meaningful payload, may drop, strip, or misforward that data, or even the whole packet, since it doesn't look like a standard handshake to them.

Structured elaboration
TFO works by having the server issue a cryptographic cookie to the client the FIRST time they connect (during a normal handshake, no fast-open data yet). On any SUBSEQUENT connection attempt, the client includes that cookie plus its actual application data directly in the SYN packet. If the server validates the cookie, it can begin processing that data immediately, effectively saving a full round trip compared to the standard "handshake completes, THEN data starts flowing" sequence.

The middlebox risk comes from an assumption baked into a lot of older network equipment: that a SYN packet is control-plane-only and never carries a meaningful payload. Some middleboxes (older NAT devices, certain firewalls, some load balancers) built on that assumption may strip TCP options they don't recognize (breaking the cookie mechanism itself), drop SYN packets that carry payload as anomalous or suspicious, or in some documented cases, mishandle the connection entirely.

Worked example
The required fallback behavior: if a TFO attempt's SYN (carrying the cookie and data) gets no response, or gets a response that doesn't correctly acknowledge the fast-open data, a correct client implementation must FALL BACK to a standard handshake, retransmitting the SYN WITHOUT the fast-open data and cookie, and only sending the actual application data after the connection is fully, conventionally established. This fallback is what keeps TFO safe to enable broadly: in the worst case (a hostile middlebox on the path), the connection degrades to ordinary TCP behavior rather than failing outright, the client just loses the round-trip savings TFO was trying to provide, it never loses connectivity because of it.

Trade-offs & pitfalls
The whole design of TFO is built around the assumption that middlebox interference IS common enough to plan for, not a rare edge case, that's precisely why the fallback-to-standard-handshake behavior is a REQUIRED part of any compliant implementation, not an optional nicety. An implementation that assumes TFO will always succeed and doesn't implement the fallback path correctly risks connections silently failing specifically on paths that include one of these older devices, exactly the class of path where the round-trip savings would have mattered most (since those paths tend to be higher-latency, longer routes).