Mastering TCP/UDP, Sockets, and Connection Pools: From OSI Model to Node.js

Preface: As developers we often hear about HTTP, TCP/IP, UDP, Socket, long connections, and connection pools, but their relationships, differences, and underlying principles are not always clear. This article explains everything from basic network protocols to socket connection pools step by step.

Seven‑Layer Network Model

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

From the diagram we see that IP belongs to the Network layer, TCP and UDP to the Transport layer, and HTTP to the Application layer. OSI does not define Socket; the concept will be introduced later with code examples.

TCP and UDP Connections

TCP and UDP are the most common Transport‑layer protocols. TCP is connection‑oriented and ensures reliable delivery through a three‑way handshake, while UDP is connection‑less, faster, and does not guarantee delivery.

TCP Three‑Way Handshake and Four‑Way Termination

The three‑way handshake establishes a TCP connection, and the four‑way termination gracefully closes it.

First handshake: Client sends SYN (seq=x) and enters SYN_SEND state.

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

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

After data transfer, the connection is closed with four steps:

First termination: Host1 sends FIN and enters FIN_WAIT_1.

Second termination: Host2 acknowledges with ACK, entering FIN_WAIT_2.

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

Fourth termination: Host1 acknowledges with ACK and enters TIME_WAIT; after 2 MSL the socket moves to CLOSED.

TCP vs UDP Differences

TCP is connection‑oriented and provides reliable delivery through handshakes and acknowledgments; UDP is connection‑less, sending packets without confirmation, making it faster but unreliable.

Because UDP lacks handshakes, its overhead is lower and latency is smaller, which is why real‑time applications often prefer UDP despite the need for custom reliability mechanisms.

Common Questions

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

2. Why does TIME_WAIT wait for 2 MSL? To ensure any lost ACKs can be retransmitted; without this wait, a delayed packet could be misinterpreted as belonging to a new connection.

3. Problems caused by many TIME_WAIT sockets? Each TIME_WAIT consumes a local port; heavy short‑connection traffic can exhaust ports, leading to “address already in use” errors. Adjusting kernel parameters (e.g., tcp_tw_reuse, tcp_tw_recycle) can mitigate the issue.

Socket Long Connections

A long connection keeps a TCP socket open for multiple data exchanges, often using heartbeat packets to maintain liveliness. In contrast, a short connection opens, transfers data, and closes immediately (e.g., typical HTTP requests).

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

Heartbeat Packets

Heartbeat packets are periodic messages sent between client and server to confirm that the socket is still alive. They help detect broken connections early and can be custom‑defined (e.g., a simple JSON payload).

Implementation Example (Node.js)

Server side:

Client side:

Defining a Custom Protocol

To give transmitted data meaning, an application‑layer protocol (e.g., HTTP, MQTT, Dubbo) is needed. Key aspects include:

Heartbeat packet format and handling.

Message header defining payload length.

Serialization format (e.g., JSON).

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

Socket Connection Pool

A socket connection pool maintains a set of long‑living TCP connections, automatically checking their health, discarding invalid sockets, and creating new ones as needed. It typically tracks:

Idle connections.

Active connections.

Waiting requests.

Invalid‑connection removal.

Pool size configuration.

Connection creation logic.

When a request arrives, the pool provides an idle socket or creates a new one if the active count is below the limit; otherwise the request waits.

Node.js Generic‑Pool Example

Directory structure of the pool module:

Initializing the Pool

Using the Pool

The following usage employs the custom protocol defined earlier.

Log output shows that the first two requests create new sockets; subsequent requests reuse existing connections from the pool.

Source Code Analysis

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

The acquire method retrieves a socket, creating a new one if needed or queuing the request otherwise.

These snippets illustrate how the pool navigates various states to finally obtain a long‑living connection.