What Are TCP Communication Flags? A Guide to TCP Header Flags (SYN, ACK, FIN, RST, PSH, URG)

Key takeaways

• Memorise the handshake as SYN, SYN-ACK, ACK, and recognise FIN for graceful close and RST for abrupt reset.
• Combinations such as SYN with FIN, or no flags at all, are abnormal and often point to scanning or crafted packets.
• Practise reading flags in a Wireshark capture or tcpdump, since CCNA, Security+ and SOC interviews all expect this.

Every reliable connection on the internet, from loading a web page to an SSH session, is steered by these flag bits. Reading them is a core skill for network engineers, SOC analysts and anyone preparing for CCNA or Security+, because packet captures and firewall logs are full of them.

What are TCP flags?

TCP flags are control bits in the TCP header that tell each side what a segment is for. The modern TCP header carries a set of control bits; the six listed below handle the everyday work of opening, running and closing a connection. Each bit is either 1 (set) or 0 (not set), and several can be set at once.

Two older bits, CWR and ECE, support Explicit Congestion Notification. A further bit in the same byte, historically "reserved", was assigned to the experimental ECN nonce (NS) and later returned to reserved. You rarely touch these in day-to-day work, so this guide focuses on the six control flags.

What do the six main TCP flags do?

Each flag signals one kind of event. The table gives the short version; the notes after it add the detail that matters in practice.

• SYN only appears when a connection is being set up. A second SYN on an established connection is abnormal and often flagged by security tools.
• ACK is set on nearly all segments once the handshake is done, because TCP acknowledges data continuously. A packet with ACK but no SYN or FIN is usually ordinary data or a plain acknowledgement.
• FIN closes one direction at a time. A full close needs a FIN and an ACK from each side, so you often see four packets at the end of a connection.
• RST skips the polite close. It is normal when you connect to a port nothing is listening on, and it is what lets a firewall or host cut a session dead.
• PSH tells the receiver not to wait for its buffer to fill before handing data up to the application. Interactive protocols set it so each keystroke or message arrives without delay.
• URG is almost extinct. Modern applications avoid the urgent pointer, and some middleboxes clear the bit, so treat unexpected URG traffic with suspicion.

Where do the flags sit in the TCP header?

The control bits live in byte 13 of the TCP header, just after the data offset and reserved bits and before the window size. This layout follows the order defined in the TCP specification (RFC 9293), which now consolidates the original RFC 793.

 0 1 2 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+---------------------------------------------------------------+
| Sequence Number |
+---------------------------------------------------------------+
| Acknowledgement Number |
+-------+-----------+-+-+-+-+-+-+---------------------------------+
| Data | Reserved |U|A|P|R|S|F| Window Size |
| Offset| |R|C|S|S|Y|I| |
| | |G|K|H|T|N|N| |
+-------+-----------+-+-+-+-+-+-+---------------------------------+
| Checksum | Urgent Pointer |
+---------------------------------------------------------------+
| Options and Padding |
+---------------------------------------------------------------+

Each flag is one bit, so the whole set fits in part of a single byte. When you read a capture, the tool decodes these bits for you, but knowing the position helps when you write filters by hand.

How do flags drive the 3-way handshake?

Opening a TCP connection takes three segments, each defined by its flags:

1. SYN: the client sends a segment with SYN set and its initial sequence number.
2. SYN-ACK: the server replies with both SYN and ACK set, acknowledging the client and sending its own sequence number. This is the clearest example of two flags in one segment.
3. ACK: the client acknowledges the server's SYN. The connection is now established and data can flow.

Closing is the mirror image. One side sends FIN, the other acknowledges with ACK, then sends its own FIN, which the first side acknowledges. If anything goes wrong in between, either side can send RST to tear the connection down at once. If you want the layer-by-layer context behind this, see our explainer on the difference between IP, TCP and UDP.

Which flag combinations are normal, and which are not?

Recognising unusual combinations is where this knowledge earns its keep.

The abnormal rows matter in practice. Older port-scanning techniques deliberately craft packets with no flags, or with FIN/PSH/URG together, to probe how a host responds. A healthy network should rarely see them, so intrusion-detection rules often alert on exactly these patterns.

How do you see TCP flags yourself?

The fastest way to understand flags is to watch them. Capture a little traffic and filter on the flags.

In tcpdump, match SYN-only packets (new connection attempts):

sudo tcpdump 'tcp[tcpflags] == tcp-syn' -n -i any

Match SYN or ACK packets, the bulk of a handshake:

sudo tcpdump 'tcp[tcpflags] & (tcp-syn|tcp-ack)!= 0' -n

In Wireshark, use display filters instead:

tcp.flags.syn == 1 && tcp.flags.ack == 0 # new connection requests
tcp.flags.reset == 1 # resets
tcp.flags == 0x012 # exactly SYN+ACK

Load a capture, follow a single connection, and you will see the SYN, SYN-ACK, ACK sequence at the start and the FIN or RST at the end. Our guides to Wireshark for beginners and Nmap for network scanning show how to generate and read this traffic safely in a lab.

Why do TCP flags matter in security?

Flags are central to both attacks and defences, which is why they appear throughout the CCNA and Security+ syllabuses.

• SYN floods: an attacker sends many SYN packets and never completes the handshake, filling the server's half-open connection table. SYN cookies and rate limiting defend against this.
• Scan detection: SYN scans, FIN scans, NULL scans and the XMAS scan each use a distinct flag pattern. A defender who knows the normal set can spot the odd ones in logs.
• Firewall behaviour: stateful firewalls track which flags are valid for a connection's current state and drop segments that do not fit, such as an ACK for a connection they never saw open.
• RST injection: a forged RST can cut a connection. Seeing resets that do not match the traffic pattern is a sign worth investigating.

The right level of detail here is recognition and defence, not attack recipes. Study these patterns so you can read captures and tune detection rules.

Common misunderstandings

• "Every packet has only one flag." No. ACK rides along with most flags, and the handshake reply carries SYN and ACK together.
• "PSH means the data is important." PSH is about timing, not priority. It tells TCP to deliver buffered data now rather than wait.
• "RST means an error occurred." Not always. A RST to a closed port is the normal, correct response.
• "URG is widely used." It is effectively obsolete and often stripped by middleboxes.
• "Flags live in the IP header." The IP header has its own, different flags (such as Don't Fragment). TCP flags are in the TCP header.

Next step

Open a packet capture tool, start a single web or SSH connection, and filter for SYN, then RST, then FIN. Matching each flag to what you see on screen fixes the idea far better than re-reading a table. To take networking fundamentals through to certification, look at structured CCNA networking training, where handshakes, flags and captures are practised hands-on.

Related reading

• What Are TCP Communication Flags? | Understanding TCP Flags in Networking & Scanning
• What Really Happens When You Type a URL in Your Browser? Step-by-Step Guide Explained
• [2026] CCNA Voice Interview Questions