nginx模块开发入门（二） -1 Overview
1.High-Level Overview of Nginx's Module Delegation
1. Nginx模块概述
Nginx的模块有三种角色：
* handlers 处理http请求并构造输出
* filters 处理handler产生的输出
* load-balancers 当有多于一个的后端服务器时，选择一台将http请求发送过去
许多可能你认为是web server的工作，实际上都是由模块来完成的：任何时候，Nginx提供文件或者转发请求到另一个server，都是通过handler来实现的；而当需要Nginx用gzip压缩输出或者在服务端加一些东东的话，filter就派上用场了；Nginx的core模块主要管理网络层和应用层协议，并启动针对特定请求的一系列后续模块。这种分散式的体系结构使得由你自己来实现强大的内部单元成为了可能。
注意：不像Apache的模块那样，Nginx的模块都不是动态链接的。（换句话说，Nginx的模块都是静态编译的）
模块是如何被调用的呢?具体地说，当server启动时，每一个handler都有机会去处理配置文件中的location定义，如果有多个 handler被配置成需要处理某一特定的location时，只有其中一个handler能够“获胜”（掌握正确配置规则的你，当然不希望这样的冲突发生）。
一个handler有三种返回方式：正常；错误；放弃处理转由默认的handler来处理（典型地如处理静态文件的时候）。
如果handler的作用是把请求反向代理到后端服务器，那么就是刚才说的模块的第三种角色load-balancer了。load-balancer主要是负责决定将请求发送给哪个后端服务器。Nginx目前支持两种load-balancer模块：round-robin（轮询，处理请求就像打扑克时发牌那样）和IP hash（众多请求时，保证来自同一ip的请求被分发的同一个后端服务器）。
如果handler返回（译者注：就是http响应，即filter的输入）正确无误，那么fileter就被调用了。每个location配置里都可以添加多个filter，所以说（比如）响应可以被压缩和分块。多个filter的执行顺序是编译时就确定了的。filter采用了经典的“接力链表（CHAIN OF RESPONSIBILITY）”模式：一个filter被调用并处理，接下来调用下一个filter，直到最后一个filter被调用完成，Nginx才真正完成响应流程。
最帅的部分是在 filter链中，每个filter不会等待之前的filter完全完工，它可以处理之前filter正在输出的内容，这有一点像Unix中的管道。 Filter的操作都基于buffers，buffer通常情况下等于一个页的大小（4k),你也可以在nginx.conf里改变它的大小。这意味着，比如说，模块可以在从后端服务器收到全部的响应之前，就开始压缩这个响应并流化(stream to)给客户端了。好牛逼啊~
总结一下上面的内容，一个典型的周期应当是这样的：
我之所以说“典型地”是因为Ngingx的模块具有很强的定制性。模块开发者需要花很多精力精确定义模块在何时如何产生作用（我认为是件不容易的事）。模块调用实际上是通过一系列的回调函数做到的，很多很多。名义上来说，你的函数可以在以下时候被执行：
* server读取配置文件之前
* 读取location和server的每一条配置指令
* 当Nginx初始化main配置段时
* 当Nginx初始化server配置段时（例如：host/port）
* 当Nginx合并server配置和main配置时
* 当Nginx初始化location配置时
* 当Nginx合并location配置和它的父server配置时
* 当Nginx的主进程启动时
* 当一个新的worker进程启动时
* 当一个worker进程退出时
* 当主进程退出时
* handle 一个请求
* Filter响应头
* Filter响应体
* 选择一个后端服务器
* 初始化一个将发往后端服务器的请求
* 重新-初始化一个将发往后端服务器的请求
* 处理来自后端服务器的响应
* 完成与后端服务器的交互
难以置信！有这么多的功能任你处置，而你只需仅仅通过多组有用的钩子（由函数指针组成的结构体）和相应的实现函数。让我们开始接触一些模块吧。
原文： http://www.evanmiller.org/nginx-modules-guide.html
1. Nginx模块概述
Nginx的模块有三种角色：
* handlers 处理http请求并构造输出
* filters 处理handler产生的输出
* load-balancers 当有多于一个的后端服务器时，选择一台将http请求发送过去
许多可能你认为是web server的工作，实际上都是由模块来完成的：任何时候，Nginx提供文件或者转发请求到另一个server，都是通过handler来实现的；而当需要Nginx用gzip压缩输出或者在服务端加一些东东的话，filter就派上用场了；Nginx的core模块主要管理网络层和应用层协议，并启动针对特定请求的一系列后续模块。这种分散式的体系结构使得由你自己来实现强大的内部单元成为了可能。
注意：不像Apache的模块那样，Nginx的模块都不是动态链接的。（换句话说，Nginx的模块都是静态编译的）
模块是如何被调用的呢?具体地说，当server启动时，每一个handler都有机会去处理配置文件中的location定义，如果有多个 handler被配置成需要处理某一特定的location时，只有其中一个handler能够“获胜”（掌握正确配置规则的你，当然不希望这样的冲突发生）。
一个handler有三种返回方式：正常；错误；放弃处理转由默认的handler来处理（典型地如处理静态文件的时候）。
如果handler的作用是把请求反向代理到后端服务器，那么就是刚才说的模块的第三种角色load-balancer了。load-balancer主要是负责决定将请求发送给哪个后端服务器。Nginx目前支持两种load-balancer模块：round-robin（轮询，处理请求就像打扑克时发牌那样）和IP hash（众多请求时，保证来自同一ip的请求被分发的同一个后端服务器）。
如果handler返回（译者注：就是http响应，即filter的输入）正确无误，那么fileter就被调用了。每个location配置里都可以添加多个filter，所以说（比如）响应可以被压缩和分块。多个filter的执行顺序是编译时就确定了的。filter采用了经典的“接力链表（CHAIN OF RESPONSIBILITY）”模式：一个filter被调用并处理，接下来调用下一个filter，直到最后一个filter被调用完成，Nginx才真正完成响应流程。
最帅的部分是在 filter链中，每个filter不会等待之前的filter完全完工，它可以处理之前filter正在输出的内容，这有一点像Unix中的管道。 Filter的操作都基于buffers，buffer通常情况下等于一个页的大小（4k),你也可以在nginx.conf里改变它的大小。这意味着，比如说，模块可以在从后端服务器收到全部的响应之前，就开始压缩这个响应并流化(stream to)给客户端了。好牛逼啊~
总结一下上面的内容，一个典型的周期应当是这样的：
客户端发送HTTP request → Nginx基于location的配置选择一个合适的handler → (如果有) load-balancer选择一个后端服务器 → Handler处理请求并顺序将每一个响应buffer发送给第一个filter → 第一个filter讲输出交给第二个filter → 第二个给第三个 → 第三个给第四个 → 以此类推 → 最终响应发送给客户端
我之所以说“典型地”是因为Ngingx的模块具有很强的定制性。模块开发者需要花很多精力精确定义模块在何时如何产生作用（我认为是件不容易的事）。模块调用实际上是通过一系列的回调函数做到的，很多很多。名义上来说，你的函数可以在以下时候被执行：
* server读取配置文件之前
* 读取location和server的每一条配置指令
* 当Nginx初始化main配置段时
* 当Nginx初始化server配置段时（例如：host/port）
* 当Nginx合并server配置和main配置时
* 当Nginx初始化location配置时
* 当Nginx合并location配置和它的父server配置时
* 当Nginx的主进程启动时
* 当一个新的worker进程启动时
* 当一个worker进程退出时
* 当主进程退出时
* handle 一个请求
* Filter响应头
* Filter响应体
* 选择一个后端服务器
* 初始化一个将发往后端服务器的请求
* 重新-初始化一个将发往后端服务器的请求
* 处理来自后端服务器的响应
* 完成与后端服务器的交互
难以置信！有这么多的功能任你处置，而你只需仅仅通过多组有用的钩子（由函数指针组成的结构体）和相应的实现函数。让我们开始接触一些模块吧。
原文： http://www.evanmiller.org/nginx-modules-guide.html