TCP Header Structure

Introduction: Fields of the TCP Header

The IP packet carries a TCP segment between hosts, while the TCP header contains fields describing the connection and stream processing. It specifies ports, sequence numbers, acknowledgments, the window size, and control flags. Together, these fields support ordered delivery, error detection, and connection management. The base layout is followed by application data.

Before application data is sent, the TCP software on the sending computer constructs this header. The header is prepended to the application payload to form a TCP segment. A segment can also carry no application data. The complete segment is then handed to the IP layer, which adds an IP header and creates a packet for transmission across the network.

Each TCP header field addresses a specific problem related to data ordering, error detection, flow control, or connection management.

Overall Structure of the TCP Header

The TCP header has a standardized structure. Its base size is 20 bytes (160 bits), but it can be larger if optional fields are included, up to a maximum of 60 bytes. The header is organized as a series of fields, each with a fixed size and specific purpose. The receiver interprets fields according to their order and length. This layout is shared by data and control segments.

The receiver uses the header fields to identify the connection and interpret the segment. The base layout in RFC 9293 has four reserved bits and eight control flags. RFC 9768 assigns one of those reserved bits to Accurate ECN.

Source Port and Destination Port

These two fields provide the basic endpoint identifiers within the TCP header.

• Source Port (16 bits): This field identifies the port number of the application that sent the segment on the source machine. When a client application like a web browser initiates a connection, the operating system assigns it a temporary, ephemeral port from the dynamic range. This number is placed in the source port field so that the server knows where to send its reply.
• Destination Port (16 bits): This field identifies the port number of the application that is meant to receive the segment on the destination machine. For server applications, this is typically a well-known port associated with a standard service, such as port 443 for a secure web server (HTTPS).

Together, the combination of source IP, source port, destination IP, and destination port creates a unique identifier for a specific TCP connection, allowing a single server to handle thousands of client connections simultaneously.

Sequence Number (32 bits)

This field supports TCP reliability and ordered delivery. TCP treats application data as a byte stream and numbers every byte in that stream.

For a segment carrying data without the SYN flag, the Sequence Number field contains the number of the first byte of data in its payload. For example, if a segment contains 100 bytes of data and its sequence number is 501, it means this segment carries bytes 501 through 600 of the total data stream. A SYN segment uses the Initial Sequence Number and consumes one sequence number.

The field has 32 bits, so numbering covers $2^{32}$ values, or 4 GiB, before wrapping around. On high-speed networks, a delayed segment from a previous cycle can resemble a new one; sequence-number comparison mechanisms limit this risk.

During connection setup (the three-way handshake), the client and server exchange an unpredictable Initial Sequence Number (ISN). Subsequent sequence numbers are derived relative to this starting point.

Acknowledgment Number (32 bits)

This field is the counterpart to the Sequence Number and is the mechanism for confirming the successful receipt of data. It is only considered valid if the ACK control flag is set.

The value of the Acknowledgment Number field indicates the sequence number of the next byte the sender is expecting from the other party. This acknowledgment is cumulative. For example, if the receiver sends back an acknowledgment number of 750, it is confirming that it has successfully and correctly received all data bytes up to sequence number 749, and it is now ready for byte 750.

This cumulative acknowledgment system is efficient but can lead to ambiguity if a single segment is lost. If segments 1, 2, and 4 arrive, but segment 3 is lost, the receiver will keep acknowledging the sequence number of the start of segment 3 until it arrives. More advanced options like Selective Acknowledgment (SACK) can address this.

Header Length (4 bits)

This field, sometimes called the Data Offset, is necessary because the TCP header is not always a fixed size. The base size is 20 bytes, but it can be extended by the TCP Options field. This 4-bit field specifies the total length of the header in 32-bit words (4-byte units).

The minimum value is 5, corresponding to a 20-byte header $(5 \times 4 \text{ bytes} = 20 \text{ bytes})$. The maximum is 15, corresponding to a 60-byte header $(15 \times 4 \text{ bytes} = 60 \text{ bytes})$. The field tells the receiver where the header ends and application data begins.

Reserved bits

RFC 9293 reserves four bits for future use. Without a negotiated extension, the sender sets them to zero and the receiver ignores them. RFC 9768 assigns the bit immediately before CWR to AE (Accurate ECN), leaving three bits reserved. This allocation extends congestion feedback without increasing the fixed header size.

Control flags and Accurate ECN

RFC 9293 defines eight control flags: CWR, ECE, URG, ACK, PSH, RST, SYN, and FIN. RFC 9768 adds AE at the position previously used by the historical NS flag. Once AccECN is negotiated, AE, CWR, and ECE jointly form the three-bit ACE field for congestion feedback. The separate CWR and ECE meanings apply to Classic ECN.

