前  言

Nginx服务器在互联网推波助澜的作用下脱颖而出，创下了高并发的记录，因此，在短短10年的发展中，在全世界前100万的网站中，已经有5.1%的网站使用了Nginx服务器，使得Nginx成为继Apache（70.2%）和IIS（20.5%）之后的第三大Web服务器软件，而且它的使用数量与日俱增，直逼Apache的市场。有人说，Nginx将会取代Apache的市场，我们且不关心Nginx能不能取代Apache，1996年4月以来，Apache一直是Internet上最流行的HTTP伺服器，而且在Linux系统下Apache几乎是不二的选择，而在2002年诞生的Nginx服务器在这种形式下能够崛起那绝对是个奇迹，它有两个方面能够打败Apache服务器，一是高并发，二是节省资源，即轻量级。在我们现有的应用中，基本上将Apache跑在了后台，而是同Nginx服务器代理访问了。

使用Nginx服务器就是使用它的两大特点，一是高并发访问，二是代理，它能够快速地解析静态文件，而对于动态语言实现的动态程序则传递到后台的服务，实现了动静网页解析的分离。

Nginx是一个自由的、开源的、高性能的HTTP服务器和反向代理，同时也是一个IMAP/POP3的代理服务器，它是由Igor Sysoev于2002年开发，并且在2004年发布了第一个版本，在互联网上使用Nginx的主机近乎6.55%（13.5M）。

Nginx之所以能够脱颖而出闻名世界，是因为它的高性能、稳定性、丰富的功能设置、简单的配置和资源消耗低。

Nginx解决了服务器的C10K问题，它的设计不像传统的服务器使用线程处理请求，取而代之的是使用了一个更加高级的机制——事件驱动机制，而且是异步事件驱动结构。

即使你不希望处理成千上万的并发请求，你同样能够从Nginx的高性能和低消耗内存（占用内存小）的结构中获益。Nginx的使用规模很全面：从很小的VPS到服务器集群都可以。

Nginx强有力地用在了一些高知名度的站点，例如WordPress、Hulu、Github、Ohloh、SourceForge 和 TorrentReactor。

本套书所包括的内容

本套书共包括卷1和卷2两本书，共10个部分（包括了86章的内容，其中第十部分是一个独立部分，没有章节），其中卷1包括了前3部分的内容，而卷2包括了后面的7部分内容。

卷1内容

第1部分  Nginx服务器

第2部分  Nginx服务器的功能模块

第3部分  Nginx与缓存

第1部分  Nginx服务器

该部分包括了服务器的功能、Nginx服务器的模块管理和进程管理、5XX错误处理、协助用户操作Nginx的工具和高可用的Nginx等内容。

第1章  Nginx的功能

本章认识Nginx服务器的基本功能和其扩展功能，以及Nginx核心模块的相关指令和变量。

第2章  Nginx的模块管理和进程管理

Nginx同Apache一样，同样使用了模块化管理，但是与Apache有很大的不同，如果说Apache支持“热插拔”（就是说如果对Apache添加模块不用重新编译Apache，而只是添加必要的模块，然后再重新载入Apache就可以了），那么Nginx则必须“重启动”，就是说如果要对Nginx服务器添加模块，那么需要重新编译Nginx才可以添加相应的功能模块，因此在这一点上要比Apache服务器麻烦。

第3章  Nginx如何处理一个请求

Nginx服务器在处理一个请求时是按照两部分例子进行的，第一部分是IP、域名，第二部分是URI。本章将分析这两部分是如何进行工作的。

第4章  服务器名字

服务器的名字是由指令server_name来定义，并且也决定了使用哪一个server区段来提供对客户端请求的响应。服务器名字的定义可以使用准确的名字（exact name）、通配符名字（wildcard name）或者是正则表达式。

第5章  协助用户操作Nginx的工具

工具nginx.vim是一个辅助工具，通过下面的配置，在使用时它将成为vim工具的一部分，具体的作用是用于编辑Nginx的配置文件。

这个工具是一个shell（Bash）脚本，是Debian系统下用于控制Apache2.2虚拟主机命令a2ensite 和 a2dissite的复制版，用于控制Nginx。原始的a2ensite 和 a2dissite是用Perl语言编写，a2dissite是a2ensite的一个符号链接，在本工具中，开发者遵循了同样的方法，例如，nginx_dissite是nginx_ensite的一个符号链接。

如果没有安装Apache，那么可以使用该工具来产生和管理htpasswd文件。

