Mastering TCP/UDP, HTTP, and Socket Connection Pools: A Complete Guide

Preface : Developers often encounter terms like HTTP, TCP/IP, UDP, Socket, long‑living connections, and connection pools, yet their relationships and underlying principles are not always clear. This article starts from basic network protocol concepts and progresses step‑by‑step to socket connection pools.

Seven‑Layer OSI 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 to these layers: IP resides in the Network layer, TCP and UDP in the Transport layer, and HTTP in the Application layer. OSI does not define sockets, which will be introduced later with code examples.

TCP and UDP Connections

TCP is connection‑oriented and reliable, requiring a three‑way handshake to establish a connection and a four‑step termination to close it. UDP is connection‑less, faster, and does not guarantee delivery.

TCP Three‑Way Handshake and Four‑Way Termination

First Handshake : Client sends SYN (sequence number x) and enters SYN_SEND state.

Second Handshake : Server replies with SYN‑ACK (acknowledgment x+1, its own SYN with sequence y) and enters SYN_RECV state.

Third Handshake : Client sends ACK (acknowledgment y+1); both sides reach ESTABLISHED state.

Data transfer proceeds, then the connection is closed via four steps:

First FIN : Host 1 sends FIN and enters FIN_WAIT_1.

Second ACK : Host 2 acknowledges with ACK, entering FIN_WAIT_2.

Third FIN : Host 2 sends its own FIN, entering LAST_ACK.

Fourth ACK : Host 1 acknowledges, enters TIME_WAIT, then finally CLOSED after waiting 2 MSL.

Thus a TCP session involves at least seven message exchanges, whereas UDP requires no handshake.

Differences Between TCP and UDP

TCP is connection‑oriented and reliable; UDP is connection‑less and unreliable.

UDP has lower overhead and higher real‑time performance, making it suitable for scenarios where speed outweighs reliability.

Common Questions About the Transport Layer

1. Maximum concurrent TCP connections : The limit is not the 65 535 port range; it depends on system resources such as the maximum number of open file descriptors (ulimit -n) and kernel parameters.

2. Why does TIME_WAIT wait 2 MSL? To ensure any delayed ACKs are retransmitted and to avoid stray packets from being misinterpreted by future connections.

3. Problems caused by many TIME_WAIT sockets : Each TIME_WAIT consumes a local port, potentially leading to “address already in use” errors under high‑load short‑connection scenarios. Adjusting kernel parameters (e.g., tcp_tw_reuse, tcp_tw_recycle) can mitigate this.

Relevant kernel settings:

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = <em>value</em>

Long‑Living Socket Connections

A long connection keeps a TCP socket open for multiple data exchanges, often using heartbeat packets to maintain liveness. Short connections open, transmit, and close for each request.

Use long connections when operations are frequent and the number of concurrent sockets is manageable, such as database connections.

Heartbeat Packets

Heartbeat packets are periodic messages sent between client and server to indicate that the connection is still alive. They help detect broken sockets and can be implemented at the application layer.

Defining a Custom Application‑Layer Protocol

When transmitting meaningful data, an application‑level protocol (e.g., HTTP, MQTT, Dubbo) is needed. Key aspects include:

Heartbeat packet format and handling.

Message header defining payload length.

Data serialization format (e.g., JSON).

Socket Connection Pool

A socket connection pool maintains a set of reusable long‑living sockets, automatically checking their health, discarding invalid ones, and replenishing the pool as needed. Core components:

Idle socket queue.

Active socket queue.

Waiting request queue.

Invalid‑socket removal.

Pool size configuration.

Socket creation logic.

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 until a socket becomes idle.

Node.js Generic‑Pool Example

The following images illustrate the directory structure, pool initialization, usage with the custom protocol, and log output showing socket acquisition and reuse.

Log output demonstrates 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, which defines the idle, active, and waiting queues, as well as methods such as acquire that handle socket allocation logic.

Further screenshots show the detailed flow of Pool.acquire handling various cases until a socket is finally obtained.

These excerpts illustrate how the pool continuously checks conditions and eventually returns a usable long‑living socket.