Understanding TCP, HTTP, Sockets, and Socket Connection Pools

The article begins by introducing the OSI seven‑layer model, mapping IP to the network layer, TCP/UDP to the transport layer, and HTTP to the application layer, and notes that sockets are not part of the OSI model.

TCP and UDP

It details TCP's three‑handshake process (SYN, SYN‑ACK, ACK) and four‑step teardown (FIN, ACK, FIN, ACK), describing each packet’s fields and state transitions, then contrasts UDP as a connection‑less, faster but unreliable protocol.

Common Questions

Maximum concurrent TCP connections are limited by the operating system’s file descriptor limit rather than the 65,535 port range; the limit can be raised 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 settings such as net.ipv4.tcp_tw_reuse, net.ipv4.tcp_tw_recycle, and net.ipv4.tcp_fin_timeout can mitigate this.

Long vs. Short Connections

Short connections follow connect → data → close, while long connections keep the TCP link alive, sending periodic heartbeat messages to verify liveness. Long connections are preferable for frequent, point‑to‑point communication where connection setup overhead would degrade performance.

Heartbeat Implementation

The article explains the purpose of heartbeat packets and shows example server and client output images illustrating a custom heartbeat protocol.

Defining a Custom Protocol

To give meaning to transmitted data, the article outlines a simple application‑layer protocol with a fixed‑length header (e.g., length:000000000xxxx) and JSON payload, describing header design and serialization choices.

Socket Connection Pool

A socket pool maintains a collection of long‑lived socket connections, automatically discarding invalid sockets and creating new ones as needed. It manages four queues: idle sockets, active sockets, waiting requests, and configuration for pool size.

The article introduces the Node.js generic-pool module, showing its directory structure, initialization, and usage with the custom protocol. Logs demonstrate that the first two requests create new sockets, while subsequent requests reuse pooled sockets after a timer expires.

Source Code Analysis

Key implementation resides in lib/Pool.js, which defines the idle, active, and waiting queues, and the acquire method that selects or creates a socket based on pool state. The analysis walks through the method’s logic, illustrating how it ultimately returns a long‑lived connection.

Overall, the article provides a step‑by‑step guide from networking fundamentals to a practical socket pool implementation, highlighting configuration knobs and trade‑offs for high‑concurrency server applications.