一、网络IO的基础模型：阻塞与非阻塞之争

1.1 阻塞式IO的原始形态

在早期网络编程中，阻塞式IO是最直观的实现方式。当调用recv()或read()系统调用时，进程会主动挂起，直到内核完成数据接收并返回。这种模式的典型特征是：

// 阻塞式IO示例
int sockfd = socket(AF_INET, SOCK_STREAM, 0);
char buffer[1024];
ssize_t n = recv(sockfd, buffer, sizeof(buffer), 0); // 阻塞点

性能瓶颈分析：在并发连接数超过1000时，线程/进程资源消耗会急剧上升。每个连接都需要独立的线程维护，导致内存占用和上下文切换开销显著增加。

1.2 非阻塞IO的突破尝试

通过fcntl()设置O_NONBLOCK标志后，IO操作会立即返回。当没有数据可读时，系统调用返回EAGAIN或EWOULDBLOCK错误。这种模式需要配合循环检查：

// 非阻塞IO示例
int flags = fcntl(sockfd, F_GETFL, 0);
fcntl(sockfd, F_SETFL, flags | O_NONBLOCK);
while (1) {
    ssize_t n = recv(sockfd, buffer, sizeof(buffer), 0);
    if (n > 0) {
        // 处理数据
    } else if (n == -1 && errno == EAGAIN) {
        // 资源暂时不可用
        usleep(1000); // 避免CPU空转
    } else {
        // 其他错误处理
    }
}

缺陷暴露：虽然解决了线程资源问题，但CPU使用率在空闲时依然高达100%，形成”忙等待”现象。这种模式仅适用于连接数较少且实时性要求不高的场景。

二、IO多路复用的技术演进

2.1 select模型：多路监控的雏形

select系统调用实现了对多个文件描述符的监控能力，其核心接口为：

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

工作机制：

1. 将需要监控的文件描述符集合传入内核
2. 内核遍历所有fd，检查就绪状态
3. 返回就绪fd的数量，应用层需再次遍历确认

性能限制：

• 单进程最多监控1024个fd（受FD_SETSIZE限制）
• 每次调用都需要将fd集合从用户空间拷贝到内核空间
• 时间复杂度为O(n)，当fd数量增加时性能线性下降

2.2 poll模型：突破数量限制

poll通过动态数组解决了select的fd数量限制问题，其接口为：

int poll(struct pollfd *fds, nfds_t nfds, int timeout);
struct pollfd {
    int fd;         // 文件描述符
    short events;   // 请求的事件
    short revents;  // 返回的事件
};

改进点：

• 理论支持无限个fd（受系统内存限制）
• 事件通知机制更清晰
• 避免select的fd集合重置问题

残留问题：

• 仍然需要每次调用都传递完整的fd数组
• 线性扫描机制导致性能随fd数量增加而下降

2.3 epoll模型：革命性突破

Linux 2.5.44内核引入的epoll机制，通过三个核心系统调用实现了质的飞跃：

int epoll_create(int size);       // 创建epoll实例
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); // 等待事件

技术优势：

1. 红黑树管理：内核使用红黑树存储监控的fd，插入/删除时间复杂度为O(log n)
2. 就绪列表：内核维护一个就绪fd的双向链表，epoll_wait直接返回就绪fd
3. 文件描述符共享：多个线程可共享同一个epoll实例
4. 边缘触发(ET)与水平触发(LT)：
   • LT模式：只要fd可读就持续通知
   • ET模式：仅在状态变化时通知一次，要求应用必须处理完所有数据

性能对比（百万连接场景）：
| 机制 | 内存占用 | 事件通知延迟 | CPU使用率 |
|————|—————|———————|—————-|
| select | 200MB+ | 500μs+ | 85% |
| poll | 150MB+ | 400μs+ | 75% |
| epoll | 15MB | 50μs | 12% |

三、实战中的技术选型建议

3.1 不同场景的适用方案

• 低并发场景(C10K以下)：select/poll足够使用，代码实现简单
• 高并发长连接(C10K~C100K)：epoll LT模式是最佳选择
• 超大规模连接(C100K+)：需结合epoll ET模式+非阻塞IO+工作线程池

3.2 代码优化实践

ET模式正确用法：

// 必须循环读取直到EAGAIN
struct epoll_event ev;
ev.events = EPOLLIN | EPOLLET; // 边缘触发
epoll_ctl(epfd, EPOLL_CTL_ADD, sockfd, &ev);
while (1) {
    int n = epoll_wait(epfd, events, MAX_EVENTS, -1);
    for (int i = 0; i < n; i++) {
        int fd = events[i].data.fd;
        if (events[i].events & EPOLLIN) {
            char buf[1024];
            ssize_t cnt;
            while ((cnt = read(fd, buf, sizeof(buf))) > 0) {
                // 处理数据
            }
            if (cnt == -1 && errno != EAGAIN) {
                // 错误处理
            }
        }
    }
}

3.3 常见问题解决方案

1. 惊群效应：使用EPOLLEXCLUSIVE标志（Linux 4.5+）或边缘触发模式
2. 文件描述符泄漏：确保在epoll_ctl删除fd前关闭文件描述符
3. 跨平台兼容：Windows使用IOCP，macOS使用kqueue，可通过条件编译实现

四、未来发展趋势

随着RDMA技术和智能网卡的发展，IO处理正在向硬件加速方向演进。DPDK框架通过用户态驱动直接处理网络数据包，将延迟降低到微秒级。而XDP（eXpress Data Path）技术则允许在内核协议栈早期阶段就处理数据包，为IO多路复用提供了新的可能性。

对于开发者而言，理解从原始网络IO到现代多路复用技术的演进路径，不仅有助于解决当前的高并发问题，更能为未来技术选型提供理论支撑。在实际项目中，建议根据业务特点（连接数、数据量、实时性要求）进行技术选型，并通过压力测试验证性能指标。