Long Connection in TCP

Long‑lived connections (persistent connections) are essential for modern web applications that require real‑time updates, low latency, or reduced overhead. This document explains how HTTP, WebSocket, and TLS handle long connections, the mechanisms that keep them alive, and the challenges involved. Each section includes a conceptual diagram.

---

1. HTTP Persistent Connections (Keep‑Alive)

Overview

In HTTP/1.1, persistent connections (also called keep‑alive) allow multiple requests and responses to be sent over a single TCP connection, avoiding the overhead of repeated TCP handshakes and slow starts. The connection remains open until explicitly closed by either party.

How It Works

• The client includes Connection: keep-alive in the request (default in HTTP/1.1).

• The server keeps the TCP socket open after sending the response.

• Subsequent requests reuse the same connection.

• Either side can close the connection by sending Connection: close or after an idle timeout.

Maintenance Mechanisms

• Timeout: Servers close idle connections after a period (e.g., 60 seconds) to free resources.

• Maximum requests: Some servers limit the number of requests per connection (e.g., Apache default is 100).

• TCP keep‑alive: Optional at the TCP layer, sends probes to detect dead peers (usually disabled for HTTP due to long default intervals).

Limitations

• Half‑duplex: Request–response pattern; server cannot push data without a prior request.

• Head‑of‑line blocking: In HTTP/1.1, requests on the same connection are processed sequentially (mitigated by HTTP/2 multiplexing).

Diagram: HTTP Persistent Connection Flow

Client                      Server
  |                           |
  |  ---- TCP Handshake --->  |
  |<---   SYN, SYN-ACK   ----|
  |                           |
  |  ---- HTTP Request 1 -->  |
  |<--- HTTP Response 1 ----  |
  |                           |
  |  ---- HTTP Request 2 -->  (same connection)
  |<--- HTTP Response 2 ----  |
  |                           |
  |       ... idle ...        |
  |                           |
  |<--- idle timeout --------|
  |--- FIN (close) --------->|

---

2. WebSocket – Full‑Duplex Long‑Lived Connection

Overview

WebSocket provides a full‑duplex communication channel over a single TCP connection. It starts as an HTTP upgrade handshake and then switches to the WebSocket protocol, allowing both client and server to send messages at any time.

Connection Establishment

1. Client sends an HTTP GET request with Upgrade: websocket and Connection: Upgrade.

2. Server responds with 101 Switching Protocols.

3. The connection upgrades from HTTP to WebSocket.

Frame Format

Data is transmitted in frames (text or binary). A small header (2–14 bytes) contains opcode, payload length, and masking information.

Maintenance Mechanisms

• Ping/Pong frames: Standard control frames to keep the connection alive. Either endpoint can send a Ping; the peer must reply with a Pong.

• Close handshake: A control frame to gracefully close the connection.

• TCP keep‑alive: Often enabled to detect dead peers at the OS level.

• Application‑level heartbeats: Custom ping/pong if the protocol’s built‑in is not used.

Diagram: WebSocket Handshake and Lifecycle

Client                                 Server
  |                                       |
  |  ---- HTTP GET (Upgrade) -------->   |
  |<--- 101 Switching Protocols ------   |
  |                                       |
  |  ---- WebSocket Data Frame ------>   |
  |<--- WebSocket Data Frame -------     |
  |  ---- Ping (opcode 0x9) -------->   |
  |<--- Pong (opcode 0xA) ----------     |
  |                                       |
  |  ---- Close Frame (opcode 0x8) -->   |
  |<--- Close Frame -----------------     |
  |--- TCP FIN ----------------------->  |

---

3. TLS – Securing Long Connections

Overview

TLS (Transport Layer Security) encrypts the data sent over TCP. When used with persistent connections (HTTP keep‑alive or WebSocket), the TLS session is established once and reused for the entire duration.

Session Resumption

• Session IDs: The server assigns a session ID during the initial handshake. On reconnection, both parties reference the cached session to skip asymmetric cryptography.

• Session Tickets (RFC 5077): The server encrypts session state and sends it to the client as a ticket. The client presents it in a later connection.

Maintenance Mechanisms

• TLS heartbeat (RFC 6520): An optional extension that allows periodic keep‑alive messages at the TLS layer, independent of the application. Not widely deployed.

• Renegotiation: Can be used to update keys or re‑authenticate, but often disabled due to security concerns.

• TCP keep‑alive: Still active beneath TLS; the TLS stack is unaware but benefits from the TCP layer’s dead‑peer detection.

