Linux——IO复用

Linux——I/O复用技术

什么是I/O多路复用模型？

是一种针对大量描述符I/O事件就绪监控的一种技术，在某个描述符的某个I/O事件就绪后告知进程，避免进程针对未就绪的描述符进行操作，进而提高处理效率，以及避免可能出现的流程阻塞

网络程序在什么情况下需要使用I/O复用技术？

• 客户端程序要同时处理多个socket
• 客户端程序要同时处理用户输入和网络连接
• TCP服务器同时处理监听socket和连接socket
• 服务器要同时处理TCP请求和UDP
• 服务器要同时监听多个端口

I/O复用虽然能同时监听多个文件描述符，但它本身是阻塞的。并且当多个文件描述符同时就绪时，如果不采取额外的措施，程序就只能按顺序依次处理其中的每一个文件描述符，这使得服务器程序虽然看起来像是串行工作的。如果要实现并发，只能使用多进程或多线程等编程手段

Linux下实现IO复用的系统调用主要有select、poll和epoll

IO就绪事件：

可读：一个描述符的接收缓冲区中的数据大小大于低水平位标记（一个基准判断值——默认1字节）
可写：一个描述符的发送缓冲区中的剩余空间大小大于低水平标记（一个基准判断值——默认1字节）
异常：一个描述符产生了异常（比如一个连接断开了，描述符关闭了，描述符没有打开…）

select系统调用

select系统调用的用途：在一段指定时间内，监听用户感兴趣的文件描述符上的IO就绪事件。

select API？

API接口？

select系统调用的原型：

#incluce<sys/select.h>
int select(int nfds,fd_set* readfds,fd_set* writefds,
			fd_set* excptfds,struct timeval* timeout);

（1）nfds：指定被监听的文件描述符的总数+1(因为文件描述符是从0开始计数的)
（2）readfds、writefds和exceptfds：分别指向可读，可写和异常等事件对应的文件描述符集合
（3）timeout：用来设置select函数的超时时间。若为NULL则将一直阻塞(直到某个文件描述符就绪，没有描述符就绪就一直等待)；若其中数据(tv_sec、tv_usec)为0，则表示非阻塞（没有描述符就绪则立即返回）
timeval结构体的定义

struct timeval
{
	long tv_sec;	//秒数
	long tv_usec;	//微秒数
};

操作流程

1、用户定义一个指定事件的描述符集合(IO就绪事件)进行初始化

#include<typesizes.h>
#include<sys/select.h>
#define __FD_SETSIZE 1024
#define __NFDBITS (8*(int)sizeof(__fd_mask))
struct fd_set
{
	__fd_mask __fds_bits[__FD_SETSIZE / __NFDBITS]
};
//这个结构体只有一个数组成员，被当作位图使用，拥有1024个比特位，取决于 __FD_SETSIZE大小

void FD_ZERO(fd_set* fdset);//初始化，清除fdset的所有位

2、然后将需要监控指定事件的描述符添加到指定集合中(例如：对描述符监控可读事件，则将其添加到可读事件描述符集合中)

void FD_SET(int fd,fd_set* fdset)//添加fd描述符到fdset集合中(其实就是把fd对应的比特位置1)

3、将集合中数据拷贝到内核中，开始监控，当某个描述符就绪了指定要监控的事件，或者监控超时了则监控返回

#incluce<sys/select.h>
int select(int nfds,fd_set* readfds,fd_set* writefds,
			fd_set* excptfds,struct timeval* timeout);

4、在监控返回之前，select会将事件描述符集合中未就绪的描述符从集合中删除掉（这时候集合中的描述符都是就绪描述符）
5、用户遍历所有监控的描述符，看那个还在哪个集合中，则表示这个描述符就绪了什么事件，进而进行对应操作

void FD_ISSET(int fd,fd_set* fdset);//判断fd描述符是否在fdset集合中

6、如果不想监控某个描述符，则可以移除监控（把描述符从监控集合中移除掉）

void FD_CLR(int fd,fd_set* fdset);//清除fdset的位fd

描述符就绪条件？

哪些情况下文件描述符可以被认为是可读、可写或出现异常，对于select的使用非常关键。
在网络编程中，socket可读的情况有：

