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

OSI Model Overview

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, and notes that the OSI model does not define sockets.

TCP Handshake and Termination

The three‑step TCP three‑way handshake is described in detail: SYN from client, SYN‑ACK from server, ACK from client, after which both sides enter the ESTABLISHED state. The four‑step termination (FIN, ACK, FIN, ACK) is also explained, highlighting that a full TCP session involves at least seven packet exchanges, whereas UDP requires none.

TCP vs UDP Differences

TCP is connection‑oriented, providing reliable delivery through handshakes and acknowledgments; UDP is connection‑less and does not guarantee delivery, resulting in lower overhead and higher real‑time performance.

Because UDP lacks handshaking, it can achieve higher throughput, which explains why protocols like QQ (using UDP) can transfer files faster than TCP‑based services such as MSN, though additional application‑level checks are needed for reliability.

Common TCP Questions

1. Maximum concurrent TCP connections : The limit is not the 65 535 port range; a single server port can handle far more connections limited by the OS file‑descriptor limit (ulimit -n) and system resources.

2. Why TIME_WAIT lasts 2 MSL : The state ensures that delayed packets from the closed connection are not misinterpreted by a new connection, allowing retransmission of the final ACK if needed.

3. Impact of many TIME_WAIT sockets : Excessive TIME_WAIT sockets can exhaust local ports, causing “address already in use” errors; tuning sysctl 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 and Heartbeats

A short connection follows the pattern connect → data → close, while a long (persistent) connection adds periodic heartbeat packets to keep the socket alive: connect → data → heartbeat → data → … → close. Long connections are beneficial for frequent, point‑to‑point communication where establishing a new TCP handshake for each request would add latency.

Heartbeats are custom messages sent at regular intervals (e.g., every 3 seconds) to confirm that both ends are still reachable.

Defining a Custom Application Protocol

To give meaning to transmitted data, the article suggests creating an application‑layer protocol (e.g., HTTP, MQTT, Dubbo) with three key components:

Heartbeat packet format and handling.

Message header that includes the payload length (e.g., a fixed‑size 20‑byte header where the length field is padded with zeros).

Payload serialization format, such as JSON.

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

Socket Connection Pool Concept

A Socket connection pool maintains a collection of long‑lived TCP sockets, automatically checking their health, discarding invalid ones, and creating new sockets as needed. The pool tracks:

Idle sockets ready for use.

Active sockets currently handling requests.

Requests waiting for an idle socket.

Invalid socket removal.

Pool size configuration.

Creation of new sockets.

The acquisition flow: a request grabs an idle socket; if none are available 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 Generic‑Pool Implementation

The article demonstrates using the generic-pool library. It shows the directory layout, initialization of the pool, and usage with the previously defined custom protocol. Log screenshots illustrate that the first two requests create new sockets, while subsequent requests reuse existing sockets from the pool after the timer expires.

Source Code Walkthrough (Pool.js)

The core implementation resides in lib/Pool.js. The constructor sets up the idle queue, active queue, and waiting queue. The acquire method contains the logic described above, iterating through the queues to either return an idle socket, create a new one, or enqueue the request.

Readers are encouraged to explore the remaining code for deeper understanding of resource management and error handling.