设想一个场景，有100万用户同时与一个进程保持着TCP连接，而每一时刻只有几十个或几百个TCP连接是活跃的（接收到TCP包）也就是说，在每一时刻进程只需要处理这100万连接中的一小部分连接，那么，如何才能高效的处理这种场景那，进程是否在每次询问操作系统收集有事件发生的TCP连接时，把这100万个连接告诉操作系统，然后由操作系统找出其中有事件发生的几百个连接呢？，实际上在linux2.4版本以前，那时的select或者poll事件驱动方式就是这样做的（就是每次通过轮询的方式从100万个连接中找出活跃连接）
这里有个明显的问题，即在某一时刻，进程收集有事件的连接时，其实这100万连接中的大部分都是没有事件发生的，因此，如果每次收集事件时，都把这100万连接的套接字传给操作系统，而由操作系统内核寻找这些连接上有没有未处理的事件，将会是巨大的资源浪费，而select和poll就是这样做的，因此他们最多只能处理几千个并发连接，而epoll不是这样做的，epoll把原先的一个select或者poll调用分成了3个部分，调用epoll_create建立一个epoll对象，调用epoll_ctl向epoll对象中添加这100万个连接的套接字，调用epoll_wait收集发生事件的连接，这样只需要在进程启动时建立一个epoll对象，并在需要的时候向他删除或添加连接就可以了，在实际收集事件中，epoll_wait的效率会非常高，因为调用epoll_wait时并没有向它传递这100万个连接，内核也不需要去遍历全部的连接
epoll_create方法
当某一进程调用epoll_create方法时，linux内核会创建一个eventpoll结构体，这个结构体中有两个成员与epoll的使用方法密切相关，如下所示：
Struct eventpoll { Struct rb_root rbr; //红黑树的根节点，保存着100万个链接的套接字 Struct list_head rdllist; //保存着发生事件的连接，通过epoll_wait返回给用户满足 条件的事件 }
所有添加到epoll中的事件，都会与设备（网卡）驱动程序建立回调关系，也就是说相应的事件发生时会调用这里的回调方法，这个回调方法在内核中叫做ep_poll_callback，当被调用时会把事件放到rdllist双向链表中（正是这种回调机制使不用轮询就可以知道哪些连接有事件发生）
当调用epoll_wait检查是否有发生事件的连接时，只是检查eventpoll对象中的rdllist双向链表是否有epitem元素而已，如果rdllist链表不为空，则把这里的事件复制到用户态内存中，同时将事件数量返回给用户，因此epoll_wait的效率非常高。
epoll_ctl在向epoll对象中添加，修改和删除事件时，从rbr红黑树中查找事件也非常的快，也就是说epoll是非常高效的，可以轻易处理百万的并发。