nginx的前世今生

Nginx最初的设计是称为一个http服务器，一个能够解决C10K问题的http服务器。

那么问题来了，什么是C10K呢？C10K问题即（单机10万个并发链接问题），这个概念最早是由Dan Kegel发布于其个人站点。

我们说互联网的基础是网络通信对吗？而早期的互联网可以说是一个小群体的集合。互联网还不够普及，用户也不多，一台服务器同时在线100个用户估计在当时已经是大型网站了，所以并不存在C10K的难题。互联网的爆发期应该在www网站，浏览器，雅虎出现后。

web1.0的出现，互联网的大部分使用场景是下载一个HTML页面，用户在浏览器中查看网页上的信息，这个时期也不存在C10K的问题。

web2.0时代的到来，一方面是普及率大大提升，用户集群倍数增长，另一方面互联网不在是单纯的浏览万维网网页上的信息，逐渐开始进行交互，而且应用程序的逻辑也变的更复杂了，从简单的表单提交提交，到即时通信和在线实时互动，C10K的问题出现了。因为每一个用户都需要与服务器保持TCP链接才能进行实时的数据交互。

最初的服务器都是基于进程/线程模型的，新到来的一个TCP链接，就需要分配1个进程（或者线程）。而进程又是操作系统最昂贵的资源，一台机器无法创建很多个进程。如果是C10K就要创建1万个进程，那么单机而言操作系统是无法承受的，如果采用分布式系统，维持1亿的在线用户需要10万台服务器，成本巨大。

这些局限和问题最早被Dan Kegel进行了归纳和总结，并首次系统分析并提粗解决方案，后来这种普遍的网络网络现象和技术局限被成为C10K。

解决以上问题呢，有两种思路：

一种是对于每一个链接处理分配一个独立的进程/线程；另一个思路是用同一个进程/线程来同时处理若干链接。

创建的进程线程多了，数据拷贝频繁（缓存I/O、内核将数据拷贝到用户进程空间、阻塞）， 进程/线程上下文切换消耗大， 导致操作系统崩溃。

● 实现方式2：select要解决上面阻塞的问题，思路很简单，如果我在读取文件句柄之前，先查下它的状态，ready 了就进行处理，不 ready 就不进行处理，这不就解决了这个问题了嘛？于是有了 select 方案。用一个 fd_set 结构体来告诉内核同时监控多个文件句柄，当其中有文件句柄的状态发生指定变化（例如某句柄由不可用变为可用）或超时，则调用返回。之后应用可以使用 FD_ISSET 来逐个查看是哪个文件句柄的状态发生了变化。这样做，小规模的连接问题不大，但当连接数很多（文件句柄个数很多）的时候，逐个检查状态就很慢了。因此，select 往往存在管理的句柄上限（FD_SETSIZE）。同时，在使用上，因为只有一个字段记录关注和发生事件，每次调用之前要重新初始化 fd_set 结构体。

intselect(intnfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds,structtimeval *timeout);

实现小结：有连接请求抵达了再检查处理。
问题归纳：句柄上限+重复初始化+逐个排查所有文件句柄状态效率不高。

● 实现方式3：poll 主要解决 select 的前两个问题：通过一个 pollfd 数组向内核传递需要关注的事件消除文件句柄上限，同时使用不同字段分别标注关注事件和发生事件，来避免重复初始化。

实现小结：设计新的数据结构提供使用效率。
问题归纳：逐个排查所有文件句柄状态效率不高。

● 实现方式4：epoll既然逐个排查所有文件句柄状态效率不高，很自然的，如果调用返回的时候只给应用提供发生了状态变化（很可能是数据 ready）的文件句柄，进行排查的效率不就高多了么。epoll 采用了这种设计，适用于大规模的应用场景。实验表明，当文件句柄数目超过 10 之后，epoll 性能将优于 select 和 poll；当文件句柄数目达到 10K 的时候，epoll 已经超过 select 和 poll 两个数量级。

实现小结：只返回状态变化的文件句柄。
问题归纳：依赖特定平台（Linux）。

nginx正是基于这样的开发理念，使得其有占用内存少，并发能力强的特性。