epoll

https://blog.csdn.net/dyx810601/article/details/79163848 https://www.cnblogs.com/zl-graduate/articles/6724446.html 再说一句，IO多路复用和NIO、BIO并没有太大关系，它只是实现了一个线程就可以监听大量连接请求。该线程监听连接请求有select、poll、epoll三种形式，最佳形式是epoll，前两者都需要不断轮训fd，查看是否就绪；而epoll则是采用事件驱动回调模式，当某个fd就绪后主动通知线程进行读取或写入。 来源： CSDN 作者： Kevin照墨 链接： https://blog.csdn.net/JustKian/article/details/104308587

直入正题 Epoll 用于Linux系统； IOCP 是用于 Windows； Epoll 是当事件资源满足时发出可处理通知消息； IOCP 则是当事件完成时发出完成通知消息。 从应用程序的角度来看， Epoll 本质上来讲是同步非阻塞的； IOCP 本质上来讲则是异步操作； 举例说明吧 有一个打印店，有一台打印机，好几个人在排队打印。 普通打印店，正常情况是： 1、你准备好你的文档，来到打印店。 2、排队，等别人打印完。 3、轮到你了，打印你的文档。 4、你取走文档，做后面的处理。 这种方式，你会浪费很多等待时间，非常低效。 于是就Linux和windows都提出了自己最优的模型。 Linux的epoll模型，则可以描述如下： 1、你准备好你的文档，来到打印店。 2、告诉店小二说，我先排队在这位置，轮到我了通知一声(假定你来回路上不耗时) 3、你先去忙你的事情去了 4、轮到你了，店小二通知你(假定你来回路上不耗时) 5、你获得打印机使用权了，开始打印 6、打印完了拿走。 你会发现，你节省了排队的时间，等到你能获得打印机资源的时候，告诉你来处理。 但是这里，就浪费了一点时间，就是你自己打印。 这就是epoll的同步费阻塞。 windows的IOCP模型，则可以描述如下： 1、你准备好你的文档，来到打印店。 2、告诉店小二说，我先排队，轮到我了帮打印下，好了通知我

常用配置项 在工作中，我们与 Nginx 打交道更多的是通过其配置文件来进行。那么掌握这些配置项各自的作用就很有必要了。 首先，nginx.conf 的内容通常是这样的： ... ... #核心摸块 events { #事件模块 ... } http { # http 模块 server { # server块 location [PATTERN] { # location块 ... } location [PATTERN] { ... } } server { ... } } mail { # mail 模块 server { # server块 ... } } 我们依次看一下每个模块一般有哪些配置项： 核心模块 user admin; #配置用户或者组。 worker_processes 4; #允许生成的进程数，默认为1 pid /nginx/pid/nginx.pid; #指定 nginx 进程运行文件存放地址 error_log log/error.log debug; #错误日志路径，级别。 事件模块 events { accept_mutex on; #设置网路连接序列化，防止惊群现象发生，默认为on multi_accept on; #设置一个进程是否同时接受多个网络连接，默认为off use epoll; #事件驱动模型select|poll|kqueue