Nginx启动脚本，由于在默认的安装包中没有提供管理脚本，为了管理方便，我们需要为它添加一个启动/关闭/脚本。

第6章  5XX错误处理

本章介绍了500、502和504错误代码的原因及处理。

第7章  使用TCMalloc优化Nginx

TCMalloc即Thread-Caching Malloc的缩写，它是由Google公司开发的一款开源工具google-perftools中的一成员。TCMalloc在内存的分配上效率和速度要比标准的glibc库高得多，它不但可以用来优化高并发下的MySQL，从而可以降低系统的负载，同样它可以用于Nginx实现同样的功能，因此，对于高并发的Nginx来说无疑是如虎添翼。

第8章  PCRE正则表达式

由于在使用Nginx的过程中会用到正则表达式，因此有必要对这一部分内容进行一个清晰的说明。并且讲述了pcre-config和pcretest命令，以及Nginx服务器支持UTF8正则表达式匹配。

第9章  Nginx高可用的实现

我们在Nginx下实现高可用不是担心Nginx服务出问题，而是担心硬件的问题，因此在设计通过Heartbeat服务来提供高可用时没有通过Heartbeat服务器来控制Nginx服务器的启动、停止等，而只是通过它提供了一个“浮动”的IP地址，次IP就是Nginx服务器提供访问的IP，也就是被解析到相应域名的IP地址。

第10章  10个QA

10个经常被问的问题。

第二部分  Nginx服务器的功能模块

本部分，详细地讲述了Nginx提供的模块实现的功能：

第11章  限制流量

第12章  限制用户并发连接数

第13章  修改或隐藏Nginx的版本号

第14章  配置FLV服务器

第15章  Nginx的访问控制

第16章  提供FTP下载

第17章  Nginx与编码

第18章  网页压缩传输

第19章  控制Nginx如何记录日志

第20章  map模块的使用

第21章  Nginx预防应用层DDoS攻击

第22章  为Nginx添加、清除或改写响应头

第23章  重写URI

第24章  Nginx与服务器端包含

第25章  Nginx与X-Sendfile

第26章  在Nginx的响应体之前或之后添加内容

第27章  Nginx与访问者的地理信息

第28章  Nginx的图像处理

第29章  location中随机显示文件

第30章  后台Nginx服务器记录原始客户端的IP地址

第31章  解决防盗链

第32章  Nginx提供HTTPS服务

第33章  监控Nginx的工作状态

第34章  使用empty_gif

第35章  Nginx对响应体内容的替换

第36章  Nginx的WebDAV

第37章  Nginx的Xslt模块

第38章  Nginx的基本认证方式

第39章  Nginx的cookie

第40章  Nginx基于客户端请求头的访问分类

第41章  通过Upstream模块使得Nginx实现后台服务器集群

第42章  根据浏览器选择主页

第43章  关于Nginx提供下载.ipa或.apk文件的处理方法

第44章  SCGI

第45章  Expires与ETag

第46章  使用upstream_keepalive模块实现keep-alive

第47章  后台服务器的健康检测

第48章  使用sticky模块实现粘贴性会话

第49章  Nginx对后台服务器实现“公平”访问

第50章  Nginx使用redis数据库

第51章  Nginx访问MongoDB

第52章  Nginx访问Mogilefs

第三部分  Nginx与缓存

通过Nginx来实现缓存功能基本上有四类方法，其中第一类方法Nginx自带，即proxy_cache、proxy_store和memcached，在没有proxy_cache之前只能用proxy_store缓存页面，但是memcached需要第三方软件Memcached；第二类是通过添加第三方模块，下面我们通过例子来分析；第三类是通过Varnish服务器。这样共有五种方法来实现缓存。

第53章  缓存技术——proxy_cache

Nginx的这个功能从0.7.48版本开始提供的，它开始支持类似Squid的缓存功能。它的原理是把URL及相关变量的组合当做Key，再用MD5编码，编码后的哈希值作为文件名，然后再将缓存的文件保存在硬盘中。我们现在使用的是0.8.53版本，早在0.8.31版本中proxy_cache就比较完善了，之所以说它比较完善，其实就是说它没有缓存清除机制，但是通过第三方模块ngx_cache_purge来清除指定的URL缓存，它支持任意URL链接、支持404/301/302/200状态码缓存，因此，在使用反向代理的同时使用Nginx的proxy_cache缓存机制是个很不错的做法。

第54章  缓存技术——proxy_store

