Networking Fundamentals and Protocols Questions

Direct answer
The OSI model splits network communication into seven layers, each handing off a well-defined unit of work to the layer above and below it: Physical, Data Link, Network, Transport, Session, Presentation, and Application. Knowing which layer a protocol or symptom belongs to lets you reason about failures systematically instead of guessing.

Structured elaboration

The mnemonic that matters more than memorizing names is the DIRECTION of responsibility: each layer only needs to trust the layer directly below it to deliver its unit of data, and it only exposes a clean interface to the layer above. That's what lets a Transport-layer protocol like TCP work identically over Ethernet, Wi-Fi, or a VPN tunnel: it never needs to know which Layer 1/2 technology is underneath.

Worked example
Say a user reports "the site is down." Layer-by-layer reasoning turns that vague complaint into a specific hypothesis:

• Physical/Data Link symptom: the NIC shows no link light, or ip link reports the interface as DOWN a cable or switch-port problem.
• Network layer symptom: ping to the server's IP times out but the local gateway responds a routing problem somewhere between here and there.
• Transport layer symptom: ping succeeds but a TCP connection to the port hangs or resets a firewall, a service that isn't listening, or a transport-level issue.
• Application layer symptom: the TCP connection completes but the HTTP response is an error or garbage the service is up but misbehaving.

Each of these is a different team, a different fix, and a different urgency. That's the actual payoff of the model: it turns "the site is down" into "which layer, which evidence."

Trade-offs & pitfalls
The OSI model is a teaching and troubleshooting framework, not how real stacks are literally implemented. Session and Presentation are rarely separate pieces of code in modern systems; TLS, for instance, is commonly described as "sits between Transport and Application" rather than cleanly as Layer 6. Don't over-fit a real symptom to exactly one layer: a firewall dropping SYN packets looks like a Transport-layer symptom (connection never establishes) but the actual cause and fix live at a security-policy layer that OSI doesn't model at all.

Direct answer
The UDP header is deliberately minimal, just four fields: source port, destination port, length, and checksum, and it provides no reliability, no ordering, and no flow or congestion control at all. The checksum is optional over IPv4 (it can be all-zeros to mean "not computed") but MANDATORY over IPv6, since IPv6 dropped the network-layer checksum that IPv4 had, leaving UDP's checksum as the only integrity check left covering the payload for that traffic.

Structured elaboration

• Source port (16 bits): the sending application's port, allowing a reply to be addressed back to the right process; can legitimately be zero if no reply is expected.
• Destination port (16 bits): identifies which application on the receiving host should get the datagram.
• Length (16 bits): the total length of the UDP header plus payload, in bytes, this is how a receiver knows where the datagram actually ends (UDP has no separate "end of message" marker otherwise).
• Checksum (16 bits): a checksum computed over a pseudo-header (which includes the source/destination IP addresses, borrowed conceptually from the IP layer to catch certain misdelivery errors) plus the UDP header and payload.

Over IPv4, the sender is technically permitted to skip computing the checksum entirely, since IPv4 packets already carry a header checksum which catches SOME corruption, though notably NOT payload corruption. Over IPv6, sending a UDP checksum is mandatory, precisely because IPv6 has no header checksum of its own at all, so UDP's checksum became the last line of defense for detecting corruption anywhere in the packet.

Worked example
If corrupted UDP payloads are reaching an application in production despite the checksum being enabled, that's actually a meaningful signal about WHERE the corruption is happening: a valid checksum plus corrupted payload data can only mean the corruption happened AFTER the checksum was computed and BEFORE the packet was actually transmitted onto the wire (for instance, in host memory, in a buggy driver, or in hardware), or that checksum offloading to the NIC is misconfigured or buggy (many NICs compute the checksum in hardware rather than the OS, and a broken offload implementation can silently produce or accept bad checksums). It would NOT typically indicate ordinary in-transit bit-flip corruption, since that's exactly the class of error the checksum exists to catch and reject.

Trade-offs & pitfalls
The 16-bit checksum, while better than nothing, is not cryptographically strong and won't catch every possible corruption pattern, especially certain kinds of systematic bit errors; applications with strict data-integrity requirements over UDP (like some real-time media or gaming protocols) often layer their own additional integrity or authentication checks on top rather than relying on the UDP checksum alone.

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
Over the life of a connection, TCP's congestion window grows exponentially in slow start, switches to growing linearly in congestion avoidance once it approaches a known safe ceiling, and reacts to loss with fast retransmit and fast recovery rather than always restarting from scratch.

Structured elaboration

