Networking Fundamentals and Protocols Questions

Direct answer
TIME_WAIT is the state the side that sent the FINAL ACK of a connection close sits in for a fixed period (commonly twice the maximum expected segment lifetime, often around 60 seconds on Linux) before the connection's resources are fully released. It exists so a delayed, duplicate packet from an old connection can't be mistaken for part of a brand-new connection reusing the same address/port pair. A half-open connection is one where only one side still believes the connection is alive; the other side has already reset, crashed, or otherwise abandoned it without a clean FIN exchange.

Structured elaboration
TIME_WAIT exists to protect two things: (1) it guarantees the final ACK the closing side sent actually gets through, by giving time to retransmit it if the peer's FIN gets retransmitted (meaning the ACK was lost); (2) it prevents a stray, delayed packet from a previous incarnation of a connection (same 4-tuple: source IP, source port, destination IP, destination port) from being delivered into a brand new connection that happens to reuse the same 4-tuple before the old segments have had time to disappear from the network.

To detect a large number of sockets stuck in TIME_WAIT on Linux, ss -tan state time-wait | wc -l (or the older netstat -ant | grep TIME_WAIT | wc -l) gives a live count; watching this metric over time distinguishes a normal, self-draining backlog from a genuine problem.

Worked example
A server that closes millions of short-lived outbound connections per hour (for instance, a service making one HTTP call per request to an upstream) can exhaust its available ephemeral source ports if TIME_WAIT sockets accumulate faster than they expire, because each TIME_WAIT socket still holds its port reserved. The two standard mitigations are: raise the number of available client-side (ephemeral) ports and/or reuse connections via keepalive/connection pooling so fewer connections churn through TIME_WAIT in the first place; and, on the SERVER side specifically, enabling SO_REUSEADDR and, where safe, tcp_tw_reuse lets a new outgoing connection reuse a TIME_WAIT 4-tuple once TCP timestamps confirm it's safe to do so, rather than waiting out the full timer.

Trade-offs & pitfalls
Disabling or drastically shortening TIME_WAIT globally (rather than tuning port ranges or reuse settings) is the wrong fix: it reintroduces the exact correctness problem TIME_WAIT was designed to prevent, stray old packets landing in a new connection and corrupting it. The safe levers are reducing HOW MANY connections churn through the state (pooling, keepalive) and widening the ephemeral port range, not shrinking the safety window itself.

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
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
IPv6 removed the ability for ROUTERS along the path to fragment a packet; only the ORIGINATING host may fragment an IPv6 packet, using a dedicated fragmentation extension header, which pushes the entire responsibility for correctly sizing packets (and reacting to Path MTU, Maximum Transmission Unit, Discovery feedback) onto the sender rather than sharing it with the network.

Structured elaboration
In IPv4, any router along the path could fragment a packet too large for its outgoing link (unless the Don't Fragment bit was set), a convenience that came at real cost: routers doing fragmentation work on the fly, and receivers having to reassemble fragments that could have been created by ANY device along the path, not just the sender. IPv6's designers removed this entirely: routers now MUST drop an IPv6 packet that's too large for the next link and send back an ICMPv6 "Packet Too Big" message reporting the link's MTU, rather than fragmenting it themselves. If the ORIGINATING host still needs to send data larger than the smallest MTU along the path, it must fragment the packet itself, before sending, using the IPv6 Fragment extension header (which carries the same conceptual information as IPv4's Identification/Flags/Offset fields, just in a dedicated extension header rather than baked into the main IP header).

Worked example
This design change makes Path MTU Discovery load-bearing in IPv6 in a way it wasn't strictly required to be in IPv4: since no device in the middle of the path can rescue an oversized packet by fragmenting it, a sender that doesn't properly discover and respect the path's minimum MTU will simply have its packets dropped along the way (with an ICMPv6 message reporting why, PROVIDED that message isn't itself being filtered somewhere, the classic PMTUD-blackhole failure mode). This is also why a middlebox in the middle of an IPv6 path is a materially different kind of obstacle than in IPv4: it cannot silently paper over an oversized-packet problem by fragmenting on the sender's behalf; it can only drop and (hopefully) report back.

Trade-offs & pitfalls
The IPv6 design trades away routers' ability to "fix" an oversized packet on the fly in exchange for a simpler, more predictable job for routers (never having to fragment) and a stronger incentive for senders to get Path MTU Discovery right in the first place, rather than relying on the network to quietly compensate for an oversized packet. The practical implication: if ICMPv6 "Packet Too Big" messages are filtered anywhere along an IPv6 path (the same class of misconfiguration that breaks IPv4 PMTUD), there is NO fallback fragmentation happening in the middle of the path to mask the problem, the failure is more absolute than the equivalent IPv4 case.

Direct answer
Flow control protects the RECEIVER from being overwhelmed by data it can't process fast enough; congestion control protects the NETWORK from being overwhelmed by more traffic than the path between sender and receiver can actually carry. They use different signals and different windows, and confusing them leads to fixing the wrong end of the problem.

Structured elaboration
Flow control is implemented via the receive window (often written rwnd): the receiver advertises, in every ACK, how many more bytes of buffer space it currently has available. If the receiver's application is slow to read data out of its socket buffer, the advertised window shrinks, telling the sender to slow down regardless of how healthy the network path is. This is purely an endpoint-to-endpoint negotiation; the network in between plays no role.

Congestion control is implemented via the congestion window (cwnd), a value the SENDER maintains based on inferred network conditions, growing during slow start and congestion avoidance, and shrinking sharply when loss (or, with explicit congestion notification, an ECN mark) signals that the path is overloaded. Crucially, the sender is never allowed to have more unacknowledged data in flight than the SMALLER of rwnd and cwnd, whichever is more restrictive wins.

Worked example
Consider a video-conferencing server pushing data to a client on a fast, low-latency corporate network with no packet loss anywhere on the path. If the client's own CPU is pegged and its application isn't draining its TCP receive buffer fast enough, throughput will stall even though the network itself has plenty of headroom, that's a rwnd (flow control) problem, and the fix is on the client (free up CPU, drain the socket faster), not on the network. Conversely, if the same server saturates a congested shared WAN link, cwnd will shrink due to loss even though the receiver's buffer is empty and eager for more data, that's a congestion-control problem, and the fix is either reducing the amount of data in flight or addressing the actual network bottleneck, not the receiver.

Trade-offs & pitfalls
Confusing the two leads to genuinely wrong fixes: tuning net.ipv4.tcp_rmem (receive buffer size, which affects flow control's rwnd) will do nothing for a connection that's actually congestion-limited, and conversely, tuning the congestion control algorithm won't help a connection that's flow-control-limited by a slow receiving application. The fastest way to tell them apart in practice: watch which window value (rwnd vs cwnd) is the SMALLER, limiting one during the stall, most modern TCP instrumentation (ss -i on Linux) exposes both.