# 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. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://www.damonyuan.com/tech/260202-long-connection-in-tcp.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.