Overview of High‑Performance Server I/O Models

With the rapid development of the Internet, traditional blocking server architectures can no longer handle massive concurrent user traffic. This article offers a useful overview of high‑performance network programming I/O models and compares different server process models to demystify the design and implementation of efficient network architectures.

Principles of Internet Server Handling Network Requests

A typical server request handling flow includes three main steps, as shown in the diagram below:

1) Acquire request data : The client establishes a connection and sends a request; the server receives it (steps 1‑3).

2) Build response : After the server finishes processing the request in user space, it constructs the response (step 4).

3) Return data : The server sends the prepared response back to the client via kernel‑space network I/O (steps 5‑7).

When designing a server concurrency model, two key points must be considered:

How the server manages connections and obtains input data.

How the server processes the requests.

Both points ultimately relate to the operating system’s I/O model and thread (or process) model, which are introduced in detail below.

Basic Understanding of I/O Models

Before discussing OS I/O models, it is helpful to distinguish a few concepts:

Blocking vs. non‑blocking calls.

Synchronous vs. asynchronous processing.

Blocking calls suspend the calling thread until the result is ready, while non‑blocking calls return immediately (often with an error) if the operation cannot be completed instantly.

Synchronous processing means the callee returns the final result before control goes back to the caller; asynchronous processing returns an acknowledgement first and later notifies the caller when the result is ready.

The distinction can be summarized as:

Blocking / non‑blocking concerns the caller.

Synchronous / asynchronous concerns the callee.

The recvfrom system call (used for receiving data on a socket) typically involves two stages: waiting for data to become ready, and copying data from the kernel buffer to the user‑space buffer.

Combining the call type (blocking or non‑blocking) with the processing style (synchronous or asynchronous) yields five common I/O models (referencing "UNIX Network Programming, Volume 1").

I/O Model 1: Blocking I/O

In this model the application blocks from the moment recvfrom is called until data is ready. After recvfrom returns, the process handles the datagram.

Analogy: Like a fisherman sitting on the shore waiting for a bite.

Advantages: Simple implementation; the thread sleeps while waiting, consuming almost no CPU.

Disadvantages: Each connection requires a dedicated thread or process; with many concurrent connections, memory and context‑switch overhead become prohibitive.

I/O Model 2: Non‑Blocking I/O

The application sets the socket to non‑blocking mode, telling the kernel not to put the process to sleep if the operation cannot be completed immediately. Instead, the call returns an error and the application repeatedly polls the socket until data becomes available.

Analogy: Fishing while playing on a phone, periodically checking if a fish has bitten.

Advantages: No thread is blocked waiting for I/O; each request returns immediately, offering better responsiveness.

Disadvantages: Continuous polling consumes CPU cycles, leading to low resource utilization; therefore most web servers avoid pure non‑blocking I/O.

I/O Model 3: I/O Multiplexing (Select/Poll/Epoll)

Functions like select , poll , or epoll can block on multiple file descriptors simultaneously. They return when at least one descriptor becomes ready for reading or writing, after which the application performs the actual I/O.

Analogy: Placing many fishing rods on the shore and checking them all together, playing on the phone while waiting.

Advantages: A single thread can monitor many connections, reducing the number of threads and saving system resources.

Disadvantages: When the number of connections is small, the overhead of extra system calls can make this model slower than a simple threaded blocking approach.

High‑performance reverse proxies such as Nginx succeed largely because they rely on epoll .

I/O Model 4: Signal‑Driven I/O

The application registers a signal handler (e.g., for SIGIO ) and continues execution without blocking. When data becomes ready, the kernel sends the signal, and the handler performs the I/O.

Analogy: A bell attached to the fishing rod rings when a fish bites, allowing you to focus on other tasks.

Advantages: The thread is not blocked while waiting, improving resource utilization.

Disadvantages: Under heavy I/O loads the signal queue may overflow, and for TCP the model is rarely useful due to the complexity of the required notifications.

I/O Model 5: Asynchronous I/O (AIO)

Defined by POSIX, the application requests the kernel to perform an operation and the kernel notifies the application upon completion, including the data copy back to user space.

Difference from signal‑driven I/O: Signal‑driven I/O tells the application when to start an operation; asynchronous I/O tells the application when the operation has finished.

Advantages: Allows DMA to overlap I/O with computation, achieving high efficiency.

Disadvantages: Implementing true asynchronous I/O requires substantial OS support; Windows provides IOCP, while Linux’s AIO is still immature (only fully usable after kernel 2.6 for certain workloads).

In practice, Linux high‑concurrency network programs usually adopt the I/O multiplexing model.

I/O Model Summary

The diagram shows that as we move from blocking to asynchronous models, the amount of blocking decreases and theoretical efficiency increases. The first four models are considered synchronous I/O because the actual recvfrom call blocks the thread; only the asynchronous model matches POSIX’s definition of true asynchronous I/O.

Author: Chen Caihua (caison), senior backend engineer at Guangzhou BeLiao, specializing in server development, requirement analysis, system design, and performance optimization, primarily using Java.

Recommended Reading:

InfiniBand Architecture and Practical Summary

How to Build a Container Service Platform (CaaS)

Warm Tip: Search for “ICT_Architect” or scan the QR code to follow the public account and click the original link for more e‑book details.