1. Slow start: the connection begins with a small congestion window (historically 1 segment; modern stacks start higher, commonly around 10 segments per RFC 6928) and roughly DOUBLES the window every round trip, since each of the ACKs for the previous batch triggers sending two new segments. This continues until either loss occurs, or the window reaches a threshold called ssthresh (slow start threshold), at which point the sender switches strategies.
2. Congestion avoidance: once at or above ssthresh, growth switches from exponential to roughly linear (classically, additive increase of about one segment per round trip), a much more cautious probe for additional capacity.
3. Fast retransmit: if the sender sees three duplicate ACKs (the receiver repeatedly acknowledging the same byte, implying a specific segment is missing but LATER data did arrive), it retransmits the missing segment immediately, without waiting for the retransmission timer to expire, since three duplicate ACKs is strong, specific evidence of loss rather than simple reordering.
4. Fast recovery: after a fast retransmit, rather than collapsing all the way back to slow start, ssthresh is set to about half the current window, and the window itself is set near that halved value, so the sender doesn't have to re-earn all its previous progress from a window of one segment; it resumes near where it estimates the path can actually sustain.

Worked example
Picture a connection whose window has grown to 64 segments in flight when a single segment is lost and detected via three duplicate ACKs (not a full timeout). Fast retransmit resends the missing segment immediately. Fast recovery sets ssthresh to roughly 32 (half of 64) and the window to near that value, then resumes congestion avoidance's linear growth from there, rather than collapsing to slow start's small initial window and doubling all the way back up. Contrast this with a RETRANSMISSION TIMEOUT (no duplicate ACKs arrived at all, meaning the loss was severe enough that the whole flight of data went missing): that's a much stronger loss signal, and the sender resets ssthresh to half the current window but drops the actual window all the way back to slow start's minimum, since a timeout implies the path may be far more broken than a few duplicate ACKs would suggest.

Trade-offs & pitfalls
It's a common mistake to say TCP always halves its window on any loss and moves on; a full retransmission timeout is treated far more conservatively (full reset to slow start) than a fast-retransmit-detected loss (a much gentler recovery), because the ABSENCE of any duplicate ACKs at all is itself informative: it suggests either a much larger loss event or a badly congested/broken path, not just one unlucky dropped segment.

Direct answer
TCP's retransmission timeout (RTO) is computed from a smoothed estimate of round-trip time (SRTT) plus a term for how MUCH the round-trip time has been varying (RTTVAR), not from RTT alone, so the timer stays reasonably tight on a stable path and automatically widens on a noisy one.

Structured elaboration
The standard algorithm (RFC 6298) updates two running estimates on every new RTT sample:
$\text{RTTVAR} = (1-\beta)\cdot \text{RTTVAR} + \beta \cdot |\text{SRTT} - \text{RTT}_{\text{sample}}|$
$\text{SRTT} = (1-\alpha)\cdot \text{SRTT} + \alpha \cdot \text{RTT}_{\text{sample}}$
with the standard constants $\alpha = 1/8$ and $\beta = 1/4$. The retransmission timeout itself is then:
$\text{RTO} = \text{SRTT} + \max(\text{clock granularity}, 4 \cdot \text{RTTVAR})$
The intuition: if round-trip times are steady (RTTVAR is small), RTO sits close to the smoothed RTT, so genuine loss is detected quickly. If round-trip times are jittery (RTTVAR is large, common on congested or highly variable paths), RTO widens automatically, so ordinary jitter isn't mistaken for loss and doesn't trigger a storm of unnecessary retransmissions.

Retransmissions triggered purely by the RTO timer firing (as opposed to fast retransmit via duplicate ACKs) are treated as a MUCH stronger signal of serious congestion, since it means not even a single later segment's ACK arrived to trigger a duplicate-ACK-based fast retransmit; the response is to collapse all the way back to slow start, not the gentler fast-recovery halving.

Worked example
Suppose a connection's SRTT has settled around 50ms with RTTVAR around 10ms. RTO would be approximately $50 + 4\times10 = 90$ ms. If a burst of network jitter pushes several samples up to 120ms, RTTVAR grows to reflect that variability (say to 25ms), and RTO widens to roughly $70 + 4\times25 = 170$ ms (SRTT itself also shifts upward, more slowly, toward the new samples). This is why an environment full of many short-lived connections (each starting from scratch with no RTT history) behaves differently from one with few long-lived connections (which have had time to build a stable, well-calibrated SRTT/RTTVAR estimate): short-lived connections are stuck using a generic initial RTO (commonly 1 second per RFC 6298) until they've collected enough samples to calibrate, making them systematically slower to detect a REAL loss early in their life.

Trade-offs & pitfalls
A common mistake is assuming a single fixed RTO value would be simpler and just as effective; a fixed timeout either fires too eagerly on a naturally variable path (spurious retransmissions that waste bandwidth and can trigger unnecessary congestion-window collapses) or too slowly on a stable path (wasted time before a real loss is detected), the adaptive SRTT/RTTVAR scheme exists specifically to avoid both failure modes at once.