• socket内核接收缓存区中的字节数大于或等于其低水位标记SO_RCVLOWAT。此时我们可以无阻塞地读该socket，并且读操作返回的字节数大于0.
• socket通信的对方关闭连接，此时对该socket的读操作将返回0
• 监听socket上有新的连接请求
• socket上有未处理的错误。此时我们可以使用getsocket来读取和清除该错误。

socket可写的情况：

• socket内核发送缓存区中的可用字节数大于或等于其低水位标记SO_SNDLOWAT。此时我们可以无阻塞地写该socket，并且写操作返回的字节数大于0
• socket的写操作被关闭。对写操作被关闭的socket执行写操作将触发一个SIGPIPE信号
• socket使用非阻塞connect连接成功或失败(超时)之后
• socket上有未处理的错误。此时我们可以使用getsockopt来读取和清除该错误

网络程序中，select能处理的异常情况只有一种：socket上接收到外带数据。

优缺点？

优点：

遵循posix标准，跨平台移植性良好

缺点：

1、select所能监控的描述符有数量上限，上线取决于宏__FD_SETSIZE，默认是1024
2、select因为每次监控都会修改超时时间，以及描述符集合，因此每次监控都需要重新设置（大量描述符监控时较为麻烦）
3、select每次监控都需要重新把数据拷贝到内核中，并且监控原理需要多次遍历集合，因此描述符越多，效率越低
4、select只是返回了就绪的描述符集合，仍然需要用户判断哪个描述符在哪个集合中才能确定哪个描述符就绪了哪个事件

poll系统调用

poll API接口：

#include<poll.h>
int poll(struct pollfd* fds,nfds_t nfds,int timeout);
/*
fds：事件结构体数组的首元素地址
nfds：数组元素的有效元素个数
timeout：监控超时时间	-1表示阻塞监控，没有就绪则一直等待；0表示非阻塞，没有就绪也会直接返回
返回值：出错返回-1；返回0表示监控超时；返回值大于0表示就绪的事件个数
*/

pollfd结构体：

struct pollfd
{
	int fd;			//文件描述符
	short events;	//注册的事件
	short revents;	//实际发生的事件，由内核填充
}

其中fd成员指定文件描述符：events成员告诉poll监听fd上的那些事件，它是一系列事件的按位或；revents成员则由内核修改，以通知应用程序fd上实际发生了那些事件。

操作流程：

1、用户定义一个IO就绪事件结构体数组

struct pollfd
{
	int fd;			//要监控的描述符
	short events;	//对应fd描述符想要监控的事件 POLLIN--可读 POLLOUT--可写
	short revents;	//监控返回后描述符实际就绪的事件
}

2、向事件结构体数组中，添加需要监控的描述符以及对应的事件信息
3、调用监控接口，将数据拷贝岛内核，开始监控，当监控超时或与描述符就绪了对应事件则调用返回
4、调用返回前监控会将每个事件结构体中revents成员进行置位，置为实际就绪的事件（没有就绪则置0）
5、当调用返回后，则遍历事件结构体数据，就能确定哪个描述符就绪了哪个事件，进而可以进行对应操作

优缺点？

优点：

1、所能监控的描述符数量没有上线限制
2、使用时间结构体实现监控，简化了select多种集合以及每次重新添加描述符的缺点，即使得操作流程更加简单

缺点：

1、跨平台移植性没有select好
2、大量描述符监控上新能没有epoll好（因为监控原理与select是一样得，多次遍历，性能会随着描述符增多而降低）
3、依然要在监控调用返回后，遍历数组才能直到哪个描述符就绪了哪个事件

epoll系统调用

epoll的特点？

epoll是Linux特有的I/O复用函数。它在实现和使用上与select、poll有很大差异。首先，epoll使用一组函数来完成任务，而不是单个函数。其次，epoll把用户关心的文件描述符上的事件放在内核里的一个事件表中，从而无须像select和 poll那样每次调用都要重复传人文件描述符集或事件集。但epoll需要使用一个额外的文件描述符，来唯一标识内核中的这个事件表。这个文件描述符使用epoll_create函数来创建:

#include<sys/epoll.h>
int epoll_create(int size);

size现在并不起作用，只是给内核一个提示，告诉事件表需要多大。该函数返回的文件描述符将用作其他所有epoll系统调用得第一个参数，以指定要访问得内核事件表。

