Linux

Socket I/O

I/O 模型概览

一个输入操作通常包括两个阶段：

  • 等待数据准备好
  • 从内核向进程复制数据

对于一个套接字上的输入操作，第一步通常涉及等待数据从网络中到达。当所等待数据到达时，它被复制到内核中的某个缓冲区。第二步就是把数据从内核缓冲区复制到应用进程缓冲区

Unix 有五种 I/O 模型：

  • 阻塞 I/O：调用阻塞到数据复制完成。
  • 非阻塞 I/O：立即返回，需要轮询。
  • I/O 复用：select/poll/epoll 等待多个 fd。
  • 信号驱动 I/O：数据就绪时发 SIGIO，再读取。
  • 异步 I/O：提交请求后由内核完成并通知。

实践侧重：

  • 阻塞模型简单，适合连接数少且延迟不敏感的 CLI/工具脚本；
  • 非阻塞模型常与事件循环/定时器配合，否则轮询会耗 CPU；
  • I/O 复用是高并发网络服务的基础；
  • 信号驱动在 Linux 上使用较少，更多见于嵌入式/老项目；
  • 异步 I/O 需要平台支持（如 Linux AIO/io_uring、Windows IOCP）。

阻塞 I/O

应用进程被阻塞，直到数据从内核缓冲区复制到应用进程缓冲区中才返回。 应该注意到，在阻塞的过程中，其它应用进程还可以执行，因此阻塞不意味着整个操作系统都被阻塞。因为其它应用进程还可以执行，所以不消耗 CPU 时间，这种模型的 CPU 利用率会比较高。 例如，recvfrom() 用于接收 Socket 传来的数据，并复制到应用进程的缓冲区 buf 中。这里把 recvfrom() 当成系统调用。

1

ssize_t recvfrom(int sockfd, void *buf, size_t len, int flags, struct sockaddr *src_addr, socklen_t *addrlen);

  sequenceDiagram
  participant App as 应用进程
  participant Kernel as 内核
  App->>Kernel: recvfrom()
  Note left of App: 调用recvform()进程阻塞
  Note right of Kernel: 等待数据到达并存入内核缓冲
  Kernel-->>App: 数据复制完成后返回

特点：实现简单，CPU 利用率高（阻塞期间不占用 CPU），但吞吐受限。

  • 典型用法：短连接 RPC、小工具一次性读写；
  • 隐患：若对端长时间不发数据或网络抖动，线程被长期占用，需要超时控制（如 SO_RCVTIMEO）；
  • 在多线程服务器中，线程数与连接数线性相关，易受线程栈内存与调度开销限制。

非阻塞 I/O

应用进程执行系统调用之后，内核返回一个错误码。应用进程可以继续执行，但是需要不断的执行系统调用来获知 I/O 是否完成，这种方式称为轮询（polling）。 由于 CPU 要处理更多的系统调用，因此这种模型的 CPU 利用率比较低。

  sequenceDiagram
  participant App as 应用
  participant Kernel as 内核
  App->>Kernel: recvfrom() (非阻塞)
  Kernel-->>App: EWOULDBLOCK
  App->>Kernel: recvfrom() 轮询直至可读
  Kernel-->>App: 数据复制完成

I/O 复用（事件驱动）

使用 select 或者 poll 等待数据，并且可以等待多个套接字中的任何一个变为可读。这一过程会被阻塞，当某一个套接字可读时返回，之后再使用 recvfrom 把数据从内核复制到进程中。

它可以让单个进程具有处理多个 I/O 事件的能力。又被称为 Event Driven I/O，即事件驱动 I/O。

如果一个 Web 服务器没有 I/O 复用，那么每一个 Socket 连接都需要创建一个线程去处理。如果同时有几万个连接，那么就需要创建相同数量的线程。相比于多进程和多线程技术，I/O 复用不需要进程线程创建和切换的开销，系统开销更小。

  sequenceDiagram
    participant App as 应用层
    participant Kernel as 内核

    App->>Kernel: select
    Note left of App: 调用select()进程阻塞,等待某一个套接字可读
    Kernel-->>App: 数据就绪
    App->>Kernel: recvfrom()
    Note left of App: 在数据拷贝到应用的buffer的过程中，进程阻塞
    Kernel-->>App: 返回数据
    Note right of Kernel: copy data form kernel to user
    App->>App: 处理数据

