Connection Termination

In human communication, ending a conversation gracefully requires mutual acknowledgment—a simple "goodbye" from one party and a corresponding acknowledgment from the other. In the world of TCP, with its unwavering commitment to reliability, ending a connection is far more ceremonial and deliberate than starting one.

While the TCP three-way handshake establishes connections with elegant efficiency, connection termination demands a four-way handshake—an intentionally asymmetric process that ensures both parties have completed their data transfer, acknowledged all outstanding segments, and can safely release connection resources without losing a single byte.

This asymmetry isn't accidental. It reflects a profound architectural decision: connections are bidirectional, and each direction must be closed independently. This page explores the four-way handshake in exhaustive detail, revealing why TCP's designers chose this approach and how it guarantees the reliability that TCP promises.

Why is termination different from establishment?

TCP connection establishment uses three segments (SYN, SYN-ACK, ACK) to synchronize both endpoints and establish bidirectional communication. This works efficiently because both sides can piggyback their acknowledgments and synchronization in combined messages.

Connection termination, however, faces a fundamental asymmetry: either endpoint can initiate closure independently, and the other endpoint may still have data to send. This creates the need for a four-segment exchange.

The Bidirectional Nature of TCP

A TCP connection consists of two independent, unidirectional data streams:

• Client → Server stream: Data flows from client to server
• Server → Client stream: Data flows from server to client

Each stream must be closed separately. When the client finishes sending data, it closes its outbound stream, but the server may still be transmitting. The four-way handshake respects this independence.

The Four Segments Explained

The four-way handshake consists of:

1. FIN from Initiator: "I have finished sending data"
2. ACK from Receiver: "I acknowledge your finish"
3. FIN from Receiver: "I have also finished sending data"
4. ACK from Initiator: "I acknowledge your finish"

Each FIN closes one direction of data flow. Each ACK confirms receipt of that closure. Together, they ensure both parties agree that communication has ended.

Let's trace through the four-way handshake step by step, examining the precise sequence of events, the TCP header flags involved, and the state transitions at each endpoint.

Initial State: ESTABLISHED

Both client and server are in the ESTABLISHED state. Data can flow in both directions. Either party can initiate connection termination; for this example, we'll assume the client initiates.

Step 1: Client Sends FIN (Active Close)

The client application calls close() on the socket. The TCP stack responds by:

• Setting the FIN (Finish) flag in the TCP header
• Including the client's current sequence number
• Transitioning to the FIN_WAIT_1 state
• The client can no longer send data (but can still receive)

Step 2: Server Sends ACK (Passive Close Initiated)

Upon receiving the FIN, the server's TCP stack:

• Acknowledges the FIN by adding 1 to the received sequence number
• Transitions to the CLOSE_WAIT state
• Notifies the server application that the client has finished sending
• The server can still send data to the client

Client State Transition: FIN_WAIT_1 → FIN_WAIT_2

When the client receives the server's ACK for its FIN:

• The client transitions from FIN_WAIT_1 to FIN_WAIT_2
• The client's outbound stream is now officially closed
• The client waits for the server's FIN

Step 3: Server Sends FIN

When the server application finishes sending data and calls close():

• The server's TCP stack sends a FIN segment
• Server transitions from CLOSE_WAIT to LAST_ACK
• Server waits for final acknowledgment

Step 4: Client Sends Final ACK

Upon receiving the server's FIN:

• Client acknowledges by adding 1 to the server's final sequence number
• Client transitions from FIN_WAIT_2 to TIME_WAIT
• Client starts the 2MSL timer
• After 2MSL expires, client transitions to CLOSED

Key Observations from the Diagram

1. Asymmetric Timing: The server can delay its FIN arbitrarily while finishing data transmission. The time between steps 2 and 3 can range from microseconds to minutes.

2. State Differences: The client goes through FIN_WAIT_1 → FIN_WAIT_2 → TIME_WAIT → CLOSED, while the server goes through CLOSE_WAIT → LAST_ACK → CLOSED.

3. Who Waits: Only the active closer (initiator) enters TIME_WAIT. The passive closer goes directly to CLOSED after receiving the final ACK.

4. Sequence Number Consumption: Each FIN consumes exactly one sequence number, which is why acknowledgments increment by 1 even though no data is transmitted.