内核事件表？

用epoll_ctl创建内核事件表

#include<sys/epoll.h>
int epoll_ctl(int epfd,int op,int fd,struct epoll_event* event);

fd：是要操作的文件描述符，
op：指定操作类型
操作类型：

• EPOLL_CTL_ADD，往事件表中注册事件
• EPOLL_CTL_MOD，修改fd上得注册事件
• EPOLL_CTL_DEL，删除fd上得注册事件

event 指定事件，是epoll_event结构指针类型。
epoll_event得定义：

struct epoll_event
{
	__uint32_t events;//epoll事件
	epoll_data_t data;//用户数据
}

其中events成员描述事件类型。epoll支持的事件类型和poll基本相同。表示epoll事件类型的宏是在poll对应的宏前加上“E”"，比如epoll 的数据可读事件是EPOLLIN。但epoll有两个额外的事件类型——EPOLLET和EPOLLONESHOT。它们对于epoll的高效运作非常关键，我们将在后面讨论它们。
data成员用于存储用户数据，其类型epoll_data_t的定义:

typedef union epoll_data
{
	void* ptr;
	int fd;
	uint32_t u32;
	uint64_t u64;
}epoll_data_t;

epoll_ctl成功时返回0，失败则返回-1并设置errno。

epoll_wait函数？

epoll系列系统调用的主要接口是epoll_wait函数。
它在一段超时时间内等待一组文件描述符上的事件

#include<sys/epoll.h>
int epoll_wait(int epfd,struct epoll_event* events,
			int maxevents,int timeout);

该函数成功时返回就绪的文件描述符的个数，失败时返回-1并设置errno。
timeout参数的含义与poll接口的timeout参数相同。maxevents参数指定最多监听多少个事件，它必须大于0。