适合单线程/单进程管理多连接，减少线程切换

  • 事件循环典型结构：注册 fd -> 等待 -> 处理就绪 -> 重新注册或继续等待；
  • 需要把 fd 设置为非阻塞，避免单个 read/write 卡住事件循环；
  • 回调里要尽量快，耗时任务应投递到工作线程池；
  • 要关注粘包/拆包，事件驱动只告诉“可读/可写”，应用层需处理协议边界。

信号驱动 I/O

应用进程使用 sigaction 系统调用，内核立即返回，应用进程可以继续执行，也就是说等待数据阶段应用进程是非阻塞的。内核在数据到达时向应用进程发送 SIGIO 信号，应用进程收到之后在信号处理程序中调用 recvfrom 将数据从内核复制到应用进程中。

相比于非阻塞式 I/O 的轮询方式，信号驱动 I/O 的 CPU 利用率更高。

  sequenceDiagram
  participant App as 应用
  participant Kernel as 内核
  App->>Kernel: sigaction(SIGIO)
  Kernel-->>App: return
  App-->>App: 继续执行其他逻辑
  Kernel-->>App: 发送SIGIO
  App->>Kernel: recvfrom()
  Note left of App: blocked
  Kernel-->>App: data copy 完成

减少轮询开销，但信号处理需谨慎。

  • 需设置 F_SETOWN/F_SETSIG 等，且信号处理函数中能做的事情有限（不可重入操作要避免）；
  • 可与 signalfd 结合在 Linux 上统一为 fd 事件，但通用性较差；
  • 在复杂网络服务中通常被 epoll 等方案取代。

异步 I/O（AIO）

应用进程执行 aio_read 系统调用会立即返回，应用进程可以继续执行，不会被阻塞，内核会在所有操作完成之后向应用进程发送信号。

异步 I/O 与信号驱动 I/O 的区别在于，异步 I/O 的信号是通知应用进程 I/O 完成，而信号驱动 I/O 的信号是通知应用进程可以开始 I/O

  sequenceDiagram
  participant App as 应用
  participant Kernel as 内核
  App->>Kernel: aio_read()
  Kernel-->>App: return
  App-->>App: 继续执行
  Kernel-->>Kernel: copy data from kernel to user
  Kernel-->>App: deliver signal specified in aio_read            
  App-->>App: signal handler处理data
  • Linux 传统 AIO 限制较多，推荐现代接口如 io_uring；
  • Windows IOCP、.NET async/await、Node.js libuv 都属于异步完成通知模型；
  • 适合高吞吐文件 I/O 或网络 I/O，减少上下文切换和拷贝。

五大模型对比

  • 同步 vs 异步：同步在“数据复制到用户缓冲”阶段会阻塞；异步不会。

  • 阻塞/非阻塞/I/O 复用/信号驱动：都属同步 I/O，本质差别在“等待数据”阶段是否阻塞。

  • CPU 利用率：阻塞高、非阻塞低、复用和信号介于其间、AIO 最优但实现/平台支持差异大。

  • 拷贝次数：经典模型仍需用户态/内核态拷贝；部分异步框架支持零拷贝（如 sendfile, splice）。

  • 编程复杂度：阻塞 < 非阻塞 < I/O 复用 < 异步 AIO；

  • 适用连接规模：阻塞/非阻塞适合少量连接；复用/异步适合大量连接。

I/O 复用详解

select/poll/epoll 都是 I/O 多路复用的具体实现，select 出现的最早，之后是 poll，再是 epoll

select 

1

int select(int n, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);

