TCP State Diagram

After the careful choreography of the three-way handshake, the TCP connection enters its most important and longest-lasting state: ESTABLISHED. This is where TCP delivers on its promise—reliable, ordered, bidirectional byte stream delivery between two endpoints. The transient nature of handshake states gives way to a stable platform for data exchange that may persist for milliseconds or months.

The ESTABLISHED state is where applications actually use TCP. Every HTTP request you make, every database query you send, every real-time message you receive—all travel through connections in the ESTABLISHED state. Understanding this state means understanding how TCP maintains reliability during data transfer, how it detects and handles failures, and how applications interact with established connections.

This page explores the ESTABLISHED state comprehensively—from the conditions that define it, through the mechanics of data transfer it enables, to the keep-alive mechanisms that maintain it, and the socket operations available during this phase.

The ESTABLISHED state represents a fully synchronized, bidirectional communication channel. Both endpoints have completed the handshake and agreed on the parameters that will govern their data exchange.

Entry Conditions

A socket enters ESTABLISHED from different prior states:

What's Been Negotiated

By the time ESTABLISHED is reached, both sides have agreed on:

Sequence Number Spaces:

• Client knows server's Initial Sequence Number (ISN)
• Server knows client's ISN
• Both know the next expected sequence number from the peer

Communication Parameters:

• Maximum Segment Size (MSS) for each direction
• Window scaling factor (if negotiated)
• SACK support (if both sides agreed)
• Timestamp usage (if both sides agreed)

Connection Identity:

• Local IP:Port ↔ Remote IP:Port (the 4-tuple)
• Uniquely identifies this connection in both kernels

The Established Connection Structure

The kernel maintains substantial state for established connections:

// Simplified view of socket state in ESTABLISHED
struct tcp_sock {
    // Sequence number tracking
    u32 snd_una;        // Oldest unacknowledged sequence number
    u32 snd_nxt;        // Next sequence number to send
    u32 snd_wnd;        // Send window (from receiver's advertisements)
    u32 rcv_nxt;        // Next expected sequence from peer
    u32 rcv_wnd;        // Our receive window
    
    // Buffer management
    struct sk_buff_head write_queue;    // Data waiting to send
    struct sk_buff_head receive_queue;  // Data received, awaiting read
    struct sk_buff_head out_of_order;   // Out-of-order segments
    
    // Timing and RTT
    u32 srtt_us;        // Smoothed RTT estimate
    u32 rttvar_us;      // RTT variance
    u32 rto;            // Retransmission timeout
    
    // Congestion control
    u32 cwnd;           // Congestion window
    u32 ssthresh;       // Slow start threshold
    
    // Keep-alive state
    u8 keepalive_probes; // Number of keepalive probes sent
    unsigned long keepalive_time; // Last data/ACK time
};

TCP in ESTABLISHED state provides full-duplex communication—both endpoints can send data to each other simultaneously, independently. This is not alternating half-duplex but truly concurrent bidirectional data flow.

The Byte Stream Model

TCP presents a byte stream abstraction to applications:

• Data written is a continuous stream of bytes, not discrete messages
• TCP may segment and reassemble as needed
• Receiver sees bytes in the same order they were sent
• No inherent message boundaries (application must implement if needed)

Application writes:  [Hello Wo][rld! How are ][you?]
                          │         │           │
TCP segments:        [Hello World! Ho][w are you?]
                          │               │
Receiver sees:       [Hello World! How are you?]
                     (same bytes, same order, different grouping)

Send and Receive Buffers

Each direction of data flow uses a buffer managed by the kernel:

                        ┌─────────────────────────┐
  Application          │       TCP Socket         │          Network
                       │                          │
     write() ─────────▶│   ┌──────────────────┐  │───▶ Segments
                       │   │   Send Buffer    │  │
                       │   │   (SO_SNDBUF)    │  │
                       │   └──────────────────┘  │
                       │                          │
     read() ◀─────────│   ┌──────────────────┐  │◀─── Segments
                       │   │  Receive Buffer  │  │
                       │   │   (SO_RCVBUF)    │  │
                       │   └──────────────────┘  │
                       └─────────────────────────┘

Send Buffer (SO_SNDBUF):

