Unveiling the Hidden Mechanics of Sockets: From Bytes to Network Communication

Sockets are a concept familiar to most programmers and form the foundation of computer network programming, handling TCP/UDP message transmission. Web servers, MySQL, Redis, chat applications, and online games all rely on sockets, and this article itself is made possible by their silent support of network communication.

1. Simple Process

When a client and server communicate using the TCP protocol, the client packages a request object req, serializes it into a byte array, and sends it through a socket to the server. The server reads the byte array from its socket, deserializes it back into req, processes the request, creates a response object res, serializes it, and sends the byte array back to the client, which then deserializes it into res.

Communication frameworks often hide the serialization steps; the diagram above shows the request req and response res objects shuttling between client and server.

Although the process may seem simple, the actual events occurring behind the scenes are far more complex than most people imagine. The real communication flow involves many additional steps that are not captured in the illustration, prompting the question of whether a deep understanding is necessary.

Experience in the internet services industry shows that without knowledge of the underlying mechanisms, developers cannot explain why socket reads and writes sometimes block, why partial packets appear, or why NIO behaves the way it does. Understanding these details is essential for diagnosing such issues.

2. Detailed Process

To help visualize the lower‑level workings, an animation was created (not shown here). The following explanation expands on that animation.

The socket you use is essentially a reference (object ID) whose actual object resides in the operating system kernel. Inside the kernel, the socket maintains two important buffers: a read buffer and a write buffer, both of which are finite‑sized arrays.

When the client writes a serialized byte array (the request) to its socket, the data is copied into the kernel’s write buffer. A separate kernel network thread continuously transfers data from the write buffer to the network interface card (NIC), which then sends it over the physical network to the server’s NIC.

Conversely, the server’s kernel network thread copies incoming data into the socket’s read buffer, where the user‑level process reads it via the socket’s read method, deserializes it into a request object, processes it, and sends a response back through the reverse flow.

2.1 Blocking

The write buffer has limited space; if an application writes too quickly, the buffer fills and the write operation blocks until space becomes available. With non‑blocking I/O (NIO), the write call returns the number of bytes actually written, allowing the application to retry later for the remaining data.

The read buffer may also be empty, causing read operations to block until enough data arrives to fill the requested byte array. NIO enables non‑blocking reads that return whatever data is currently available.

2.2 ACK

Data is not removed from the write buffer immediately after being handed to the NIC. It stays there until an acknowledgment (ACK) is received from the peer, confirming successful delivery. If the network is poor and ACKs are delayed, the write buffer can fill quickly.

2.3 Packet Header

When the kernel’s network module transfers a message to the NIC, it may split large buffers into multiple smaller packets, each with additional header information such as source and destination MAC addresses, sequence numbers, etc. The receiver must reassemble these packets, strip the headers, and place the payload into the read buffer.

2.4 Rate

If the read buffer becomes full, the NIC may discard incoming packets and refrain from sending ACKs, prompting the sender to retransmit. This situation arises when the receiver processes data slower than the sender produces it. TCP employs a dynamic window algorithm to adjust the sender’s transmission rate, while UDP simply drops the lost packets.