select 允许应用程序监视一组文件描述符，等待一个或者多个描述符成为就绪状态，从而完成 I/O 操作。

  • fd_set 使用数组实现，数组大小使用 FD_SETSIZE 定义，所以只能监听少于 FD_SETSIZE 数量的描述符。有三种类型的描述符类型：readset、writeset、exceptset，分别对应读、写、异常条件的描述符集合。

  • timeout 为超时参数，调用 select 会一直阻塞直到有描述符的事件到达或者等待的时间超过 timeout。

  • 成功调用返回结果大于 0，出错返回结果为 -1，超时返回结果为 0

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

fd_set fd_in, fd_out;
struct timeval tv;

// Reset the sets
FD_ZERO( &fd_in );
FD_ZERO( &fd_out );

// Monitor sock1 for input events
FD_SET( sock1, &fd_in );

// Monitor sock2 for output events
FD_SET( sock2, &fd_out );

// Find out which socket has the largest numeric value as select requires it
int largest_sock = sock1 > sock2 ? sock1 : sock2;

// Wait up to 10 seconds
tv.tv_sec = 10;
tv.tv_usec = 0;

// Call the select
int ret = select( largest_sock + 1, &fd_in, &fd_out, NULL, &tv );

// Check if select actually succeed
if ( ret == -1 )
    // report error and abort
else if ( ret == 0 )
    // timeout; no event detected
else
{
    if ( FD_ISSET( sock1, &fd_in ) )
        // input event on sock1

    if ( FD_ISSET( sock2, &fd_out ) )
        // output event on sock2
}

poll 

1

int poll(struct pollfd *fds, unsigned int nfds, int timeout);

poll 的功能与 select 类似，也是等待一组描述符中的一个成为就绪状态。 poll 中的描述符是 pollfd 类型的数组，pollfd 的定义如下：

1
2
3
4
5

struct pollfd {
               int   fd;         /* file descriptor */
               short events;     /* requested events */
               short revents;    /* returned events */
           };

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

// The structure for two events
struct pollfd fds[2];

// Monitor sock1 for input
fds[0].fd = sock1;
fds[0].events = POLLIN;

// Monitor sock2 for output
fds[1].fd = sock2;
fds[1].events = POLLOUT;

// Wait 10 seconds
int ret = poll( &fds, 2, 10000 );
// Check if poll actually succeed
if ( ret == -1 )
    // report error and abort
else if ( ret == 0 )
    // timeout; no event detected
else
{
    // If we detect the event, zero it out so we can reuse the structure
    if ( fds[0].revents & POLLIN )
        fds[0].revents = 0;
        // input event on sock1

    if ( fds[1].revents & POLLOUT )
        fds[1].revents = 0;
        // output event on sock2
}

select vs poll

  • 功能: select 和 poll 的功能基本相同，不过在一些实现细节上有所不同。
    • select 会修改描述符，而 poll 不会；
    • select 的描述符类型使用数组实现，FD_SETSIZE 大小默认为 1024，因此默认只能监听少于 1024 个描述符。 如果要监听更描述符的话，需要修改 FD_SETSIZE 之后重新编译；而 poll 没有描述符数量的限制；
    • poll 提供了更多的事件类型，并且对描述符的重复利用上比 select 高。
    • 如果一个线程对某个描述符调用了 select 或者 poll，另一个线程关闭了该描述符，会导致调用结果不确定。
  • 速度: select 和 poll 速度都比较慢，每次调用都需要将全部描述符从应用进程缓冲区复制到内核缓冲区。
  • 可移植性: 几乎所有的系统都支持 select，但是只有比较新的系统支持 poll。

epoll 

1
2
3

int epoll_create(int size);
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event)；
int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);

epoll_ctl() 用于向内核注册新的描述符或者是改变某个文件描述符的状态。已注册的描述符在内核中会被维护在一棵红黑树上，通过回调函数内核会将 I/O 准备好的描述符加入到一个链表中管理，进程调用 epoll_wait() 便可以得到事件完成的描述符。

从上面的描述可以看出，epoll 只需要将描述符从进程缓冲区向内核缓冲区拷贝一次，并且进程不需要通过轮询来获得事件完成的描述符。