在没有proxy_cache之前，都是使用proxy_store，由于Nginx的proxy_store技术当时在设计时没有采用任何刷新机制，因此，对于缓存的管理上也就更“人为”了一些（你不觉得这么说更好听些？！），我们可以自己写个脚本进行缓存清理等。使用proxy_store的原理其实也很简单，那就是Nginx首先在本地查找客户端请求的内容，如果找不到就去proxy_pass指定的后端服务器上查找，然后会被保存到本地的缓存中。使用proxy_store技术有一个缺点，其实也能认为是优点，它会在本地缓存中构建一个和远程服务器——proxy_pass指定的后端服务器目录结构完全一样的结构（真得可以叫镜像了！），这是从它的优点方面讲。从缺点方面讲，那么它会浪费很大的磁盘空间，如果没有一个足够大的硬盘或者是没有及时地清除缓存中的过时文件，那么将是一个可怕的问题，所以你要么准备一个足够大的硬盘，要么及时或是有计划地清除缓存。

第55章  缓存技术——Memcached

这是使用比较多的一种缓存方式，使用Memcached模块也会分为四部分分析，第一部分就是Nginx的memcached模块本身，而另一部分就是Memcached服务，第三部分就是Nginx的配置文件，将这二者结合起来，就是第四部分客户端。

第56章  缓存技术——NCache

这个缓存方式我们只需要了解一下就可以了。第三方模块用得较多的就是新浪网的开源项目——NCache。这是一个比较古老的模块了，NCache，Nginx Cache，它只支持Nginx的0.6.x版本，对于Nginx的其他版本并不支持，相反的是在后面的版本中是以Nginx内核形式出现的。

第57章  缓存技术——Varnish

在Nginx中Varnish缓存是通过代理模块来实现的，在我使用的Varnish缓存服务器中，其中之一就是为了Apache而使用它。

Varnish是一个高性能的、先进的Web加速器，它可以安装在Linux 2.6、FreeBSD 6/7 和 Solaris 10系统上，以便发挥其高效的性能。

卷2内容

第1部分  Nginx与PHP

第2部分  Nginx与Python

第3部分  Nginx与Perl

第4部分  Nginx与Java

第5部分  Nginx与Ruby

第6部分  Nginx与ASP.NET

后记  Nginx与Apache

第1部分  Nginx与PHP

要将Nginx和PHP结合，让Nginx解析静态网页，而PHP的动态网页交给PHP处理。解决方法从大的方向有两类：（从Nginx角度来讲）一类是使用Nginx的代理模块，而另外一类则是使用FastCGI模块；而从PHP角度来讲则是FastCGI进程，它的方法有三种：一种是以php-fpm方式运行，第二种是PHP自带的fastcgi server，第三种就是借助lighttpd带的spawn-fcgi（听起来有点龌龊，但是确实可行，有时候还必须使用这种方法）。

第1章  环境部署

本章作为该部分的第1章，首先来部署环境。在PHP方面我们使用了php-fpm，而在Nginx方面我们使用的是FastCGI模块。

第2章  PHP访问Memcached

为理解Memcached的使用，我们在这里讲述两个例子，一个是微博网站的部署，具体就是用Memcached存储什么数据，我没有仔细分析过，只负责部署和测试是否符合要求就够了；另一个是在我所运维环境中使用的一个例子，非常简单且实用。

在PHP下使用Memcached服务器，有两个选择，一个是纯PHP框架开发的memcache，而另一个则是使用libmemcached的memcached。

第3章  php-fpm的状态

了解php-fpm的工作状态。

第2部分 Nginx与Python

本部分我们将了解到Nginx的uwsgi模块、uWSGI服务器以及ngx_cache_purge，当然根据需要我们还可以对Django 架构了解一下。

第4章  uWSGI服务器

uWSGI 是一个快速的、自维护的、对开发者和系统管理者友好的应用程序容器，是纯C语言开发的服务器。

在它的诞生之日，uWSGI只是作为一个WSGI服务器，但是随着时间的推移，它现在已经演变为一个完整的网络、集群Web应用服务器，可以执行消息、对象传递、缓存、RPC和进程管理。

它使用的协议是uwsgi（注意，所有的字母都是小写，该协议已被Nginx和Cherokee的发行版本所包含），所有网络或进程间通信均使用uwsgi协议。

uWSGI可以运行在预fork模式、线程模式、异步模式等，并且支持green threads、coroutines各种形式，例如 uGreen、Greenlet、Stackless和Fiber。

对于管理人员来说，uWSGI服务器提供了各种配置方法：命令行、环境变量、XML、ini、yaml、json、sqlite3 数据库和LDAP。