为什么要使用epoll select不足 1.select需要从用户态将监听的集合拷贝给内核， 2.内核通过轮询的方式查找有事件的文件描述符并返回 3.且文件描述符有上限 4.没有直接告诉我们具体哪个fd有数据，导致需要遍历 Epoll函数就是解决select的不足的 从第一个函数看起int epoll_create(int size); 创建epoll函数 返回一个epoll对象 这个epoll对象其实也是个文件描述符，但是这个文件描述符的本质其实是一个二叉树，平衡二叉树，也就是红黑树左子树和右子树高度差小于1.这个函数调用成功将在内核中发生。 第二个函数int epoll_ctl(int epfd, int op, int fd, struct epoll_event event); 第一个参数epfd是那个红黑树文件描述符不必说了 第二个参数Int op代表的是对这个对象的各种操作增删改查 第三个参数指的是需要监听的套接字。 第四个参数则是结构体的指针 struct epoll_event { uint32_t events; / Epoll 事件 / 就是监听套接字的各种事件 读写连接等等 epoll_data_t data; / 用户数据 */ IP端口等等 }; 等待返回函数int epoll_wait(int epid, struct epoll_event

　　发现自己近一年有些毛病，自己也算是研习了不少的源代码，看了不少的技术书籍，但是自己就是记忆力不行，总是过段时间就会忘记，忘记之后还得从头开始啃源码、啃书籍。而且有些重要技术点也会遗忘，导致再学习的时候发现自己又回到了起点！我总结为，就是自己近一年期间犯懒，没有再写一下博客，技能点不能很好的再回顾！ 　　趁着发现自己的问题，同时自己也在做前后端 rpc分离实践，现在将之前研习netty的结果再总结出来，写到博客上！ 　　首先，我们要确定 java中的netty用来做什么的？具体的工作模式优势不解释，网上能找一大堆，主要讲它通信这块的rpc，高效稳定的协议栈绕不开 tcp/ip 协议！ 　　 本来是不想记录 tcp/ip的，这个实在是没有太多好说的，但是也发现虽然自己明白，有时候却也是会遗漏要点知识，所以也还是记录一下吧！ 　　似乎作为上层程序员只需要了解 tcp的握手与挥手情况即可！ 　　首先要了解 tcp/ip的头部结构 16位源端端口 | 16位目标端端口 32位序列号（发送端确认信息） 32位确认序号（服务端确认） 4位偏移量（每个数字表示1个4字节，所以最大表示15个4字节，也就是60字节）---- 6位保留位（记不太清了） | 标志位：包括 6种报文段 urg、ack、rst、syn、fin、psh 16位校验和 | 16位紧急指针 16位窗口大小

一、web请求处理机制 1.1 多进程方式 多进程方式: 服务器每接受到一个客户端请求就有服务器的 主进程 生成一个 子进程 响应客户端 ，直到用户关闭连接 优点：处理速度快，子进程之间相互独立 缺点： 访问过多会导致服务器资源耗尽而无法再提供请求 1.2 多线程方式 多线程方式： ：与多进程方式类似，但是每收到一个客户端请求会有 服务进程 派生出一个 线程 来和客户方进行交互。 优点： 一个线程的开销远远小于一个进程 ，因此减轻了web服务器对系统资源的要求 缺点：当多个线程位于同一个进程内工作的时候，可以相互访问同一的内存地址空间，所以 线程相互影响 ， 一旦主进程挂掉则所有子线程都不能工作 ，IIS服务器使用了多线程的方式，需要间隔一段时间就重启一次才能稳定。 1.3 异步 异步的方式：nginx的epoll，apache的event等 二、同步异步,阻塞非阻塞和Nginx的I/O模型 2.1 同步与异步(应用程序与内核的交互方式) 同步： 进程发出数据后，等内核返回响应以后才继续下一个请求，即如果内核一直不返回数据，那么进程就一直等，直到天荒地老，死机error。 异步： 进程发出数据后，不等内核返回响应，接着处理下一个请求,内核通过回调函数来处理进程。Nginx是异步的。 同步和异步关注的是消息通信机制 ，在同步机制中，所有的请求在服务器端得到同步

在c++网络编程中几乎都会使用epoll模式，epoll提供了两种触发模式ET(边缘触发)和LT(水平触发 默认的触发模式)。边缘触发就是当有可读事件之后如何一次没有读取完所有数据那么epoll不会在触发可读事件，只有再次从不可读变为可读才会再次触发可读，可写也是同样的道理。水平触发就是只要可读就会不断触发可读事件，只要可写就会不断触发可写事件。所以一般大并发服务器都会使用ET模式，这样比LT模式更高效（我在实际项目中验证过）。那在ET模式我们不可能对一个句柄进行无限次的读取，因为一个句柄读取过多可能导致其他句柄饿死，一般会在一次循环中读取10次或者20次等，那如果这个时候句柄依旧可读应该如何处理，因为本次不读完那么epoll的可读事件将不会在触发，其实可以简单的再次EPOLLMOD，这样在下次循环的时候将会再次触发可读事件。发送数据的处理方式是直接调用send函数发送，如果返回错误就将数据放入等待发送队列，下次触发可写事件在发送数据。这样的处理方式比较简单可直观，不用在句柄依旧可读和可写的情况下自己保存这些句柄。那通过EPOLLMOD是否会降低epoll的效率了，答案是不会，因为这种操作不会频繁的触发。我自己项目中一个进程中包含网关，数据库和逻辑处理也就是说只有一个进程的游戏服务器单服可以负载8000+的人，所以如果独立进程的网关这种处理1万并发应该是毫无压力的。 ps

1、事件渠道模型。事件渠道为异步IO的原型。 2、IO模式，一次IO调用会经历两个阶段。一、等待数据阶段，将数据从网络或者是磁盘读取到系统内核（kennel） 二、将数据从内核拷贝到进程中。 基于这两个阶段，linux系统下面产生了五种网络网络模式方案。 -阻塞I/O（blocking IO） -非阻塞I/O(nobokcing IO) - I/O多路复用。（I/O multiplexing） - 信号驱动 -异步I/O（async） 由于信号驱动使用较少，主要介绍其余四种模式。 3、阻塞I/O（blocking IO）在数据准备阶段和贝考数据阶段都会阻塞。用户调用recefrom 以后会一直等待数据拷贝到用户内存未至。 2、非阻塞I/O(nobokcing IO)，用户会一直调用recefrom，如果数据没有准备好。会返回一个ERROR。一直到数据准备好。因此在读数据阶段不会卡住。 3、epoll模式，也就是IO多路复用模式。一次性可以处理多个网络IO。调用select方法。首先会卡住。直到其中一个有数据就会立即返回。然后拷贝数据。然后进入下一个循环 4、异步IO，异步I/O不会阻塞。当用户进程发起read操作以后。可以立刻开始做其他的事情（相当于告诉在内核注册一个事件。由内核进行监控，处理完以后内核主动通知）。而另一方面从kennel角度看当他收到一个async read以后

1. Nginx的模块与工作原理 Nginx由内核和模块组成，其中，内核的设计非常微小和简洁，完成的工作也非常简单，仅仅通过查找配置文件将客户端请求映射到一个location block（location是Nginx配置中的一个指令，用于URL匹配），而在这个location中所配置的每个指令将会启动不同的模块去完成相应的工作。 Nginx的模块从结构上分为核心模块、基础模块和第三方模块： 核心模块：HTTP模块、EVENT模块和MAIL模块 基础模块：HTTP Access模块、HTTP FastCGI模块、HTTP Proxy模块和HTTP Rewrite模块， 第三方模块：HTTP Upstream Request Hash模块、Notice模块和HTTP Access Key模块。 用户根据自己的需要开发的模块都属于第三方模块。正是有了这么多模块的支撑，Nginx的功能才会如此强大。 Nginx的模块从功能上分为如下三类。 Handlers（处理器模块）。此类模块直接处理请求，并进行输出内容和修改headers信息等操作。Handlers处理器模块一般只能有一个。 Filters （过滤器模块）。此类模块主要对其他处理器模块输出的内容进行修改操作，最后由Nginx输出。 Proxies （代理类模块）。此类模块是Nginx的HTTP Upstream之类的模块

我们知道，服务器并发模型通常可分为单线程和多线程模型，这里的线程通常是指“I/O线程”，即负责I/O操作，协调分配任务的“管理线程”，而实际的请求和任务通常交由所谓“工作者线程”处理。通常多线程模型下，每个线程既是I/O线程又是工作者线程。所以这里讨论的是，单I/O线程+多工作者线程的模型，这也是最常用的一种服务器并发模型。我所在的项目中的server代码中，这种模型随处可见。它还有个名字，叫“半同步/半异步“模型，同时，这种模型也是生产者/消费者（尤其是多消费者）模型的一种表现。 这种架构主要是基于 I/O多路复用 的思想（主要是epoll，select/poll已过时），通过单线程I/O多路复用，可以达到高效并发，同时避免了多线程I/O来回切换的各种开销，思路清晰，易于管理，而基于线程池的多工作者线程，又可以充分发挥和利用多线程的优势，利用线程池，进一步提高资源复用性和避免产生过多线程。 瓶颈在于IO密集度 。 线程池你开10个线程当然可以一上来全部accept阻塞住，这样客户端一连上来便会自动激活一个线程去处理，但是设想一下，如果10个线程全部用掉了，第11个客户端就会发生丢弃。这样为了实现”高并发“你得不断加大线程池的数量。这样会带来严重的内存占用和线程切换的时延问题。 于是前置事件轮询设施的方案就应运而生了， 主线程轮询负责IO，作业交给线程池。 在高并发下