Networking Fundamentals and Protocols Questions

Direct answer
A SYN flood works by sending a stream of SYN segments (often with spoofed source addresses) so the server allocates per-connection state for each one and replies with a SYN-ACK, but the final ACK never arrives, exhausting the server's backlog of half-open connections. SYN cookies let the server defer allocating any state at all until the final ACK actually shows up, so a flood of SYNs that never complete costs the server almost nothing.

Structured elaboration
Without SYN cookies, a normal server implementation stores an entry in its SYN backlog queue for every SYN it receives, holding onto that entry until the handshake completes or times out. A large flood of SYNs fills the backlog with half-open connections, so genuine clients' SYNs get silently dropped once the queue is full, that's the denial of service.

With SYN cookies enabled, once the backlog nears capacity, the server stops storing per-connection state up front. Instead, when it receives a SYN, it encodes the essential information it would normally have stored (effectively a hash of the source/destination IP, ports, and a secret, folded into the initial sequence number it sends back in the SYN-ACK) directly into its own sequence number field, and discards the SYN backlog entry immediately. If the final ACK ever arrives, the server checks that its acknowledgment number is the cookie value plus one, reconstructs the connection state on the spot, and only THEN commits real resources, at the exact moment a real, completing client shows up. If the SYN was part of the flood and no valid ACK ever comes, the server never allocated anything for it in the first place.

Worked example
From the legitimate client's point of view, the handshake looks completely normal: SYN, SYN-ACK, ACK, exactly as usual, it never knows cookies were involved. The difference is entirely server-side bookkeeping. The cost of the cookie scheme is that the server must give up storing some TCP options across the handshake (since there's no room left in a single 32-bit sequence number to also encode arbitrary options like the negotiated MSS (Maximum Segment Size) or window scale precisely), which is why some cookie implementations round MSS to one of a small handful of common values instead of preserving whatever exact value the client requested.

Trade-offs & pitfalls
SYN cookies alone do not stop a volumetric flood from consuming link bandwidth or CPU cycles processing the flood of SYNs in the first place, they only protect the connection-state table from being exhausted. A senior answer distinguishes "the handshake structure survives an attack that tries to exhaust connection state" (what SYN cookies solve) from "the network survives an attack that tries to exhaust bandwidth or CPU" (a separate problem requiring rate limiting, upstream filtering, or scrubbing, outside the scope of the handshake mechanism itself).

Direct answer
A graceful close is a symmetric exchange where each direction of the connection is shut down independently with its own FIN/ACK pair; an abrupt close (RST) tears down both directions immediately and without acknowledgment, discarding any data still in flight.

Structured elaboration
Graceful close, the normal case: the side that's done sending data sends a FIN. The other side ACKs it and moves to CLOSE_WAIT (it can still send its own data; only ONE direction has closed so far). When that side is also done, it sends its own FIN, the original side ACKs it, and both directions are now closed. Because it takes a FIN and an ACK in EACH direction, a full graceful close is normally four messages (though the middle ACK and FIN are frequently combined into one segment in practice), and the side that sent the last ACK enters TIME_WAIT.

Abrupt close via RST: either side can send a RST at any point to say "this connection is invalid, stop immediately," with no ACK expected and no guarantee that data already sent (or in flight) will be delivered or acknowledged. A RST is what you see when a process crashes and the OS cleans up its sockets, when data arrives for a port nothing is listening on, or when an application deliberately aborts a connection instead of finishing a clean handshake-of-goodbyes.

Simultaneous close is the edge case where BOTH sides send a FIN before either has received the other's FIN. Both sides transition through a CLOSING state (rather than one going through FIN_WAIT and the other CLOSE_WAIT) before eventually reaching TIME_WAIT once both FINs are acknowledged. It's rare, but it's why the TCP state machine has a CLOSING state at all: it exists specifically for this race.

Worked example
A RST during the handshake itself, before a connection is even established, means something different from a RST on an established connection: it almost always means nothing is listening on that port (or a firewall/security-group is actively rejecting rather than silently dropping). This is one of the fastest network diagnostics available, a connection refused instantly (RST) tells you the path and host are reachable but the service isn't there, whereas a connection that hangs and eventually times out with no RST tells you the packet may be silently dropped somewhere in the path, a materially different failure to chase down.

Trade-offs & pitfalls
Asymmetric routing can produce a half-open connection that looks alive on one side even after the other side has actually closed: if the FIN from one side never arrives (dropped along an asymmetric or otherwise broken return path), that side can sit in FIN_WAIT or the other side in ESTABLISHED indefinitely from its own perspective, believing the connection is fine when it's not. Keepalive probes exist specifically to eventually detect and clear out this class of half-open zombie connection, since neither side's own state machine will notice on its own.

Direct answer
Selective Acknowledgment (SACK) lets a receiver tell the sender exactly which non-contiguous blocks of data it has ALREADY received, so after a loss the sender only has to retransmit the specific missing segment(s), not everything that came after it.

Structured elaboration
Without SACK, TCP uses cumulative acknowledgment: an ACK only confirms "I have received everything up through this byte, contiguously." If segment 3 of a 10-segment flight is lost but segments 4 through 10 all arrive fine, the receiver can only ACK up through the end of segment 2, it has no way to tell the sender "I actually already have 4 through 10, I'm just missing 3." A sender using only cumulative ACKs, upon detecting the loss, may end up retransmitting segments 3 through 10 (everything the receiver hasn't cumulatively acknowledged), even though 4 through 10 were never actually lost.

With SACK enabled (negotiated via a permitted option in the handshake, then carried on subsequent ACKs), the receiver's ACK can include SACK blocks, explicit ranges of sequence numbers it holds that are NOT contiguous with the main acknowledged run, in the example above, a SACK block spanning segments 4 through 10. Now the sender knows precisely that only segment 3 needs retransmitting.

Worked example
Say a sender has segments with sequence ranges [1000-1500), [1500-2000), [2000-2500), ... up to [4500-5000), and segment [2000-2500) is lost in transit while everything else arrives. Without SACK: the receiver's ACKs stay pinned at ack=2000 (the last contiguous byte received) even as segments up through 5000 keep arriving; the sender, upon detecting the loss (via duplicate ACKs all saying ack=2000), knows only that SOMETHING after 2000 needs resending and, in older/naive implementations, could resend everything from 2000 onward. With SACK: the same duplicate ACKs at ack=2000 now also carry a SACK block like sack=2500-5000, telling the sender explicitly that only the single segment [2000-2500) is actually missing, so it retransmits exactly that one segment and nothing else.

Trade-offs & pitfalls
SACK is most valuable on connections with a large amount of data in flight (a large window relative to segment size) and where losses are isolated rather than in a solid burst, since that's exactly the scenario where "retransmit everything after the gap" wastes the most bandwidth compared to "retransmit only the gap." On a connection with a tiny window, or where an entire flight is lost at once (nothing left to selectively acknowledge), SACK provides little advantage.

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
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.