What Are TCP Flags?
TCP flags are single bits in the TCP header that tell the receiving stack what a segment is for. One bit opens a connection, another acknowledges data, and another tears the session down.
They carry no payload of their own. Each bit reads as set or clear, and the combination on one segment defines what that segment does.
That makes them the control language of the protocol. Among the network protocols in daily use, TCP earns its reliability through these bits and the sequence numbers beside them.
How Many TCP Flags Are There?
Eight flags exist in the current specification, RFC 9293, which has defined TCP since 2022. Six of them arrived with the original 1981 standard, and two came later with congestion notification.
You will still find references to nine. A ninth bit called NS came from an experimental congestion-notification scheme, and RFC 8311 returned that bit to reserved status in 2018. Some capture tools still decode a field the spec no longer defines.
The Eight TCP Flags and What Each One Does
The bits sit in one byte of the header, in the order below.
Flag | Full name | What it signals |
CWR | Congestion Window Reduced | The sender has cut its own sending rate after congestion was reported to it |
ECE | ECN-Echo | On a handshake segment it advertises congestion-notification support, and later it reports congestion seen on the path |
URG | Urgent | Marks the urgent pointer as meaningful, and almost nothing uses it now |
ACK | Acknowledgment | The acknowledgment number holds a real value, which it does on every segment after the first |
PSH | Push | Asks both stacks to hand buffered data to the application without waiting for more |
RST | Reset | Ends the connection immediately, with no negotiation and no guarantee about data in flight |
SYN | Synchronize | Opens a connection and carries the sender's starting sequence number |
FIN | Finish | Says the sender has finished sending and wants to close its own direction |
Four of those eight do nearly all the visible work. SYN, ACK, FIN and RST appear in every capture. CWR and ECE only show up where congestion notification runs end to end, and URG has been effectively retired.
How the Flags Appear in a Normal Connection
A healthy session moves through three phases, and the flag pattern for each one never varies.
Phase | Direction | Flags set | What happens |
Open, step 1 | Client to server | SYN | Proposes the connection and states the client's starting sequence number |
Open, step 2 | Server to client | SYN and ACK | Accepts, sends its own sequence number, acknowledges the client's |
Open, step 3 | Client to server | ACK | Confirms the server's number, and the connection opens |
Data | Both directions | ACK, often with PSH | Every segment acknowledges what has arrived so far |
Close, step 1 | Either side | FIN and ACK | One side announces it has no more data to send |
Close, step 2 | The other side | ACK | Acknowledges that FIN, which shuts one direction only |
Close, step 3 | The other side | FIN and ACK | The second side announces it has finished too |
Close, step 4 | First side | ACK | The last acknowledgment, and the session ends |
Opening costs three segments and closing costs four, which surprises people who expect symmetry. TCP shuts each direction separately, so either side can stop sending while it keeps reading.
Segments go missing on real networks, and the handshake simply repeats when they do. A retransmitted SYN tells you something dropped. That puts packet loss on the list of suspects before you look at the application.
What Does Each Flag Pattern Tell You?
Reading the pattern rather than the individual bits is what turns a capture into an answer.
What the capture shows | What it means | Usual cause |
SYN sent repeatedly, nothing comes back | The segment never reached a listener, or the reply never returned | A device dropping it silently, or a host that is down |
SYN answered with SYN and ACK | The port is open and something is listening | Normal behavior |
SYN answered at once with RST | The host exists and refuses the port | The service has stopped, or it never listened there |
RST partway through a transfer | One side abandoned the connection | An application crash, a timeout, or a device expiring an idle session |
FIN and ACK exchanged both ways | Both sides finished deliberately | Normal behavior |
Several retransmitted SYNs, then success | The handshake needed more than one attempt | Loss on the path, or a backlog queue that filled up |
PSH and ACK on almost every segment | The application flushes each write immediately | Normal for interactive and request-response protocols |
The first and third rows get confused constantly, and they point at opposite problems. A reset means a real host answered you, so routing works and the gap is at the service.
Silence means something swallowed the segment. That is usually a firewall configured to drop rather than reject. Restarting the service will not change what you see.
Which Flag Combinations Are Not Legal?
Some combinations cannot occur in a working session, so finding one tells you somebody crafted the packet by hand.
Combination | Why it cannot happen naturally | Where it comes from |
SYN and FIN together | Opening and closing in the same segment contradicts itself | Probes looking for stacks that answer anyway |
SYN and RST together | A connection cannot open and reset at the same instant | Crafted traffic, or occasionally a broken stack |
Every flag set at once | No legal purpose exists for the full set | The pattern commonly called a Christmas tree scan |
No flags set at all | Every segment has to say what it is doing | A null scan |
FIN with no ACK | Every segment after the handshake should acknowledge something | A FIN scan |
Each of these exists to test how a stack handles nonsense, because the answer often reveals the operating system. Modern stacks and firewalls drop all five. Any of them in a capture deserves a second look rather than a shrug.
How Do You See TCP Flags in a Capture?
Both standard tools filter on flags directly, and neither needs a plugin.
These tcpdump filters cover the cases that come up most.
Filter | What it matches |
tcp[tcpflags] & tcp-syn != 0 | Any segment with SYN set, including the second handshake step |
tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn | SYN without ACK, so connection attempts only |
tcp[tcpflags] & tcp-rst != 0 | Every reset crossing the interface |
tcp[tcpflags] & tcp-fin != 0 | Every graceful close |
tcp[tcpflags] == 0 | Segments carrying no flags at all |
Wireshark uses named fields instead, which read more easily once a capture is open.
Display filter | What it shows |
tcp.flags.syn 1 && tcp.flags.ack 0 | Connection attempts, with no replies counted |
tcp.flags.reset == 1 | Every reset in the file |
tcp.flags == 0x012 | SYN and ACK together, so accepted connections |
tcp.analysis.flags | Segments Wireshark judged to be retransmissions, resets or zero windows |
Capture the handshake or the flags lose half their meaning. Starting a pcap mid-session leaves you with ACKs and no record of how the connection opened. We have watched that turn a ten-minute job into an afternoon.
Why TCP Flags Matter for Network Monitoring
Captures answer one question at a time, on one link, after you already suspect something. Flow records answer the same question across the whole network, continuously.
NetFlow and IPFIX both carry the accumulated TCP flags seen in each flow. So a flow with SYN set and nothing else records a connection nobody answered. Counting those per destination surfaces a dead service without anyone opening a capture.
That is what makes flow analytics useful beyond bandwidth reporting. The same records that show you who consumed the link also show you which handshakes failed while doing it.
What to Alert On
Two ratios earn a place on a dashboard. Track the share of flows with SYN and no reply, then track the share of established flows that ended in RST rather than FIN.
Both stay low and flat on a healthy network. When either climbs, network troubleshooting starts with a known direction instead of a packet capture and a guess.
Explore More IT Terms
Browse our comprehensive IT glossary to learn more about technology terminology.