epoll_wait函数如果检测到事件，就将所有就绪的事件从内核事件表(由epfd参数指定）中复制到它的第二个参数events 指向的数组中。这个数组只用于输出 epoll_wait检测到的就绪事件，而不像select和 poll的数组参数那样既用于传入用户注册的事件，又用于输出内核检测到的就绪事件。这就极大地提高了应用程序索引就绪文件描述符的效率.

LT和ET模式？

epoll对文件描述符的操作有两种模式: LT (电平触发）模式和 ET（边沿触发）模式。

• LT模式是默认的工作模式，这种模式下epoll相当于一个效率较高的poll。当往epoll内核事件表中注册一个文件描述符上的EPOLLET事件时，epoll将以ET模式来操作该文件描述符。ET模式是epoll的高效工作模式。
• 对于采用LT工作模式的文件描述符，当epoll_wait检测到其上有事件发生并将此事件通知应用程序后，应用程序可以不立即处理该事件。这样，当应用程序下一次调用epoll_wait时，epoll_wait还会再次向应用程序通告此事件，直到该事件被处理。而对于采用ET工作模式的文件描述符，当epoll_wait检测到其上有事件发生并将此事件通知应用程序后，应用程序必须立即处理该事件，因为后续的epoll_wait调用将不再向应用程序通知这一事件。可见，ET模式在很大程度上降低了同一个epoll事件被重复触发的次数，因此效率要比LT模式高。

EPOLLLT——默认触发方式—LT(电平触发)
EPOLLET——ET(边沿触发)
就绪事件得触发：（电平触发——EPOLLLT）
可读：接收缓存区中数据大小大于低水位标记
可写：发送缓冲区中剩余空间大小大于低水位标记
边沿触发：EPOLLET
可读：缓存区中每当有新数据到来的时候才会触发一次时间（如果没有新数据到来，就算缓存区中有数据也不会触发事件）
可写：剩余空间从无到有的时候才会触发一次事件
边沿触发带来的其他影响：

因为边缘触发是每次新数据到来，才会触发一次事件，这就导致我们必须在一次事件触发中把所有的数据都读取出去，否则缓冲区中的剩余数据不会引起二次事件触发，也就不会再次获取数据，相当于数据就没有处理完
然而因为我们不知道数据有多少，所以只能循环读取，但是问题是如果缓冲区没有数据了继续读取就会阻塞这时候，我们针对边缘触发，就必须使用非阻塞操作（当没有数据的时候recv也会立即报错返回)

非阻塞操作
ssize_t recv(int fd,char* buf,int len,int flag == MSG_DONTWAIT);
int fcntl(int fd,int cmd,…/* arg */);
cmd：F_GETFL——获取描述符属性；
F_SETFL——设置描述符属性
arg：要设置的属性
int flag=fcntl(fd,F_GETFL,0);
fcntl(fd,F_SETFL,O_NONBLOCK | flag);在原有属性基础上新增非阻塞属性

边沿触发，在读取的时候只有新数据到来才会触发事件，考虑这么一种应用场景：
我们想要读取一个完整的数据，但是现在缓冲区中的数据不完整，如果我们不把他读取出来，意味着这个数据会在水平触发下一直触发事件，但是操作获取数据不完整，这种情况下就适用于边缘触发，有新数据到来的时候再看一下数据是否完整。
recv实际上是有一种操作，获取缓冲区中的数据，但是不移除缓冲区中的数据，其实就是看一下缓冲区有什么数据
常规情况下，recv获取数据会伴随将缓冲区中获取的数据也删除掉
recv(int fd, char *buf，int len，int flag == MSG_PEEK);只获取不删除，相当于查看缓冲区数据
边缘触发，归根结底是为了避免不需要的事件触发，所导致循环操作的效率降低

电平触发可能会出现的问题？——EPOLLONESHOT事件

即使我们使用ET模式，一个socket上的某个事件还是可能被触发多次。这在并发程序中就会引起一个问题。比如-一-个线程（或进程，下同）在读取完某个socket
上的数据后开始处理这些数据，而在数据的处理过程中该socket
上又有新数据可读（EPOLLIN再次被触发)，此时另外一个线程被唤醒来读取这些新的数据。于是就出现了两个线程同时操作一个socket的局面。这当然不是我们期望的。我们期望的是一个socket连接在任一时刻都只被一个线程处理。这一点可以使用epoll的
EPOLLONESHOT事件实现。
对于注册了EPOLLONESHOT事件的文件描述符，操作系统最多触发其上注册的一个可读、可写或者异常事件，且只触发一次，除非我们使用epoll_ctl函数重置该文件描述符上注册的EPOLLONESHOT事件。这样，当一个线程在处理某个socket时，其他线程是不可能有机会操作该socket
的。但反过来思考，注册了EPOLLONESHOT事件的socket一旦被某个线程处理完毕，该线程就应该立即重置这个socket 上的
EPOLLONESHOT事件，以确保这个socket下一次可读时，其EPOLLIN事件能被触发，进而让其他工作线程有机会继续处理这个socket。

优缺点？

优点:

流程简单，性能不会随着描述符增多而下降
1.监控描述符数量没有上限
⒉监控原理是异步操作，监控由内核完成，进程只需要判断就绪链表是否为空即可，效率不会随着描述符的增多下降
3.直接返回的全是就绪的描述符事件信息，可以直接针对就绪的描述符进行操作，没有空遍历

缺点:

跨平台移植性较差

三组IO复用技术的比较？

select与poll:

效率会随着描述符的增多而降低，流程select相较复杂，但是如果是单描述符的监控，或者但描述符操作的超时控制非常适用

epoll:

性能不会随着描述符增多而降低，适用于针对大量描述符监控的场景，而不太适用于单个描述符的超时操作控制因为它需要在内核中创建句柄，进行各种操作，不用了，还需要销毁

IO复用的适用场景？

多路转接模型，要么适用于单个描述符的超时控制，要么针对大量描述符的事件监控，但是多路转接模型在大量描述符的时候，只适用于有大量描述符，但是同一时间只有少量就绪的场景
因为多路转接模型，是一种单执行流的并发轮询操作，如果同一时间就绪的描述符过多，回到之后前边的处理完毕后，后边的才能得到处理,这时候有可能有些描述符已经等待超时所以通常我们是多路转接模型，搭配线程池一起使用，使用多路转接模型进行事件监控，有就绪则将就绪的描述符抛入线程池中进行处理，这样还能避免描述符没有数据空占线程的场景。
具体场景：
非阻塞connect
聊天室程序——客户端、服务端
同时处理TCP和UDP服务