http://www.cnblogs.com/Solstice/archive/2011/04/17/2018801.html
https://blog.csdn.net/FreeeLinux/article/details/53591736?utm_source=blogxgwz1
知识点1：boost::nocopyable学习
学习链接：https://blog.csdn.net/huangjh2017/article/details/60608145
在Buffer类的定义中设置的是copyable，与nocopyble含义相反，但在实际使用中nocopyble的使用更为常见。
当我们定义一个类时，我们显示地或隐式地指定在此类型的对象拷贝、移动、赋值和销毁时做什么。一个类通过定义五种特殊的成员函数来控制这些操作，包括：拷贝构造函数、拷贝赋值运算符、移动构造函数、移动赋值运算符和析构函数。我们称这些操作作为拷贝控制操作。
如果一个类没有定义所有的这些拷贝控制成员，编译器会自动为它定义缺失的操作。很多类会忽略这些拷贝控制操作。但是，对一些类来说，依赖这些操作的默认设定会导致灾难。
有时候，当我们定义某个类时，我们可能不希望我们定义的类进行拷贝操作。为此，我们可以采用将拷贝构造和拷贝赋值声明为private(私有)的，这样的话就能禁止类进行拷贝操作。不过，这样做的话，显得比较麻烦。为此，boost中就提供noncopyable，我们通过继承noncopyable就可以实现禁止拷贝了。
下面是boost::noncopyable类的实现。在实现中，将构造函数和析构函数声明为保护，这样不会影响noncopyable作为基类，也避免外部构建一个noncopyable实类
namespace noncopyable_ // protection from unintended ADL
{
class noncopyable
{
protected:
noncopyable() {}
~noncopyable() {}
private:
// emphasize the following members are private
noncopyable( const noncopyable& );
noncopyable& operator=( const noncopyable& );
};
typedef noncopyable_::noncopyable noncopyable;
};
那么，问题来了。为什么将noncopyable作为基类，能使派生类实现禁止拷贝？
这是因为，在派生类拷贝过程中，主要分为2部分：首先，调用基类的复制构造函数完成基类部分的复制，然后再复制派生类的部分。由于基类的拷贝构造函数和拷贝赋值运算符声明为私有的，派生类无法访问。所以，在第一部分的时候已经失败了，这就成功的禁止派生类的拷贝功能。
知识点2：epoll模型
https://blog.csdn.net/u011671986/article/details/79449853
https://blog.csdn.net/ljx0305/article/details/4065058?utm_source=blogxgwz1
https://blog.csdn.net/shenya1314/article/details/73691088
在linux没有实现epoll事件驱动机制之前，我们一般选择用select或者poll等IO多路复用的方法来实现并发服务程序。在大数据、高并发、集群等一些名词唱得火热之年代，select和poll的用武之地越来越有限，风头已经被epoll占尽。
select的缺点：
- 单个进程能够监视的文件描述符的数量存在最大限制，通常是1024，当然可以更改数量，但由于select采用轮询的方式扫描文件描述符，文件描述符数量越多，性能越差；(在linux内核头文件中，有这样的定义：#define __FD_SETSIZE 1024)
- 内核 / 用户空间内存拷贝问题，select需要复制大量的句柄数据结构，产生巨大的开销；select返回的是含有整个句柄的数组，应用程序需要遍历整个数组才能发现哪些句柄发生了事件；
- select的触发方式是水平触发，应用程序如果没有完成对一个已经就绪的文件描述符进行IO操作，那么之后每次select调用还是会将这些文件描述符通知进程。
poll缺点
相比select模型，poll使用链表保存文件描述符，因此没有了监视文件数量的限制，但其他三个缺点依然存在。
拿select模型为例，假设我们的服务器需要支持100万的并发连接，则在__FD_SETSIZE 为1024的情况下，则我们至少需要开辟1k个进程才能实现100万的并发连接。除了进程间上下文切换的时间消耗外，从内核/用户空间大量的无脑内存拷贝、数组轮询等，是系统难以承受的。因此，基于select模型的服务器程序，要达到10万级别的并发访问，是一个很难完成的任务。
epoll实现原理
由于epoll的实现机制与select/poll机制完全不同，上面所说的 select的缺点在epoll上不复存在。
设想一下如下场景：有100万个客户端同时与一个服务器进程保持着TCP连接。而每一时刻，通常只有几百上千个TCP连接是活跃的(事实上大部分场景都是这种情况)。如何实现这样的高并发？
在select/poll时代，服务器进程每次都把这100万个连接告诉操作系统(从用户态复制句柄数据结构到内核态)，让操作系统内核去查询这些套接字上是否有事件发生，轮询完后，再将句柄数据复制到用户态，让服务器应用程序轮询处理已发生的网络事件，这一过程资源消耗较大，因此，select/poll一般只能处理几千的并发连接。
epoll的设计和实现与select完全不同。epoll通过在Linux内核中申请一个简易的文件系统(文件系统一般用什么数据结构实现？B+树)。把原先的select/poll调用分成了3个部分：
1. 调用epoll_create()建立一个epoll对象(在epoll文件系统中为这个句柄对象分配资源)
2. 调用epoll_ctl向epoll对象中添加这100万个连接的套接字
3. 调用epoll_wait收集发生的事件的连接
如此一来，要实现上面说是的场景，只需要在进程启动时建立一个epoll对象，然后在需要的时候向这个epoll对象中添加或者删除连接。同时，epoll_wait的效率也非常高，因为调用epoll_wait时，并没有一股脑的向操作系统复制这100万个连接的句柄数据，内核也不需要去遍历全部的连接。
知识点3：nginx
https://www.cnblogs.com/yjf512/archive/2012/06/13/2548515.html
