TCP sequence numbers describe bytes, not messages

An established TCP segment's sequence number normally identifies its first payload byte. A payload of length L beginning at S covers the half-open interval [S,S+L): it includes S and excludes S+L. This notation makes adjacent ranges fit without overlap. Retransmission can divide the same bytes into different segments, so packet boundaries are not permanent message boundaries. A receiver can return one application read containing several writes, or several reads containing one write. The application needs its own framing rule, such as a length prefix, before it can recover records.

The acknowledgment number names the next byte expected in order. If all bytes below 5,000 are present but byte 5,000 is missing, the cumulative acknowledgment remains 5,000 even when later data has arrived. Do not subtract one twice: ACK 5,000 acknowledges bytes through 4,999, relative to that direction's sequence space. The two directions have independent sequence numbering. A packet carrying both payload and an ACK simultaneously advances one ledger and reports progress on the other; its two numbers need not be numerically related.

SYN and FIN each consume one sequence number even though neither is an application payload byte. With initial sequence number 900, a SYN occupies position 900 and the first ordinary data byte begins at 901. A FIN after the last payload byte similarly needs acknowledgment. An ACK-only segment consumes no new sequence position. These distinctions matter when checking a handshake or a half-close: a one-position difference may represent a control flag rather than a missing character, and closing one sending direction does not automatically close the other direction.

The header contains a 32-bit sequence field, so its displayed value eventually wraps. A numerically smaller value can be later in the stream. TCP comparisons use circular sequence-space rules together with windows and lifetime protections, not an unrestricted unsigned less-than comparison. For a short trace, unwrap positions into a larger local integer coordinate only when the connection context makes the ordering unambiguous. Reusing a four-tuple or ignoring the handshake can incorrectly combine distinct connections. A capture's convenient relative sequence numbers are an analysis convention rather than extra fields sent on the wire.

A cumulative ACK reports transport-level receipt into the receiving TCP's ordered stream. It does not establish that an application parsed a record, committed a database transaction, or persisted a file across power loss. A connection failure after a server received a payment request but before the client received the response therefore leaves an application-level ambiguity. Request identifiers and a durable deduplication contract solve a different problem from retransmitting TCP bytes. Transport reliability prevents duplicate stream bytes from being delivered as repeated positions; it does not make separately retried business requests exactly once.

Use the binomial lab as an intentionally narrower thought experiment about missing pieces. Let success mean delivery of an independently transmitted, equal-role segment, set delivery probability to 0.9, and compare five with ten trials. Predict why the chance that every segment arrives falls as the batch grows even though each segment has the same success chance. The bars count delivered segments, not their locations; they cannot determine a cumulative ACK. Return to your range ledger to locate the earliest hole. Real correlated losses, retransmissions, and reordering are outside this model.