除此之外，它的设计完全模块化，这意味着，可以使用不同的插件以便满足不同的技术应用，从而实现兼容性。

第5章  Nginx的uwsgi模块

该模块能够使得Nginx与uWSGI进程进行交互，并且可以控制传递给uWSGI进程的参数。对于uwsgi协议和uWSGI服务器，uWSGI服务器就是uwsgi协议的一个实现。

第6章  环境部署

在了解了Nginx的uwsgi模块、uWSGI服务器以及ngx_cache_purge之后，当然根据需要我们还可以对Django 架构了解一下。在这里我们按照一个全新的环境来布置，即从安装Python开始。在后面的实例部分，我们使用了Python的2.43版本，这是Red Hat系统自带的，同时也使用2.7.2版本，具体的版本根据自己的需要去选择。

第7章  实例运行

下面我们通过实例的方式来讲述。在下面的内容中将会讲述8个运行实例。

? 实例1：运行开发服务器

? 实例2：以uWSGI方式运行

? 实例3：使用Django框架

? 实例4：一个uWSGI实例实现对多个虚拟主机的支持

? 实例5：分别监听在不同端口上的两个uWSGI实例

? 实例6：针对Nginx uwsgi模块应用举例的一个具体实现

? 实例7：集群的实现

? 实例8：会话存储（基于数据库的方式和基于Memcached的两种方式）

第8章  缓存

对于Memcached服务器，Python客户端方式选择有三种：一是python-memcached，它的下载地址是http://www.tummy.com/Community/software/python-memcached/，最新版本为1.47；二是cmemcache，它的下载地址为http://gijsbert.org/cmemcache/，最新版本为0.95；三是libmemcached，它的下载地址为http://download.tangent.org/，最新版本为0.9。

第9章  会话

session是Django中的一个高级工具，它可以存储用户的个人信息，以便用户在下次访问该网站时使用这些信息，session的基础还是cookie，但是它能够提供一些更加高级的功能。

Django提供了完全支持匿名会话的功能，它的会话结构让每个网站的访问者存储并且检索任意数据。它将数据存储在服务器端并且对发送和收到的cookies做摘要，cookies包含一个会话ID，而不是数据本身。Django 只在需要的时候才发送cookie，如果我们没有设定任何的session 数据，它不会送出cookie。

此外，还需要明白一点，Django的会话（session）框架是完全基于cookie的，并且它也只能是基于cookie，而不会像其他一些软件（例如 PHP）那样，在session不能正常工作时，就会把session ID放到URL中。任何事情只要存在就有它的道理，这一决定是经过深思熟虑的，将session ID放到URL中的那种方法不仅使得URL很丑陋，并且session ID还有可能通过Referer头泄露出去，从而给网站带来安全隐患，这就是Django基于cookie的原因。

第3部分  Nginx与Perl

在Nginx的设计上并不支持CGI，这不是它本身的缺陷，而是一个重要的举措：因为Nginx不能够直接执行外部程序（CGI），因此，怀有恶意的人就不能随意地直接执行外部脚本程序。当然，什么事情都是有方法可循的，例如，PHP FastCGI脚本的支持，当我们将一个PHP脚本上传到一个可以执行PHP FastCGI的目录中，那么该脚本就可以执行，这个我们已经了解过了，但是这种方法是有一点难度，但是相对来说比较安全。但是有时候我们也需要简单的CGI程序支持，我们将介绍一个简单的CGI来替代FastCGI，我们称这样的程序为CGI程序，它是用Perl语言实现的。

本部分实现了三个应用，即CGI、perl-FCGI和Nginx内置的Perl模块。

第10章  Nginx提供Perl CGI访问

第11章  Nginx与Perl FastCGI

要将Nginx和Perl结合，让Nginx解析静态网页，而Perl的动态网页交给Perl处理。解决方法从大的方向有两类：（从Nginx角度来讲）一类是使用Nginx的代理模块，而另外一类则是使用FastCGI模块，而从Perl角度来讲则是FastCGI进程。 

有关Memcached服务器的使用通过以下客户端作为实现，Perl的memcached客户端有：

? Cache::Memcached

? Cache::Memcached::Fast

? Memcached::libmemcached

? Cache::Memcached::libmemcached

第12章  Nginx通过内置的Perl模块执行Perl程序

通过使用该模块，Nginx服务器可以直接在Nginx内部执行Perl，或者是通过SSI来调用Perl。

第4部分 Nginx与Java

在Java部分我们选择了Tomcat服务器作为Java的解析器。 在这里着重分析了Tomcat的配置文件，及其实际应用中的配置。