epoll 仅适用于 Linux OS。

epoll 比 select 和 poll 更加灵活而且没有描述符数量限制。

epoll 对多线程编程更有友好，一个线程调用了 epoll_wait() 另一个线程关闭了同一个描述符也不会产生像 select 和 poll 的不确定情况。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

// Create the epoll descriptor. Only one is needed per app, and is used to monitor all sockets.
// The function argument is ignored (it was not before, but now it is), so put your favorite number here
int pollingfd = epoll_create( 0xCAFE );

if ( pollingfd < 0 )
 // report error

// Initialize the epoll structure in case more members are added in future
struct epoll_event ev = { 0 };

// Associate the connection class instance with the event. You can associate anything
// you want, epoll does not use this information. We store a connection class pointer, pConnection1
ev.data.ptr = pConnection1;

// Monitor for input, and do not automatically rearm the descriptor after the event
ev.events = EPOLLIN | EPOLLONESHOT;
// Add the descriptor into the monitoring list. We can do it even if another thread is
// waiting in epoll_wait - the descriptor will be properly added
if ( epoll_ctl( epollfd, EPOLL_CTL_ADD, pConnection1->getSocket(), &ev ) != 0 )
    // report error

// Wait for up to 20 events (assuming we have added maybe 200 sockets before that it may happen)
struct epoll_event pevents[ 20 ];

// Wait for 10 seconds, and retrieve less than 20 epoll_event and store them into epoll_event array
int ready = epoll_wait( pollingfd, pevents, 20, 10000 );
// Check if epoll actually succeed
if ( ret == -1 )
    // report error and abort
else if ( ret == 0 )
    // timeout; no event detected
else
{
    // Check if any events detected
    for ( int i = 0; i < ready; i++ )
    {
        if ( pevents[i].events & EPOLLIN )
        {
            // Get back our connection pointer
            Connection * c = (Connection*) pevents[i].data.ptr;
            c->handleReadEvent();
         }
    }
}

epoll的工作模式

epoll 的描述符事件有两种触发模式：LT（level trigger）和 ET（edge trigger）。

  • LT（Level Trigger，默认）：当 epoll_wait() 检测到描述符事件到达时，将此事件通知进程，进程可以不立即处理该事件，下次调用 epoll_wait() 会再次通知进程。是默认的一种模式，并且同时支持 Blocking 和 No-Blocking。
  • ET（Edge Trigger）：和 LT 模式不同的是，通知之后进程必须立即处理事件，下次再调用 epoll_wait() 时不会再得到事件到达的通知。很大程度上减少了 epoll 事件被重复触发的次数，因此效率要比 LT 模式高。只支持 No-Blocking，以避免由于一个文件句柄的阻塞读/阻塞写操作把处理多个文件描述符的任务饿死。。

select vs poll vs epoll

  • select: timeout 参数精度为微秒，而 poll 和 epoll 为毫秒，因此 select 更加适用于实时性要求比较高的场景，比如核 反应堆的控制。select 可移植性更好，几乎被所有主流平台所支持。

  • poll: 没有最大描述符数量的限制，如果平台支持并且对实时性要求不高，应该使用 poll 而不是 select。

  • epoll: 只需要运行在 Linux 平台上，有大量的描述符需要同时轮询，并且这些连接最好是长连接。 需要同时监控小于 1000 个描述符，就没有必要使用 epoll，因为这个应用场景下并不能体现 epoll 的优势。 需要监控的描述符状态变化多，而且都是非常短暂的，也没有必要使用 epoll。因为 epoll 中的所有描述符都存储在内核中，造成 每次需要对描述符的状态改变都需要通过 epoll_ctl() 进行系统调用，频繁系统调用降低效率。并且 epoll 的描述符存储在内 核，不容易调试。

copy from
https://github.com/CyC2018/CS-Notes/blob/master/notes/Socket.md

Linux
Licensed under CC BY-NC-SA 4.0
© 2025 - 2026 Charles Lv
使用 Hugo 构建
主题 Stack 由 Jimmy 设计