nginx文档一

前言
在互联网编程中，http服务器编程作为一个非常重要方向一直为各种语言所重视，从c语言的apache，Lighttpd到当前非常流行的nginx。 Java有tom-cat，jetty，websphere等众多服务器，pyhoen的zope等服务器。既有重量级的服务器，又有轻量级的，嵌入式的服务器。从互联网的应用来说，c语言的http服务器一直占有主导地位，当前最流行的三个开源服务器有apache，Lighttpd和nginx。 Apache作为经典的Web服务器，除了慢没有别的缺点了，Apache2对fcgi支持并不好，非常好用的proxy和proxy_ajp（很多人用它作为tomcat的前端），不支持epoll（这年头，epoll几乎是性能的必备）。Lighttpd作为杀手级的静态文件能力，杀手级的fcgi能力但是proxy模块不够稳定。Nginx速度快，占用资源少，杀手级的proxy和rewrite，非常不错的静态文件能力，最适合作为整个网站的前端服务（将php、svn等不同请求发送往后端apache）。现在国内Nginx的用户越来越多了，多数拥抱Nginx的网站都钟意其优异的性能表现，如果是相对比较大的网站，节约下来的服务器成本无疑是客观的。当前 Ngnix美中不足之处是相关的文档和用户经验都还是很欠缺，用户之间还很难做到可借鉴性的交流。最近因为朋友遇到一些技术问题，我也翻阅了不少 Nginx的邮件列表内容，发现大量的技术细节仍然在频繁变化中，可是中文社区内相关的记录和讨论太少了。相信国内这些Nginx用户积攒的经验肯定是不少的，但可能是因为某些其它因素考虑而看不到相关的技术分享。本书的写作就是为了向大家展示nginx的内部结构，以便于大家更好的使用该服务器。对于一个八万行代码的http服务器，从性能来看它是那么的出色，从功能来看它并不逊色于几十万行的apache服务器。Nginx是实现有几个非常出色的地方：模块化设计，流水线请求处理，多进程控制，epoll的使用，平滑的升级程序或是配置文件。Nginx采用的是单线程的方式，网络服务器的几种模型可以参考C10K的介绍。当然，如果在linux下，最好的模型自然是EPool（effectiveepoll?）。目前一台服务器支持10K个客户访问，基本上还比较麻烦，64位的CPU，可能是一个比较好的解决方案。2块1000M网卡，10K客户端，每个客户端的带宽是 2000/10000=200K，这是理论值，勉强可行。考虑一下纯粹的线程模型。10K个客户端，需要10K个线程。考虑到每个进程3G的用户空间，那么每个线程的空间是3000M/10K=300K，只能说非常勉强可以运行（每个线程的cruntime大约需要2-3K空间）。但是大量的线程调度会极大的减缓系统效率。再考虑一下多个进程的模型，每个进程创建多个线程。其实与纯粹的线程模型差异不大，不过是每个线程的用户空间不受太大限制。大量的线程调度带来的巨大性能损耗会使得整个系统效率及其低下。当然，这种模型也不是一无是处，对于客户端数目不多的情况，比如ftp服务器，这种模型是非常合适的。

然后就剩下epoll模，要使用epoll模型，首先必须有Linux2.6的内核。了解select模型的人都知道，select每个句柄只能支持64个socket，这可以通过阅读linuxselect.h知道。而Poll模型则是一种事件触发的模型，没有64个socket的限制。epoll是对Poll模型的一个改造，让一个Poll句柄可以同时支持多个Socket句柄，好处是将大量Poll句柄的事件探测机制放到内核中处理，大大减少了将数据从内核态拷贝到用户态的次数，从而提高效率。阅读Linux的源码可以看到，epoll的内部使用的是一个Hashmap，Hashmap中存放Poll对象，所以从根本上来说，epoll模型是一种更好的Poll模型(我一直理解为EffectivePoll)。
当然nginx也有不足的地方，例如各个模块之间的耦合性太强，各个模块不适合直接拿出来使用。Nginx的作者过于强调按照他自己所理解的模块化，而把一些基础模块也用作者所谓的模块化来实现，导致代码相互引用太多，艰涩难懂。
本书的编写的面向的用户除了初级linux工程师外，还可以为中高级linux工程师作为开发高性能服务器的工具书，目的除了向用户展示nginx精巧的设计和完整的实现外，还希望通过本书的讲解能够让用户以nginx作为基本框架或是自己实现更多的高性能服务器。