第13章  环境部署

在我们实际使用Nginx时，往往不是Nginx单独工作，相反的是，它总是与一些动态语言所使用的“解析器”（这个名字是我起的，不是权威，可不要效仿！）构成动态网站，例如，我们将要接触的Tomcat。Tomcat在与Nginx的搭配中，我们使用Nginx的反向代理功能。

第14章  Nginx与Tomcat的结合

Nginx与Java的实现方式是通过代理模块来实现的，在Nginx方面使用代理模块，而Java方面，可以使用Tomcat也可以使用Resin，还可以是其他的应用服务器。因此在这里我们分为三方面来讲述这个问题：一是代理模块、二是Tomcat或Resin的配置，三是这两者的结合。

将Nginx作为前台服务器而把Tomcat作为后台服务器，由Nginx解析静态文件，而将动态的JSP网页发送到后台的Tomcat服务器。Nginx在默认时就将该代理（Proxy）模块建立在内，通过使用该模块允许你将客户端的HTTP请求转发到后台服务器。

第15章  配置server.xml文件

从本章开始我们将认识Tomcat的配置文件。对于我们运维人员来说，服务器的精髓都在配置文件中。

第16章  配置web.xml文件

首先我们要确定的是这个文件会有两种位置：一种是在$CATALINA_BASE/conf/目录下，而另一种情况是在$CATALINA_BASE/webapps/[webapp]/WEB-INF/目录下，前者可以叫做全局web.xml配置，而后者是各个Web应用程序自己的配置，Tomcat在部署Web应用程序时，可能会包括两种情况，一种是Tomcat在启动时，第二种是Tomcat对应用程序进行重新加载时。在这两种情况下，Tomcat都会先去读取全局配置（即conf/web.xml），然后再去读取各自Web应用程序目录下的配置（即WEB-INF/web.xml）。

我们需要明白两点：一是全局配置（conf/web.xml）会将配置文件中的配置应用到所有的Web应用程序，而每个Web应用程序自己的配置只能应用自己，因此不要在全局配置文件中配置基于特定应用程序的资源；二是对于每个Web应用程序来说，它既可以有自己的web.xml，也可以没有，如果没有该配置文件，Tomcat会给出提示，但不会停止部署该应用程序。

第17章  配置context.xml文件

本章我们来了解context.xml文件的配置情况。

第18章  配置tomcat-users.xml文件

本章将要了解的是Tomcat的用户配置文件，包括用户、角色和密码。

第19章 配置catalina.policy文件

对于catalina.policy文件来说，最大的特点是只有开启了Security Manager后，该文件才被使用，如果没有开启，那么这个配置就是一个摆设。

这一部分内容严格地来说属于Java的安全，和Tomcat本身关系并不大，但是对于我们运维来说，真不知道什么是不需要的，老实说这一部分内容如果处理不好，一是可能会引发安全问题，二是可能会导致软件工程师所写的Java程序在Tomcat上运行不了。

第20章 配置catalina.properties文件

在该部分内容中讲述两个内容：一是catalina.properties文件分析，二是Loader元素和类的加载器。

虽然两者看起来是不同的内容，但是在一定程度上，它们确实完成相同的工作。

第21章 在容器元素中可以使用的过滤器

Tomcat提供了许多过滤器（Filters），可以将这些过滤器配置在所有Web应用程序都可以使用的$CATALINA_BASE/conf/web.xml文件中，也可以配置在单独的WEB-INF/web.xml 文件中，以便应用到相应的Web应用程序中。

第5部分  Nginx与Ruby

本部分的内容为：Ruby、Rails，即RoR和Passenger。

首先讲述了Ruby的安装及相关工具gem，然后是Passenger，Passenger与Nginx的结合安装方式有两种，即Passenger安装和Nginx模块式安装，以及Passenger提供的相关分析和系统维护工具。Rails架构是一个纯Ruby的MVC架构，我们在这部分从运维的角度详细地分析了Rails，包括Rails的相关技术和项目实例分析。

Rails提供了缓存技术，在分析Rails提供的缓存技术基础之上我们着重使用了Dalli缓存接口和Memcached服务器。

第22章  环境部署

本章是该部分的第1章，因此我们首先要部署Ruby环境，Nginx与Python的结合是通过Passenger来实现的，因此在本章中要介绍两种部署Passenger的方法，Passenger模块及其在Nginx中的配置。

第23章  走进Rails 

在这一章中我们将认识Ruby的一个框架Rails，也就是RoR的另一个R。

