nginx module开发5 (完结)

upstream机制

Nginx提供的upstream机制，是nginx设计理念的忠实体现。异步、无阻塞，这是nginx的追求，任何对这种设计思想的违反，都会导致nginx达不到它预期的性能，包括nginx提供的fastCGI也是如此。

 

Upstream到底用来干什么呢？就是nginx在正常的请求处理过程中，需要访问其他SERVER，这时，nginx提供了这样的机制，把底层的http通讯全部做完。最重要的是，upstream保证了在这个请求中对其他SERVER的通讯，完全是无阻塞和异步的。个人认为，如果nginx没有提供upstream，当开发者遇到这种情形要么自己写一套多路复用IO处理机制来做，要么放弃异步去调用connection里的同步方法，就不能称为真正的高性能异步WEB SERVER了。

 

Upstream实现得其实非常狭隘，因为nginx试图把upstream做成一种proxy，也就是说nginx会对其他SERVER访问后，对client的返回也接管，这个很恶心。如果你不需要这个功能，需要在ngx_http_upstream_process_header里，调用你的module处理response后就返回，不要继续向下执行。

 

Upstream有六个需要module developer实现的方法，分别是：

   ngx_int_t                     (*create_request)(ngx_http_request_t *r);

   ngx_int_t                     (*reinit_request)(ngx_http_request_t *r);

   ngx_int_t                     (*process_header)(ngx_http_request_t *r);

    void                          (*abort_request)(ngx_http_request_t *r);

    void                          (*finalize_request)(ngx_http_request_t *r,

                                        ngx_int_t rc);

   ngx_int_t                     (*rewrite_redirect)(ngx_http_request_t *r,

                                        ngx_table_elt_t *h, size_t prefix);

 

upstream在真正实现HTTP通讯时会调用到这些函数。那么upstream的是如何进行的？首先，我们需要调用ngx_http_upstream_init来开始upstream之旅了。

 

ngx_http_upstream_init首先会去调用create_request函数，这时开发者可以在这里把HTTP请求构造好。构造完请求包后，nginx会去连接remote server，这又是一个异步事件，所以需要注册回调函数为ngx_http_upstream_handler，也就是说，当连接成功建立后，nginx的epoll会调用ngx_http_upstream_handler来处理建立好的这个连接，同时把发送HTTP请求的处理函数注册为ngx_http_upstream_send_request_handler。

 

现在与remote server建立好连接了，ngx_http_upstream_handle调用ngx_http_upstream_send_request_handler来发送create_request完成的HTTP请求包了。这里实际完成发送请求任务的是ngx_http_upstream_send_request方法，而ngx_http_upstream_send_request又是调用ngx_output_chain来把请求发送出去。成功以后，开始等待读事件的来临，如果有数据返回，则调用ngx_http_upstream_process_header来处理remote server的response了，等到确认接收到完整的response后，会调用我们实现的process_header注册函数来处理response。upstream处理完后会调用注册的finalize_request函数来清理开发者需要做的工作。

 

内存使用

Nginx给用户提供了内存池功能，所以developer在使用时，应当尽量避免绕过nginx内存池来操作内存。

 

这里不去分析nginx内存池的实现，只简要的说明如何使用它。

申请一块内存时，必须先拿到内存池的指针，然后传入内存块大小，nginx实际上会移动指针指向内存池中的空闲内存，如果失败则返回NULL，内存池大小有限且可配，所以我们必须每次申请内存都要检查是否申请成功。

我们看下最简单的一个分配buf函数：

ngx_buf_t *

ngx_create_temp_buf(ngx_pool_t *pool, size_t size)

{

    ngx_buf_t*b;

    b =ngx_calloc_buf(pool);

    if (b ==NULL) {

        returnNULL;

    }

    b->start= ngx_palloc(pool, size);

    if(b->start == NULL) {

        returnNULL;

    }

    b->pos =b->start;

    b->last= b->start;

    b->end =b->last + size;

   b->temporary = 1;

    return b;

}

 

可以看到，很简单的从内存池中申请到，释放则由pool自动进行，很好的垃圾回收机制。

配置文件的使用

