nginx详细文档.doc

nginx详细文档 （ 安装配置，深入源码，模块编写，编译器参数，系统函数 ） 吴东April 28, 2009 Contents Contents 1 Chapter 1 前言 2 Chapter 2 基本配置 3 2.1安装 3 2.2.配置说明 5 2.3启动和控制 17 Chapter 3深入源码 18 3.1源码结构 18 3.2configure配置 18 3.3nginx源码习惯 18 3.4.常用基础库 18 3.5.core模块 28 3.6event模块 32 3.7http模块 34 Chapter 4模块编写 38 4.1http模块编写 39 4.2基于nginx的高性能服务器开发 39 4.2.基于nginx的高性能服务器开发 Chapter4.模块编写 39 Chapter 5附录 39 5.1编译器参数 39 5.2系统函数 41 Chapter 1 前言 在互联网编程中，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对象