计算机网络第三部分之Socekt（8）

最新推荐文章于 2024-08-24 09:52:48 发布

转载最新推荐文章于 2024-08-24 09:52:48 发布 · 138 阅读

面经专栏收录该内容

28 篇文章

订阅专栏

本文深入探讨了I/O模型，包括阻塞式、非阻塞式、I/O复用、信号驱动和异步I/O，以及select、poll和epoll的详细对比。通过一个HttpServer的发展历程，形象地展示了I/O模型和多路复用技术在实际应用中的演变。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

一、I/O 模型

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

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

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

Unix 有五种 I/O 模型：

阻塞式 I/O
非阻塞式 I/O
I/O 复用（select 和 poll）
信号驱动式 I/O（SIGIO）
异步 I/O（AIO）

阻塞式 I/O

应用进程被阻塞，直到数据从内核缓冲区复制到应用进程缓冲区中才返回。

应该注意到，在阻塞的过程中，其它应用进程还可以执行，因此阻塞不意味着整个操作系统都被阻塞。因为其它应用进程还可以执行，所以不消耗 CPU 时间，这种模型的 CPU 利用率会比较高。

下图中，recvfrom() 用于接收 Socket 传来的数据，并复制到应用进程的缓冲区 buf 中。这里把 recvfrom() 当成系统调用。

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

进程内核

非阻塞式 I/O

应用进程执行系统调用之后，内核返回一个错误码。应用进程可以继续执行，但是需要不断的执行系统调用来获知 I/O 是否完成，这种方式称为轮询（polling）。

由于 CPU 要处理更多的系统调用，因此这种模型的 CPU 利用率比较低。

I/O 复用哪个准备好了我读哪个，读完了就复制

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

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

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

信号驱动 I/O 高级非阻塞式IO

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

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

异步 I/O

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

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

五大 I/O 模型比较

同步 I/O：将数据从内核缓冲区复制到应用进程缓冲区的阶段（第二阶段），应用进程会阻塞。
异步 I/O：第二阶段应用进程不会阻塞。

同步 I/O 包括阻塞式 I/O、非阻塞式 I/O、I/O 复用和信号驱动 I/O ，它们的主要区别在第一个阶段。

非阻塞式 I/O 、信号驱动 I/O 和异步 I/O 在第一阶段不会阻塞。

二、I/O 复用

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

select

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。

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

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

poll 的功能与 select 类似，也是等待一组描述符中的一个成为就绪状态。

poll 中的描述符是 pollfd 类型的数组，pollfd 的定义如下：

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

// 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
}

比较

1. 功能

select 和 poll 的功能基本相同，不过在一些实现细节上有所不同。

select 会修改描述符，而 poll 不会；
select 的描述符类型使用数组实现，FD_SETSIZE 大小默认为 1024，因此默认只能监听 1024 个描述符。如果要监听更多描述符的话，需要修改 FD_SETSIZE 之后重新编译；而 poll 没有描述符数量的限制；
poll 提供了更多的事件类型，并且对描述符的重复利用上比 select 高。
如果一个线程对某个描述符调用了 select 或者 poll，另一个线程关闭了该描述符，会导致调用结果不确定。

2. 速度

select 和 poll 速度都比较慢，每次调用都需要将全部描述符从应用进程缓冲区复制到内核缓冲区。

3. 可移植性

几乎所有的系统都支持 select，但是只有比较新的系统支持 poll。

epoll

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 的不确定情况。

// 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 < ret; i++ )
    {
        if ( pevents[i].events & EPOLLIN )
        {
            // Get back our connection pointer
            Connection * c = (Connection*) pevents[i].data.ptr;
            c->handleReadEvent();
         }
    }
}

工作模式

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

1. LT 模式

当 epoll_wait() 检测到描述符事件到达时，将此事件通知进程，进程可以不立即处理该事件，下次调用 epoll_wait() 会再次通知进程。是默认的一种模式，并且同时支持 Blocking 和 No-Blocking。

2. ET 模式

和 LT 模式不同的是，通知之后进程必须立即处理事件，下次再调用 epoll_wait() 时不会再得到事件到达的通知。

很大程度上减少了 epoll 事件被重复触发的次数，因此效率要比 LT 模式高。只支持 No-Blocking，以避免由于一个文件句柄的阻塞读/阻塞写操作把处理多个文件描述符的任务饿死。

应用场景

很容易产生一种错觉认为只要用 epoll 就可以了，select 和 poll 都已经过时了，其实它们都有各自的使用场景。

1. select 应用场景

select 的 timeout 参数精度为 1ns，而 poll 和 epoll 为 1ms，因此 select 更加适用于实时性要求比较高的场景，比如核反应堆的控制。

select 可移植性更好，几乎被所有主流平台所支持。

2. poll 应用场景

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

