Mastering TCP, HTTP, Sockets, and Socket Connection Pools

OSI Model and Protocol Mapping

The article starts with the seven‑layer OSI model, mapping IP to the network layer, TCP/UDP to the transport layer, and HTTP to the application layer, noting that OSI does not define sockets.

TCP and UDP Basics

It details the TCP three‑handshake (SYN, SYN‑ACK, ACK) and four‑handshake termination (FIN, ACK sequences), illustrating each step with diagrams. It then lists TCP’s connection‑oriented reliability versus UDP’s connection‑less, faster but unreliable nature, explaining why protocols like MSN (TCP) are slower than QQ (UDP).

Common TCP Questions

Maximum concurrent connections are limited by system file descriptor limits, not by the 65,535 port range; they can be increased via ulimit -n and kernel parameters.

TIME_WAIT persists for 2 MSL to allow retransmission of a possibly lost final ACK.

Excessive TIME_WAIT sockets can exhaust local ports, causing “address already in use” errors; kernel tuning (e.g., net.ipv4.tcp_tw_reuse, net.ipv4.tcp_tw_recycle) mitigates this.

Long vs. Short Socket Connections

Short connections follow connect → data → close, while long connections keep the TCP link alive with periodic heartbeat packets, allowing multiple data exchanges without repeated handshakes. Long connections are preferable for frequent, point‑to‑point communication where connection overhead must be minimized.

Heartbeat Mechanism

A heartbeat is a periodic custom command sent by client and server to confirm the socket is still alive; if the socket is broken, the heartbeat fails, prompting reconnection.

Defining a Custom Application Protocol

The article proposes a simple protocol with a fixed‑length header (e.g., length:000000000xxxx) followed by JSON‑encoded payload, covering header definition, payload format, and heartbeat handling.

Socket Connection Pool Concept

A Socket connection pool maintains a collection of long‑lived sockets, automatically discarding invalid ones and creating new connections as needed. It manages four queues: idle sockets, active sockets, waiting requests, and removal of dead sockets, with configurable pool size.

Node.js Implementation with generic‑pool

Using the generic-pool library, the article shows the directory structure, pool initialization, and usage. Images illustrate the initialization code, acquisition of a socket, and log output demonstrating that subsequent requests reuse existing connections instead of creating new ones.

Source Code Analysis (Pool.js)

The core implementation resides in lib/Pool.js. The constructor sets up the idle, active, and waiting queues. The acquire method follows the described logic: retrieve an idle socket, create a new one if the active count is below the limit, or enqueue the request if the pool is saturated. Screenshots of the constructor and acquire method are provided.