Master TCP/UDP, Socket Long Connections, and a Node.js Socket Pool

Introduction

Developers often hear terms such as HTTP, TCP/IP, UDP, Socket, long‑living sockets, and socket connection pools, but the relationships, differences, and underlying principles are not always clear. This article starts from basic network protocol concepts and gradually builds up to a practical socket connection‑pool implementation.

OSI Seven‑Layer Model

The OSI (Open Systems Interconnection) model divides network communication into seven layers: Physical, Data Link, Network, Transport, Session, Presentation, and Application. IP resides in the Network layer, TCP/UDP in the Transport layer, and HTTP in the Application layer. The model does not define a Socket; sockets are introduced later as an API for transport‑layer communication.

TCP and UDP Connections

TCP is connection‑oriented and reliable, while UDP is connection‑less and faster but unreliable. The article first details TCP’s three‑way handshake and four‑step termination, then contrasts these steps with UDP’s simpler transmission.

Three‑Way Handshake

First handshake: Client sends a SYN packet (SYN=1, Seq=x) and enters SYN_SEND state.

Second handshake: Server replies with SYN+ACK (Ack=x+1, SYN=1, Seq=y) and enters SYN_RECV state.

Third handshake: Client sends ACK (Ack=y+1) and both sides reach ESTABLISHED state.

Four‑Step Termination

First step: Host1 sends FIN, enters FIN_WAIT_1.

Second step: Host2 acknowledges with ACK, Host1 moves to FIN_WAIT_2.

Third step: Host2 sends its own FIN, entering LAST_ACK.

Fourth step: Host1 ACKs the FIN, enters TIME_WAIT; after 2 MSL the connection closes.

TCP vs UDP Differences

TCP provides reliable, connection‑oriented delivery with handshakes and acknowledgments; UDP is connection‑less, sending packets without confirmation.

Because UDP skips handshakes, it has lower overhead and higher real‑time performance, though applications must add their own reliability mechanisms if needed.

Common TCP Questions

Maximum concurrent connections: The limit is not the 65 535 port range; a single server port can handle many more connections limited by the operating system’s file‑descriptor limit (ulimit -n) and overall system resources.

Why TIME_WAIT lasts 2 MSL: To ensure any delayed ACKs are retransmitted and the other side can safely close, protecting against stray packets.

Impact of many TIME_WAIT sockets: Each TIME_WAIT consumes a local port; heavy short‑connection traffic can exhaust ports, causing “address already in use” errors. Adjusting kernel parameters such as net.ipv4.tcp_tw_reuse, net.ipv4.tcp_tw_recycle, and net.ipv4.tcp_fin_timeout can mitigate the issue.

Long vs Short Connections

Short connections follow the pattern: connect → data transfer → close. Long (persistent) connections keep the socket open for multiple data exchanges, often using heartbeat packets to detect liveness.

Long connections are beneficial when operations are frequent and the overhead of repeated handshakes would degrade performance, such as database connections or real‑time messaging.

Heartbeat Packets

A heartbeat is a periodic custom message sent between client and server to confirm that the socket is still alive. If a socket is broken (e.g., network loss), the absence of heartbeats signals the need to recreate the connection.

Defining a Custom Application Protocol

To give transmitted data meaning, an application‑layer protocol (e.g., HTTP, MQTT, Dubbo) is required. The article proposes a simple protocol with:

Header format: length:000000000xxxx where the 20‑byte header encodes the payload length.

Payload serialization: JSON.

Socket Connection Pool

A socket pool maintains a collection of long‑living socket connections, automatically discarding invalid sockets and creating new ones as needed. The pool tracks:

Idle sockets ready for use.

Active sockets currently handling requests.

Waiting requests when no idle sockets are available.

Invalid‑socket cleanup.

Configuration of pool size and creation logic.

When a request arrives, the pool provides an idle socket; if none exist and the active count is below the configured limit, a new socket is created. Otherwise the request waits until a socket becomes idle.

Node.js Implementation with generic‑pool

The article uses the generic-pool library. The directory structure of the pool module is shown, followed by initialization and usage examples (images of code and logs). The logs demonstrate that the first two requests create new sockets, while subsequent requests reuse existing sockets from the pool.

Source Code Analysis

The core implementation resides in lib/Pool.js. The constructor defines queues for idle resources, active resources, and waiting requests. The acquire method contains the logic that selects an idle socket, creates a new one if needed, or queues the request until a socket becomes available. The article includes screenshots of the constructor and the acquire method to illustrate the flow.

Overall, the guide provides a comprehensive overview of network protocol fundamentals, practical differences between TCP and UDP, and a step‑by‑step implementation of a reusable socket connection pool for high‑concurrency Node.js services.