3. epoll 应用场景

只需要运行在 Linux 平台上，有大量的描述符需要同时轮询，并且这些连接最好是长连接。

需要同时监控小于 1000 个描述符，就没有必要使用 epoll，因为这个应用场景下并不能体现 epoll 的优势。

需要监控的描述符状态变化多，而且都是非常短暂的，也没有必要使用 epoll。因为 epoll 中的所有描述符都存储在内核中，造成每次需要对描述符的状态改变都需要通过 epoll_ctl() 进行系统调用，频繁系统调用降低效率。并且 epoll 的描述符存储在内核，不容易调试。

参考资料

Stevens W R, Fenner B, Rudoff A M. UNIX network programming[M]. Addison-Wesley Professional, 2004.
http://man7.org/linux/man-pages/man2/select.2.html
http://man7.org/linux/man-pages/man2/poll.2.html
Boost application performance using asynchronous I/O
Synchronous and Asynchronous I/O
Linux IO 模式及 select、poll、epoll 详解
poll vs select vs event-based
select / poll / epoll: practical difference for system architects
Browse the source code of userspace/glibc/sysdeps/unix/sysv/linux/ online

Http Server ：一个差生的逆袭

原创：刘欣码农翻身 2016-12-26

我刚毕业那会儿，国家还是包分配工作的，我的死党小明被分配到了一个叫数据库的大城市，天天都可以坐在高端大气上档次的机房里，在那里专门执行SQL查询优化，工作稳定又舒适；

隔壁宿舍的小白被送到了编译器镇，在那里专门把C源文件编译成EXE程序，虽然累，但是技术含量非常高，工资高，假期多。

我成绩不太好，典型的差生，四级补考了两次才过，被发配到了一个不知道什么名字的村庄，据说要处理什么HTTP请求，这个村庄其实就是一个破旧的电脑，令我欣慰的是可以上网，时不时能和死党们通个信什么的。

不过辅导员说了，我们都有光明的前途。

Http Server 1.0

HTTP是个新鲜的事物，能够激起我一点点工作的兴趣，不至于沉沦下去。

一上班，操作系统老大扔给我一大堆文档： “这是HTTP协议，两天看完！”

我这样的英文水平，这几十页的英文HTTP协议我不吃不喝不睡两天也看不完，死猪不怕开水烫，慢慢磨吧。

两个星期以后，我终于大概明白了这HTTP是怎么回事：无非是有些电脑上的浏览器向我这个破电脑发送一个预先定义好的文本（Http request）, 然后我这边处理一下（通常是从硬盘上取一个后缀名是html的文件），然后再把这个文件通过文本方式发回去（http response），就这么简单。

唯一麻烦的实现，我得请操作系统给我建立Http层下面的TCP连接通道，因为所有的文本数据都得通过这些TCP通道接收和发送，这个通道是用socket建立的。

弄明白了原理，我很快就搞出了第一版程序，这个程序长这个样子：

（码农翻身注：详情参加文章《张大胖的socket》）

看看，这些socket, bind, listen , accept... 都是操作系统老大提供的接口，我能做的也就是把他们组装起来：先在80端口监听，然后进入无限循环，如果有连接请求来了，就接受(accept)，创建新的socket, 最后才可以通过这个socket来接收，发送http数据。

老大给我的程序起了个名称， Http Server, 版本1.0 。

这个名字听起来挺高端的，我喜欢。

我兴冲冲的拿来实验，程序启动了，在80端口“蹲守”，过了一会儿就有连接请求了，赶紧Accept ,建立新的socket, 成功！接下来就需要从socket 中读取Http Request了。

可是这个receive 调用好慢，我足足等了100毫秒还没有响应！我被阻塞(block)住了！

操作系统老大说： “别急啊，我也在等着从网卡那里读数据，读完以后就会复制给你。 ”

我乐的清闲，可以休息一下。

可是操作系统老大说：“别介啊，后边还有很多浏览器要发起连接，你不能在这儿歇着啊。”

我说不歇着怎么办？ receive调用在你这里阻塞着，我除了加入阻塞队列，让出CPU让别人用还能干什么？

老大说： “唉，大学里没听说过多进程吗？你现在很明显是单进程，一旦阻塞就完蛋了，想办法用下多进程，每个进程处理一个请求！ ”

老大教训的是，我忘了多进程并发编程了。

Http 2.0 ：多进程

多进程的思路非常简单，当accept连接以后，对于这个新的socket ，不在主进程里处理，而是新创建子进程来接管。这样主进程就不会阻塞在receive 上，可以继续接受新的连接了。

我改写了代码，把Http server 升级为V2.0，这次运行顺畅了很多，能并发的处理很多连接了。

这个时候Web 刚刚兴起，我这个Http Server 访问的人还不多，每分钟也就那么几十个连接发过来，我轻松应对。

