Computer NetworksTCP Header Format

TCP Header Format and Structure

LevelIntermediate

Duration75 mins

TopicTCP Header Format

4 / 5

Flags (SYN, ACK, FIN, RST, PSH, URG)

The Control Signals of TCP Communication

If sequence and acknowledgment numbers track data, then flags control behavior. These six bits—SYN, ACK, FIN, RST, PSH, and URG—occupy a single byte of the TCP header but govern the entire lifecycle of every TCP connection.

Each flag is a boolean signal, either set (1) or clear (0), and their combinations create a rich vocabulary for connection management. A segment with SYN set initiates a connection; one with FIN set gracefully terminates it; one with RST set abruptly aborts it. Understanding these flags is essential for:

Debugging network issues and connection failures
Analyzing packet captures (Wireshark, tcpdump)
Implementing firewalls and security filters
Understanding TCP state machines and transitions
Detecting and preventing network attacks

What You Will Learn

By the end of this page, you will understand the position and encoding of flags in the TCP header, the complete semantics of each flag (SYN, ACK, FIN, RST, PSH, URG), how flags combine in real-world segments, the role of flags in connection state transitions, security implications and flag-based attacks, and additional flags added in modern TCP extensions.

Position and Encoding in the TCP Header

The TCP flags reside in the 13th byte of the TCP header (bits 100–107 in 0-indexed terms, or commonly referred to as the 13th and 14th bytes when including the reserved bits). The flags occupy 6 bits within a larger control field that also contains the 4-bit data offset and reserved bits.

TCP Header: Flags Position (Bytes 12-13)
Byte Position	Bit Range	Field	Size
Byte 12	Bits 96–99	Data Offset	4 bits
Byte 12	Bits 100–102	Reserved	3 bits
Byte 12	Bit 103	NS (Nonce Sum)	1 bit (ECN extension)
Byte 13	Bit 104	CWR (Congestion Window Reduced)	1 bit (ECN)
Byte 13	Bit 105	ECE (ECN-Echo)	1 bit (ECN)
Byte 13	Bit 106	URG (Urgent)	1 bit
Byte 13	Bit 107	ACK (Acknowledgment)	1 bit
Byte 13	Bit 108	PSH (Push)	1 bit
Byte 13	Bit 109	RST (Reset)	1 bit
Byte 13	Bit 110	SYN (Synchronize)	1 bit
Byte 13	Bit 111	FIN (Finish)	1 bit

The Classic Six Flags:

The original TCP specification (RFC 793) defined six control flags. From most significant to least significant bit position:

| URG | ACK | PSH | RST | SYN | FIN |
|  6  |  5  |  4  |  3  |  2  |  1  |  (bit weights)
|  32 |  16 |  8  |  4  |  2  |  1  |  (decimal values)

Common Flag Combinations:

Decimal	Binary	Flags Set	Common Name
2	000010	SYN	Connection request
18	010010	SYN+ACK	Connection response
16	010000	ACK	Data or acknowledgment
24	011000	ACK+PSH	Data push
17	010001	FIN+ACK	Graceful close
4	000100	RST	Connection abort

tcp_flags.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
/* TCP Flag Bit Definitions */
#define TCP_FIN  0x01    /* 0000 0001 - Finish */
#define TCP_SYN  0x02    /* 0000 0010 - Synchronize */
#define TCP_RST  0x04    /* 0000 0100 - Reset */
#define TCP_PSH  0x08    /* 0000 1000 - Push */
#define TCP_ACK  0x10    /* 0001 0000 - Acknowledgment */
#define TCP_URG  0x20    /* 0010 0000 - Urgent */
 
/* Extended flags (ECN - RFC 3168) */
#define TCP_ECE  0x40    /* 0100 0000 - ECN-Echo */
#define TCP_CWR  0x80    /* 1000 0000 - Congestion Window Reduced */
#define TCP_NS   0x100   /* 1 0000 0000 - Nonce Sum (in data offset byte) */
 
/* Extract flags from TCP header */
uint8_t get_tcp_flags(const uint8_t* tcp_header) {
    /* Flags are in byte 13 (offset 13 from start) */
    return tcp_header[13];
}
 
/* Check if specific flag is set */
bool has_syn(uint8_t flags) { return (flags & TCP_SYN) != 0; }
bool has_ack(uint8_t flags) { return (flags & TCP_ACK) != 0; }
bool has_fin(uint8_t flags) { return (flags & TCP_FIN) != 0; }
bool has_rst(uint8_t flags) { return (flags & TCP_RST) != 0; }
bool has_psh(uint8_t flags) { return (flags & TCP_PSH) != 0; }
bool has_urg(uint8_t flags) { return (flags & TCP_URG) != 0; }
 
/* Common patterns */
bool is_syn_only(uint8_t flags) { return flags == TCP_SYN; }
bool is_syn_ack(uint8_t flags) { return flags == (TCP_SYN | TCP_ACK); }
bool is_fin_ack(uint8_t flags) { return (flags & (TCP_FIN | TCP_ACK)) == (TCP_FIN | TCP_ACK); }

