Understanding Network Protocols, TCP/UDP Handshakes, and Socket Connection Pools

Seven‑Layer Network Model

The OSI 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 sockets.

TCP and UDP Connections

TCP provides reliable, connection‑oriented communication using a three‑way handshake to establish a connection and a four‑step termination to close it, while UDP is connection‑less and faster but without reliability guarantees.

Three‑Way Handshake

1) SYN: client sends a SYN packet with sequence number x. 2) SYN‑ACK: server acknowledges with ACK=x+1 and sends its own SYN with sequence number y. 3) ACK: client acknowledges server's SYN with ACK=y+1, and both sides enter the ESTABLISHED state.

Four‑Step Termination

1) FIN: one side sends a FIN and enters FIN_WAIT_1. 2) ACK: the peer acknowledges the FIN and enters FIN_WAIT_2. 3) FIN: the peer sends its own FIN and enters LAST_ACK. 4) ACK: the original side acknowledges, enters TIME_WAIT, and finally both sides close.

TCP vs UDP Differences

TCP is connection‑oriented and ensures reliability through handshakes and acknowledgments; UDP is connection‑less and does not guarantee delivery.

UDP has lower overhead and higher real‑time performance, making it suitable for latency‑sensitive applications, whereas TCP is slower but more reliable.

Common Questions

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 for 2 MSL? To ensure any delayed ACKs are retransmitted and to avoid premature reuse of the same socket tuple.

3. Problems caused by many TIME_WAIT sockets? Excessive TIME_WAIT sockets can exhaust local ports, leading to “address already in use” errors; tuning kernel parameters (e.g., tcp_tw_reuse, tcp_tw_recycle) can mitigate this.

Long‑Lived Socket Connections

A long connection keeps a TCP socket open for multiple data exchanges, often using heartbeat packets to maintain liveness, whereas a short connection opens, transmits, and closes for each request.

Long connections are preferred for frequent, point‑to‑point communication where connection overhead must be minimized (e.g., database connections).

Defining a Custom Application‑Layer Protocol

To give meaning to transmitted data, one can design a protocol with a fixed‑length header (e.g., length:000000000xxxx ) indicating payload size, and use JSON for serialization.

Socket Connection Pool

A socket pool maintains a collection of reusable long‑living sockets, automatically discarding invalid ones and creating new ones as needed. It tracks idle sockets, active sockets, waiting requests, and pool size configuration.

Typical usage with Node.js’s generic-pool involves initializing the pool, acquiring a socket, performing requests, and releasing the socket back to the idle queue.

Source Code Analysis

The core implementation resides in lib/Pool.js , which defines the constructor (initializing queues) and the acquire method that handles socket allocation logic based on pool state.

Architect’s Guide

Understanding these networking fundamentals equips architects to design robust, high‑performance backend systems.