文件描述符（File descriptor）是计算机科学中的一个术语，是一个用于表述 指向文件的引用的抽象化概念 。文件描述符在形式上是一个非负整数。 实际上，它是一个索引值，指向内核为每一个进程所维护的该进程打开文件的记录表 。当程序打开一个现有文件或者创建一个新文件时，内核向进程返回一个文件描述符。在程序设计中，一些涉及底层的程序编写往往会围绕着文件描述符展开。但是文件描述符这一概念往往只适用于UNIX、Linux这样的 *** 作系统。
刚才说了，对于一次IO访问（以read举例），数据会先被拷贝到 *** 作系统内核的缓冲区中，然后才会从 *** 作系统内核的缓冲区拷贝到应用程序的地址空间。所以说，当一个read *** 作发生时，它会经历两个阶段：
1、等待数据准备 (Waiting for the data to be ready)
2、将数据从内核拷贝到进程中 (Copying the data from the kernel to the process)
正式因为这两个阶段，linux系统产生了下面 五种网络模式 的方案。
阻塞 I/O（blocking IO）
非阻塞 I/O（nonblocking IO）
I/O 多路复用（ IO multiplexing）
异步 I/O（asynchronous IO）
信号驱动 I/O（ signal driven IO）
注：由于signal driven IO在实际中并不常用，所以我这只提及剩下的四种IO Model。
阻塞 I/O（blocking IO）
在linux中，默认情况下所有的socket都是blocking，一个典型的读 *** 作流程大概是这样：
当用户进程调用了recvfrom这个系统调用，kernel就开始了IO的第一个阶段：准备数据（对于网络IO来说，很多时候数据在一开始还没有到达。比如，还没有收到一个完整的UDP包。这个时候kernel就要等待足够的数据到来）。这个过程需要等待，也就是说数据被拷贝到 *** 作系统内核的缓冲区中是需要一个过程的。而在用户进程这边，整个进程会被阻塞（当然，是进程自己选择的阻塞）。当kernel一直等到数据准备好了，它就会将数据从kernel中拷贝到用户内存，然后kernel返回结果，用户进程才解除block的状态，重新运行起来。
所以，blocking IO的特点就是在IO执行的两个阶段都被block了（内核阻塞读取数据，内核将数据复制到应用户态）。
非阻塞 I/O（nonblocking IO）
linux下，可以通过设置socket使其变为non-blocking。当对一个non-blocking socket执行读 *** 作时，流程是这个样子：
当用户进程发出read *** 作时，如果kernel中的数据还没有准备好，那么它并不会block用户进程，而是立刻返回一个error。从用户进程角度讲 ，它发起一个read *** 作后，并不需要等待，而是马上就得到了一个结果。用户进程判断结果是一个error时，它就知道数据还没有准备好，于是它可以再次发送read *** 作。一旦kernel中的数据准备好了，并且又再次收到了用户进程的system call，那么它马上就将数据拷贝到了用户内存，然后返回。
所以，nonblocking IO的特点是用户进程需要 不断的主动询问 kernel数据好了没有（ 内核读取数据时，用户态不需要阻塞，内核将数据复制到用户态时，需要阻塞 ）。
I/O 多路复用（ IO multiplexing）
IO multiplexing就是我们说的select，poll，epoll，有些地方也称这种IO方式为event driven IO。select/epoll的好处就在于单个process就可以同时处理多个网络连接的IO。它的基本原理就是 select，poll，epoll这个function会不断的轮询所负责的所有socket ，当某个socket有数据到达了，就通知用户进程。
当用户 进程调用了select ， 那么整个进程会被block ，而同时，kernel会“监视”所有 select负责的socket（一个管理多个socket连接），当任何一个socket中的数据准备好了，select就会返回 。这个时候用户进程再调用read *** 作， 将数据从kernel拷贝到用户进程 。
所以，I/O 多路复用的特点是通过一种机制一个进程能同时等待多个文件描述符，而这些文件描述符（套接字描述符）其中的任意一个进入读就绪状态，select()函数就可以返回。
这个图和blocking IO的图其实并没有太大的不同，事实上，还更差一些。 因为这里需要使用两个system call (select 和 recvfrom)，而blocking IO只调用了一个system call (recvfrom) 。但是，用select的优势在于它可以同时处理多个connection。
所以，如果处理的 连接数不是很高的话，使用select/epoll的web server不一定比使用multi-threading + blocking IO的web server性能更好，可能延迟还更大 。select/epoll的优势并不是对于单个连接能处理得更快，而是在于能处理更多的连接。）
在IO multiplexing Model中，实际中，对于每一个socket，一般都设置成为non-blocking，但是，如上图所示，整个用户的process其实是一直被block的。只不过process是被select这个函数block，而不是被socket IO给block。
总结：IO多路复用其实也是阻塞的，阻塞的地方在用当有socket连接有数据以后， 会阻塞知道数据从内核复制到用户态（第二步阻塞）。
异步 I/O（asynchronous IO）
inux下的asynchronous IO其实用得很少。先看一下它的流程：
用户进程发起read *** 作之后，立刻就可以开始去做其它的事。而另一方面，从kernel的角度，当它受到一个asynchronous read之后，首先它会立刻返回，所以不会对用户进程产生任何block。然后，kernel会等待数据准备完成，然后将数据拷贝到用户内存，当这一切都完成之后，kernel会给用户进程发送一个signal，告诉它read *** 作完成了。
总结：两个阶段都不需要用户进程干涉，内核将数据准备好以后通知用户态去读取
总结
blocking和non-blocking的区别
调用blocking IO会一直block住对应的进程直到 *** 作完成，而non-blocking IO在kernel还准备数据的情况下会立刻返回。
synchronous IO和asynchronous IO的区别
在说明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。
阻塞IO只能阻塞一个IO *** 作，IO复用模型能阻塞多个IO *** 作，所以才叫多路复用
读数据 ：
直到数据全拷贝至User Space后才返回
不断去Kernel做Polling，询问比如读 *** 作是否完成，没完成则read() *** 作会返回EWOUDBLOCK，需要过一会再尝试执行一次read()。该模式会消耗大量CPU
之前等待时间主要消耗在等数据到达上。IO Multiplexing则是将等待数据到来和读取实际数据两个事情分开，好处是通过select()等IO Multiplexing的接口一次可以等待在多个Socket上。select()返回后，处于Ready状态的Socket执行读 *** 作时候也会阻塞，只是只阻塞将数据从Kernel拷贝到User的时间
首先注册处理函数到SIGIO信号上，在等待数据到来过程结束后，系统触发SGIO信号，之后可以在信号处理函数中执行读数据 *** 作，再唤醒Main Thread或直接唤醒Main Thread让它完成数据读取。整个过程没有一次阻塞。
问题：TCP下，连接断开/可读/可写等都会产生Signal，并且Signal没有提供好的方法去区分这些Signal到底为什么被触发
AIO是注册一个读任务，直到读任务完全完成后才会通知应用层。AIO是由内核通知IO *** 作什么时候完成，信号驱动IO是由内核告知何时启动IO *** 作
也存在挺多问题，比如如何去cancel一个读任务
除了AIO是异步IO，其他全是同步IO
fd_set: 一个long类型的数组，每一位可以表示一个文件描述符
问题 ：
返回条件与select一样。
fds还是关注的描述符列表。poll将events和reevents分开了，所以如果关注的events没有发生变化就可以重用fds，poll只修改rents不会动events。fds是个数组，不是fds_set，没有了上限。
相对于select，poll解决了fds长度上限问题，解决了监听描述符无法复用问题，但仍需在poll返回后遍历fds去找ready的描述符，也要清理ready描述符对应的revents，Kernel也同样是每次poll调用需要去遍历fds注册监听，poll返回时拆除监听，也仍有惊群问题，无法动态修改描述符的问题。
使用步骤：
优点 ：
缺点 ：
changelist用于传递关心的event
nchanges用于传递changelist的大小
eventlist用于当有事件产生后，将产生的事件放在这里
nevents用于传递eventlist大小
timeout 超时时间
kqueue高级的地方在于，它监听的不一定非要是Socket，不一定非要是文件，可以是一系列事件，所以struct kevent内参数叫filter，用于过滤出关心的事件。
kqueue有epoll所有优点，还能通过changelist一次注册多个关心的event，不需要像epoll那样每次调用epoll_ctl去配置
当我们执行epoll_ctl时，除了把socket放到epoll文件系统里file对象对应的红黑树上之外，还会给内核中断处理程序注册一个回调函数，告诉内核，如果这个句柄的中断到了，就把它放到准备就绪list链表里。所以，当一个socket上有数据到了，内核在把网卡上的数据copy到内核中后就来把socket插入到准备就绪链表里。
如此，一棵红黑树，一张准备就绪句柄链表，少量的内核cache，就帮我们解决了大并发下的socket处理问题。执行epoll_create时，创建了红黑树和就绪链表，执行epoll_ctl时，如果增加socket句柄，则检查在红黑树中是否存在，存在立即返回，不存在则添加到树干上，然后向内核注册回调函数，用于当中断事件来临时向准备就绪链表中插入数据。执行epoll_wait时立刻返回准备就绪链表里的数据即可。
Epoll有两种触发模式，一种Edge Trigger简称ET，一种Level Trigger简称LT。每个使用epoll_ctl注册在epoll描述符上的被监听的描述符都能单独配置自己的触发模式。
从使用角度的区别：ET模式下当一个文件描述符Ready后，需要以Non-Blocking方式一直 *** 作这个FD直到 *** 作返回EAGAIN错误位置，期间Ready这个事件只会触发epoll_wait一次返回。LT模式，如果FD上的事件一直处在Ready状态没处理完，则每次调用epoll_wait都会立即返回
场景：
Java的NIO提供了Selector类，用于跨平台的实现Socket Polling，即IO多路复用。BSD系统上对应的是Kqueue，Window上对应的是Select，Linux上对应的是LT的Epoll(为了跨平台统一，Windows上背后是Select，是LT的)
Selector的使用：
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）