这篇文章主要是总结自己以前使用过的网络模型和服务器模型，和阅读过几个开源的实现怎么使用的，看到的文章[工作中不会经常写这些，都忘了差不多了]。介绍大概使用方法和原理，可能并不能与实际工作中的网络组件相媲美[哈哈]。
工作中自己是没有写过关于网络方面的程序，都是写业务逻辑方面，业务逻辑本身有一定的复杂度，不需要考虑消息的收发，连接的管理，是以消息驱动的形式处理的，模块间解耦。其实这些才是技术难点所在，大概实现是使用epoll实现的网络模型，收到的消息存在共享内存中，每个进程都关联两个消息队列，一个用于收消息，另一个用于发消息，使用无锁编程实现的，这个可以参考linux上的kfifo，还有连接/会话管理等等。
在开始之前需要先了解什么是阻塞和非阻塞，同步和异步。写过简单的网络程序或者使用api都会明白，要去做一件事情，比如应用层(用户态)read某个套接字，会切换到内核态，如果该套接字接收缓冲区有数据则返回，反正则被挂起等待事件发生，如果程序是单进程或某个线程发起的调用，那么会阻塞该进程或线程，不能干其他事情，效率就会降下来；如果是非阻塞，那么read时发现没有数据则立即返回一个错误码表示暂时没有数据，那么应用层可以暂时处理其他逻辑，但是还是要不断轮询数据是否可读，在非阻塞情况下效率会有明显提升。但数据是否可读还是要去询问，那么有没有办法不这样呢？那就是异步了，同步好理解，就是发出请求，在响应回来时只能干等，和阻塞的差不多，异步则是发出来请求，可以不等，然后响应回来后，以通知的形式告诉上层逻辑，有数据到了然后进行相应的逻辑处理。
这里仅列出自己常用的比较熟悉的网络I/O复用模型：select和epoll，原理是注册用户感兴趣的事件，比如套接字的可读和可写等，但他们本质上还是阻塞的，需要等待响应事件的到来。
int select(int nfds, fd_set * readfds, fd_set * writefds, fd_set * exceptfds, struct timeval * timeout)，对于的每个参数意义可以man 2 select，网上资料也有详细解释。
select的一些不足点：1)从select接口的原型得出文件描述符没有与具体的事件类型绑定，内核会对fd_set集合在线修改，使得下次调用时不得不重置这三个fd_set；2)每次select返回的是整个用户注册的事件集合，需要遍历每个描述符，判断哪些就绪，在活跃连接少的情况下，复杂度为O(N)；3)select可注册的文件描述符个数有上限；我的ubuntu系统上是1024个；4)select内部源码实现会每次准备时copy_from_user[用户态-->内核态]，就绪时copy_from_user[内核态-->用户态]，要拷贝fd_set集合，也是一笔开销；5)工作在相对低效的LT模式；
epoll三个函数原型：
int epoll_create(int size);
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout);
而epoll的出现解决了select的这些不足点：1)epoll将描述符和具体的事件类型绑定在一块，无需反复从用户态拷贝描述符到内核态；2)返回就绪的描述符，遍历到的都是有事件发生的，时间复杂度是O(1)；3)epoll可注册的文件描述符比select大很多，在我的系统上是188301；4)可以工作在高效的ET模式，当然也有LT模式[见下文]；
epoll为什么快？
一棵红黑树，用于“把socket放到epoll文件系统里file对象对应的红黑树上之外，向内核中断处理程序注册一个回调函数，告诉内核，如果这个句柄的中断到了，就把它放到就绪链表里；一个就绪链表；“当调用epoll_wait检查是否有事件发生时，只需要检查eventpoll对象中的链表中是否有epitem元素即可。如果rdlist不为空，则把发生的事件复制到用户态，同时将事件数量返回给用户”
epoll的两种工作模式ET/LT分析：
ET(edge trigger)边沿触发，当epoll_wait检测到有事件发生并通知应用程序后，如果不处理，那么后面就不会再通知该事件了。
LT(level trigger)水平触发，是epoll的默认工作模式，当epoll_wait检测到有事件发生并通知应用程序后，如果不处理或没有处理完，那么后面再epoll_wait时还会通知，直到该事件被处理。
“当一个socket句柄上有事件时，内核会把该句柄插入上面所说的准备就绪list链表，这时我们调用epoll_wait，会把准备就绪的socket拷贝到用户态内存，然后清空准备就绪list链表，最后，epoll_wait干了件事，就是检查这些socket，如果不是ET模式（就是LT模式的句柄了），并且这些socket上确实有未处理的事件时，又把该句柄放回到刚刚清空的准备就绪链表了。所以，非ET的句柄，只要它上面还有事件，epoll_wait每次都会返回。而ET模式的句柄，除非有新中断到，即使socket上的事件没有处理完，也是不会次次从epoll_wait返回的“
两种模式在socket可读/可写下的正确使用方法：
对于socket接收缓冲区有数据到达时[不可读到可读]，ET/LT模式需要把数据读完，当read返回EAGAIN或EWOULDBLOCK时，或者读到的字节数少于需要的，则表示读完；
对于socket发送缓冲区的状态从不可写到可写，需要发送数据时，先看看应用程序的缓存buffer中是否有数据，如果有，则表示发送缓冲区暂时不可写，需要把这部分缓存起来；如果没有数据，则直接调用send发送直到又不可写，那么在LT模式下，注册可写事件，当可写时发送数据，发送完毕后需要把该事件移走，否则就算没有数据要发送，也会通知；对于ET模式下，当可写时，检测应用程序的缓存是否有数据，有就发送；后者处理写事件比较简单。
两种I/O模型通用结构[单进程单线程模型下，伪代码]：
int iListenfd = socket();
int iRet = setnotblocking(iListenfd);
/**这里如果是阻塞的话，有链接的connect过来时，完成三次握手情况下，把链接从未完成三次握手队列中移至完成三次握手队列中，等待accept，如果此时客户端发来个RST，此时accept需要忽略ECONNABORTED错误并再次调用accept；**/
iRet = bind();
iRet = listen();
int ifdArray[DEFAULT_FD_MAX_COUNT]; /* 这里简单处理，不考虑越界*/
int ifdCount = 0;
fd_set fdRead;
maxfd = iListenfd;
while(true)
{
FD_ZERO(&fdRead);
FD_SET(iListenfd, &fdRead);
for (i = 0; i < ifdCount; ++ i)
{
FD_SET(ifdArray[i], &fdRead); //connect
}
//set timeout;
int iRet = select(maxfd + 1, &fdRead, NULL, NULL, NULL);
if (iRet < 0) { //error, break;}
if (iRet == 0) {//timeout, continue; }
for (int i = 0; i < ifdCount; ++ i)
{
if (FD_ISSET(ifdArray[i], &ifdRead))
{
//有数据可读，如果读到0则表示对端断开链接，需要从ifdArray[i]中移走；
}
}
if (FD_ISSET(iListenfd, &fdRead))
{
int iNewfd = accept(iListenfd);
if (iNewfd >= 0)
{
ifdArray[ifdCount ++] = iNewfd;
if (iNewfd > maxfd) { maxfd = iNewfd; }
}
else
{
//todo, skip ECONNABORTED error
}
}
}
其实select模型的使用很简单，但有几个注意点就是select的时候，会清除传进去的fd_set集合，需要在外面做个备份；然后select的第一个实参传进去的是当前最大描述符+1，因为在do_select底层实现中：for(i = 0; i < n; ++rinp, ++routp, ++rexp) {/*遍历所有fd*/；当select返回时需要对返回值判断是因为什么而返回；有新的链接过来时需要保存到ifdArray，下次select时需要监听；有链接关闭时，从ifdArray中移走；
查了下，accept返回为0也是正常的。上面的程序只是个大概，可能会有一些错误，和细节没有考虑进去。
未完。