SYN Flag: Synchronize Sequence Numbers

The SYN (Synchronize) flag initiates a TCP connection by synchronizing sequence numbers between endpoints. It is the fundamental mechanism for connection establishment and appears only at the very beginning of a connection.

Primary Functions:

Signal connection request: A SYN-only segment says "I want to establish a connection"
Communicate Initial Sequence Number (ISN): The sequence number field contains the sender's ISN
Negotiate options: Window scale, SACK, timestamps, and MSS are exchanged with SYN
Consume sequence space: SYN occupies one sequence number for reliable acknowledgment

SYN Segment Types:

Type	Flags	Direction	Purpose
SYN	SYN only	Client → Server	Initial connection request
SYN-ACK	SYN + ACK	Server → Client	Accept connection, acknowledge client's SYN

The Three-Way Handshake:

1. Client → Server: SYN, Seq=X
   "I want to connect. My starting sequence is X."

2. Server → Client: SYN+ACK, Seq=Y, Ack=X+1
   "Connection accepted. My starting sequence is Y. I expect X+1 next."

3. Client → Server: ACK, Seq=X+1, Ack=Y+1
   "Confirmed. I expect Y+1 next."

After this exchange, both sides have synchronized sequence numbers and can begin data transfer.

SYN Flood Attack

An attacker can exhaust server resources by sending massive numbers of SYN packets without completing the handshake. The server allocates memory for each half-open connection. Mitigations include SYN cookies (stateless SYN-ACK), SYN proxies, and rate limiting. SYN cookies encode state into the ISN, avoiding memory allocation until handshake completes.

SYN Segment Characteristics

•No payload data: SYN segments carry only headers (and options)
•Consumes 1 sequence number: SYN + 1 = expected next sequence
•Maximum Segment Size (MSS): Typically advertised only in SYN segments
•Option negotiation: Window scale, SACK-permitted, timestamps negotiated here
•SYN outside established connection: Processed as potential new connection (or ignored if from unwanted source)

ACK Flag: Acknowledgment Field Valid

The ACK (Acknowledgment) flag is the most frequently set flag in TCP segments. It indicates that the acknowledgment number field in the header is valid and should be processed.

Behavior by ACK State:

ACK Flag	Acknowledgment Number Field	When This Occurs
Clear (0)	Ignored/undefined	Initial SYN only
Set (1)	Must be processed	Every other segment

After the initial SYN segment, every TCP segment has the ACK flag set. Even pure data segments acknowledge previously received data. This makes ACK the default state of TCP communication.

ACK-Only Segments:

Segments with only the ACK flag set (no data, no SYN, no FIN) serve specific purposes:

Acknowledge received data without sending any new data
Keep-alive probes to verify connection is still active
Window updates to advertise newly available receive buffer space
Delayed acknowledgment when no data to send

ACK Characteristics:

Consumes 0 sequence numbers: Pure ACKs don't advance sequence space
Not retransmitted: Lost ACKs are covered by cumulative acknowledgment
Can piggyback: Almost always combined with data segments when available

The Ubiquitous ACK

If you capture TCP traffic and see a segment without ACK set, it's almost certainly the initial SYN of a new connection. Any segment without ACK after the handshake is anomalous and may indicate an attack or misconfiguration.

ACK in State Transitions:

The ACK flag is critical for TCP state machine transitions:

SYN_SENT state:
  - Receive SYN+ACK → Send ACK → Move to ESTABLISHED
  
SYN_RECEIVED state:
  - Receive ACK for our SYN → Move to ESTABLISHED
  
FIN_WAIT_1 state:
  - Receive ACK for our FIN → Move to FIN_WAIT_2

FIN Flag: Graceful Connection Termination

The FIN (Finish) flag signals the sender's intention to terminate the connection gracefully. Unlike RST, which abruptly aborts, FIN allows both sides to finish transmitting any remaining data before closing.

FIN Semantics:

"I have no more data to send"
"Please acknowledge this FIN"
"You may still send data to me" (until you also send FIN)

The Half-Close:

TCP connections are full-duplex, meaning data can flow in both directions independently. A FIN closes only one direction:

A sends FIN to B:
  - A → B direction: Closed (A will send no more data)
  - B → A direction: Open (B can still send data)
  - This is called a "half-close"

The connection is fully closed only when both sides have sent and acknowledged FINs.

The Four-Way Close:

Graceful termination typically requires four segments:

1. A → B: FIN+ACK, Seq=X
   "I'm done sending. Final data was up to X."

2. B → A: ACK, Ack=X+1
   "I acknowledge your FIN."

3. B → A: FIN+ACK, Seq=Y
   "I'm also done sending. Final data was up to Y."

4. A → B: ACK, Ack=Y+1
   "I acknowledge your FIN. Connection closed."