在ngx_command_t中，定义好需要读取的配置项名称，以及处理该配置项的方法，这样就可以nginx.conf里放置相应的配置项，在module里使用。

 

例如：

在nginx.conf里加入下行配置：

dmsargname dcname filesize blobid;

 

则需要在module里的ngx_command_t数组里分配如下：

         {

                  ngx_string("dmsargname"),

         NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF|NGX_HTTP_LMT_CONF|NGX_CONF_TAKE1234,

                  ngx_read_dmsargname,

                  NGX_HTTP_LOC_CONF_OFFSET,

                  offsetof(ngx_webex_DMD_loc_conf_t,argnameFromDC),

                  NULL

         },     

实际的处理函数为ngx_read_dmsargname。NGX_CONF_TAKE1234意为最多读取四个参数。

 

读取参数函数简易实现：

static char * /* {{{ ngx_read_datastore */

ngx_read_dmsargname(ngx_conf_t *cf, ngx_command_t*cmd, void *conf)

{

         ngx_http_core_loc_conf_t    *clcf;

         ngx_webex_DMD_loc_conf_t  *ulcf = conf;

         ngx_str_t                   *value;

         value =cf->args->elts;

         clcf =ngx_http_conf_get_module_loc_conf(cf, ngx_http_core_module);

         ulcf->argnameFromDC= value[1];

         ulcf->argnameFilesize= value[2];

         ulcf->argnameBlobID= value[3];

    returnNGX_CONF_OK;

}

 

Nginx封装的常用数据结构

这个必须要说下，因为处理http请求时，必须处理head，无论是读取head还是插入head，都需要和ngx_list_t这个数据结构打交道，nginx框架是把head都放到ngx_list_t                      headers;数据结构里的。

 

list一共有三种操作：

ngx_list_create();//创建及初始化队列

ngx_list_init();       //初始化队列

ngx_list_push();//找到下一个插入位置的指针并返回

很明显，设计者为了灵活性，没有提供遍历方法，那么首先，应该怎么遍历它？比如，拿到一个request后，最应该先分析head了。

 

画个图看看：

ngx_list_t

pool

nalloc

size

part

last

<!--[if gte vml 1]> <![endif]-->

ngx_list_part_s

nelts

elts

next

<!--[if gte vml 1]> <![endif]-->

ngx_table_elt_t

Key

Value

Hash

lowcase

 

图表 <!--[if supportFields]> SEQ 图表 /* ARABIC <![endif]-->5<!--[if supportFields]><![endif]-->-nginx封装的list结构

 

当然ngx_table_elt_t结构只是head里的ngx_list_t所用，实际上每个元素可以是任意类型，由elts指针所指。

 

ngx_list_t里的nalloc和size，分别表示元素桶的数量和每个元素的大小，所以这里大家可以看出，该数据结构是定长内存组成的了吧。元素桶这个概念，大家可以理解为ngx_list_part_s结构，这个结构里可以保存多个元素，元素数量由nelts决定。每个元素是由ngx_list_part_s->elts指向的，长度为ngx_list_t->size

 

给段遍历list取得每个head的代码看看：

         part =&r->upstream->headers_in.headers.part;

         header= part->elts;

         for (i= 0; /* void */; i++) {

                 if (i >= part->nelts) {

                     if (part->next == NULL) {

                         break;

                     }

                     part = part->next;

                     header = part->elts;

                     i = 0;

                 }

                  if(header[i].hash == 0) {

                     continue;

                 }

                  //header[i].key就是head的名字，header[i].value就是head的值了

}

 

总结

开发nginx module，可以非常灵活的实现自己需要的功能。很多时候我们需要修改源码才能实现自己的特定功能，比如，nginx的thumbnail resize功能，不支持实时的对每一个请求按照指定的size来压缩，实际上在它的代码中完全可以做到，只需要稍微修改下源码而已。

又如upstream，nginx把它当足是个proxy机制，如果我们想让它只做为异步网络调用，也只需要在upstream_process_header里做些改动。

 

在需要某些特殊的功能时，我们最应该首先阅读nginx的源码，通常都会发现很多意想不到的收获。

 

Nginx的性能确实不错，对http协议的处理也很高效，在我们需要高性能webserver时，应该去优先考虑它。