第24章  缓存

Rails架构提供了不同的缓存技术，对于行为（action）和片段（fragment）缓存策略来说可以使用这些缓存技术，而对于页面（page）缓存技术来说，它总是存储在磁盘上。

缓存技术有以下几种：

? 内存缓存技术

? 文件系统缓存技术

? Memcached服务器技术

? Ehcache缓存技术

? Dalli —— Memcached的客户端

第6部分  Nginx与ASP.NET

本部分讲述的是通过Mono将ASP.NET程序运行在Linux操作系统下，ASP.NET跑在Linux系统下的使用实例不是没有，但也不是很多，好像是越来越多的出现这种跨平台的移植现象。

第25章  Mono

在本章中我们简单地认识一下Mono。

在本章需要了解两个问题，一个是什么是Mono，另一个是Mono的使用级别。

第26章  Nginx与ASP.NET的解决方案

在本章我们实施了三个方案，每一个方案都有自己的特点，在具体的实施中可以做适当的选择。在这部分中讲述了三种结合方案：

? 方案一：Nginx+mono+ fastcgi-mono-server

? 方案二：Nginx+mono+Jexus

? 方案三：Nginx+mono+xsp

第27章  Session存储

由于HTTP协议是无状态的协议，因此在客户端每次访问Web页面时，作为服务器端都要重新打开会话，作为开发人员，或者说是从用户使用的角度来看待这种无状态的协议是不会自动维护客户端所访问的环境信息，因此需要session。

第28章  缓存

关于缓存我们已经讨论了很多，从缓存存储的位置来讲，归纳起来无非三种：

? 服务器端缓存

? 第三方缓存

? 客户端缓存

从缓存内容来讲，分为两种：

? 缓存动态内容

? 缓存静态内容

对于静态文件的缓存，由于我们通过Nginx做了动静分离，因此，通常静态文件是通过Nginx提供服务。

从缓存由动态程序产生的缓存来看，又分为以下类型：

? 全部内容缓存

? 部分内容缓存

那么我们在这里作为总结分析一下。

第29章  Nginx代理IIS

与Mono相比，更多的ASP.NET是运行在IIS服务器之下。在一个大型的网站中，往往会出现使用多种语言的情况。如果使用了ASP.NET技术，就免不了有Windows的系统，也就是使用了IIS。在这种情况下，为了使用Nginx的高效性（运行在Linux下），可以使用Nginx的代理模块来实现，将IIS作为后台服务器来运行，而让Nginx服务器运行在前台

后记  Nginx与Apache

这是一个独立的部分，不再有章节，一是为了怀念Apache，二是为了更好地使用Apache，在没有Nginx的那个年代，Apache为我们的网站作出了不可磨灭的贡献！

Nginx服务器的功能再强大，不要忘记为我们立下汗马功劳的Apache服务器，否则你就是一个忘恩负义的人。

我不赞成用Nginx替换掉Apache，相反我们可以使用混合的环境，对于这种Nginx、Apache混合使用的架构中，一是根据实际的应用来逐步使用Nginx，二是在现有基础上实现Nginx+Apache，具体的方法还是反向代理，让Apache运行在后台，而Nginx运行在前台。

使 用 对 象

? 广大的Linux爱好者。

? 具有一定Linux基础的系统管理员。

? Linux下的Web服务器管理员。

? Linux服务器下动态语言开发人员。

? Nginx服务器管理员。

? 培训中心。

? 运维人员。

? 一切应该了解和使用Nginx的用户。

内 容 声 明

关于本书内容的说明，如果你在哪里看到了与本书雷同的内容，你需要确定一下它的内容是否来自于相应软件的官方网站、man文档、howto、README，Changelog、INSTALL、LICENSE、* .conf等，这些是原创，在我看来，什么是原创，只有这些才是原创（我个人的观点，别拿砖头拍我！），我们只不过是对它们的衍生和应用，本书中的内容就是这样，这是我个人的一个学习方法，对于每一个新使用的软件，我都会看它提供的相关文档和其官方网站，配置文件绝对是软件的精华所在，因此在本书中讲述了大量的配置文件，没办法，Linux下的服务不就是命令加上配置吗？ 

由于这些官方网站、man文档、howto、README，Changelog、INSTALL、LICENSE、* .conf等都是英文的，因此对于我们的认识和阅读是不方便的，事实上我们也正是缺乏这些文档的知识才导致我们一直徘徊在技术的门口，因此本人就是基于这个基础来编写本书，将这些最基础也是最权威的文档通过理解来实现汉语化，以便更多的国人阅读，以个人的感觉，这些东西实际上是我们最需要的，它是认知的第一步，毕竟我们的官方语言是汉语。

