网络编程里常听到阻塞IO、非阻塞IO、同步IO、异步IO等概念,总听别人聊不如自己下来钻研一下。不过,搞清楚这些概念之前,还得先回顾一些基础的概念。
下面说的都是Linux环境下,跟Windows环境不一样哈·☺。
现在操作系统都采用虚拟寻址,处理器先产生一个虚拟地址,通过虚拟地址翻译成物理地址(内存的地址),再通过总线的传递,最后处理器拿到某个物理地址返回的字节。
操作系统的核心是内核,独立于普通的应用程序,可以访问受保护的内存空间,也有访问底层硬件设备的所有权限。为了保证用户进程不能直接操作内核(kernel),保证内核的安全,操心系统将虚拟空间划分为两部分,一部分为内核空间,一部分为用户空间。
对32位linux操作系统而言,它的寻址空间(虚拟存储空间)为4G(2的32次方),将最高的1G字节(从虚拟地址0xC0000000到0xFFFFFFFF),供内核使用,称为内核空间,而将较低的3G字节(从虚拟地址0x00000000到0xBFFFFFFF),供各个进程使用,称为用户空间。
为了控制进程的执行,内核必须有能力挂起正在CPU上运行的进程,并恢复以前挂起的某个进程的执行。这种行为被称为进程切换(也叫调度)。因此可以说,任何进程都是在操作系统内核的支持下运行的,是与内核紧密相关的。
从一个进程的运行转到另一个进程上运行,这个过程中经过下面这些变化:
保存当前进程A的上下文。
上下文就是内核再次唤醒当前进程时所需要的状态,由一些对象(程序计数器、状态寄存器、用户栈等各种内核数据结构)的值组成。这些值包括描绘地址空间的页表、包含进程相关信息的进程表、文件表等。
切换页全局目录以安装一个新的地址空间。
...
恢复进程B的上下文。
进程切换是一个比较耗资源的过程。
正在执行的进程,由于期待的某些事件未发生,如请求系统资源失败、等待某种操作的完成、新数据尚未到达或无新工作做等,则由系统自动执行阻塞原语(Block),使自己由运行状态变为阻塞状态。
进程的阻塞是进程自身的一种主动行为,也因此只有处于运行态的进程(获得CPU),才可能将其转为阻塞状态。当进程进入阻塞状态,是不占用CPU资源的。
文件描述符(File descriptor)是计算机科学中的一个术语,是一个用于表述指向文件的引用的抽象化概念。
文件描述符在形式上是一个非负整数。实际上,它是一个索引值,指向内核为每一个进程所维护的该进程打开文件的记录表。当程序打开一个现有文件或者创建一个新文件时,内核向进程返回一个文件描述符。在程序设计中,一些涉及底层的程序编写往往会围绕着文件描述符展开。文件描述符这一概念往往只适用于UNIX、Linux这样的操作系统。
缓存I/O又被称作标准I/O,大多数文件系统的默认I/O操作都是缓存I/O。在Linux的缓存I/O机制中,以write为例,数据会先被拷贝到进程的缓冲区,再拷贝到操作系统内核的缓冲区中,然后才会写到存储设备中。write过程中会有很多次拷贝,直到数据全部写到磁盘。
缓存I/O 的 write :
直接I/O 的 write(少了拷贝到进程缓冲区这一步):
对于一次I/O访问(这回以read举例),数据会先被拷贝到操作系统内核的缓冲区中,然后才会从操作系统内核的缓冲区拷贝到应用程序的缓冲区,最后交给进程。所以说,当一个read操作发生时,它会经历两个阶段:
等待数据准备 (Waiting for the data to be ready)
将数据从内核拷贝到进程中 (Copying the data from the kernel to the process)
正是因为这两个阶段,linux 系统产生了下面五种网络模式的方案:
-- 阻塞 I/O( blocking IO )
-- 非阻塞 I/O( nonblocking IO )
-- I/O 多路复用( IO multiplexing )
-- 信号驱动 I/O( signal driven IO )
-- 异步 I/O( asynchronous IO )
由于
signal driven IO
在实际中并不常用,所以只提及剩下的四种IO 模型。
阻塞I/O模型示意图:
read过程:
(1)进程发起read,进行recvfrom系统调用;
(2)内核开始第一阶段,准备数据(从磁盘拷贝到缓冲区),进程请求的数据并不是一下就能准备好;准备数据是要消耗时间的;
(3)与此同时,进程阻塞(进程是自己选择阻塞与否),等待数据ing;
(4)直到数据从内核拷贝到了用户空间,内核返回结果,进程解除阻塞;
也就是说,内核准备数据和数据从内核拷贝到进程内存地址这两个过程都是阻塞的。
可以通过设置 Socket 使其变为non-blocking
。当对一个 non-blocking Socket 执行读操作时,流程是这个样子:
read过程:
(1)当用户进程发出read操作时,如果kernel中的数据还没有准备好;
(2)那么它并不会block用户进程,而是立刻返回一个error,从用户进程角度讲 ,它发起一个read操作后,并不需要等待,而是马上就得到了一个结果;
(3)用户进程判断结果是一个error时,它就知道数据还没有准备好,于是它可以再次发送read操作。一旦kernel中的数据准备好了,并且又再次收到了用户进程的system call;
(4)那么它马上就将数据拷贝到了用户内存,然后返回。
所以,non-blocking IO
的特点是用户进程在内核准备数据的阶段需要不断的主动询问数据好了没有。
I/O多路复用实际上就是用select, poll, epoll监听多个io对象,当io对象有变化(有数据)的时候就通知用户进程。好处就是单个进程可以处理多个Socket。当然具体区别我们后面再讨论,现在先来看下I/O多路复用的流程:
read过程:
(1)当用户进程调用了select,那么整个进程会被block;
(2)而同时,kernel会“监视”所有select负责的Socket;
(3)当任何一个Socket中的数据准备好了,select就会返回;
(4)这个时候用户进程再调用read操作,将数据从kernel拷贝到用户进程。
所以,I/O 多路复用的特点是通过一种机制一个进程能同时等待多个文件描述符,而这些文件描述符(套接字描述符)其中的任意一个进入读就绪状态,select()函数就可以返回。
这个图和 blocking IO 的图其实并没有太大的不同,事实上,还更差一些。因为这里需要使用两个 system call (select 和 recvfrom),而 blocking IO 只调用了一个 system call (recvfrom)。但是,用 select 的优势在于它可以同时处理多个 connection。
所以,如果处理的连接数不是很高的话,使用 select/epoll 的web server不一定比使用 多线程 + 阻塞 IO 的web server性能更好,可能延迟还更大。
select/epoll 的优势并不是对于单个连接能处理得更快,而是在于能处理更多的连接。
在 IO multiplexing Model 中,实际中,对于每一个 Socket ,一般都设置成为 non-blocking ,但是,如上图所示,整个用户的 process 其实是一直被 block 的。只不过 process 是被 select 这个函数 block,而不是被 Socket IO 给 block。
真正的异步I/O很牛逼,流程大概如下:
read过程:
(1)用户进程发起read操作之后,立刻就可以开始去做其它的事。
(2)而另一方面,从kernel的角度,当它受到一个asynchronous read之后,首先它会立刻返回,所以不会对用户进程产生任何block。
(3)然后,kernel会等待数据准备完成,然后将数据拷贝到用户内存,当这一切都完成之后,kernel会给用户进程发送一个signal,告诉它read操作完成了。
调用 blocking IO 会一直 block 住对应的进程直到操作完成,而 non-blocking IO 在 kernel 还准备数据的情况下会立刻返回。
在说明 synchronous IO 和 asynchronous IO 的区别之前,需要先给出两者的定义。POSIX 的定义是这样子的:
✎ A synchronous I/O operation causes the requesting process to be blocked until that I/O operation completes;
✎ An asynchronous I/O operation does not cause the requesting process to be blocked;
两者的区别就在于 synchronous IO 做“IO operation”的时候会将 process 阻塞。按照这个定义,之前所述的 blocking IO , non-blocking IO , IO multiplexing 都属于 synchronous IO 。
有人会说, non-blocking IO 并没有被 block 啊。这里有个非常“狡猾”的地方,定义中所指的”IO operation”是指真实的 IO 操作,就是例子中的 recvfrom 这个 system call。 non-blocking IO 在执行 recvfrom 这个 system call 的时候,如果 kernel 的数据没有准备好,这时候不会 block 进程。但是,当 kernel 中数据准备好的时候,recvfrom 会将数据从kernel 拷贝到用户内存中,这个时候进程是被 block 了,在这段时间内,进程是被 block 的。
而 asynchronous IO 则不一样,当进程发起 IO 操作之后,就直接返回再也不理睬了,直到 kernel 发送一个信号,告诉进程说 IO 完成。在这整个过程中,进程完全没有被 block。
可以发现 non-blocking IO 和 asynchronous IO 的区别还是很明显的:
▶ 在 non-blocking IO 中,虽然进程大部分时间都不会被 block,但是它仍然要求进程去主动的 check,并且当数据准备完成以后,也需要进程主动的再次调用 recvfrom 来将数据拷贝到用户内存。
▶ 而 asynchronous IO 则完全不同。它就像是用户进程将整个 IO 操作交给了他人(kernel)完成,然后他人做完后发信号通知。在此期间,用户进程不需要去检查IO操作的状态,也不需要主动的去拷贝数据。
I/O多路复用实际上就是用 select, poll, epoll 监听多个 io 对象,当 io 对象有变化(有数据)的时候就通知用户进程。
好处就是单个进程可以处理多个 Socket。
select 是操作系统提供的系统调用函数,通过它,我们可以把一个文件描述符的数组发给操作系统,让操作系统去遍历,确定哪个文件描述符可以读写, 然后告诉我们去处理。
select 系统调用的函数定义:
int select( int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout ); // nfds:监控的文件描述符集里最大文件描述符加1 // readfds:监控有读数据到达文件描述符集合,传入传出参数 // writefds:监控写数据到达文件描述符集合,传入传出参数 // exceptfds:监控异常发生达文件描述符集合, 传入传出参数 // timeout:定时阻塞监控时间,3种情况: // 1.NULL,永远等下去 // 2.设置timeval,等待固定时间 // 3.设置timeval里时间均为0,检查描述字后立即返回,轮询
服务端代码:
首先一个线程不断接受客户端连接,并把 Socket 文件描述符放到一个 list 里。
while(1) { connfd = accept(listenfd); fcntl(connfd, F_SETFL, O_NONBLOCK); fdlist.add(connfd); }
然后,另一个线程不再自己遍历,而是调用 select,将这批文件描述符 list 交给操作系统去遍历。
while(1) { // 把一堆文件描述符 list 传给 select 函数 // 有已就绪的文件描述符就返回,nready 表示有多少个就绪的 nready = select(list); ... }
不过,当 select 函数返回后,用户依然需要遍历刚刚提交给操作系统的 list。
只不过,操作系统会将准备就绪的文件描述符做上标识,用户层将不会再有无意义的系统调用开销。
while(1) { nready = select(list); // 用户层依然要遍历,只不过少了很多无效的系统调用 for(fd <-- fdlist) { if(fd != -1) { // 只读已就绪的文件描述符 read(fd, buf); // 总共只有 nready 个已就绪描述符,不用过多遍历 if(--nready == 0) break; } } }
直观效果:
可以看出几个细节:
select 调用需要传入 fd 数组,需要拷贝一份到内核,高并发场景下这样的拷贝消耗的资源是惊人的。(可优化为不复制)
select 在内核层仍然是通过遍历的方式检查文件描述符的就绪状态,是个同步过程,只不过无系统调用切换上下文的开销。(内核层可优化为异步事件通知)
select 仅仅返回可读文件描述符的个数,具体哪个可读还是要用户自己遍历。(可优化为只返回给用户就绪的文件描述符,无需用户做无效的遍历)
总结:整个 select 的流程
可以看到,这种方式,既做到了一个线程处理多个客户端连接(文件描述符),又减少了系统调用的开销(多个文件描述符只有一次 select 的系统调用 + n 次就绪状态的文件描述符的 read 系统调用)。
poll 也是操作系统提供的系统调用函数。
poll 系统调用的函数定义:
int poll(struct pollfd *fds, nfds_tnfds, int timeout); struct pollfd { intfd; /* 文件描述符 */ shortevents; /* 监控的事件 */ shortrevents; /* 监控事件中满足条件返回的事件 */ };
它和 select 的主要区别就是,去掉了 select 只能监听 1024 个文件描述符的限制。
epoll 是最终的大 boss,它解决了 select 和 poll 的一些问题:
内核中保存一份文件描述符集合,无需用户每次都重新传入,只需告诉内核修改的部分即可。
内核不再通过轮询的方式找到就绪的文件描述符,而是通过异步 IO 事件唤醒。
内核仅会将有 IO 事件的文件描述符返回给用户,用户也无需遍历整个文件描述符集合。
具体,操作系统提供了这三个函数:
// 第一步,创建一个 epoll 句柄 int epoll_create(int size); // 第二步,向内核添加、修改或删除要监控的文件描述符。 int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event); // 第三步,类似发起了 select() 调用 int epoll_wait(int epfd, struct epoll_event *events, int max events, int timeout);
直观效果:
IO多路复用是指内核一旦发现进程指定的一个或者多个IO条件准备读取,它就通知该进程。IO多路复用适用如下场合:
(1)当客户处理多个描述字时(一般是交互式输入和网络套接口),必须使用I/O复用。
(2)当一个客户同时处理多个套接口时,而这种情况是可能的,但很少出现。
(3)如果一个TCP服务器既要处理监听套接口,又要处理已连接套接口,一般也要用到I/O复用。
(4)如果一个服务器即要处理TCP,又要处理UDP,一般要使用I/O复用。
(5)如果一个服务器要处理多个服务或多个协议,一般要使用I/O复用。
与多进程和多线程技术相比,I/O多路复用技术的最大优势是系统开销小,系统不必创建进程/线程,也不必维护这些进程/线程,从而大大减小了系统的开销。