• Holds data written by application but not yet acknowledged
• write() blocks when buffer is full (unless non-blocking)
• Data removed when ACKs arrive
• Typical size: 16KB - 4MB

Receive Buffer (SO_RCVBUF):

• Holds data received from network but not yet read by application
• Determines advertised window size
• Data removed when application calls read()
• Typical size: 16KB - 4MB

Sequence Numbers and Acknowledgments

During data transfer, sequence numbers track every byte:

Sender's View:

snd_una               snd_nxt                 snd_una + snd_wnd
   │                     │                            │
   ▼                     ▼                            ▼
   ├─────────────────────┼────────────────────────────┤
   │     Unacked data    │    Available window        │
   │   (awaiting ACKs)   │   (can send more)         │
   └─────────────────────┴────────────────────────────┘

Receiver's View:

   rcv_nxt                                   rcv_nxt + rcv_wnd
      │                                              │
      ▼                                              ▼
      ├──────────────────────────────────────────────┤
      │              Receive Window                  │
      │     (will accept these sequence numbers)     │
      └──────────────────────────────────────────────┘

Every data segment contains:

• Sequence number of first byte
• ACK bit set (acknowledging peer's data)
• Acknowledgment number (next expected from peer)
• Window size (receiver's available buffer space)

Example Exchange:

Time  │  Direction  │  Seq       │  Ack     │  Data
──────┼─────────────┼────────────┼──────────┼────────────
  1   │  A → B      │  1000      │  5000    │  100 bytes
  2   │  B → A      │  5000      │  1100    │  200 bytes
  3   │  A → B      │  1100      │  5200    │  150 bytes
  4   │  B → A      │  5200      │  1250    │  ACK only

The ESTABLISHED state is where TCP's reliability guarantees are continuously enforced. Every segment must be acknowledged, lost segments must be retransmitted, and order must be preserved.

The Reliability Guarantee

TCP guarantees that data written to a socket will be:

1. Delivered to the remote application (or an error returned)
2. Delivered in order (bytes arrive in send order)
3. Delivered without corruption (checksum verification)
4. Delivered exactly once (duplicate detection)

Acknowledgment Mechanisms

Cumulative ACKs:

• ACK number acknowledges all bytes up to that point
• If bytes 1-1000 and 2001-3000 received, ACK = 1001 (gap present)
• Simple but inefficient when segments are lost out of order

Selective ACKs (SACK):

• Additional option field lists received ranges
• Sender knows exactly which segments are missing
• Enables targeted retransmission

Standard ACK:  "I've received up to byte 1000"
With SACK:    "I've received up to byte 1000, 
               plus bytes 2001-3000 and 4001-5000"
               
Sender knows: Need to retransmit bytes 1001-2000 and 3001-4000

Retransmission Triggers

The Retransmission Timer (RTO)

TCP maintains a retransmission timer that adapts to network conditions:

RTO = SRTT + 4 × RTTVAR

Where:
- SRTT = Smoothed Round-Trip Time (exponentially weighted average)
- RTTVAR = RTT Variance estimate

On timeout:
- RTO doubles (exponential backoff)
- Maximum typically 60-120 seconds
- Minimum typically 200ms-1s

Calculating RTT:

// Jacobson's algorithm (simplified)
void update_rtt(long measured_rtt) {
    // First measurement
    if (srtt == 0) {
        srtt = measured_rtt;
        rttvar = measured_rtt / 2;
        rto = srtt + 4 * rttvar;
        return;
    }
    
    // Subsequent measurements
    long err = measured_rtt - srtt;
    
    // SRTT = SRTT + (1/8) * (RTT - SRTT)
    srtt = srtt + (err >> 3);
    
    // RTTVAR = RTTVAR + (1/4) * (|RTT - SRTT| - RTTVAR)
    rttvar = rttvar + ((abs(err) - rttvar) >> 2);
    
    // RTO = SRTT + 4 * RTTVAR (with minimum)
    rto = max(MIN_RTO, srtt + 4 * rttvar);
}

Out-of-Order Handling

When segments arrive out of order, TCP must handle them carefully:

1. Buffer out-of-order segments in a separate queue
2. Send immediate duplicate ACK (signals gap to sender)
3. Reassemble when gap is filled (move to receive buffer)
4. Deliver to application in order (never deliver gaps)

Segments arrive:  1000  3000  2000  4000
                    ↓     ↓     ↓     ↓
                    
Receive buffer:  [1000]           (deliver 1000)
OOO buffer:            [3000]     (buffer 3000)
ACK sent:        1001             (expecting 1001, not 3001)

After 2000:      [1000][2000][3000][4000] (reassembled)
ACK sent:        5000             (all received)

An established TCP connection can exist indefinitely without any data transfer. The connection is purely a state maintained by both kernels—there's no "active" component that requires constant communication. But this creates a problem: how do you detect a dead peer?

The Dead Peer Problem

Consider these scenarios:

1. Remote host crashes (power failure, kernel panic)

   • No FIN or RST sent (crash was instantaneous)
   • Local side doesn't know connection is dead
   • Data written will never be acknowledged

2. Network path fails

   • Cables cut, routers fail, firewall state expires
   • Packets can't reach destination
   • Neither side knows until data transfer fails

3. Remote application hangs

   • Still technically "alive" but unresponsive
   • May recover later
   • How long should we wait?

Without keep-alive, a silent connection could remain "ESTABLISHED" in the kernel forever, consuming resources.

How Keep-Alive Works

TCP keep-alive sends probe packets when the connection is idle:

┌─────────────────────────────────────────────────────────────────┐
│                        Keep-Alive Timeline                      │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  Last data ──────────── tcp_keepalive_time ─────────────▶ Probe │
│     (2 hours default)                                           │
│                                                                 │
│  Probe ──────────────── tcp_keepalive_intvl ─────────────▶ Probe │
│     (75 seconds default)                                        │
│                                                                 │
│  After tcp_keepalive_probes failures (default 9): Connection dead │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Keep-alive probe packet:

• Empty segment (no data)
• Sequence number = snd_nxt - 1 (deliberately old)
• Peer must respond with ACK (acknowledging its rcv_nxt)
• Response proves peer is alive and reachable

Keep-alive response interpretation:

When to Use Keep-Alive

Good Use Cases:

• Long-lived connections (database pools, message queues)
• Connections through stateful firewalls (prevents state expiration)
• Detecting crashed servers in distributed systems
• IoT devices that may lose connectivity silently

Caution Needed:

• Mobile networks (aggressive keep-alive drains battery, uses data quota)
• Connections expected to be idle for legitimate reasons
• High connection counts (keep-alive adds overhead)

The Controversy Around Keep-Alive

TCP keep-alive is somewhat controversial in the networking community:

Arguments Against:

• Violates end-to-end principle (network shouldn't care about idle connections)
• Default 2-hour timeout is too long to be useful
• Application-level heartbeats are more flexible
• Adds network overhead for inactive connections

Arguments For:

• Catches scenarios application heartbeats can't (kernel crash, network failure)
• Simpler than implementing per-application heartbeats
• Prevents resource leaks from zombie connections
• Works even when application is blocked

The ESTABLISHED state is where the primary socket I/O operations are used. Understanding these operations and their behaviors is essential for network programming.

Reading Data: read() / recv()

ssize_t recv(int sockfd, void *buf, size_t len, int flags);

Behavior:

• Blocks until at least 1 byte is available (unless non-blocking)
• Returns number of bytes read (may be less than requested)
• Returns 0 on graceful close (FIN received)
• Returns -1 on error (check errno)

Important Flags:

Edge Cases:

int n = recv(sockfd, buf, 1024, 0);

if (n > 0) {
    // Data received (process n bytes)
} else if (n == 0) {
    // Connection closed by peer (FIN received)
    // Socket transitioning to CLOSE_WAIT
} else { // n < 0
    if (errno == EAGAIN || errno == EWOULDBLOCK) {
        // Non-blocking: no data available yet
    } else if (errno == ECONNRESET) {
        // Connection reset by peer (RST received)
    } else {
        // Other error
        perror("recv");
    }
}

Writing Data: write() / send()

ssize_t send(int sockfd, const void *buf, size_t len, int flags);

Behavior:

• Copies data to kernel send buffer
• Blocks if send buffer is full (unless non-blocking)
• Returns number of bytes copied (may be less than len)
• Actual transmission happens asynchronously
• Success does NOT mean data was received by peer!

Important Flags:

Shutdown Operations

While the connection is ESTABLISHED, you can partially close it:

int shutdown(int sockfd, int how);

shutdown(SHUT_WR) is the clean way to signal "I'm done sending":

• Sends FIN to peer
• Peer's read() returns 0 (EOF)
• Peer knows no more data coming
• Connection transitions to FIN_WAIT states
• You can still receive data from peer

Socket Status and Options

// Check socket error status
int error;
socklen_t len = sizeof(error);
getsockopt(sockfd, SOL_SOCKET, SO_ERROR, &error, &len);
// error non-zero means connection broken

// Get buffer sizes
int sndbuf, rcvbuf;
getsockopt(sockfd, SOL_SOCKET, SO_SNDBUF, &sndbuf, &len);
getsockopt(sockfd, SOL_SOCKET, SO_RCVBUF, &rcvbuf, &len);

// Get connection info
struct sockaddr_in peer;
getpeername(sockfd, (struct sockaddr*)&peer, &len);
// peer now contains remote IP and port

Even in ESTABLISHED state, connections can fail. Applications must detect and handle these failures appropriately.

How Failures Manifest

1. Graceful Close (recv returns 0)

The peer called close() or shutdown()—a normal, expected closure.

int n = recv(sockfd, buf, sizeof(buf), 0);
if (n == 0) {
    // Peer closed connection gracefully
    // This is normal, not an error
    close(sockfd);
}

2. Connection Reset (ECONNRESET)

The peer sent RST—connection is forcibly terminated.

int n = recv(sockfd, buf, sizeof(buf), 0);
if (n < 0 && errno == ECONNRESET) {
    // Peer reset connection (RST received)
    // Possible causes:
    //   - Peer crashed and rebooted
    //   - Peer process died abnormally
    //   - Firewall injection attack
    close(sockfd);
}

3. Broken Pipe (EPIPE / SIGPIPE)

Write to a connection that peer has closed.

// Peer has closed their side (FIN received)
// We try to send data
int n = send(sockfd, data, len, MSG_NOSIGNAL);
if (n < 0 && errno == EPIPE) {
    // Cannot write: connection broken
    close(sockfd);
}

// Without MSG_NOSIGNAL, SIGPIPE is raised instead!
// Default SIGPIPE action: terminate process

4. Timeout (ETIMEDOUT)

Retransmission limit exceeded—no response from peer.

int n = recv(sockfd, buf, sizeof(buf), 0);
if (n < 0 && errno == ETIMEDOUT) {
    // Network path is dead (no response to probes)
    // Takes a long time to detect with defaults
    close(sockfd);
}

Proactive Failure Detection

Don't wait for failures to manifest—detect them early:

1. Enable TCP Keep-Alive (as discussed earlier)

2. Implement Application Heartbeats

import threading
import time

def heartbeat_monitor(sock, interval=30, timeout=90):
    """Send periodic heartbeats, detect missing responses"""
    last_response = time.time()
    
    while True:
        # Send heartbeat
        try:
            sock.send(b"PING")
        except:
            raise ConnectionError("Failed to send heartbeat")
        
        # Check for response (with timeout)
        sock.settimeout(timeout)
        try:
            response = sock.recv(4)
            if response == b"PONG":
                last_response = time.time()
        except socket.timeout:
            if time.time() - last_response > timeout:
                raise ConnectionError("Heartbeat timeout")
        
        time.sleep(interval)

3. Use Proper Timeouts

// Set socket receive timeout
struct timeval tv;
tv.tv_sec = 30;   // 30 seconds
tv.tv_usec = 0;
setsockopt(sockfd, SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof(tv));

// recv() will now return EAGAIN/EWOULDBLOCK after 30 seconds

We've explored the ESTABLISHED state comprehensively—the stable, productive phase of TCP connections where reliable data transfer occurs.

Key Takeaways

What's Next

All good things must end. When one or both sides want to terminate the connection, TCP enters its closing states: FIN_WAIT and TIME_WAIT. These states handle the orderly teardown of the connection, ensuring all data is delivered and no orphaned packets can interfere with future connections. In the next page, we'll explore the connection termination states and the critical role of TIME_WAIT.