A natural question arises: Why can't we combine the server's ACK and FIN into a single segment, reducing termination to three segments?

The answer lies in the nature of application behavior and the separation between acknowledging reception and being ready to close.

Scenario Analysis

Consider a web server handling an HTTP request:

1. Client sends request, then wants to close its send stream (FIN)
2. Server receives the FIN and acknowledges it (ACK) immediately
3. Server is still processing the request and generating the response
4. Server continues sending response data
5. Server finishes sending and closes its stream (FIN)

In this scenario, the server's ACK and FIN cannot be combined because there's application work between them. The ACK is sent immediately by the TCP stack, but the FIN is only sent when the application explicitly closes the socket.

The Separation of Concerns Principle

TCP's design separates several concerns:

• Transport layer acknowledgment (ACK): "I received your segment" — handled by TCP stack
• Application layer completion (FIN): "I'm done sending" — controlled by application
• Connection state management: Tracking progress through state machine

This separation ensures that TCP can acknowledge receipt immediately (essential for flow control and retransmission) while allowing applications arbitrary time to complete their work before signaling closure.

Understanding the TCP state machine is essential for debugging connection issues in production. Let's examine each state involved in connection termination in detail.

FIN_WAIT_1: Initiator Awaiting ACK

When the initiating endpoint sends a FIN:

• Transitions to FIN_WAIT_1
• Waits for ACK of its FIN
• Can still receive data from the peer
• Retransmits FIN if no ACK received within RTO
• Normal duration: one round-trip time

FIN_WAIT_2: Initiator Awaiting Peer's FIN

After receiving ACK for its FIN:

• Transitions to FIN_WAIT_2
• Outbound stream is closed, inbound open
• Waiting for peer to close its stream
• Can receive data (half-close mode)
• No timeout by default (RFC 793)

CLOSE_WAIT: Passive Closer Awaiting Application Close

When a peer's FIN is received:

• TCP acknowledges the FIN automatically
• Transitions to CLOSE_WAIT
• Application is notified (EOF on read)
• Application may continue sending data
• Stays here until application calls close()

LAST_ACK: Passive Closer Awaiting Final ACK

After sending its FIN:

• Transitions to LAST_ACK
• Waiting for ACK of its FIN
• Will retransmit FIN if ACK not received
• Upon receiving ACK, transitions directly to CLOSED

TIME_WAIT: The Final Waiting Period

After sending the final ACK:

• Active closer transitions to TIME_WAIT
• Waits for 2 × MSL (Maximum Segment Lifetime)
• Prevents delayed segment confusion
• Can respond to retransmitted FINs
• Resources held but connection closed

What happens when both endpoints decide to close at exactly the same time? TCP handles this gracefully through a mechanism called simultaneous close.

The Scenario

1. Both applications call close() at roughly the same time
2. Both endpoints send FIN segments
3. Both FINs cross in the network
4. Each endpoint receives the peer's FIN instead of an ACK

The State Transitions

Both endpoints:

1. Start in ESTABLISHED
2. Send FIN, enter FIN_WAIT_1
3. Receive peer's FIN while in FIN_WAIT_1
4. Send ACK, enter CLOSING (a special state for simultaneous close)
5. Receive ACK of their FIN
6. Enter TIME_WAIT
7. After 2MSL, enter CLOSED

Key Observations

1. Both Enter TIME_WAIT: Unlike normal close where only the active closer enters TIME_WAIT, simultaneous close puts both endpoints in TIME_WAIT.

2. Four Segments Total: Despite being simultaneous, the handshake still requires four segments—two FINs and two ACKs.

3. Rare in Practice: Simultaneous close is uncommon in real applications but TCP must handle it correctly.

4. Protocol Correctness: This scenario demonstrates TCP's state machine completeness—it handles all possible timing scenarios gracefully.

Understanding the four-way handshake has significant implications for application development and system administration.

Application Patterns

When closing sockets, applications have several options:

Monitoring Connection States

System administrators should regularly monitor TCP states to detect potential issues:

The four-way handshake is TCP's solution to the fundamental challenge of reliably closing a bidirectional connection. Let's consolidate the key concepts:

What's Next

Now that we understand the complete four-way handshake flow, the next page examines the FIN and ACK segments in detail—their precise encoding in TCP headers, their role as control signals, and the nuances of their handling by TCP implementations.