• AE (Accurate ECN): Negotiates AccECN support during the handshake and then contributes to the ACE counter. Its interpretation depends on the feedback mode agreed by both endpoints.

• NS (Nonce Sum): A historical experimental flag used by ECN Nonce. RFC 8311 retired that experiment, and RFC 9768 subsequently assigned the bit to AE.

• CWR (Congestion Window Reduced): In Classic ECN, set by the sender to indicate that it has reduced its sending rate after receiving a segment with the ECE flag set. In AccECN mode, this bit contributes to the ACE counter instead of carrying this standalone CWR signal.

• ECE (ECN-Echo): Used in Explicit Congestion Notification (ECN). In Classic ECN, set by a receiver to inform the sender that it received a signal of network congestion from a router. In AccECN mode, this bit contributes to the ACE counter instead of carrying a standalone ECE echo.

• URG (Urgent): Indicates that the Urgent Pointer field is significant. It marks urgent data whose handling depends on the TCP interface semantics; the data remains part of the ordered stream.

• ACK (Acknowledgment): Indicates that the Acknowledgment Number field is valid. Nearly all packets sent after the initial SYN packet will have this flag set.

• PSH (Push): A request to pass data to the application without deliberately waiting for the buffer to fill. It does not define a separate data channel or guarantee immediate delivery to the application. It can be useful for interactive applications such as Telnet.

• RST (Reset): Immediately terminates a connection in response to an error. This is an abrupt way to end a session, for example, if one side receives a packet for a connection that no longer exists or if there is a fatal error.

• SYN (Synchronize): Used in the SYN and SYN-ACK segments during connection establishment. It synchronizes the initial sequence numbers between the two hosts; retransmissions can repeat these segments.

• FIN (Finish): Signals that the sender has no more data to send in its direction of the stream. It starts connection closing; this often leads to four segments, but other sequences are possible.

Window Size (16 bits)

This field is the core of TCP's flow control mechanism. It specifies the number of bytes, starting from the byte indicated in the Acknowledgment Number field, that the sender of this segment is currently willing to receive.

The receiver reports X bytes of free buffer space, so the sender should not transmit more than X additional bytes until a new update arrives. This prevents the sender from exceeding the receiver's capacity. Since the field is 16 bits, the maximum unscaled advertisement is 65,535 bytes. On high-speed, long-distance paths this limit can restrict throughput, which led to the Window Scale TCP option.

Checksum (16 bits)

The checksum field is used for basic error detection. The sender calculates a 16-bit checksum value based on the contents of the TCP header, the application data, and a special pseudo-header. The receiver performs the same calculation. If the results differ, the receiver knows the segment was corrupted in transit and discards it.

The pseudo-header is a conceptual structure that includes the source and destination IP addresses, the transport-protocol identifier, and the TCP segment length. TCP uses protocol number 6 in IPv4; IPv6 uses the Next Header value, including the effect of any IPv6 extension headers. Including the addresses in the checksum helps detect cases where IP misdelivered a segment to the wrong host or protocol.

Urgent Pointer (16 bits)

This field is only valid if the URG flag is set. It is a 16-bit offset from the current sequence number that points to the sequence number of the octet following the urgent data. This lets the receiving system interpret the urgent-data range, for example a Ctrl-C break command in a remote terminal session, according to the TCP interface semantics.

TCP Options (Variable Length) and Padding

The base 20-byte TCP header provides the core functionality, but modern networking requires additional features. The Options field allows for this extensibility. It can be up to 40 bytes long. If options are used, the Header Length field will have a value greater than 5.

Common options include:

• Maximum Segment Size (MSS): This option is sent in SYN segments. Each side uses it to announce the largest amount of TCP data it is willing to receive in one segment. This helps avoid IP fragmentation, which can degrade network performance.
• Window Scale: Solves the limitation of the 16-bit Window Size field. It is a scaling factor (a power of 2) that multiplies the value in the Window Size field, allowing much larger receive windows, up to about 1 GiB with the maximum shift of 14. This supports high throughput on paths with a large Bandwidth-Delay Product.
• Selective Acknowledgment (SACK): Allows the receiver to acknowledge non-contiguous blocks of received data. This is much more efficient than the standard cumulative ACK when multiple packets are lost from a single window of data.
• Timestamps: When negotiated, adds timestamp information to TCP segments. It supports Round-Trip Time (RTT) measurement and provides another mechanism to protect against wrapped sequence numbers (PAWS - Protection Against Wrapped Sequence numbers).

Finally, Padding is used to ensure that the total length of the header is a multiple of 4 bytes. Since some options do not end on a 4-byte boundary, zero bytes are added as padding to fill out the last 32-bit word of the header.