TCP

Find the delay in the capture and say what caused it.

Decide from the capture whether the host is unreachable, filtered, or simply not listening.

Using only the client-side capture, determine why the connection fails.

Find the moment the sender changed its behaviour and say what triggered it.

Explain how sending more produced less, using the capture.

A browser opens http://shop.example.test — connection setup only.

After the handshake, the browser sends a GET and the server answers.

Handshake, HTTP exchange, and a polite four-way close — every common flag in one trace.

A client uploads 6000 bytes to a slow server whose application stops reading — the window closes to zero, then reopens.

The first data segment is lost in transit. A later segment triggers a duplicate ACK, the retransmission timer fires, and TCP recovers.

Both sides close politely: FIN, ACK, FIN, ACK — then TIME-WAIT.

Nothing is listening on port 80 — the SYN is answered with an immediate RST.

The server application crashes mid-conversation and aborts with an RST.

A client uploads a 21.9 KB file. Watch cwnd double each round trip, one segment get lost, three duplicate ACKs trigger a fast retransmit, and the window halve.

A 6 KB upload to a well-behaved receiver: full-sized segments, prompt reads, steady cumulative ACKs — window management as intended.

The server app sips 200 bytes at a time and the stack advertises every tiny opening (no SWS avoidance) — watch the connection degenerate into 200-byte crumbs.

Identical sipping application, but the stack follows RFC 9293: window updates held until worth advertising, no crumb segments sent. Same app, healthy wire.

Eight keystrokes typed into a remote session with Nagle disabled: one 41-byte-overhead packet per byte of typing.

The same eight keystrokes with Nagle enabled: the first byte goes immediately, the rest coalesce behind the outstanding ACK — self-clocked batching.

Client announces MSS 1460, the constrained server announces 536. Each direction obeys the OTHER side's number — watch 1200 bytes travel as 536+536+128 one way and as a single segment the other.

A 4-segment transfer with RFC 1122 §4.2.3.2 delayed ACKs: one ACK per two full segments, and a lone trailing segment ACKed only when the 200 ms timer expires.

The client's SYN carries NO MSS option — so the server must assume the ancient default of 536 bytes and chops its 1200-byte response into 536-byte pieces, even though the client could take 1460.

The client announces MSS 1460, but a middlebox on the path rewrites the SYN's option to 536 in transit. The server obediently sends small segments — and the client never knows why. Inspect the SYN: the wire disagrees with the sender.

A slow link (60 B/ms), a 4-packet router queue, and a sender whose RTO (80 ms) is shorter than the queue-inflated RTT: premature retransmissions flood the queue with duplicates, drops multiply, and goodput falls while total traffic rises.

The identical slow, shallow-queued link — but with a conservative 1-second RTO. The burst tail still overflows the queue, yet every retry now answers a REAL loss: no spurious copies, no duplicates competing with live data.

The receiver's window closes and stays closed for three seconds. A compliant sender probes it — 500 ms, then 1 s, then 2 s — so the reopening can never be lost, then finishes the transfer.

Every data segment is being lost, and this sender retries at a FIXED interval instead of doubling it. Read the timer events: is this host compliant?

Data arrives intact — and vanishes. No ACK ever covers it. Watch the sender retry with growing patience and finally give up. Which host broke the rules, and which packets prove it?

The receiver advertises window 0 — and this sender keeps transmitting anyway. Watch the receiver discard the overrun segments and re-ACK the same edge, over and over.

A 200 ms satellite-class path and 256 KB of buffer on both sides — but no window scaling, so the 16-bit window field caps everything at 65,535 bytes in flight. Watch the sender idle between window-fulls.

Identical path and buffers, but both SYNs offer Window Scale (shift 3). The window field now means ×8, the full 256 KB is usable, and the same file finishes in a fraction of the time.

The client offers shift 2 (×4), the server shift 7 (×128). Both are honoured — each side scales what IT receives. Inspect the two SYNs and the window fields that follow.

The client offers Window Scale; the (older) server's SYN-ACK carries none. Per RFC 7323 §2.2 the offer is void for BOTH directions — watch the connection fall back to raw 16-bit windows.

Every segment carries TSval/TSecr. Each returning ACK echoes the timestamp of the data it acknowledges, giving the sender an exact RTT sample — the raw material for the retransmission timer.

Eight segments; two non-adjacent ones vanish. The receiver can only repeat one number — 'I still need byte X' — so the sender resends far more than was lost.

Identical losses, but SACK-Permitted was negotiated: the receiver now reports exactly which ranges arrived, and the sender retransmits only the two missing segments.

Four request/response exchanges over a rock-steady 40 ms path. Watch SRTT lock onto 40 ms while RTTVAR decays toward zero — and the RTO sit stubbornly at its 1-second floor.

The same steady path, but one response is delayed by 400 ms. Watch a single outlier widen RTTVAR sharply — the estimator buying safety margin exactly when the path proves unpredictable.

A segment is lost, the timer fires and doubles, and the retransmission is finally acknowledged — but that ACK is AMBIGUOUS (which copy did it answer?), so Karn's rule throws the sample away instead of poisoning SRTT.

Identical loss, but the pre-2011 rules: with no measurement yet, the first timer is 3 seconds instead of 1. Compare how long the connection sits blind before it acts.

The same loss under today's rules: the first timer is 1 second, so recovery starts two seconds sooner. This single constant is the headline change from RFC 2988.

cwnd has grown large but the receiver only advertises 4 KB. The sender may use min(cwnd, rwnd) — so flow control, not congestion control, is the brake here.

A burst grows cwnd nicely, then the application goes quiet for eight seconds. When it speaks again the ACK clock is long gone — so cwnd restarts at the initial window rather than trusting stale evidence.

A user reports that shop.example.test never loads. The capture shows what their machine sent — work out what is wrong.

The identical sipping application on a historic stack (every tiny window opening advertised) and on an RFC 9293-compliant stack (updates held, crumbs suppressed).

Eight keystrokes over a 40 ms RTT: one packet per keystroke (Nagle off) versus self-clocked coalescing (Nagle on).

The same 4½-segment transfer ACKed two ways: a receipt per segment versus RFC 1122's one-per-two-full-segments with a bounded timer.

The HTTP exchange with both sides at MSS 1460 versus a constrained server announcing 536 — segment sizes obey the receiver's announcement, per direction.

The same slow, shallow-queued link and the same 17.5 KB transfer — once with an RTO shorter than the queue-inflated RTT (premature retransmissions), once with a conservative timer.

The same 438 KB transfer over the same 200 ms path with 256 KB buffers — once capped by the raw window field, once with Window Scale negotiated.

Eight segments, two non-adjacent losses, identical in both runs. The only difference is whether the receiver may describe what it actually holds.

The same lost segment on the same path, timed by the 2000 rules and by today's. Same formulas, one different constant.