-
【Linux从0到1】第十七篇：高级IO
一、五种IO模型
-
阻塞IO: 当用户发出IO请求之后，内核会去查看数据是否就绪，如果没有就绪系统调用就会等待数据就绪，此时操作系统会将进程从运行队列拿到等待队列，当数据就绪时，操作系统又会将进程从等待队列拿到运行队列，进行数据读取， 所有的套接字, 默认都是阻塞方式.
阻塞IO是最常见的IO模型。
-
非阻塞IO: 当用户发出IO请求之后，内核会去查看数据是否就绪，如果内核还未将数据准备好, 系统调用仍然会直接返回, 并且返回EWOULDBLOCK错误码.
非阻塞IO往往需要程序员循环的方式反复尝试读写文件描述符, 这个过程称为轮询. 这对CPU来说是较大的浪费, 一般只有特定场景下才使用.
-
信号驱动IO: 当用户发出IO请求之后，内核会去查看数据是否就绪，内核将数据准备好的时候, 使用SIGIO信号通知应用程序进行IO操作
-
IO多路转接: 虽然从流程图上看起来和阻塞IO类似. 实际上最核心在于IO多路转接能够同时等待多个文件描述符的就绪状态.
-
异步IO: 当用户发出IO请求之后，进程立刻就可以开始去做其它的事，内核会将由内核在数据拷贝完成时, 通知应用程序(而信号驱动是告诉应用程序何时可以开始拷贝数据).，该也就说该进程完全不需要知道实际的整个IO操作是如何进行的，只需要先发起一个请求，当接收内核返回的成功信号时表示IO操作已经完成，可以直接去使用数据了。
小结
- 任何IO过程中, 都包含两个步骤. 第一是等待, 第二是拷贝. 而且在实际的应用场景中, 等待消耗的时间往
- 往都远远高于拷贝的时间. 让IO更高效, 最核心的办法就是让等待的时间尽量少.
二、高级IO重要概念
在这里, 我们要强调几个概念
2.1 同步通信 vs 异步通信(synchronous communication/ asynchronouscommunication)
同步和异步关注的是消息通信机制.
- 所谓同步，就是在发出一个调用时，在没有得到结果之前，该调用就不返回. 但是一旦调用返回，就得到返回值了; 换句话说，就是由调用者主动等待这个调用的结果
- 异步则是相反， 调用在发出之后，这个调用就直接返回了，所以没有返回结果; 换句话说，当一个异步过程调用发出后，调用者不会立刻得到结果; 而是在调用发出后， 被调用者通过状态、通知来通知调用者，或通过回调函数处理这个调用.
另外, 我们回忆在讲多进程多线程的时候, 也提到同步和互斥. 这里的同步通信和进程之间的同步是完全不想干的概念.
- 进程/线程同步也是进程/线程之间直接的制约关系
- 是为完成某种任务而建立的两个或多个线程，这个线程需要在某些位置上协调他们的工作次序而等待、传递信息所产生的制约关系. 尤其是在访问临界资源的时候
2.2 阻塞 vs 非阻塞
阻塞和非阻塞关注的是程序在等待调用结果（消息，返回值）时的状态
- 阻塞调用是指调用结果返回之前，当前线程会被挂起. 调用线程只有在得到结果之后才会返回.
- 非阻塞调用指在不能立刻得到结果之前，该调用不会阻塞当前线程
2.3 其他高级IO
非阻塞IO，纪录锁，系统V流机制， I/O多路转接（也叫I/O多路复用） ,readv和writev函数以及存储映射IO（mmap），这些统称为高级IO.
我们此处重点讨论的是I/O多路转接
2.4 非阻塞IO
fcntl
一个文件描述符, 默认都是阻塞IO.
传入的cmd的值不同, 后面追加的参数也不相同
fcntl函数有5种功能:- 复制一个现有的描述符（cmd=F_DUPFD） .
- 获得/设置文件描述符标记(cmd=F_GETFD或F_SETFD).
- 获得/设置文件状态标记(cmd=F_GETFL或F_SETFL).
- 获得/设置异步I/O所有权(cmd=F_GETOWN或F_SETOWN).
- 获得/设置记录锁(cmd=F_GETLK,F_SETLK或F_SETLKW)
我们此处只是用第三种功能, 获取/设置文件状态标记, 就可以将一个文件描述符设置为非阻塞.
实现函数SetNoBlock#include#include #include #include #include using namespace std; void SetNonBlock(int fd) { int fl = fcntl(fd, F_GETFL); if (fl < 0) { perror("tcntl"); return; } fcntl(fd, F_SETFL, fl | O_NONBLOCK); } int main() { SetNonBlock(0); // 非阻式等待 char buffer[100]; while (1) { ssize_t s = read(0, buffer, sizeof(buffer) - 1); if (s > 0) { buffer[s] = '\0'; std::cout << "read success!" << std::endl; write(1, buffer, strlen(buffer)); } else { // 区分是否是 if (errno == EAGAIN || errno == EWOULDBLOCK) { std::cerr << "read failed:数据没有准备好： " << errno << std::endl; sleep(1); continue; } } } return 0; } - 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
2.5 I/O多路转接之select
初识select
系统提供select函数来实现多路复用输入/输出模型.- select系统调用是用来让我们的程序监视多个文件描述符的状态变化的;
- 程序会停在select这里等待，直到被监视的文件描述符有一个或多个发生了状态改变，通知上层读取，没有读取和写入数据的功能;
select函数原型
参数解释:- 参数nfds是需要监视的最大的文件描述符值+1；
- rdset,wrset,exset分别对应于需要检测的可读文件描述符的集合，可写文件描述符的集 合及异常文件描述符的集合;
- 参数timeout为结构timeval，用来设置select()的等待时间
参数timeout取值:
- NULL：则表示select（）没有timeout， select将一直被阻塞，直到某个文件描述符上发生了事件;
- 0：仅检测描述符集合的状态，然后立即返回，并不等待外部事件的发生。
- 特定的时间值：如果在指定的时间段里没有事件发生， select将超时返回。
关于fd_set结构
其实这个结构就是一个整数数组, 更严格的说, 是一个 “位图”. 使用位图中对应的位来表示要监视的文件描述符
提供了一组操作fd_set的接口, 来比较方便的操作位图.void FD_CLR(int fd, fd_set *set); // 用来清除描述词组set中相关fd 的位 int FD_ISSET(int fd, fd_set *set); // 用来测试描述词组set中相关fd 的位是否为真 void FD_SET(int fd, fd_set *set); // 用来设置描述词组set中相关fd的位 void FD_ZERO(fd_set *set); // 用来清除描述词组set的全部位- 1
- 2
- 3
- 4
函数返回值：
- 执行成功则返回文件描述词状态已改变的个数
- 如果返回0代表在描述词状态改变前已超过timeout时间，没有返回
- 当有错误发生时则返回-1，错误原因存于errno，此时参数readfds， writefds, exceptfds和timeout的值变成不可预测。
错误值可能为：
- EBADF 文件描述词为无效的或该文件已关闭
- EINTR 此调用被信号所中断
- EINVAL 参数n 为负值。
- ENOMEM 核心内存不足
常见的程序片段如下:
fs_set readset； FD_SET(fd,&readset); select(fd+1,&readset,NULL,NULL,NULL); if(FD_ISSET(fd,readset)){……}- 1
- 2
- 3
- 4
理解select执行过程
理解select模型的关键在于理解fd_set,为说明方便，取fd_set长度为1字节， fd_set中的每一bit可以对应一个文件描述符fd。则1字节长的fd_set最大可以对应8个fd- （1） 执行fd_set set; FD_ZERO(&set);则set用位表示是0000,0000。
- （2）若fd＝ 5,执行FD_SET(fd,&set);后set变为0001,0000(第5位置为1)
- （3）若再加入fd＝ 2， fd=1,则set变为0001,0011
- （4）执行select(6,&set,0,0,0)阻塞等待
- （5）若fd=1,fd=2上都发生可读事件，则select返回，此时set变为0000,0011。注意：没有事件发生的fd=5被清空
socket就绪条件
读就绪- socket内核中, 接收缓冲区中的字节数, 大于等于低水位标记SO_RCVLOWAT. 此时可以无阻塞的读该文件
- 描述符, 并且返回值大于0;
- socket TCP通信中, 对端关闭连接, 此时对该socket读, 则返回0;
- 监听的socket上有新的连接请求;
- socket上有未处理的错误;
写就绪
- socket内核中, 发送缓冲区中的可用字节数(发送缓冲区的空闲位置大小), 大于等于低水位标记
- SO_SNDLOWAT, 此时可以无阻塞的写, 并且返回值大于0;
- socket的写操作被关闭(close或者shutdown). 对一个写操作被关闭的socket进行写操作, 会触发SIGPIPE信号;
- socket使用非阻塞connect连接成功或失败之后;
- socket上有未读取的错误;
异常就绪(选学)
- socket上收到带外数据. 关于带外数据, 和TCP紧急模式相关(回忆TCP协议头中, 有一个紧急指针的字段),同学们课后自己收集相关资料.
select的特点
- 可监控的文件描述符个数取决与sizeof(fd_set)的值. 我这边服务器上sizeof(fd_set)＝ 128，每bit表示一个文件描述符，则我服务器上支持的最大文件描述符是128*8=1024
- 将fd加入select监控集的同时，还要再使用一个数据结构array保存放到select监控集中的fd，
一是用于再select 返回后， array作为源数据和fd_set进行FD_ISSET判断。
二是select返回后会把以前加入的但并无事件发生的fd清空，则每次开始select前都要重新从array取得fd逐一加入(FD_ZERO最先)，扫描array的同时取得fd最大值maxfd，用于select的第一个参数。
备注: fd_set的大小可以调整，可能涉及到重新编译内核. 感兴趣的同学可以自己去收集相关资料.
select缺点
- 每次调用select, 都需要手动设置fd集合, 从接口使用角度来说也非常不便.
- 每次调用select，都需要把fd集合从用户态拷贝到内核态，这个开销在fd很多时会很大
- 同时每次调用select都需要在内核遍历传递进来的所有fd，这个开销在fd很多时也很大
- select支持的文件描述符数量太小
样例：
#include#include #include #include #include #include "Sock.hpp" #define NUM (sizeof(fd_set) * 8) int fd_array[NUM]; // 内容>=0, 合法的fd,如果是-1，该位置没有fd void Usage(std::string proc) { std::cout << "Usage\n\t" << proc << " port" << std::endl; } // ./SelectServer 8080 int main(int argc, char *argv[]) { // std::cout << sizeof(fd_set) * 8 << std::endl;// fd_set的大小 if (argc != 2) { Usage(argv[0]); exit(1); } int listen_sock = Sock::Socket(); uint16_t port = static_cast<uint16_t>(atoi(argv[1])); Sock::Bind(listen_sock, port); Sock::Listen(listen_sock); // accept: 不应该，accept的本质叫做通过listen_sock获取新链接 // 前提是listen_sock上面有新链接，accept怎么知道有新链接呢？？ // 不知道！！！accept阻塞式等待 // 站在多路转接的视角，我们认为，链接到来，对于listen_sock,就是读事件就绪！！！ // 对于所有的服务器，最开始的时候，只有listen_sock // 事件循环 fd_set fds; for (int i = 1; i < NUM; ++i) { fd_array[i] = -1; } fd_array[0] = listen_sock; int max_fd = listen_sock; for (;;) { FD_ZERO(&fds); //将位图全部清零 for (int i = 0; i < NUM; ++i) { // 用户告诉内核，你要帮我关心哪些fd上的读事件已经就绪 if (fd_array[i] == -1) continue; FD_SET(fd_array[i], &fds); if (fd_array[i] > max_fd) { max_fd = fd_array[i]; } } struct timeval timeout = {5, 0}; // int n = select(max_fd + 1, &fds, nullptr, nullptr, &timeout); int n = select(max_fd + 1, &fds, nullptr, nullptr, nullptr); // 阻塞式等待多个文件描述符,等待链接 switch (n) { case -1: std::cerr << "select failed!" << std::endl; break; // 时间超出 case 0: std::cout << "select timeout" << std::endl; break; default: std::cout << "select success, 有对应的fd已经就绪了" << std::endl; // 查找哪些fd就绪了 for (int i = 0; i < NUM; ++i) { // for 1 if (fd_array[i] == -1) continue; // 判断是否是合法的fd else if (FD_ISSET(fd_array[i], &fds)) { if (fd_array[i] == listen_sock) { std::cout << "listen_sock:" << listen_sock << " 正在获取新链接" << std::endl; int new_sock = Sock::Accept(listen_sock); // 获取成功 // recv,read了呢？绝对不能！ // 新链接到来，不意味着有数据到来！！什么时候数据到来呢?不知道 // 可是，谁可以最清楚的知道那些fd，上面可以读取了？select！ // 无法直接将fd设置进select，但是，好在我们有fd_array[]! if (new_sock >= 0) { std::cout << "listen_sock:" << listen_sock << " 获取新链接成功 new_sock:" << new_sock << std::endl; int pos = 1; // 将合法的fd设置进fd_array数组 for (; pos < NUM; pos++) { if (fd_array[pos] == -1) break; } if (pos < NUM) { // 成功找到了一个位置 std::cout << "新链接new_sock:" << new_sock << "已经被添加到fd_array[" << pos << "]中" << std::endl; fd_array[pos] = new_sock; } else { std::cout << "服务器已满,关闭套接字" << std::endl; close(new_sock); } } } else { //正常读取 // 普通的sock，读事件就绪啦！ // 可以进行读取啦，recv，read // 可是，本次读取就一定能读完吗？读完，就一定没有所谓的数据包粘包问题吗？ // 但是，我们今天没法解决！我们今天没有场景！仅仅用来测试 std::cout << "new_sock: " << fd_array[i] << " 上面有普通读取" << std::endl; char recvbuffer[1024]; ssize_t s = read(fd_array[i], recvbuffer, sizeof(recvbuffer)); if (s > 0) { recvbuffer[s] = '\0'; std::cout << "client " << fd_array[i] << " " << recvbuffer << std::endl; } else if (s == 0) { std::cout << "client已经关闭,服务端关闭new_sock" << std::endl; close(fd_array[i]); fd_array[i] = -1; } else { std::cout << "读取失败,服务端关闭new_sock" << std::endl; close(fd_array[i]); fd_array[i] = -1; } } } } // end of for 1 break; } } return 0; } - 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
- 100
- 101
- 102
- 103
- 104
- 105
- 106
- 107
- 108
- 109
- 110
- 111
- 112
- 113
- 114
- 115
- 116
- 117
- 118
- 119
- 120
- 121
- 122
- 123
- 124
- 125
- 126
- 127
- 128
- 129
- 130
- 131
- 132
- 133
- 134
- 135
- 136
- 137
- 138
- 139
- 140
- 141
- 142
- 143
- 144
- 145
- 146
- 147
- 148
- 149
2.6 I/O多路转接之poll [选学]
poll函数接口
参数说明- fds是一个poll函数监听的结构列表. 每一个元素中, 包含了三部分内容: 文件描述符, 监听的事件集合, 返回的事件集合.
- nfds表示fds数组的长度.
- timeout表示poll函数的超时时间, 单位是毫秒(ms).
events和revents的取值:
返回结果- 返回值小于0, 表示出错;
- 返回值等于0, 表示poll函数等待超时;
- 返回值大于0, 表示poll由于监听的文件描述符就绪而返回
poll的优点
不同与select使用三个位图来表示三个fdset的方式， poll使用一个pollfd的指针实现.- pollfd结构包含了要监视的event和发生的event，不再使用select“参数-值”传递的方式. 接口使用比select更方便.
- poll并没有最大数量限制 (但是数量过大后性能也是会下降).
poll的缺点
poll中监听的文件描述符数目增多时- 和select函数一样， poll返回后，需要轮询pollfd来获取就绪的描述符.
- 每次调用poll都需要把大量的pollfd结构从用户态拷贝到内核中.
- 同时连接的大量客户端在一时刻可能只有很少的处于就绪状态, 因此随着监视的描述符数量的增长, 其效率也会线性下降
poll示例:
#include#include #include #include int main() { struct pollfd fds; fds.fd = 0; fds.events = POLLIN; fds.revents = 0;//标准输入 int timeout = 1000; // timeout -1 阻塞式等待，0非阻塞式等待 for (;;) { int n = poll(&fds, 1, -1); switch (n) { case -1: std::cerr << "poll error" << std::endl; break; case 0: std::cout << "poll timeout..." << std::endl; break; default: std::cout << "有事件发生" << std::endl; if(fds.revents & POLLIN) { std::cout << fds.fd << "上面的读事件发生了" << std::endl; char buffer[128]; ssize_t s = read(fds.fd, buffer, sizeof(buffer)); if(s > 0) { buffer[s] = '\0'; write(1, buffer, strlen(buffer)); } } break; } } return 0; } - 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
2.7 I/O多路转接之epoll
epoll初识
按照man手册的说法: 是为处理大批量句柄而作了改进的poll.
它是在2.5.44内核中被引进的(epoll(4) is a new API introduced in Linux kernel 2.5.44)
它几乎具备了之前所说的一切优点，被公认为Linux2.6下性能最好的多路I/O就绪通知方法epoll的相关系统调用
epoll 有3个相关的系统调用epoll_create
创建一个epoll的句柄- 自从linux2.6.8之后， size参数是被忽略的.
- 用完之后, 必须调用close()关闭
epoll_ctl
epoll的事件注册函数- 它不同于select()是在监听事件时告诉内核要监听什么类型的事件, 而是在这里先注册要监听的事件类型.
- 第一个参数是epoll_create()的返回值(epoll的句柄).
- 第二个参数表示动作，用三个宏来表示.
- 第三个参数是需要监听的fd.
- 第四个参数是告诉内核需要监听什么事
第二个参数的取值:
- EPOLL_CTL_ADD ：注册新的fd到epfd中；
- EPOLL_CTL_MOD ：修改已经注册的fd的监听事件；
- EPOLL_CTL_DEL ：从epfd中删除一个fd；
struct epoll_event结构如下:
events可以是以下几个宏的集合：- EPOLLIN : 表示对应的文件描述符可以读 (包括对端SOCKET正常关闭);
- EPOLLOUT : 表示对应的文件描述符可以写;
- EPOLLPRI : 表示对应的文件描述符有紧急的数据可读 (这里应该表示有带外数据到来);
- EPOLLERR : 表示对应的文件描述符发生错误;
- EPOLLHUP : 表示对应的文件描述符被挂断;
- EPOLLET : 将EPOLL设为边缘触发(Edge Triggered)模式, 这是相对于水平触发(Level Triggered)来说的.
- EPOLLONESHOT：只监听一次事件, 当监听完这次事件之后, 如果还需要继续监听这个socket的话, 需要再次把这个socket加入到EPOLL队列里
epoll_wait
收集在epoll监控的事件中已经发送的事件- 参数events是分配好的epoll_event结构体数组.
- epoll将会把发生的事件赋值到events数组中 (events不可以是空指针，内核只负责把数据复制到这个events数组中，不会去帮助我们在用户态中分配内存).
- maxevents告之内核这个events有多大，这个 maxevents的值不能大于创建epoll_create()时的size.
- 参数timeout是超时时间 (毫秒， 0会立即返回， -1是永久阻塞).
- 如果函数调用成功，返回对应I/O上已准备好的文件描述符数目，如返回0表示已超时, 返回小于0表示函数失败
epoll工作原理
- 当某一进程调用epoll_create方法时， Linux内核会创建一个eventpoll结构体，这个结构体中有两个成员与epoll的使用方式密切相关
struct eventpoll{ .... /*红黑树的根节点，这颗树中存储着所有添加到epoll中的需要监控的事件*/ struct rb_root rbr; /*双链表中则存放着将要通过epoll_wait返回给用户的满足条件的事件*/ struct list_head rdlist; .... };- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 每一个epoll对象都有一个独立的eventpoll结构体，用于存放通过epoll_ctl方法向epoll对象中添加进来的事件.
- 这些事件都会挂载在红黑树中，如此，重复添加的事件就可以通过红黑树而高效的识别出来(红黑树的插入时间效率是lgn，其中n为树的高度).
- 而所有添加到epoll中的事件都会与设备(网卡)驱动程序建立回调关系，也就是说，当响应的事件发生时会调用这个回调方法.
- 这个回调方法在内核中叫ep_poll_callback,它会将发生的事件添加到rdlist双链表中.
- 在epoll中，对于每一个事件，都会建立一个epitem结构体
struct epitem{ struct rb_node rbn;//红黑树节点 struct list_head rdllink;//双向链表节点 struct epoll_filefd ffd; //事件句柄信息 struct eventpoll *ep; //指向其所属的eventpoll对象 struct epoll_event event; //期待发生的事件类型 }- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 当调用epoll_wait检查是否有事件发生时，只需要检查eventpoll对象中的rdlist双链表中是否有epitem元素即可.
- 如果rdlist不为空，则把发生的事件复制到用户态，同时将事件数量返回给用户. 这个操作的时间复杂度是O(1).
总结一下, epoll的使用过程就是三部曲:
- 调用epoll_create创建一个epoll句柄;
- 调用epoll_ctl, 将要监控的文件描述符进行注册;
- 调用epoll_wait, 等待文件描述符就绪;
epoll的优点(和 select 的缺点对应)
- 接口使用方便: 虽然拆分成了三个函数, 但是反而使用起来更方便高效. 不需要每次循环都设置关注的文件描述符, 也做到了输入输出参数分离开
- 数据拷贝轻量: 只在合适的时候调用 EPOLL_CTL_ADD 将文件描述符结构拷贝到内核中, 这个操作并不频繁(而select/poll都是每次循环都要进行拷贝)
- 事件回调机制: 避免使用遍历, 而是使用回调函数的方式, 将就绪的文件描述符结构加入到就绪队列中,epoll_wait 返回直接访问就绪队列就知道哪些文件描述符就绪. 这个操作时间复杂度O(1). 即使文件描述符数目很多, 效率也不会受到影响.
- 没有数量限制: 文件描述符数目无上限
注意!!
网上有些博客说, epoll中使用了内存映射机制- 内存映射机制: 内核直接将就绪队列通过mmap的方式映射到用户态. 避免了拷贝内存这样的额外性能开销
这种说法是不准确的. 我们定义的struct epoll_event是我们在用户空间中分配好的内存. 势必还是需要将内核的数据拷贝到这个用户空间的内存中的.
请同学们对比总结select, poll, epoll之间的优点和缺点(重要, 面试中常见).
样例：
#include#include #include #include #include #include #include "Sock.hpp" #define NUM 128 #define SIZE 64 // epoll_server.cc 8080 void Usage(std::string proc) { std::cout << "Usage:\n\t" << proc << " port" << std::endl; } int main(int argc, char *argv[]) { if (argc != 2) { Usage(argv[0]); return 1; } // 创建套接字，等待链接 uint16_t port = static_cast<uint16_t>(atoi(argv[1])); int listen_sock = Sock::Socket(); Sock::Bind(listen_sock, port); Sock::Listen(listen_sock); // 创建epoll的句柄 int epfd = epoll_create(NUM); // epoll的事件注册 struct epoll_event ev; ev.events = EPOLLIN; ev.data.fd = listen_sock; epoll_ctl(epfd, EPOLL_CTL_ADD, listen_sock, &ev); // 事件循环 struct epoll_event revs[SIZE]; while (true) { // 收集在epoll监控的事件中已经发送的事件 int timeout = 1000; int n = epoll_wait(epfd, revs, SIZE, -1); switch (n) { case -1: std::cerr << "epoll error" << std::endl; break; case 0: std::cerr << "epoll timeout..." << std::endl; break; default: std::cout << "事件就绪了" << std::endl; for (int i = 0; i < n; ++i) { // 获取已经准备好的 sock int sock = revs[i].data.fd; std::cout << "文件描述符: " << sock << " 就绪啦" << std::endl; if (revs[i].events & EPOLLIN) { std::cout << "文件描述符" << sock << " 上面有事件就绪了" << std::endl; if (sock == listen_sock) { int newSock = Sock::Accept(sock); if (newSock >= 0) { std::cout << "获取信新链接成功了" << newSock << std::endl; // epoll的事件注册,将new_sock添加到epoll模型当中 struct epoll_event _ev; _ev.events = EPOLLIN; _ev.data.fd = newSock; epoll_ctl(epfd, EPOLL_CTL_ADD, newSock, &_ev); } // 普通读取 else { //do nothing } } else { // 进行普通读取 char buffer[1024]; ssize_t s = read(sock, buffer, sizeof(buffer)-1); if(s < 0) { std::cerr << "read failed!" << std::endl; close(sock); epoll_ctl(epfd, EPOLL_CTL_DEL, sock, nullptr); std::cout << "sock: " << sock << "delete from epoll success" << std::endl; } else if(s == 0) { std::cout << "对端关闭了链接" << std::endl; close(sock); epoll_ctl(epfd, EPOLL_CTL_DEL, sock, nullptr); std::cout << "sock: " << sock << "delete from epoll success" << std::endl; } else { buffer[s] = '\0'; std::cout << "client #" << buffer << std::endl; } } } else if (revs[i].events & EPOLLOUT) { } } break; } } close(listen_sock); close(epfd); return 0; } - 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
- 100
- 101
- 102
- 103
- 104
- 105
- 106
- 107
- 108
- 109
- 110
- 111
- 112
- 113
- 114
- 115
- 116
- 117
- 118
- 119
epoll工作方式
epoll有2种工作方式-水平触发(LT)和边缘触发(ET)
假如有这样一个例子:- 我们已经把一个tcp socket添加到epoll描述符
- 这个时候socket的另一端被写入了2KB的数据
- 调用epoll_wait，并且它会返回. 说明它已经准备好读取操作
- 然后调用read, 只读取了1KB的数据
- 继续调用epoll_wait…
水平触发Level Triggered 工作模式
epoll默认状态下就是LT工作模式.- 当epoll检测到socket上事件就绪的时候, 可以不立刻进行处理. 或者只处理一部分.
- 如上面的例子, 由于只读了1K数据, 缓冲区中还剩1K数据, 在第二次调用 epoll_wait 时, epoll_wait
- 仍然会立刻返回并通知socket读事件就绪.
- 直到缓冲区上所有的数据都被处理完, epoll_wait 才不会立刻返回.
- 支持阻塞读写和非阻塞读写
边缘触发Edge Triggered工作模式
如果我们在第1步将socket添加到epoll描述符的时候使用了EPOLLET标志, epoll进入ET工作模式- 当epoll检测到socket上事件就绪时, 必须立刻处理.
- 如上面的例子, 虽然只读了1K的数据, 缓冲区还剩1K的数据, 在第二次调用 epoll_wait 的时候,
epoll_wait 不会再返回了. - 也就是说, ET模式下, 文件描述符上的事件就绪后, 只有一次处理机会.
- ET的性能比LT性能更高( epoll_wait 返回的次数少了很多). Nginx默认采用ET模式使用epoll.
只支持非阻塞的读写
select和poll其实也是工作在LT模式下. epoll既可以支持LT, 也可以支持ET
对比LT和ET
LT是 epoll 的默认行为. 使用 ET 能够减少 epoll 触发的次数. 但是代价就是强逼着程序猿一次响应就绪过程中就把所有的数据都处理完.相当于一个文件描述符就绪之后, 不会反复被提示就绪, 看起来就比 LT 更高效一些. 但是在 LT 情况下如果也能做到每次就绪的文件描述符都立刻处理, 不让这个就绪被重复提示的话, 其实性能也是一样的.
另一方面, ET 的代码复杂程度更高了
理解ET模式和非阻塞文件描述符
使用 ET 模式的 epoll, 需要将文件描述设置为非阻塞. 这个不是接口上的要求, 而是 “工程实践” 上的要求.假设这样的场景: 服务器接受到一个10k的请求, 会向客户端返回一个应答数据. 如果客户端收不到应答, 不会发送第二个10k请求.
如果服务端写的代码是阻塞式的read, 并且一次只 read 1k 数据的话(read不能保证一次就把所有的数据都读出来,参考 man 手册的说明, 可能被信号打断), 剩下的9k数据就会待在缓冲区中
此时由于 epoll 是ET模式, 并不会认为文件描述符读就绪. epoll_wait 就不会再次返回. 剩下的 9k 数据会一直在缓冲区中. 直到下一次客户端再给服务器写数据. epoll_wait 才能返回但是问题来了.
- 服务器只读到1k个数据, 要10k读完才会给客户端返回响应数据.
- 客户端要读到服务器的响应, 才会发送下一个请求
- 客户端发送了下一个请求, epoll_wait 才会返回, 才能去读缓冲区中剩余的数据
所以, 为了解决上述问题(阻塞read不一定能一下把完整的请求读完), 于是就可以使用非阻塞轮训的方式来读缓冲区,保证一定能把完整的请求都读出来
而如果是LT没这个问题. 只要缓冲区中的数据没读完, 就能够让 epoll_wait 返回文件描述符读就绪.
epoll的高性能, 是有一定的特定场景的. 如果场景选择的不适宜, epoll的性能可能适得其反
- 对于多连接, 且多连接中只有一部分连接比较活跃时, 比较适合使用epoll.
-
-
相关阅读:
Vue之transition组件
高通导航器软件开发包使用指南（6）
C++零碎记录（十四）
Java Design Patterns 之API 网关模式
Browserslist 信息和配置使用整理
极客君的人生咨询
阿里云ack集群升级流程
自学成为一名黑客（自学笔记）
C++实现轻量级RPC分布式网络通信框架
516 最长回文子序列（区间DP）（灵神笔记）
- 原文地址：https://blog.csdn.net/qq_52809807/article/details/126372264
