Summary

  • TCP implicitly gives SYN and FIN one position each in sequence space so those control events can be acknowledged and retransmitted without being acted upon twice.
  • SYN is ordered before the first data octet in its segment; FIN is ordered after the last data octet in its segment.
  • The occupied positions are protocol bookkeeping, not application bytes, and other flags such as ACK, PSH and RST do not receive the same one-position treatment.
  • Because each direction has its own sequence space, a FIN ends only its sender's stream direction and consumes a number only there.

A sequence number for an event

TCP's reliable service begins with a simple-looking instrument: number the octets, acknowledge the next one expected, and retransmit what remains unacknowledged. Opening and closing create a harder problem. SYN and FIN are control events rather than payload, but losing or duplicating either one can change the meaning of the connection.

RFC 793 solved that problem by extending the numbering scheme to selected control information. Its rationale is explicit: a sequenced control can be retransmitted and acknowledged without confusion, so one and only one copy is acted upon. The current standard, RFC 9293, preserves both the mechanism and that reason.

The result is not that a SYN or FIN becomes an octet. The flag remains in the TCP header, outside the segment's data space. TCP merely reserves a logical position for it in the arithmetic that orders arrivals, advances acknowledgments and retires retransmission-queue entries.

SYN goes before the bytes

For an ordinary data segment, the sequence-number field identifies the first data octet. SYN is the exception. When SYN is set, the field carries the initial sequence number, and the first data octet is numbered ISN+1.

That ordering matters even when a SYN carries application data, which TCP permits. The control event occupies the first position; the data follows. A receiver acknowledging the SYN advances its next-expected boundary by one before counting any attached data. A retransmitted SYN reuses the same position rather than announcing a second opening event.

This article does not revisit how the ISN is chosen or why it must be difficult for an off-path attacker to predict. Those are separate questions. Here the important point is what comes immediately after the chosen ISN: the sequence space advances because the SYN itself must be reliably ordered.

FIN goes after the bytes

FIN uses the opposite edge. TCP considers it to occur after the last actual data octet in the segment that carries it. If a segment begins at sequence number S, contains N application octets and also carries FIN, its logical sequence length is N+1. The FIN occupies the position after the N bytes.

That placement prevents the close event from overtaking data in the same direction. The receiver can acknowledge through the bytes and then through FIN using one cumulative boundary. If FIN must be retransmitted, its repeated copy refers to the same sequence position and does not create another end of stream.

FIN means that its sender has no more data to send. It does not by itself close the reverse direction, whose sequence space and closing event belong to the other endpoint. Counting FIN therefore supports TCP's directional close semantics; it does not collapse them into a single shared switch.

What SEG.LEN really counts

Both specifications define SEG.LEN so that it counts the data octets and also counts SYN and FIN. The formula for the last occupied sequence number, the receive-window tests and the rule for deciding when a retransmission-queue entry is fully acknowledged all use that logical length.

A packet capture can therefore appear puzzling if payload length is treated as the whole sequence-space advance. A zero-data SYN or FIN still advances the next expected number by one. A segment with N data octets and one of those flags advances it by N+1. If SYN and FIN were ever considered together in the arithmetic, each would contribute its own position, though their normal roles remain opening and closing.

The distinction between logical length and physical payload is the central design move. TCP did not put a synthetic byte into the application stream. It made its accounting wide enough to include the two control events that needed reliable, ordered treatment.

Why the other flags do not join them

RFC 9293 says SYN and FIN are the only controls requiring this protection. ACK makes the acknowledgment field significant; PSH expresses a push function; RST deletes connection state when accepted. None of those flags, merely by being set, adds one to SEG.LEN.

That asymmetry follows the job of the sequence space. SYN establishes the starting edge of a stream, and FIN establishes its ending edge. Both must occupy an ordered point relative to data. An acknowledgment instead reports the receiver's boundary. PSH asks for progress without defining a boundary. RST is expressly described as occupying no sequence space.

The rule is thus narrower than the slogan that “TCP flags consume sequence numbers.” Most do not. The accurate statement is that TCP implicitly numbers SYN and FIN because these opening and closing controls need the duplicate protection, ordering and acknowledgment machinery of the stream.

Sources