由于是新鲜事物，我还有资本给搞数据库的小明和做编译的小白吹吹牛，告诉他们我可是网络高手。

没过几年, Web迅速发展，我所在的破旧机器也不行了，换成了一个性能强悍的服务器，也搬到了四季如春的机房里。

现在每秒中都有上百个连接请求了，有些连接持续的时间还相当的长，所以我经常得创建成百上千的进程来处理他们，每个进程都得耗费大量的系统资源，很明显操作系统老大已经不堪重负了。

他说： “咱们不能这么干了，这么多进程，光是做进程切换就把我累死了。”

“要不对每个Socket连接我不用进程了，使用线程？ ”

“可能好一点，但我还是得切换线程啊，你想想办法限制一下数量吧。”

我怎么限制？我只能说同一时刻，我只能支持x个连接，其他的连接只能排队等待了。

这肯定不是一个好的办法。

Http Server 3.0 : Select模型

老大说： “我们仔细合计合计，对我来说，一个Socket连接就是一个所谓的文件描述符（File Descriptor ,简称 fd , 是个整数） , 这个fd 背后是一个简单的数据结构，但是我们用了一个非常重量级的东西-- 进程 --来表示对它的读写操作，有点浪费啊。”

我说： “要不咱们还切换回单进程模型？但是又会回到老路上去，一个receive 的阻塞就什么事都干不了了”

“单进程也不是不可以，但是我们要改变一下工作方式。”

“改成什么？” 我想不透老大在卖什么关子。

“你想想你阻塞的本质原因，还不是因为人家浏览器还没有把数据发过来，我自然也没法给你，而你又迫不及待的想去读，我只好把你阻塞。在单进程情况下，一阻塞，别的事儿都干不了。“

“对，就是这样”

“所以你接受了客户端连接以后，不能那么着急的去读，咱们这么办，你的每个socket fd 都有编号，你把这些编号告诉我，就可以阻塞休息了 ”

我问道：“这不和以前一样吗？原来是调用receive 时阻塞，现在还是阻塞”

“听我说完，我会在后台检查这些编号的socket, 如果发现这些socket 可以读写，我会把对应的socket 做个标记，把你唤醒去处理这些socket 的数据，你处理完了，再把你的那些socket fd 告诉我，再次进入阻塞，如此循环往复。”

我有点明白了： “ 这是我们俩的一种通信方式，我告诉你我要等待什么东西，然后阻塞，如果事件发生了，你就把我唤醒，让我做事情。”

“对，关键点是你等我的通知，我把你从阻塞状态唤醒后，你一定要去遍历一遍所有的socket fd，看看谁有标记，有标记的做相应处理。我把这种方式叫做 select ”

我用select的方式改写了Http server，抛弃了一个socket请求对于一个进程的模式，现在我用一个进程就可以处理所有的socket了。

Http Server4.0 : epoll

这种称为select的方式运行了一段时间，效果还不错，我只管把socket fd 告诉老大，然后等着他通知我就行了。

有一次我无意中问老大：“我每次最多可以告诉你多少个socket fd？”

“1024个”

“那就是说我一个进程最多只能监控1024个socket了？ ”

"是的，你可以考虑多用几个进程啊"

这倒是一个办法，不过"select"的方式用的多了，我就发现了弊端，最大的问题就是我从阻塞中恢复以后，需要遍历这1000多个socket fd，看看有没有标志位需要处理。

实际的情况是，很多socket 并不活跃，在一段时间内浏览器并没有数据发过来，这1000多个socket 可能只有那么几十个需要真正的处理，但是我不得不查看所有的socket fd，这挺烦人的。

难道老大不能把那些发生了变化的socket 告诉我吗？

我把这个想法给老大说了下，他说：“嗯，现在访问量越来越大， select 方式已经不满足要求，我们需要与时俱进了，我想了一个新的方式，叫做epoll”

“看到没有，使用epoll和select 其实类似“ 老大接着说： ” 不同的地方是第3步和第4步，我只会告诉你那些可以读写的socket , 你呢只需要处理这些'ready' 的socket 就可以了“

“看来老大想的很周全，这种方式对我来说就简单的多了。 ”

我用epoll 把Http Server 再次升级，由于不需要遍历全部集合，只需要处理哪些有变化的，活跃的socket 文件描述符，系统的处理能力有了飞跃的提升。

我的Http Server 受到了广泛的欢迎，全世界有无数人在使用，最后死党数据库小明也知道了，他问我：“ 大家都说你能轻松的支持好几万的并发连接，真是这样吗？ ”

我谦虚的说： “过奖，其实还得做系统的优化啦。”

他说：“厉害啊，你小子走了狗屎运了啊。”

我回答： “毕业那会儿辅导员不是说过吗，每个人都有光明的前途。”

（完）