特性：

模块化设计，较好的扩展性
高可靠性
支持热部署：不停机更新配置文件，升级版本，更换日志文件
低内存消耗：10000个keep-alive连接模式下的非活动连接，仅需2.5M内存
event-driven,aio,mmap，sendfile

基本功能：

静态资源的web服务器
http协议反向代理服务器
pop3/imap4协议反向代理服务器
FastCGI(LNMP),uWSGI(python)等协议
模块化（非DSO），如zip，SSL模块

nginx的程序架构：

web服务相关的功能：

虚拟主机（server）
支持 keep-alive 和管道连接
访问日志（支持基于日志缓冲提高其性能）
url rewirte
路径别名
基于IP及用户的访问控制
支持速率限制及并发数限制
重新配置和在线升级而无须中断客户的工作进程
Memcached 的 GET 接口

一个Master主进程管理多个worker进程，worker再并发处理并相应用户请求

正反向代理流程图：

“`代理，字面意义上来说，他就是相当于一个中间人这么个概念。
带到项目中也一样，那么来这样一个比喻。
用户（客户端） 代理（正，反） ?提供者（服务端）。

`正向代理`

把整个流程比如成去饭店吃饭，我们也就是用户（客户端）去饭店吃饭（发送一个请求），你知道你要吃的是鱼香肉丝（请求），可是你不能自己做，那么就需要让大厨（服务端）给你做 ，可是去了饭店，大厨是在后台的，你也不能直接去告诉大厨，因为你没有权限（服务端在后台）这时候就需要服务员（代理）来帮忙告诉说某某某客户（客户端）要一盘鱼香肉丝（请求/访问资源）大厨（服务端）收到给做好然后交给服务员（代理）服务员拿到鱼香肉丝（资源/响应）给客户（用户端）送回来。
好，简单的流程结束。这样大家明白代理的作用了吧。

`反向代理`

继续比喻，说我们（客户端）今天要在你饭店吃一个大闸蟹（请求），服务员（代理）收到这个请求发现大厨做不了这个大闸蟹，可是又需要挣钱，这怎么办呢？服务员这么一想，隔壁那家饭店可以做，而我也和那家大厨（另一个服务端）有交集，那我去让另一家大厨给做怎么样？好。于是服务员就去告诉另一家大厨说你帮我做一个大闸蟹（请求）吧，隔壁大厨说好呀，可以。就做好交给服务员。那么这个时候，这个服务员（反向代理）就成为了反向代理，因为他去调用别的服务端。这个时候我们（客户端）通常来说是没必要知道这大闸蟹怎么来的，只要有就好。

`注意：`

那这个服务员是谁都可以当的吗？肯定不可以呀，所以这个服务员（代理）需要在饭店任职（配置）之后才可以。也就是代理需要配置。
那么反向代理需要吗？答案是不需要的，自己思考就会明白。
那么反向代理的优点就体现出来了，我不需要配置，而且我不仅只能在一家调用请求，我可以向多个服务端去发出请求。而且反向代理还可以向多台后端服务器进行负载平衡。
“`

转载请注明：黑夜 » nginx系列之(二)介绍(特性、功能、反向代理)