The TCP Header, Field by Field, and What to Read in a Capture

The fieldsThe TCP header fields, in the order they appear

Two of those TCP header fields cause more confusion than the rest combined, and both are about units.

Data offset is in 32-bit words, not bytes. A value of 5 means a twenty byte TCP header, and 15 means sixty. Reading the field as a byte count is the classic mistake when parsing a packet by hand.

Sequence numbers count bytes, not packets. A segment carrying 1,460 bytes of data advances the sequence number by 1,460, not by one. This is why acknowledgment numbers appear to jump in odd amounts, and it is the reason TCP can acknowledge part of what it received.

The flagsThe TCP flags, and which ones actually matter

Eight flag bits are defined in the TCP header and four of them carry almost all the meaning in practice.

SYN opens a TCP connection and synchronizes the starting sequence numbers. It appears exactly twice in a healthy connection, once in each direction.

ACK says the acknowledgment number field is meaningful. It is set on every segment after the first, so seeing it is unremarkable and its absence on anything but the opening SYN is not.

FIN closes one direction politely. Each side sends its own, so an orderly shutdown has two, and a connection with one FIN is half closed and still legal.

RST aborts immediately. It is the single most informative flag in any capture, because it means a refusal rather than a failure: nothing is listening on that port number, a firewall rejected the packet, or one side gave up on a connection it no longer recognizes.

The remaining four flags are specialized. PSH asks the receiver to hand the data to the application without waiting, URG and the urgent pointer are effectively obsolete, and ECE and CWR belong to explicit congestion notification, a congestion control mechanism negotiated at connection setup and rarely visible unless you look for it.

The windowThe window, and the fault it exposes

The window field says how much more data the sender of this segment can accept before its buffer is full. It changes constantly, and this flow control is the mechanism by which a slow receiver stops a fast sender from overwhelming it.

Sixteen bits caps the raw value at 65,535 bytes, which was generous when the protocol was written in 1981 and is nothing on a modern link. The window scale option fixes it by declaring a shift factor at connection setup, so the real window is the field multiplied by a power of two.

This has one significant practical consequence: window scaling is negotiated only in the SYN segments, so an analyzer that did not capture the start of the connection cannot know the multiplier and will report window sizes that are wrong by a large factor.

A zero window is worth recognizing on sight. It means the receiver buffer is full and the sender must stop sending data, and it is nearly always an application that is not reading its socket fast enough rather than a network problem.

Blaming the network for a zero window is one of the more common wrong turns in performance work, and the header says plainly where to look instead.

The optionsThe options, where the modern behavior lives

Options appear only in the space between the fixed header and the data, and most of them are negotiated in the SYN.

Maximum segment size declares the largest amount of data this side will accept in one segment, derived from the local MTU. The two ends settle on the smaller of the two values, and a mismatch between that and the real path MTU is the cause of TCP connections that open and then hang on large transfers.

Window scale provides the multiplier described above, without which throughput on a long fast path is capped far below the link speed.

Selective acknowledgment lets a receiver say which non-contiguous blocks of data arrived, so a sender retransmits only the gap rather than everything after it. Without it, one lost packet costs far more than one segment of retransmission.

Timestamps give a round trip measurement on every segment and protect against sequence numbers wrapping on very fast TCP connections.

All four options are ordinary today, and all four are absent if the SYN was blocked, rewritten by a middlebox or stripped by an old firewall. TCP running without window scaling and selective acknowledgment works and performs badly, which is exactly the kind of fault that survives for years.

In the packetWhere the header sits, and what the checksum covers

The TCP header does not travel alone. It sits directly behind an IP header in every packet, and the protocol field of that IP header carries the value 6, which is how the receiving stack knows to hand the rest of the packet to the Transmission Control Protocol rather than to UDP.

That arrangement is why there are no addresses in the TCP header. The port numbers identify the process at each end, and the internet layer underneath supplies the source address and the destination address. A segment on its own cannot say which host it came from.

The checksum is the one field that reaches across that boundary. RFC 793 says the checksum also covers a 96 bit pseudo header conceptually prefixed to the TCP header, and that this pseudo header contains the source address, the destination address, the protocol and the TCP length.

Those twelve octets are never transmitted on the network. Each end builds them from the IP header it already holds, which is why a segment delivered to the wrong host or handed to the wrong protocol fails the checksum even when every byte of the TCP header and the data arrived intact.

The specification itself has moved on, and it is worth citing the current one. RFC 9293, published as Internet Standard STD 7, obsoletes RFC 793 together with the six later RFCs that had each patched part of it. The header format did not change.

In a captureWhat to read first in a capture

Four TCP header fields, read in this order, resolve most investigations.

Look for RST. A reset says the connection was refused or abandoned, and which side sent it tells you which end made that decision.

Check the SYN and the SYN-ACK. TCP options are negotiated there, so a missing MSS, window scale or SACK is visible only at the start. This is why capturing from the beginning of a connection matters so much.

Watch the window. A window falling toward zero is a receiver that cannot keep up, and it points at the application rather than the link.

Follow the sequence numbers. Repeated numbers are retransmissions, and three duplicate acknowledgments of the same number are the receiver saying a packet is missing, which triggers a fast retransmit before any timer expires.

PitfallsWhere people go wrong

Reading data offset as bytes. The field counts 32-bit words. Five means a twenty byte TCP header, and every hand-written parser gets this wrong once.

Assuming sequence numbers count packets. They count bytes, which is what makes partial acknowledgment possible and what makes the arithmetic look strange at first.

Trusting window sizes in a capture that missed the SYN. Without the scale factor the numbers are wrong, and they are wrong in the direction that hides a problem.

Treating a zero window as congestion. It is flow control, deliberately signaled by the receiver, and the cause is an application that is not reading the data fast enough.

Ignoring the difference between a RST and a timeout. A reset is an answer and a timeout is silence. One means something refused you and the other means nothing replied, and they point at completely different causes.

Expecting PSH to mean anything urgent. It asks the stack not to buffer. It has no priority meaning on the network at all.

ComparisonTwo headers, and the trade expressed in bytes

The size row is the trade in one line. Everything TCP adds to the header is a feature that UDP leaves to the application, which is the whole of the TCP against UDP argument expressed in bytes.

FAQFrequently asked questions

Keep readingRelated concepts

Read next · Protocols TCP vs UDP Everything in this header is a feature UDP leaves to the application, which is the comparison in one drawing. Open this next10 min

• Diagnostics · 12 min Reading a Wireshark Capture Without Drowning in Packets These fields are what you are looking at, and this is how to get to them without drowning.
• Fundamentals · 10 min The IPv4 Header, Field by Field and in Order of Usefulness The header underneath this one, and the source of the pseudo-header the TCP checksum covers.
• Network fundamentals · 9 min TCP Window Size, and Why It Caps Your Throughput Where the 16-bit window value lives in every TCP segment.