https://blog.csdn.net/majianfei1023/article/details/45788591
epoll除了提供select/poll那种IO事件的电平触发 （Level Triggered）外，还提供了边沿触发（Edge Triggered）
”可读事件"表示有数据到来，"可写事件"表示内核缓冲区有剩余发送空间，“错误事件“表示socket发生了一些网络错误。
socket可读可写条件，经常做为面试题被问，因为它考察被面试者对网络编程的基础了解的是不是够深入。
要了解socket可读可写条件，我们先了解几个概念：
1.接收缓存区低水位标记（用于读）和发送缓存区低水位标记（用于写）：
每个套接字有一个接收低水位和一个发送低水位。他们由select函数使用。
接收低水位标记是让select返回"可读"时套接字接收缓冲区中所需的数据量。对于TCP,其默认值为1。 【已用空间超过低水平位，可读】
发送低水位标记是让select返回"可写"时套接字发送缓冲区中所需的可用空间。对于TCP，其默认值常为2048. 【剩余空间的大小超过低水平位，可写】
通俗的解释一下，缓存区我们当成一个大小为 n bytes的空间，那么：
接收区缓存的作用就是，接收对面的数据放在缓存区，供应用程序读。当然了，只有当缓存区可读的数据量(接收低水位标记)到达一定程度（eg:1）的时候，我们才能读到数据，不然不就读不到数据了吗。
发送区缓存的作用就是，发送应用程序的数据到缓存区，然后一起发给对面。当然了，只有当缓存区剩余一定空间(发送低水位标记)（eg:2048）,你才能写数据进去，不然可能导致空间不够。
2.FIN: (结束标志,Finish)用来结束一个TCP回话.但对应端口仍处于开放状态,准备接收后续数据.
- 首先来看看socket可读的条件.
一、下列四个条件中的任何一个满足时,socket准备好读:
1. socket的接收缓冲区中的【已用】数据字节大于等于该socket的接收缓冲区低水位标记的当前大小。对这样的socket的读操作将不阻塞并返回一个大于0的值(也就是返回准备好读入的数据)。我们可以用SO_RCVLOWAT socket选项来设置该socket的低水位标记。对于TCP和UDP .socket而言，其缺省值为1.
2. 该连接的读这一半关闭(也就是接收了FIN的TCP连接)。对这样的socket的读操作将不阻塞并返回0
3.socket是一个用于监听的socket,并且已经完成的连接数为非0.这样的soocket处于可读状态,是因为socket收到了对方的connect请求,执行了三次握手的第一步:对方发送SYN请求过来,使监听socket处于可读状态;正常情况下,这样的socket上的accept操作不会阻塞;
4.有一个socket有异常错误条件待处理.对于这样的socket的读操作将不会阻塞,并且返回一个错误(-1),errno则设置成明确的错误条件.这些待处理的错误也可通过指定socket选项SO_ERROR调用getsockopt来取得并清除;
- 再来看看socket可写的条件.
二、下列三个条件中的任何一个满足时,socket准备好写:
1. socket的发送缓冲区中的【剩余】数据字节大于等于该socket的发送缓冲区低水位标记的当前大小。对这样的socket的写操作将不阻塞并返回一个大于0的值(也就是返回准备好写入的数据)。我们可以用SO_SNDLOWAT socket选项来设置该socket的低水位标记。对于TCP和UDP socket而言，其缺省值为2048
2. 该连接的写这一半关闭。对这样的socket的写操作将产生SIGPIPE信号，该信号的缺省行为是终止进程。
3.有一个socket异常错误条件待处理.对于这样的socket的写操作将不会阻塞并且返回一个错误(-1),errno则设置成明确的错误条件.这些待处理的错误也可以通过指定socket选项SO_ERROR调用getsockopt函数来取得并清除;
解释一下连接的读/写这一半关闭：
如图：
终止一个连接需要4个分节，主动关闭的一端（A）调用close发送FIN到另一端（B），B接收到FIN后，知道A已经主动关闭了，也就是，A不会发数据来了，那么这一端调用read必然可读，且返回0(read returns 0).
---------------------
https://www.cnblogs.com/my_life/articles/5320230.html
根据圣经《UNIX网络编程卷1》，当如下任一情况发生时，会产生套接字的可读事件：
- 该套接字的接收缓冲区中的数据字节数大于等于套接字接收缓冲区低水位标记的大小；
- 该套接字的读半部关闭（也就是收到了FIN），对这样的套接字的读操作将返回0（也就是返回EOF）；
- 该套接字是一个监听套接字且已完成的连接数不为0；
- 该套接字有错误待处理，对这样的套接字的读操作将返回-1。
当如下任一情况发生时，会产生套接字的可写事件：
- 该套接字的发送缓冲区中的可用空间字节数大于等于套接字发送缓冲区低水位标记的大小；
- 该套接字的写半部关闭，继续写会产生SIGPIPE信号；
- 非阻塞模式下，connect返回之后，该套接字连接成功或失败；
- 该套接字有错误待处理，对这样的套接字的写操作将返回-1。
-----------------------
https://www.cnblogs.com/my_life/articles/5382399.html
LT模式的特点是：
- 若数据可读，epoll返回可读事件
- 若开发者没有把数据完全读完，epoll会不断通知数据可读，直到数据全部被读取。
- 若socket可写，epoll返回可写事件，而且是只要socket发送缓冲区未满，就一直通知可写事件。
- 优点是对于read操作比较简单，只要有read事件就读，读多读少都可以。
- 缺点是write相关操作较复杂，由于socket在空闲状态时发送缓冲区一定是不满的，故若socket一直在epoll wait列表中，则epoll会一直通知write事件，所以必须保证没有数据要发送的时候，要把socket的write事件从epoll wait列表中删除。而在需要的时候在加入回去，这就是LT模式的最复杂部分。
ET模式的特点是：
- 若socket可读，返回可读事件
- 若开发者没有把所有数据读取完毕，epoll不会再次通知epoll read事件，也就是说存在一种隐患，如果开发者在读到可读事件时，如果没有全部读取所有数据，那么可能导致epoll在也不会通知该socket的read事件。（其实这个问题并没有听上去难，参见下文）。
- 若发送缓冲区未满，epoll通知write事件，直到开发者填满发送缓冲区，epoll才会在下次发送缓冲区由满变成未满时通知write事件。 【应该：剩余可写缓冲区的大小高于低水平位时，通知可写】
- ET模式下，只有socket的状态发生变化时才会通知，也就是读取缓冲区由无数据到有数据时通知read事件，发送缓冲区由满变成未满通知write事件。
- 缺点是epoll read事件触发时，必须保证socket的读取缓冲区数据全部读完（事实上这个要求很容易达到）
- 优点：对于write事件，发送缓冲区由满到未满时才会通知【不会一直通知】，若无数据可写，忽略该事件，若有数据可写，直接写。Socket的write事件可以一直放在epoll的wait列表。Man epoll中我们知道，当向socket写数据，返回的值小于传入的buffer大小或者write系统调用返回EWouldBlock时，表示发送缓冲区已满。
让我们换一个角度来理解ET模式，事实上，epoll的ET模式其实就是socket io完全状态机。
需要读者注意的是，socket模式是可写的，因为发送缓冲区初始时空的。故应用层有数据要发送时，直接调用write系统调用发送数据，若write系统调用返回EWouldBlock则表示socket变为不可写，或者write系统调用返回的数值小于传入的buffer参数的大小，这时需要把未发送的数据暂存在应用层待发送列表中，等待epoll返回write事件，再继续发送应用层待发送列表中的数据，同样若应用层待发送列表中的数据没有一次性发完，那么继续等待epoll返回write事件，如此循环往复。
所以可以反推得到如下结论，若应用层待发送列表有数据，则该socket一定是不可写状态，那么这时候要发送新数据直接追加到待发送列表中。若待发送列表为空，则表示socket为可写状态，则可以直接调用write系统调用发送数据。
总结如下：
- 当发送数据时，若应用层待发送列表有数据，则将要发送的数据追加到待发送列表中。否则直接调用write系统调用。
- Write系统调用发送数据时，检测write返回值，若返回数值>0且小于传入的buffer参数大小，或返回EWouldBlock错误码，表示，发送缓冲区已满，将未发送的数据追加到待发送列表
- Epoll返回write事件后，检测待发送列表是否有数据，若有数据，依次尝试发送直到数据全部发送完毕或者发送缓冲区被填满。
总结
LT模式主要是读操作比较简单，但是对于ET模式并没有优势，因为将读取缓冲区数据全部读出并不是难事。而write操作，ET模式则流程非常的清晰，按照完全状态机来理解和实现就变得非常容易。而LT模式的write操作则复杂多了，要频繁的维护epoll的wail列表。
在代码编写时，把epoll ET当成状态机，当socket被创建完成（accept和connect系统调用返回的socket）时加入到epoll列表，之后就不用在从中删除了。为什么呢？man epoll中的FAQ告诉我们，当socket被close掉后，其自动从epoll中删除。对于监听socket简单说几点注意事项：
- 监听socket的write事件忽略
- 监听socket的read事件表示有新连接，调用accept接受连接，直到返回EWouldBlock。
- 对于Error事件，有些错误是可以接受的错误，比如文件描述符用光的错误
GitHub ：https://github.com/fanchy/FFRPC
ffrpc 介绍: http://www.cnblogs.com/zhiranok/p/ffrpc_summary.html
故，综上所述，服务器程序中推荐使用epoll 的ET 模式！！！！
http://www.cnblogs.com/yuuyuu/p/5103744.html
对于监听的socket文件描述符我们用sockfd表示，对于accept()返回的文件描述符(即要读写的文件描述符)用connfd表示。
五.总结
1.对于监听的sockfd，最好使用水平触发模式，边缘触发模式会导致高并发情况下，有的客户端会连接不上。如果非要使用边缘触发，网上有的方案是用while来循环accept()。
2.对于读写的connfd，水平触发模式下，阻塞和非阻塞效果都一样，不过为了防止特殊情况，还是建议设置非阻塞。
3.对于读写的connfd，边缘触发模式下，必须使用非阻塞IO，并要一次性全部读写完数据(用while来循环读)。
https://www.cnblogs.com/my_life/articles/4727771.html
epoll的工作方式
epoll分为两种工作方式LT和ET。
LT(level triggered) 是默认/缺省的工作方式，同时支持 block和no_block socket。这种工作方式下，内核会通知你一个fd是否就绪，然后才可以对这个就绪的fd进行I/O操作。就算你没有任何操作，系统还是会继续提示fd已经就绪，不过这种工作方式出错会比较小，传统的select/poll就是这种工作方式的代表。
ET(edge-triggered) 是高速工作方式，仅支持no_block socket，这种工作方式下，当fd从未就绪变为就绪时，内核会通知fd已经就绪，并且内核认为你知道该fd已经就绪，不会再次通知了，除非因为某些操作导致fd就绪状态发生变化。如果一直不对这个fd进行I/O操作，导致fd变为未就绪时，内核同样不会发送更多的通知，因为only once。所以这种方式下，出错率比较高，需要增加一些检测程序。
https://www.cnblogs.com/my_life/articles/5315364.html
对每一网络连接均需要维持其接收与发送数据缓冲区，当连接可读取时则先读取数据到接收缓冲区，然后判断是否完整并处理之；
当向连接发送数据时一般都直接发送，若不能立即完整发送时则将其缓存到发送缓冲区，然后等连接可写时再发送，但需要注意的是，若在可写缓冲区非空且可写之前需要发送新数据，则此时不能直接发送而是应该将其追加到发送缓冲区后统一发送，否则会导致网络数据窜包。
https://www.zhihu.com/question/22840801
##水平触发模式（Level-Triggered）第一种方法
-
当需要向socket写数据时，将该socket加入到epoll模型（epoll_ctl）；等待可写事件。
-
接收到socket可写事件后，调用write()或send()发送数据。
-
当数据全部写完后， 将socket描述符移出epoll模型。
这种方式的缺点是： 即使发送很少的数据，也要将socket加入、移出epoll模型，有一定的操作代价。
##水平触发模式（Level-Triggered）第二种方法
-
向socket写数据时，不将socket加入到epoll模型；而是直接调用send()发送；
-
只有当或send()返回错误码EAGAIN（系统缓存满），才将socket加入到epoll模型，等待可写事件后，再发送数据。
-
全部数据发送完毕，再移出epoll模型。
这种方案的优点：当用户数据比较少时，不需要epool的事件处理。
在高压力的情况下，性能怎么样呢？
对一次性直接写成功、失败的次数进行统计。如果成功次数远大于失败的次数， 说明性能良好。（如果失败次数远大于成功的次数，则关闭这种直接写的操作，改用第一种方案。同时在日志里记录警告）
##第三种方法使用Edge-Triggered（边沿触发）
这样socket有可写事件，只会触发一次。
可以在应用层做好标记。以避免频繁的调用 epoll_ctl( EPOLL_CTL_ADD, EPOLL_CTL_MOD)。 这种方式是epoll 的 man 手册里推荐的方式， 性能最高。但如果处理不当容易出错，事件驱动停止。
=====
epoll的两种模式LT和ET
二者的差异在于level-trigger模式下只要某个socket处于readable/writable状态，无论什么时候进行epoll_wait都会返回该socket；
而edge-trigger模式下只有某个socket从unreadable变为readable或从unwritable变为writable时，epoll_wait才会返回该socket。
正确的accept，accept 要考虑 2 个问题
(1) 阻塞模式 accept 存在的问题
考虑这种情况：TCP连接被客户端夭折，即在服务器调用accept之前，客户端主动发送RST终止连接，导致刚刚建立的连接从就绪队列中移出，如果套接口被设置成阻塞模式，服务器就会一直阻塞在accept调用上，直到其他某个客户建立一个新的连接为止。但是在此期间，服务器单纯地阻塞在accept调用上，就绪队列中的其他描述符都得不到处理。
解决办法是把监听套接口设置为非阻塞，当客户在服务器调用accept之前中止某个连接时，accept调用可以立即返回-1，这时源自Berkeley的实现会在内核中处理该事件，并不会将该事件通知给epool，而其他实现把errno设置为ECONNABORTED或者EPROTO错误，我们应该忽略这两个错误。
(2)ET模式下accept存在的问题
考虑这种情况：多个连接同时到达，服务器的TCP就绪队列瞬间积累多个就绪连接，由于是边缘触发模式，epoll只会通知一次，accept只处理一个连接，导致TCP就绪队列中剩下的连接都得不到处理。
解决办法是用while循环抱住accept调用，处理完TCP就绪队列中的所有连接后再退出循环。如何知道是否处理完就绪队列中的所有连接呢？accept返回-1并且errno设置为EAGAIN就表示所有连接都处理完。
综合以上两种情况，服务器应该使用非阻塞地accept，accept在ET模式下的正确使用方式为：
| while ((conn_sock = accept(listenfd,(struct sockaddr *) &remote, (size_t *)&addrlen)) > 0) { |
| handle_client(conn_sock); |
| } |
| if (conn_sock == -1) { |
| if (errno != EAGAIN && errno != ECONNABORTED && errno != EPROTO && errno != EINTR) |
| perror("accept"); |
| } |
#include <sys/socket.h>
#include <sys/wait.h>
#include <netinet/in.h>
#include <netinet/tcp.h>
#include <sys/epoll.h>
#include <sys/sendfile.h>
#include <sys/stat.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <strings.h>
#include <fcntl.h>
#include <errno.h>
#define MAX_EVENTS 10
#define PORT 8080
//设置socket连接为非阻塞模式
void setnonblocking(int sockfd) {
int opts;
opts = fcntl(sockfd, F_GETFL);
if(opts < 0) {
perror("fcntl(F_GETFL)\n");
exit(1);
}
opts = (opts | O_NONBLOCK);
if(fcntl(sockfd, F_SETFL, opts) < 0) {
perror("fcntl(F_SETFL)\n");
exit(1);
}
}
int main(){
struct epoll_event ev, events[MAX_EVENTS];
int addrlen, listenfd, conn_sock, nfds, epfd, fd, i, nread, n;
struct sockaddr_in local, remote;
char buf[BUFSIZ];
//创建listen socket
if( (listenfd = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
perror("sockfd\n");
exit(1);
}
setnonblocking(listenfd);
bzero(&local, sizeof(local));
local.sin_family = AF_INET;
local.sin_addr.s_addr = htonl(INADDR_ANY);;
local.sin_port = htons(PORT);
if( bind(listenfd, (struct sockaddr *) &local, sizeof(local)) < 0) {
perror("bind\n");
exit(1);
}
listen(listenfd, 20);
epfd = epoll_create(MAX_EVENTS);
if (epfd == -1) {
perror("epoll_create");
exit(EXIT_FAILURE);
}
ev.events = EPOLLIN;
ev.data.fd = listenfd;
if (epoll_ctl(epfd, EPOLL_CTL_ADD, listenfd, &ev) == -1) {
perror("epoll_ctl: listen_sock");
exit(EXIT_FAILURE);
}
for (;;) {
nfds = epoll_wait(epfd, events, MAX_EVENTS, -1);
if (nfds == -1) {
perror("epoll_pwait");
exit(EXIT_FAILURE);
}
for (i = 0; i < nfds; ++i) {
fd = events[i].data.fd;
if (fd == listenfd) {
while ((conn_sock = accept(listenfd,(struct sockaddr *) &remote,
(size_t *)&addrlen)) > 0) {
setnonblocking(conn_sock);
ev.events = EPOLLIN | EPOLLET;
ev.data.fd = conn_sock;
if (epoll_ctl(epfd, EPOLL_CTL_ADD, conn_sock,
&ev) == -1) {
perror("epoll_ctl: add");
exit(EXIT_FAILURE);
}
}
if (conn_sock == -1) {
if (errno != EAGAIN && errno != ECONNABORTED
&& errno != EPROTO && errno != EINTR)
perror("accept");
}
continue;
}
if (events[i].events & EPOLLIN) {
n = 0;
while ((nread = read(fd, buf + n, BUFSIZ-1)) > 0) {
n += nread;
}
if (nread == -1 && errno != EAGAIN) {
perror("read error");
}
ev.data.fd = fd;
ev.events = events[i].events | EPOLLOUT;
if (epoll_ctl(epfd, EPOLL_CTL_MOD, fd, &ev) == -1) {
perror("epoll_ctl: mod");
}
}
if (events[i].events & EPOLLOUT) {
sprintf(buf, "HTTP/1.1 200 OK\r\nContent-Length: %d\r\n\r\nHello World", 11);
int nwrite, data_size = strlen(buf);
n = data_size;
while (n > 0) {
nwrite = write(fd, buf + data_size - n, n);
if (nwrite < n) {
if (nwrite == -1 && errno != EAGAIN) {
perror("write error");
}
break;
}
n -= nwrite;
}
close(fd);
}
}
}
return 0;
}