Master TCP/UDP, Sockets & Connection Pools: From OSI Model to Node.js

Introduction

Developers often encounter terms such as HTTP, TCP/IP, UDP, Socket, long‑living Socket connections, and Socket connection pools, yet the relationships, differences, and underlying principles are not always clear. This guide starts from basic network protocol concepts and progresses step‑by‑step to a full Socket connection‑pool implementation.

OSI Seven‑Layer Model

The OSI (Open System Interconnection) model divides network communication into seven layers: Physical, Data Link, Network, Transport, Session, Presentation, and Application. The diagram below maps common protocols and hardware to each layer.

From the diagram, IP resides in the Network layer, TCP/UDP in the Transport layer, and HTTP in the Application layer. OSI does not define Socket; its role will be introduced later with code examples.

TCP and UDP Connections

TCP provides reliable, connection‑oriented communication through a three‑handshake establishment and four‑step termination, while UDP offers faster, connection‑less transmission without guarantees.

TCP Three‑Way Handshake

1. First handshake : Client sends SYN (sequence number x) and enters SYN_SEND state. 2. Second handshake : Server replies with SYN‑ACK (acknowledgment x+1, its own SYN with sequence y) and enters SYN_RECV. 3. Third handshake : Client sends ACK (acknowledgment y+1) and both sides reach ESTABLISHED state.

TCP Four‑Way Termination

1. First termination : Host1 sends FIN and enters FIN_WAIT_1. 2. Second termination : Host2 acknowledges with ACK, entering FIN_WAIT_2. 3. Third termination : Host2 sends its own FIN and enters LAST_ACK. 4. Fourth termination : Host1 acknowledges, enters TIME_WAIT, and after 2 MSL (maximum segment lifetime) moves to CLOSED.

TCP vs UDP

TCP is connection‑oriented and reliable; UDP is connection‑less and unreliable but has lower overhead and higher real‑time performance.

Because UDP skips handshakes, protocols like QQ can achieve faster file transfer than TCP‑based services, though additional application‑level verification may be needed.

Common Questions

Maximum concurrent TCP connections are not limited by the 65535 port range; they depend on system file‑descriptor limits and can be increased via ulimit -n and kernel parameters.

The TIME_WAIT state 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; tuning kernel parameters such as net.ipv4.tcp_tw_reuse and net.ipv4.tcp_tw_recycle mitigates the issue.

Relevant sysctl settings are shown below.

Long vs. Short Connections

A long connection keeps a TCP socket alive for multiple data exchanges, often using heartbeat packets to detect liveness. A short connection is created, used for a single request, and closed immediately (e.g., typical HTTP).

Heartbeat Packets

Heartbeat packets are periodic messages that inform the peer of the sender’s status, preventing silent disconnections. TCP already provides a keep‑alive mechanism, but custom heartbeats can be defined for application‑level protocols.

Defining a Custom Protocol

To give transmitted data meaning, an application‑layer protocol (e.g., HTTP, MQTT, Dubbo) is required. A custom protocol over TCP must define:

Heartbeat packet format and handling.

Message header indicating payload length.

Serialization format (e.g., JSON).

Example header: length:000000000xxxx where xxxx is the data length.

Socket Connection Pool

A Socket connection pool maintains a set of reusable long‑living connections, automatically discarding invalid sockets and replenishing the pool as needed. It typically tracks:

Idle connections.

Active connections.

Waiting requests.

Invalid‑connection removal.

Pool size configuration.

Creation of new connections.

When a request arrives, the pool provides an idle socket; if none are available and the pool has not reached its limit, a new socket is created; otherwise the request waits.

Node.js Implementation with generic‑pool

The directory structure of the sample project is shown below.

Initializing the Pool

Using the Pool

The pool is used with the previously defined custom protocol.

Source Code Analysis

The core implementation resides in lib/Pool.js. The constructor sets up queues for idle, active, and waiting resources.

The acquire method retrieves a socket from the pool, creates a new one if needed, or queues the request.

These snippets illustrate how the pool continuously cycles through states until a long‑living socket is finally obtained.