书中的内容是我在工作中的一个总结，我没有去刻意改变一个说法，相反只要是官方文档中有的，我就尽可能地采用它们的提法、说法及方法。

与儿子的对话

有一天我儿子问我：“写这套书能挣多少钱？”

这一句话问的不是我，而是问到了人的灵魂，我不知道是否又要归功于教育？有一首歌叫做《我在马路边捡到一分钱》，回忆我小时候，我们学过这首歌，我做到了捡到交公。

我问我儿子：“你学过这首歌吗？”

我儿子说没有学过，他没有学过，但是他也做到了，不但他做到了，而且也帮助他的同学做到了，对于这些我不便多说，报纸有报道。

但是儿子能够问我“写这套书能挣多少钱？”，我确实没有想到。

于是我对他说，写这套书我有三个目的。

第一，对我这么多年做系统管理的一个总结；

第二，帮助那些需要帮助的系统管理和运维人员；

第三，劳动者总是光荣的，出版者给我的报酬是一个物质的体现。

这三个目的是有联系的，没有经验就无法总结，没有总结何谈帮助别人，一个人生活在人世间不只有索取才能感到快乐，相反，给别人带来快乐才是真正的快乐，我希望每个人的奉献要远远大于索取，就是说奉献是我们真正要做的，那么我们的人类才会有真正意义上的和谐，而不是一句口号、一个形式或一个章程！ 

我儿子又问我：“那干嘛不免费发表在互联网上？”

我对儿子是这样说的：

在这个社会形式下，没有钱是无法生存的。达尔文的进化论说了“适者生存”，达尔文的进化论也说了“要么选择，要么适应”，因此，我们需要适应这个社会。首先我不知道怎么适者生存，但我们要解决自己的温饱问题。

还有一个问题，我发表在网上的文章被别人抄袭了，而且有很多地方都抄错了，最后还有人问我是不是抄袭了别人的，这个很让我郁闷！其实我写在网上的文章就是让别人看的，“天下文章一大抄，就看你会抄不会抄”，这个是小学就明白的道理，技术又何尝不是如此，看看我们所使用的这些技术，有哪个是我们自己的技术，人家外国人什么时候找过我们的麻烦！因此，关于本书的内容，我在“内容声明”中做了特别的说明。总言之，第二个不发表在网上的原因就是本书具有可行性（照着本书，每一个实例都能实现），因此，在转载中的修改对于最终的读者会有障碍。

这是我与我9岁儿子的对话。

关 于 读 者

为了使读者尽快地进入Nginx世界，可以从以下四个方面来认识Nginx。

从功能上要认识到以下五点：

? 提供静态文件和index文件，生成自动索引，打开文件描述符缓存；

? 使用缓存加速反向代理，简单的负载平衡和容错；

? 使用缓存机制加速远程FastCGI服务器的访问，简单的负载平衡和容错；

? 模块化结构；

? 支持SSL 和 TLS SNI。

对于“邮件代理服务器功能”也可以做适当的了解，毕竟也是Nginx的一个功能。

从使用上要认识到以下两点：

? 高并发访问，解决了10K的问题；

? 代理，作为代理是它最主要的功能，因此，我们在学习Nginx时这是它的主线。

对于Nginx的工作机制要认识以下八点：

? 一个master进程和几个workers进程，workers进程由非特权用户运行。

? 消息通知方法：kqueue（FreeBSD 4.1+），epoll（Linux 2.6+），rt signals（Linux 2.2.19+），/dev/poll（Solaris 7 11/99+），event ports（Solaris 10），select和poll。

? 支持kqueue的各种功能，包括EV_CLEAR，EV_DISABLE（禁用临时事件，NOTE_LOWAT，EV_EOF，number of available data，错误代码。

? 支持sendfile（FreeBSD 3.1+，Linux 2.2+，Mac OS X 10.5），sendfile64（Linux 2.4.21+）和sendfilev（Solaris 8 7/01+）。 

? File AIO（FreeBSD 4.3+，Linux 2.6.22+）。

? 支持Accept-filters（FreeBSD 4.1+）和TCP_DEFER_ACCEPT（Linux 2.4+）。

? 10 000个非活动HTTP keep-alive连接用掉2.5MB内存。

? 数据复制操作控制在最低限度。

对于安装平台要认识以下五点：