Impact on Long Connections

• The initial handshake adds latency (2 RTTs), but session resumption reduces it to 1 RTT or 0‑RTT (TLS 1.3).

• Long‑lived TLS connections must manage certificate expiration or key updates. TLS 1.3 supports key update messages.

Diagram: TLS over a Persistent Connection

Client (TLS)                           Server (TLS)
     |                                      |
     |  ---- TCP Handshake ----------->    |
     |<---   SYN, SYN-ACK ------------     |
     |                                      |
     |  ---- TLS Handshake ----------->    |
     |<---   Certificate, Key Exchange -   |
     |  ---- Encrypted Application Data -> |
     |<--- Encrypted Application Data --   |
     |                                      |
     |  ---- TLS Key Update ---------->    |
     |<--- TLS Key Update ------------     |
     |                                      |
     |  ---- TLS Close Notify -------->    |
     |--- FIN -------------------------->  |

---

4. General Maintenance Mechanisms for Long Connections

Long‑lived connections, regardless of the application protocol, require careful management to avoid resource exhaustion and to detect dead peers.

4.1 TCP Keep‑Alive

• Built into the TCP stack.

• After an idle period (default 2 hours on Linux), the OS sends an empty probe. If no reply after several probes, the connection is closed.

• Configurable via socket options (SO_KEEPALIVE, TCP_KEEPIDLE, etc.).

4.2 Application‑Level Heartbeats

• Ping/pong messages inside the application protocol (WebSocket, SIP, custom protocols).

• More responsive than TCP keep‑alive and independent of OS settings.

• Allows detection of zombie connections (e.g., half‑open TCP).

4.3 Idle Timeouts

• Both client and server typically impose an idle timeout.

• After the timeout, the connection is closed, forcing a reconnect if needed.

• Common values: 60 seconds for HTTP keep‑alive, 30–120 seconds for WebSocket proxies.

4.4 Load Balancer Considerations

• Proxies and load balancers often have their own idle timeouts.

• They may terminate idle connections prematurely unless the application sends periodic keep‑alive messages.

• Solutions: adjust proxy timeouts, use WebSocket ping frames, or implement a “heartbeat” at the application layer.

4.5 Graceful Close

• Avoid abrupt termination (RST).

• Use protocol‑specific close handshakes (HTTP Connection: close, WebSocket Close frame, TLS close_notify).

• Ensures reliable delivery of final data.

---

Comprehensive Diagram: Interaction of Layers

Below is a simplified view of how HTTP, WebSocket, TLS, and TCP interact in a long‑lived connection, highlighting maintenance mechanisms at each layer.

+------------------------------------------------------+
|                    Application                       |
|  (HTTP Keep-Alive / WebSocket / Custom Protocol)     |
|  • Ping/Pong frames                                  |
|  • Application-level heartbeats                     |
|  • Idle timeouts                                   |
+------------------------------------------------------+
                        ⇅
+------------------------------------------------------+
|              TLS / SSL (optional)                    |
|  • Session resumption (ID / Ticket)                 |
|  • Key update (TLS 1.3)                            |
|  • Heartbeat (RFC 6520, rarely used)               |
+------------------------------------------------------+
                        ⇅
+------------------------------------------------------+
|                   TCP (transport)                    |
|  • Connection establishment (SYN, SYN-ACK)          |
|  • Keep-alive probes                                |
|  • Flow control / congestion control               |
|  • Graceful close (FIN)                            |
+------------------------------------------------------+
                        ⇅
+------------------------------------------------------+
|                     IP Network                       |
+------------------------------------------------------+

                    Maintenance Signals
--------------------------------------------------------
1. TCP Keep‑Alive : Probes at OS level (long interval).
2. TLS Heartbeat  : Optional TLS-level keep‑alive.
3. App‑level Ping : Short interval, explicit reply.
4. Idle Timeout   : Both sides close after inactivity.

---

Summary

• HTTP persistent connections reduce latency by reusing the same TCP connection for multiple requests, but are half‑duplex and subject to head‑of‑line blocking.

• WebSocket upgrades an HTTP connection to a full‑duplex, long‑lived channel, with built‑in ping/pong for keep‑alive.

• TLS secures long connections and provides session resumption to avoid repeated handshakes; modern versions support key updates.

• Maintenance mechanisms operate at different layers: TCP keep‑alive, application heartbeats, and idle timeouts. A robust system combines them to balance responsiveness and resource usage.

These technologies together enable efficient, secure, and real‑time communication in today’s web applications.