Piggybacked FIN-ACK:

Steps 2 and 3 can be combined if B has no more data:

1. A → B: FIN+ACK
2. B → A: FIN+ACK (acknowledges A's FIN and sends B's FIN)
3. A → B: ACK (acknowledges B's FIN)

This reduces the exchange to three segments.

FIN Characteristics

•Consumes 1 sequence number: Like SYN, FIN+1 = expected next sequence
•Always has ACK set: FIN-only (without ACK) is unusual and suspicious
•Can carry data: The segment containing FIN may include final payload bytes
•Must be acknowledged: Sender retransmits FIN if no ACK received
•Triggers TIME_WAIT: The side sending the final ACK enters TIME_WAIT (typically 2×MSL)

TIME_WAIT State

After sending the final ACK, TCP enters TIME_WAIT for 2×MSL (Maximum Segment Lifetime, typically 60-120 seconds). This ensures: (1) the final ACK is retransmittable if lost, and (2) old segments from this connection drain from the network before the same four-tuple is reused.

RST Flag: Abortive Connection Reset

The RST (Reset) flag immediately and abruptly terminates a TCP connection. Unlike FIN's graceful closure, RST discards any outstanding data and ends the connection without negotiation.

When RST is Generated:

No listener on port: Connection attempt to closed port
Segment for non-existent connection: Data arrives for unknown four-tuple
Application abort: Application explicitly aborts (SO_LINGER = 0)
Resource exhaustion: System cannot handle more connections
Security measures: Firewall or IDS rejects connection

RST Generation Scenarios
Scenario	Trigger	RST Contents
Connection to closed port	SYN to port with no listener	RST+ACK, Ack=SYN's Seq+1
Data on half-open connection	Server rebooted during handshake	RST, Seq=what receiver expects
Application abort	close() with SO_LINGER=0	RST, discards outgoing queue
FIN during SYN_RECEIVED	FIN arrives before ESTABLISHED	RST
Invalid segment	Segment fails security check	RST (or silent discard)

RST vs. FIN:

Aspect	RST	FIN
Data handling	Discards unsent data	Waits for data to complete
State transitions	Immediate CLOSED	Goes through FIN_WAIT, TIME_WAIT
TIME_WAIT	No TIME_WAIT	TIME_WAIT required
Acknowledgment	RST is not acknowledged	FIN must be acknowledged
Use case	Error conditions, aborts	Normal shutdown

RST Attack / TCP Reset Attack

Attackers can inject spoofed RST segments to forcibly terminate connections. If the attacker can guess the correct sequence number (within the receive window), the victim accepts the RST and closes the connection. This attack has been used to disrupt BGP sessions between ISPs. Mitigations include TCP-AO authentication and requiring RST sequence to exactly match expected.

RST Characteristics

•Consumes 0 sequence numbers: RST doesn't advance sequence space
•Not acknowledged: There's no ACK for an RST; it's fire-and-forget
•Immediate effect: Receiving RST immediately transitions to CLOSED
•Sequence validation: RST is processed only if sequence number is acceptable
•RFC 5961 strengthening: Modern TCP requires RST seq to exactly match RCV.NXT

PSH Flag: Push Data to Application

The PSH (Push) flag signals that the receiver should "push" buffered data to the application immediately rather than waiting to accumulate more data. It's a hint about data urgency, not a hard requirement.

PSH Semantics (Receiver Side):

Without PSH: TCP may buffer data before delivering to application
With PSH: TCP should deliver buffered data promptly

Common PSH Usage:

Interactive applications: Telnet, SSH send PSH to minimize latency
Request completion: HTTP request ends with PSH to indicate "process this now"
Small writes: Many implementations set PSH on final segment of each write()
Prompt delivery: Any time sender wants receiver to act immediately

Sender Behavior:

When an application makes a write() call, TCP buffering may delay transmission:

Without PSH: 
  write("GET / HTTP/1.1\r
") → Buffer, maybe wait for more data
  
With PSH:
  write("GET / HTTP/1.1\r
", MSG_PUSH) → Send immediately with PSH set

However, most TCP implementations automatically set PSH when:

Sending the last segment of buffered data
The send buffer becomes empty
The application explicitly requests it

Modern Reality:

In practice, the PSH flag is often set automatically and rarely configured by applications. Modern operating systems typically set PSH on every segment that empties the send buffer, making it a nearly ubiquitous flag in TCP traffic.

PSH and Nagle's Algorithm

PSH interacts with Nagle's algorithm. When an application wants low-latency delivery, setting TCP_NODELAY disables Nagle (preventing send-side buffering), and PSH prevents receive-side buffering. Together, they minimize end-to-end latency for interactive applications.

PSH Flag Effect on Data Delivery
PSH State	Sender Behavior	Receiver Behavior
Clear (0)	May buffer more application writes	May buffer before application read()
Set (1)	Send buffered data now	Deliver buffered data to application promptly

URG Flag: Urgent Data Marker

The URG (Urgent) flag and its companion Urgent Pointer field implement out-of-band data delivery within the TCP stream. Urgent data can be processed before normally sequenced data, enabling time-sensitive signals.

URG Mechanism:

When URG is set:

The 16-bit Urgent Pointer field (bytes 18–19) becomes valid
Urgent Pointer = offset from sequence number to end of urgent data
Receiver should notify application of urgent data presence

Segment: Seq=1000, URG=1, UrgPtr=10, Data="URGENT!!!NORMAL"

Interpretation:
  Urgent data: bytes 1000-1009 ("URGENT!!!" - 10 bytes)
  Normal data: bytes 1010+ ("NORMAL")

Historical Ambiguity:

The original RFC 793 was ambiguous about whether Urgent Pointer points to the last byte of urgent data or one past it. Different implementations chose differently:

BSD interpretation: Points to last byte of urgent data
RFC 1122 clarification: Points to first byte after urgent data

This inconsistency caused interoperability problems, and modern systems follow RFC 1122.

URG is Rarely Used

The urgent mechanism is rarely used in modern applications. Originally intended for out-of-band signals (like TELNET interrupt), most applications now use separate control connections or in-band signaling. Some protocols (like FTP) still use URG for ABORT commands, but its use is declining.

Application Interface:

Unix/POSIX systems expose urgent data through:

/* Sender: Send out-of-band data */
send(sock, "!", 1, MSG_OOB);

/* Receiver: Check for urgent data */
int atmark;
ioctl(sock, SIOCATMARK, &atmark);
if (atmark) {
    recv(sock, buf, 1, MSG_OOB);  /* Receive urgent byte */
}

/* Or use SIGURG signal to be notified of urgent data */
fcntl(sock, F_SETOWN, getpid());
/* SIGURG delivered when urgent data arrives */

Security Implications:

Some intrusion detection systems have historically failed to properly handle urgent data, creating evasion opportunities. Fragmented urgent data across multiple segments could bypass detection of malicious content.

Flag Combinations and the TCP State Machine

TCP flags aren't used in isolation—their combinations trigger state machine transitions that define the connection lifecycle. Understanding these combinations is essential for network debugging and security analysis.

Common Flag Combinations in Practice
Flags	Binary	Meaning	When Seen
SYN	000010	Connection initiation	First packet of connection
SYN+ACK	010010	Accept connection	Second packet of handshake
ACK	010000	Acknowledgment/Data	Most common in established state
PSH+ACK	011000	Data, deliver immediately	Interactive traffic, request/response
FIN+ACK	010001	Close connection	Connection termination
RST	000100	Abort connection	Error or rejection
RST+ACK	010100	Abort with acknowledgment	Common reset response
URG+ACK+PSH	111000	Urgent data with push	Out-of-band signals (rare)

Illegal or Suspicious Combinations:

Certain flag combinations are protocol violations or attack signatures:

Combination	Why Suspicious
SYN+FIN	Ambiguous: start or end? Confuses IDS/firewalls
SYN+RST	Contradictory: "start" and "abort"
FIN+RST	Contradictory: "graceful close" and "abort"
No flags (NULL scan)	Invalid segment; used for OS fingerprinting
All flags (XMAS scan)	Invalid; used for firewall probing
SYN+FIN+RST+etc	"Christmas tree" packet; attack probe

Security tools use these anomalies for detection:

Null scan: No flags set → May elicit different responses
XMAS scan: FIN+PSH+URG → Some systems respond differently
Maimon scan: FIN+ACK to closed port → Some systems don't RST

Firewall Evasion via Flags

Stateless firewalls that only check individual flags (like 'block SYN to port 22') can be evaded. An attacker might send ACK packets that pass the filter but are processed by a host that accepts data on established connections. Stateful firewalls track connection state to prevent such evasion.

Extended Flags: ECN and NS

Beyond the original six flags, modern TCP includes three additional flags for Explicit Congestion Notification (ECN):

ECN Flags:

Flag	Purpose
NS (Nonce Sum)	Protection against accidental/malicious ECN marking removal
CWR (Congestion Window Reduced)	Sender acknowledges ECN-Echo, has reduced sending rate
ECE (ECN-Echo)	Receiver echoes congestion indication back to sender

ECN Operation:

ECN capability negotiated via SYN exchange (ECE+CWR in initial SYN)
Routers mark IP header with Congestion Experienced (CE) when queues fill
TCP receiver sees CE mark, sets ECE flag in ACKs
TCP sender receives ECE, reduces congestion window, sets CWR
CWR signals to receiver: "I got your ECE, you can stop setting it"

ecn_handling.py
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
import socket
 
# Enable ECN for a socket (Linux)
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
 
# IP_TOS options for ECN
# 0x01 = ECT(1) - ECN Capable Transport (ECT(1))
# 0x02 = ECT(0) - ECN Capable Transport (ECT(0))
# 0x03 = CE - Congestion Experienced
 
# Set TCP_QUICKACK for immediate ACK of congestion
sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_QUICKACK, 1)
 
# Check system ECN configuration
# Linux: /proc/sys/net/ipv4/tcp_ecn
# Values:
#   0 = ECN disabled
#   1 = ECN enabled (initiate and accept)  
#   2 = ECN enabled (accept only, don't initiate)
 
# ECN negotiation happens automatically in the SYN exchange
# SYN with ECE+CWR set = "I support ECN"
# SYN-ACK with ECE = "I also support ECN, let's use it"
 
# Wireshark filter for ECN traffic
# tcp.flags.cwr == 1 or tcp.flags.ecn == 1

ECN Benefits

ECN allows routers to signal congestion BEFORE dropping packets. This means TCP can slow down proactively rather than waiting for packet loss. Studies show ECN can significantly reduce latency and retransmissions in congested networks, particularly benefiting short flows.

Summary: TCP Control Flags

We've explored the six classic TCP control flags and their modern extensions—the Boolean signals that govern every aspect of TCP connection management.

Key Takeaways

•SYN (Synchronize): Initiates connections, synchronizes sequence numbers, negotiates options. Consumes one sequence number.
•ACK (Acknowledgment): Validates the acknowledgment number field. Set on every segment after the initial SYN.
•FIN (Finish): Gracefully terminates one direction of the connection. Consumes one sequence number and triggers half-close.
•RST (Reset): Abruptly terminates connection without negotiation. Discards data, skips TIME_WAIT.
•PSH (Push): Requests immediate delivery to the application. Often set automatically by TCP stack.
•URG (Urgent): Signals presence of out-of-band data. Rarely used in modern applications.
•ECN Flags (NS, CWR, ECE): Enable explicit congestion notification without packet loss.

What's Next:

With flags controlling connection lifecycle and data delivery behavior, one critical piece remains: window size. The next page explores the window field—the mechanism that enables flow control by advertising available receive buffer space, ensuring senders don't overwhelm receivers.

Page Complete

You now possess comprehensive understanding of TCP control flags: their position in the header, individual semantics, common combinations, state machine implications, security considerations, and ECN extensions. This prepares you for understanding how the window size field enables flow control.

4 / 5

Loading learning content...

Computer NetworksTCP Header Format

TCP Header Format and Structure

LevelIntermediate

Duration75 mins

TopicTCP Header Format

4 / 5

Flags (SYN, ACK, FIN, RST, PSH, URG)

The Control Signals of TCP Communication

Debugging network issues and connection failures
Analyzing packet captures (Wireshark, tcpdump)
Implementing firewalls and security filters
Understanding TCP state machines and transitions
Detecting and preventing network attacks

What You Will Learn

Position and Encoding in the TCP Header

TCP Header: Flags Position (Bytes 12-13)
Byte Position	Bit Range	Field	Size
Byte 12	Bits 96–99	Data Offset	4 bits
Byte 12	Bits 100–102	Reserved	3 bits
Byte 12	Bit 103	NS (Nonce Sum)	1 bit (ECN extension)
Byte 13	Bit 104	CWR (Congestion Window Reduced)	1 bit (ECN)
Byte 13	Bit 105	ECE (ECN-Echo)	1 bit (ECN)
Byte 13	Bit 106	URG (Urgent)	1 bit
Byte 13	Bit 107	ACK (Acknowledgment)	1 bit
Byte 13	Bit 108	PSH (Push)	1 bit
Byte 13	Bit 109	RST (Reset)	1 bit
Byte 13	Bit 110	SYN (Synchronize)	1 bit
Byte 13	Bit 111	FIN (Finish)	1 bit

The Classic Six Flags:

The original TCP specification (RFC 793) defined six control flags. From most significant to least significant bit position:

| URG | ACK | PSH | RST | SYN | FIN |
|  6  |  5  |  4  |  3  |  2  |  1  |  (bit weights)
|  32 |  16 |  8  |  4  |  2  |  1  |  (decimal values)

Common Flag Combinations:

Decimal	Binary	Flags Set	Common Name
2	000010	SYN	Connection request
18	010010	SYN+ACK	Connection response
16	010000	ACK	Data or acknowledgment
24	011000	ACK+PSH	Data push
17	010001	FIN+ACK	Graceful close
4	000100	RST	Connection abort

tcp_flags.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
/* TCP Flag Bit Definitions */
#define TCP_FIN  0x01    /* 0000 0001 - Finish */
#define TCP_SYN  0x02    /* 0000 0010 - Synchronize */
#define TCP_RST  0x04    /* 0000 0100 - Reset */
#define TCP_PSH  0x08    /* 0000 1000 - Push */
#define TCP_ACK  0x10    /* 0001 0000 - Acknowledgment */
#define TCP_URG  0x20    /* 0010 0000 - Urgent */
 
/* Extended flags (ECN - RFC 3168) */
#define TCP_ECE  0x40    /* 0100 0000 - ECN-Echo */
#define TCP_CWR  0x80    /* 1000 0000 - Congestion Window Reduced */
#define TCP_NS   0x100   /* 1 0000 0000 - Nonce Sum (in data offset byte) */
 
/* Extract flags from TCP header */
uint8_t get_tcp_flags(const uint8_t* tcp_header) {
    /* Flags are in byte 13 (offset 13 from start) */
    return tcp_header[13];
}
 
/* Check if specific flag is set */
bool has_syn(uint8_t flags) { return (flags & TCP_SYN) != 0; }
bool has_ack(uint8_t flags) { return (flags & TCP_ACK) != 0; }
bool has_fin(uint8_t flags) { return (flags & TCP_FIN) != 0; }
bool has_rst(uint8_t flags) { return (flags & TCP_RST) != 0; }
bool has_psh(uint8_t flags) { return (flags & TCP_PSH) != 0; }
bool has_urg(uint8_t flags) { return (flags & TCP_URG) != 0; }
 
/* Common patterns */
bool is_syn_only(uint8_t flags) { return flags == TCP_SYN; }
bool is_syn_ack(uint8_t flags) { return flags == (TCP_SYN | TCP_ACK); }
bool is_fin_ack(uint8_t flags) { return (flags & (TCP_FIN | TCP_ACK)) == (TCP_FIN | TCP_ACK); }

SYN Flag: Synchronize Sequence Numbers

Primary Functions:

Signal connection request: A SYN-only segment says "I want to establish a connection"
Communicate Initial Sequence Number (ISN): The sequence number field contains the sender's ISN
Negotiate options: Window scale, SACK, timestamps, and MSS are exchanged with SYN
Consume sequence space: SYN occupies one sequence number for reliable acknowledgment

SYN Segment Types:

Type	Flags	Direction	Purpose
SYN	SYN only	Client → Server	Initial connection request
SYN-ACK	SYN + ACK	Server → Client	Accept connection, acknowledge client's SYN

The Three-Way Handshake:

1. Client → Server: SYN, Seq=X
   "I want to connect. My starting sequence is X."

2. Server → Client: SYN+ACK, Seq=Y, Ack=X+1
   "Connection accepted. My starting sequence is Y. I expect X+1 next."

3. Client → Server: ACK, Seq=X+1, Ack=Y+1
   "Confirmed. I expect Y+1 next."

After this exchange, both sides have synchronized sequence numbers and can begin data transfer.

SYN Flood Attack

SYN Segment Characteristics

•No payload data: SYN segments carry only headers (and options)
•Consumes 1 sequence number: SYN + 1 = expected next sequence
•Maximum Segment Size (MSS): Typically advertised only in SYN segments
•Option negotiation: Window scale, SACK-permitted, timestamps negotiated here
•SYN outside established connection: Processed as potential new connection (or ignored if from unwanted source)

ACK Flag: Acknowledgment Field Valid

The ACK (Acknowledgment) flag is the most frequently set flag in TCP segments. It indicates that the acknowledgment number field in the header is valid and should be processed.

Behavior by ACK State:

ACK Flag	Acknowledgment Number Field	When This Occurs
Clear (0)	Ignored/undefined	Initial SYN only
Set (1)	Must be processed	Every other segment

After the initial SYN segment, every TCP segment has the ACK flag set. Even pure data segments acknowledge previously received data. This makes ACK the default state of TCP communication.

ACK-Only Segments:

Segments with only the ACK flag set (no data, no SYN, no FIN) serve specific purposes:

Acknowledge received data without sending any new data
Keep-alive probes to verify connection is still active
Window updates to advertise newly available receive buffer space
Delayed acknowledgment when no data to send

ACK Characteristics:

Consumes 0 sequence numbers: Pure ACKs don't advance sequence space
Not retransmitted: Lost ACKs are covered by cumulative acknowledgment
Can piggyback: Almost always combined with data segments when available

The Ubiquitous ACK

ACK in State Transitions:

The ACK flag is critical for TCP state machine transitions:

SYN_SENT state:
  - Receive SYN+ACK → Send ACK → Move to ESTABLISHED
  
SYN_RECEIVED state:
  - Receive ACK for our SYN → Move to ESTABLISHED
  
FIN_WAIT_1 state:
  - Receive ACK for our FIN → Move to FIN_WAIT_2

FIN Flag: Graceful Connection Termination

FIN Semantics:

"I have no more data to send"
"Please acknowledge this FIN"
"You may still send data to me" (until you also send FIN)

The Half-Close:

TCP connections are full-duplex, meaning data can flow in both directions independently. A FIN closes only one direction:

A sends FIN to B:
  - A → B direction: Closed (A will send no more data)
  - B → A direction: Open (B can still send data)
  - This is called a "half-close"

The connection is fully closed only when both sides have sent and acknowledged FINs.

The Four-Way Close:

Graceful termination typically requires four segments:

1. A → B: FIN+ACK, Seq=X
   "I'm done sending. Final data was up to X."

2. B → A: ACK, Ack=X+1
   "I acknowledge your FIN."

3. B → A: FIN+ACK, Seq=Y
   "I'm also done sending. Final data was up to Y."

4. A → B: ACK, Ack=Y+1
   "I acknowledge your FIN. Connection closed."

Piggybacked FIN-ACK:

Steps 2 and 3 can be combined if B has no more data:

1. A → B: FIN+ACK
2. B → A: FIN+ACK (acknowledges A's FIN and sends B's FIN)
3. A → B: ACK (acknowledges B's FIN)

This reduces the exchange to three segments.

FIN Characteristics

•Consumes 1 sequence number: Like SYN, FIN+1 = expected next sequence
•Always has ACK set: FIN-only (without ACK) is unusual and suspicious
•Can carry data: The segment containing FIN may include final payload bytes
•Must be acknowledged: Sender retransmits FIN if no ACK received
•Triggers TIME_WAIT: The side sending the final ACK enters TIME_WAIT (typically 2×MSL)

TIME_WAIT State

RST Flag: Abortive Connection Reset

The RST (Reset) flag immediately and abruptly terminates a TCP connection. Unlike FIN's graceful closure, RST discards any outstanding data and ends the connection without negotiation.

When RST is Generated:

No listener on port: Connection attempt to closed port
Segment for non-existent connection: Data arrives for unknown four-tuple
Application abort: Application explicitly aborts (SO_LINGER = 0)
Resource exhaustion: System cannot handle more connections
Security measures: Firewall or IDS rejects connection

RST Generation Scenarios
Scenario	Trigger	RST Contents
Connection to closed port	SYN to port with no listener	RST+ACK, Ack=SYN's Seq+1
Data on half-open connection	Server rebooted during handshake	RST, Seq=what receiver expects
Application abort	close() with SO_LINGER=0	RST, discards outgoing queue
FIN during SYN_RECEIVED	FIN arrives before ESTABLISHED	RST
Invalid segment	Segment fails security check	RST (or silent discard)

RST vs. FIN:

Aspect	RST	FIN
Data handling	Discards unsent data	Waits for data to complete
State transitions	Immediate CLOSED	Goes through FIN_WAIT, TIME_WAIT
TIME_WAIT	No TIME_WAIT	TIME_WAIT required
Acknowledgment	RST is not acknowledged	FIN must be acknowledged
Use case	Error conditions, aborts	Normal shutdown

RST Attack / TCP Reset Attack

RST Characteristics

•Consumes 0 sequence numbers: RST doesn't advance sequence space
•Not acknowledged: There's no ACK for an RST; it's fire-and-forget
•Immediate effect: Receiving RST immediately transitions to CLOSED
•Sequence validation: RST is processed only if sequence number is acceptable
•RFC 5961 strengthening: Modern TCP requires RST seq to exactly match RCV.NXT

PSH Flag: Push Data to Application

PSH Semantics (Receiver Side):

Without PSH: TCP may buffer data before delivering to application
With PSH: TCP should deliver buffered data promptly

Common PSH Usage:

Interactive applications: Telnet, SSH send PSH to minimize latency
Request completion: HTTP request ends with PSH to indicate "process this now"
Small writes: Many implementations set PSH on final segment of each write()
Prompt delivery: Any time sender wants receiver to act immediately

Sender Behavior:

When an application makes a write() call, TCP buffering may delay transmission:

Without PSH: 
  write("GET / HTTP/1.1\r
") → Buffer, maybe wait for more data
  
With PSH:
  write("GET / HTTP/1.1\r
", MSG_PUSH) → Send immediately with PSH set

However, most TCP implementations automatically set PSH when:

Sending the last segment of buffered data
The send buffer becomes empty
The application explicitly requests it

Modern Reality:

PSH and Nagle's Algorithm

PSH Flag Effect on Data Delivery
PSH State	Sender Behavior	Receiver Behavior
Clear (0)	May buffer more application writes	May buffer before application read()
Set (1)	Send buffered data now	Deliver buffered data to application promptly

URG Flag: Urgent Data Marker

URG Mechanism:

When URG is set:

The 16-bit Urgent Pointer field (bytes 18–19) becomes valid
Urgent Pointer = offset from sequence number to end of urgent data
Receiver should notify application of urgent data presence

Segment: Seq=1000, URG=1, UrgPtr=10, Data="URGENT!!!NORMAL"

Interpretation:
  Urgent data: bytes 1000-1009 ("URGENT!!!" - 10 bytes)
  Normal data: bytes 1010+ ("NORMAL")

Historical Ambiguity:

The original RFC 793 was ambiguous about whether Urgent Pointer points to the last byte of urgent data or one past it. Different implementations chose differently:

BSD interpretation: Points to last byte of urgent data
RFC 1122 clarification: Points to first byte after urgent data

This inconsistency caused interoperability problems, and modern systems follow RFC 1122.

URG is Rarely Used

Application Interface:

Unix/POSIX systems expose urgent data through:

/* Sender: Send out-of-band data */
send(sock, "!", 1, MSG_OOB);

/* Receiver: Check for urgent data */
int atmark;
ioctl(sock, SIOCATMARK, &atmark);
if (atmark) {
    recv(sock, buf, 1, MSG_OOB);  /* Receive urgent byte */
}

/* Or use SIGURG signal to be notified of urgent data */
fcntl(sock, F_SETOWN, getpid());
/* SIGURG delivered when urgent data arrives */

Security Implications:

Flag Combinations and the TCP State Machine

Common Flag Combinations in Practice
Flags	Binary	Meaning	When Seen
SYN	000010	Connection initiation	First packet of connection
SYN+ACK	010010	Accept connection	Second packet of handshake
ACK	010000	Acknowledgment/Data	Most common in established state
PSH+ACK	011000	Data, deliver immediately	Interactive traffic, request/response
FIN+ACK	010001	Close connection	Connection termination
RST	000100	Abort connection	Error or rejection
RST+ACK	010100	Abort with acknowledgment	Common reset response
URG+ACK+PSH	111000	Urgent data with push	Out-of-band signals (rare)

Illegal or Suspicious Combinations:

Certain flag combinations are protocol violations or attack signatures:

Combination	Why Suspicious
SYN+FIN	Ambiguous: start or end? Confuses IDS/firewalls
SYN+RST	Contradictory: "start" and "abort"
FIN+RST	Contradictory: "graceful close" and "abort"
No flags (NULL scan)	Invalid segment; used for OS fingerprinting
All flags (XMAS scan)	Invalid; used for firewall probing
SYN+FIN+RST+etc	"Christmas tree" packet; attack probe

Security tools use these anomalies for detection:

Null scan: No flags set → May elicit different responses
XMAS scan: FIN+PSH+URG → Some systems respond differently
Maimon scan: FIN+ACK to closed port → Some systems don't RST

Firewall Evasion via Flags

Extended Flags: ECN and NS

Beyond the original six flags, modern TCP includes three additional flags for Explicit Congestion Notification (ECN):

ECN Flags:

Flag	Purpose
NS (Nonce Sum)	Protection against accidental/malicious ECN marking removal
CWR (Congestion Window Reduced)	Sender acknowledges ECN-Echo, has reduced sending rate
ECE (ECN-Echo)	Receiver echoes congestion indication back to sender

ECN Operation:

ECN capability negotiated via SYN exchange (ECE+CWR in initial SYN)
Routers mark IP header with Congestion Experienced (CE) when queues fill
TCP receiver sees CE mark, sets ECE flag in ACKs
TCP sender receives ECE, reduces congestion window, sets CWR
CWR signals to receiver: "I got your ECE, you can stop setting it"

ecn_handling.py
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
import socket
 
# Enable ECN for a socket (Linux)
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
 
# IP_TOS options for ECN
# 0x01 = ECT(1) - ECN Capable Transport (ECT(1))
# 0x02 = ECT(0) - ECN Capable Transport (ECT(0))
# 0x03 = CE - Congestion Experienced
 
# Set TCP_QUICKACK for immediate ACK of congestion
sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_QUICKACK, 1)
 
# Check system ECN configuration
# Linux: /proc/sys/net/ipv4/tcp_ecn
# Values:
#   0 = ECN disabled
#   1 = ECN enabled (initiate and accept)  
#   2 = ECN enabled (accept only, don't initiate)
 
# ECN negotiation happens automatically in the SYN exchange
# SYN with ECE+CWR set = "I support ECN"
# SYN-ACK with ECE = "I also support ECN, let's use it"
 
# Wireshark filter for ECN traffic
# tcp.flags.cwr == 1 or tcp.flags.ecn == 1

ECN Benefits

Summary: TCP Control Flags

We've explored the six classic TCP control flags and their modern extensions—the Boolean signals that govern every aspect of TCP connection management.

Key Takeaways

•SYN (Synchronize): Initiates connections, synchronizes sequence numbers, negotiates options. Consumes one sequence number.
•ACK (Acknowledgment): Validates the acknowledgment number field. Set on every segment after the initial SYN.
•FIN (Finish): Gracefully terminates one direction of the connection. Consumes one sequence number and triggers half-close.
•RST (Reset): Abruptly terminates connection without negotiation. Discards data, skips TIME_WAIT.
•PSH (Push): Requests immediate delivery to the application. Often set automatically by TCP stack.
•URG (Urgent): Signals presence of out-of-band data. Rarely used in modern applications.
•ECN Flags (NS, CWR, ECE): Enable explicit congestion notification without packet loss.

What's Next:

Page Complete

4 / 5