? FreeBSD 3 — 8 / i386，FreeBSD 5 — 8 / amd64。

? Linux 2.2 — 2.6 / i386，Linux 2.6 / amd64。

? Solaris 9 / i386，sun4u，Solaris 10 / i386，amd64，sun4v。

? MacOS X / ppc，i386。

? Windows XP，Windows Server 2003。

作 者 声 明

本书的内容是我在工作中的一个总结，在生产环境中都使用过，并非纸上谈兵，但是书中的例子，我尽可能地不使用生产环境中的例子，一是怕对你造成误导，二是不想说什么是权威。

我在前面说了文稿内容的来源，对于文稿的构成，一部分是对员工培训的文稿，一部分是在培训中心的文案，还有一部分是我在学习中的笔记，由这三部分融合而成，而非简单的拼凑。

另外，毕竟我们都是做互联网的，每天面对着无数个页面，我所要说的是，如果读者在阅读本书的过程中发现有和网络上相似的内容，那么确定一下是否是两者（即笔者和您看到大文章的作者）参考了同一个官方的资料，本人绝对没有有意抄袭其他作者的内容，这是第一；第二，如果真的是我写的内容确实是和您的内容有相同之处，那么及时和我联系（绝对是缘分！）；第三，互联网给了我们发展，也给了我们交流，如果您在看本书的过程中发现有个别说法、提法和您的相同，那么请您海涵，往往是一个提法、说法用久了就觉得是自己的说法了（我相信谁都会犯这种错！）；第四，由于本人是做运维（系统管理和网络管理），因此在写作风格上也是按照自己的认知过程所写，既没有受过专业的训练也没有模仿某个作者或者某个作品的写作风格，如果真的和您的写作风格相同，那么绝对是巧合（这个就不要计较了！）；第五，本套书中引用了互联网的一些内容，由于同一个内容被转来转去，确实很难找到原出处，因此在引用的内容处只指明了来源于互联网。

由于本人才疏学浅，因此，对于本书难免会有疏漏和不足，因此，如果广大读者如果有什么建议和意见可以给本人发邮件：nginx_web_service@126.com。

写 给 读 者

我们告别20世纪已经10多年了，小的时候老师总对我们说：2000年后会如何如何，作为70后的我，在2000年后明白了，生活还得自己去继续，《国际歌》中有一句唱词“从来没有什么救世主”，因此，我很感谢你购买了这套书，希望你能够认真仔细地去阅读。写在书上的叫知识，而被掌握的知识才能转化为财富。我不想大谈什么给人类做多少贡献，只是觉得不要成为社会的拖累和人类的敌人就行了，我们的国家在繁荣富强，在走向文明，但殊不知文明背后就是垃圾，一个塑料袋文明了、方便了，可是看看刮风时漫天的塑料袋，不得不让我想起《水手》中的唱词“那一片被文明糟蹋过的海洋和天地”。再看看我们这个行业，我们每天在玩命地工作，公司或是单位拿着真金白银买着服务器，托管在高档次的IDC，拼死拼活地去赚钱，3～5年之后这些服务器将成为垃圾，然后又得去拿着真金白银去买服务器，看看我们服务器的市场，哪个是我们国人生产的，别和我说XX，那是二道贩子，它只是在挂着自己的羊头在卖别人的狼肉；说完了硬件我们再来看看软件，多亏了我们是在开源中生存，否则就这个软件的费用也受不了，我们还有哪一个是国产的软件，真是让我们无语。20多年的历程了，拿不出一款与世界抗衡的软件，20多年的历程了，拿不出与世界抗衡的硬件……

我向来都是把自己看做生活与工作在社会最底层的人，原则就是不成为人类的敌人，不成为国家的拖累，而我们的那些天之骄子哪里去了，能够改变人类、改变生活的人哪里去了！假学说、假学历，假履历，这又让我想起一个冯巩小品中的说辞“这年头有假的谁还用真的”。

伟大领袖毛泽东同志的诗词“天若有情天亦老，人间正道是沧桑”，传统的炼油太不容易，因此很多人就投资炼地沟油去了，十种地沟油八种合格，想的都让人跳楼，是化验的不准，还是这种地沟油就是合格，如果要是合格那么就是可以使用了，这再好不过了，废物能够再利用，那是人类的功臣才对，还可以为人类做很大的贡献；如果是化验不准，那我们的科研人员都干什么去了，是为了节约国家运营成本裁掉了？

好了，写给读者的就这些，我不再多说了，就让我们以“天若有情天亦老，人间正道是沧桑”共勉！

陶利军