《深入理解Nginx：模块开发与架构解析》一1.5　configure详解

1.5　configure详解

可以看出，configure命令至关重要，下文将详细介绍如何使用configure命令，并分析configure到底是如何工作的，从中我们也可以看出Nginx的一些设计思想。

1.5.1　configure的命令参数

使用help命令可以查看configure包含的参数。

./configure --help

这里不一一列出help的结果，只是把它的参数分为了四大类型，下面将会详述各类型下所有参数的用法和意义。
1. 路径相关的参数
表1-2列出了Nginx在编译期、运行期中与路径相关的各种参数。

  1. 编译相关的参数
    表1-3列出了编译Nginx时与编译器相关的参数。
  2. 依赖软件的相关参数
    表1-4～表1-8列出了Nginx依赖的常用软件支持的参数。


  3. 模块相关的参数
    除了少量核心代码外，Nginx完全是由各种功能模块组成的。这些模块会根据配置参数决定自己的行为，因此，正确地使用各个模块非常关键。在configure的参数中，我们把它们分为五大类。
    事件模块。
    默认即编译进入Nginx的HTTP模块。
    默认不会编译进入Nginx的HTTP模块。
    邮件代理服务器相关的mail 模块。
    其他模块。
    （1）事件模块
    表1-9中列出了Nginx可以选择哪些事件模块编译到产品中。

（2）默认即编译进入Nginx的HTTP模块
表1-10列出了默认就会编译进Nginx的核心HTTP模块，以及如何把这些HTTP模块从产品中去除。


（3）默认不会编译进入Nginx的HTTP模块
表1-11列出了默认不会编译至Nginx中的HTTP模块以及把它们加入产品中的方法。


（4）邮件代理服务器相关的mail模块
表1-12列出了把邮件模块编译到产品中的参数。

5.其他参数
configure还接收一些其他参数，表1-13中列出了相关参数的说明。

1.5.2　configure执行流程

我们看到configure命令支持非常多的参数，读者可能会好奇它在执行时到底做了哪些事情，本节将通过解析configure源码来对它有一个感性的认识。configure由Shell脚本编写，中间会调用/auto/目录下的脚本。这里将只对configure脚本本身做分析，对于它所调用的auto目录下的其他工具脚本则只做功能性的说明。
configure脚本的内容如下：

#!/bin/sh

# Copyright (C) Igor Sysoev
# Copyright (C) Nginx, Inc.

#auto/options脚本处理configure命令的参数。例如，如果参数是--help，那么显示支持的所有参数格式。options脚本会定义后续工作将要用到的变量，然后根据本次参数以及默认值设置这些变量

. auto/options

#auto/init脚本初始化后续将产生的文件路径。例如，Makefile、ngx_modules.c等文件默认情况下将会在<nginx-source>/objs/

. auto/init


#auto/sources脚本将分析Nginx的源码结构，这样才能构造后续的Makefile文件

. auto/sources


#编译过程中所有目标文件生成的路径由—builddir=DIR参数指定，默认情况下为<nginx-source>/objs，此时这个目录将会被创建

test -d $NGX_OBJS || mkdir $NGX_OBJS

#开始准备建立ngx_auto_headers.h、autoconf.err等必要的编译文件

echo > $NGX_AUTO_HEADERS_H
echo > $NGX_AUTOCONF_ERR

#向objs/ngx_auto_config.h写入命令行带的参数
echo "#define NGX_CONFIGURE \"$NGX_CONFIGURE\"" > $NGX_AUTO_CONFIG_H

#判断DEBUG标志，如果有，那么在objs/ngx_auto_config.h文件中写入DEBUG宏
if [ $NGX_DEBUG = YES ]; then
    have=NGX_DEBUG . auto/have
fi

#现在开始检查操作系统参数是否支持后续编译
if test -z "$NGX_PLATFORM"; then
    echo "checking for OS"

    NGX_SYSTEM=`uname -s 2>/dev/null`
    NGX_RELEASE=`uname -r 2>/dev/null`
    NGX_MACHINE=`uname -m 2>/dev/null`

#屏幕上输出OS名称、内核版本、32位/64位内核
    echo " + $NGX_SYSTEM $NGX_RELEASE $NGX_MACHINE"

    NGX_PLATFORM="$NGX_SYSTEM:$NGX_RELEASE:$NGX_MACHINE";

    case "$NGX_SYSTEM" in
        MINGW32_*)
            NGX_PLATFORM=win32
        ;;
    esac

else
    echo "building for $NGX_PLATFORM"
    NGX_SYSTEM=$NGX_PLATFORM
fi

#检查并设置编译器，如GCC是否安装、GCC版本是否支持后续编译nginx
. auto/cc/conf

#对非Windows操作系统定义一些必要的头文件，并检查其是否存在，以此决定configure后续步骤是否可以成功
if [ "$NGX_PLATFORM" != win32 ]; then
    . auto/headers
fi

#对于当前操作系统，定义一些特定的操作系统相关的方法并检查当前环境是否支持。例如，对于Linux，在这里使用sched_setaffinity设置进程优先级，使用Linux特有的sendfile系统调用来加速向网络中发送文件块
. auto/os/conf

#定义类UNIX 操作系统中通用的头文件和系统调用等，并检查当前环境是否支持
if [ "$NGX_PLATFORM" != win32 ]; then
    . auto/unix
fi

最核心的构造运行期modules的脚本。它将会生成ngx_modules.c文件，这个文件会被编译进Nginx中，其中它所做的唯一的事情就是定义了ngx_modules数组。ngx_modules指明Nginx运行期间有哪些模块会参与到请求的处理中，包括HTTP请求可能会使用哪些模块处理，因此，它对数组元素的顺序非常敏感，也就是说，绝大部分模块在ngx_modules数组中的顺序其实是固定的。例如，一个请求必须先执行ngx_http_gzip_filter_module模块重新修改HTTP响应中的头部后，才能使用ngx_http_header_filter模块按照headers_in结构体里的成员构造出以TCP流形式发送给客户端的HTTP响应头部。注意，我们在--add-module=参数里加入的第三方模块也在此步骤写入到ngx_modules.c文件中了
. auto/modules

#conf脚本用来检查Nginx在链接期间需要链接的第三方静态库、动态库或者目标文件是否存在
. auto/lib/conf
``

处理Nginx安装后的路径
case ".$NGX_PREFIX" in
.)
NGX_PREFIX=${NGX_PREFIX:-/usr/local/nginx}
have=NGX_PREFIX value="\"$NGX_PREFIX/\"" . auto/define
;;

.!)
    NGX_PREFIX=
;;

*)
    have=NGX_PREFIX value="\"$NGX_PREFIX/\"" . auto/define
;;

esac

处理Nginx安装后conf文件的路径
if [ ".$NGX_CONF_PREFIX" != "." ]; then
    have=NGX_CONF_PREFIX value="\"$NGX_CONF_PREFIX/\"" . auto/define
fi

处理Nginx安装后，二进制文件、pid、lock等其他文件的路径可参见configure参数中路径类选项的说明
have=NGX_SBIN_PATH value="\"$NGX_SBIN_PATH\"" . auto/define
have=NGX_CONF_PATH value="\"$NGX_CONF_PATH\"" . auto/define
have=NGX_PID_PATH value="\"$NGX_PID_PATH\"" . auto/define
have=NGX_LOCK_PATH value="\"$NGX_LOCK_PATH\"" . auto/define
have=NGX_ERROR_LOG_PATH value="\"$NGX_ERROR_LOG_PATH\"" . auto/define

have=NGX_HTTP_LOG_PATH value="\"$NGX_HTTP_LOG_PATH\"" . auto/define
have=NGX_HTTP_CLIENT_TEMP_PATH value="\"$NGX_HTTP_CLIENT_TEMP_PATH\"" . auto/define
have=NGX_HTTP_PROXY_TEMP_PATH value="\"$NGX_HTTP_PROXY_TEMP_PATH\"" . auto/define
have=NGX_HTTP_FASTCGI_TEMP_PATH value="\"$NGX_HTTP_FASTCGI_TEMP_PATH\"" . auto/define
have=NGX_HTTP_UWSGI_TEMP_PATH value="\"$NGX_HTTP_UWSGI_TEMP_PATH\"" . auto/define
have=NGX_HTTP_SCGI_TEMP_PATH value="\"$NGX_HTTP_SCGI_TEMP_PATH\"" . auto/define

创建编译时使用的objs/Makefile文件
. auto/make

#为objs/Makefile加入需要连接的第三方静态库、动态库或者目标文件
. auto/lib/make

为objs/Makefile加入install功能，当执行make install时将编译生成的必要文件复制到安装路径，建立必要的目录
. auto/install

#在ngx_auto_config.h文件中加入NGX_SUPPRESS_WARN宏、NGX_SMP宏
. auto/stubs

在ngx_auto_config.h文件中指定NGX_USER和NGX_GROUP宏，如果执行configure时没有参数指定，默认两者皆为nobody（也就是默认以nobody用户运行进程）
have=NGX_USER value="\"$NGX_USER\"" . auto/define
have=NGX_GROUP value="\"$NGX_GROUP\"" . auto/define

#显示configure执行的结果，如果失败，则给出原因
. auto/summary

###1.5.3　configure生成的文件
当configure执行成功时会生成objs目录，并在该目录下产生以下目录和文件：
```javascript
|---ngx_auto_headers.h
|---autoconf.err
|---ngx_auto_config.h
|---ngx_modules.c
|---src
|    |---core
|    |---event
|    |    |---modules
|    |---os
|    |    |---unix
|    |    |---win32
|    |---http
|    |    |---modules
|    |    |      |---perl
|    |---mail
|    |---misc
|---Makefile

上述目录和文件介绍如下。
1）src目录用于存放编译时产生的目标文件。
2）Makefile文件用于编译Nginx工程以及在加入install参数后安装Nginx。
3）autoconf.err保存configure执行过程中产生的结果。
4）ngx_auto_headers.h和ngx_auto_config.h保存了一些宏，这两个头文件会被src/core/ngx_config.h及src/os/unix/ngx_linux_config.h文件（可将“linux”替换为其他UNIX操作系统）引用。
5）ngx_modules.c是一个关键文件，我们需要看看它的内部结构。一个默认配置下生成的ngx_modules.c文件内容如下：

#include <ngx_config.h>
#include <ngx_core.h>

…

ngx_module_t *ngx_modules[] = {
    &ngx_core_module,
    &ngx_errlog_module,
    &ngx_conf_module,
    &ngx_events_module,
    &ngx_event_core_module,
    &ngx_epoll_module,
    &ngx_http_module,
    &ngx_http_core_module,
    &ngx_http_log_module,
    &ngx_http_upstream_module,
    &ngx_http_static_module,
    &ngx_http_autoindex_module,
    &ngx_http_index_module,
    &ngx_http_auth_basic_module,
    &ngx_http_access_module,
    &ngx_http_limit_zone_module,
    &ngx_http_limit_req_module,
    &ngx_http_geo_module,
    &ngx_http_map_module,
    &ngx_http_split_clients_module,
    &ngx_http_referer_module,
    &ngx_http_rewrite_module,
    &ngx_http_proxy_module,
    &ngx_http_fastcgi_module,
    &ngx_http_uwsgi_module,
    &ngx_http_scgi_module,
    &ngx_http_memcached_module,
    &ngx_http_empty_gif_module,
    &ngx_http_browser_module,
    &ngx_http_upstream_ip_hash_module,
    &ngx_http_write_filter_module,
    &ngx_http_header_filter_module,
    &ngx_http_chunked_filter_module,
    &ngx_http_range_header_filter_module,
    &ngx_http_gzip_filter_module,
    &ngx_http_postpone_filter_module,
    &ngx_http_ssi_filter_module,
    &ngx_http_charset_filter_module,
    &ngx_http_userid_filter_module,
    &ngx_http_headers_filter_module,
    &ngx_http_copy_filter_module,
    &ngx_http_range_body_filter_module,
    &ngx_http_not_modified_filter_module,
    NULL
};

ngx_modules.c文件就是用来定义ngx_modules数组的。
ngx_modules是非常关键的数组，它指明了每个模块在Nginx中的优先级，当一个请求同时符合多个模块的处理规则时，将按照它们在ngx_modules数组中的顺序选择最靠前的模块优先处理。对于HTTP过滤模块而言则是相反的，因为HTTP框架在初始化时，会在ngx_modules数组中将过滤模块按先后顺序向过滤链表中添加，但每次都是添加到链表的表头，因此，对HTTP过滤模块而言，在ngx_modules数组中越是靠后的模块反而会首先处理HTTP响应（参见第6章及第11章的11.9节）。
因此，ngx_modules中模块的先后顺序非常重要，不正确的顺序会导致Nginx无法工作，这是auto/modules脚本执行后的结果。读者可以体会一下上面的ngx_modules中同一种类型下（第8章会介绍模块类型，第10章、第11章将介绍的HTTP框架对HTTP模块的顺序是最敏感的）各个模块的顺序以及这种顺序带来的意义。
可以看出，在安装过程中，configure做了大量的幕后工作，我们需要关注在这个过程中Nginx做了哪些事情。configure除了寻找依赖的软件外，还针对不同的UNIX操作系统做了许多优化工作。这是Nginx跨平台的一种具体实现，也体现了Nginx追求高性能的一贯风格。
configure除了生成Makefile外，还生成了ngx_modules.c文件，它决定了运行时所有模块的优先级（在编译过程中而不是编码过程中）。对于不需要的模块，既不会加入ngx_modules数组，也不会编译进Nginx产品中，这也体现了轻量级的概念。

时间： 2024-11-03 02:00:37

《深入理解Nginx：模块开发与架构解析》一1.5　configure详解的相关文章

《深入理解Nginx：模块开发与架构解析》一1.3　准备工作

1.3 准备工作 由于Linux具有免费.使用广泛.商业支持越来越完善等特点,本书将主要针对Linux上运行的Nginx来进行介绍.需要说明的是,本书不是使用手册,而是介绍Nginx作为Web服务器的设计思想,以及如何更有效地使用Nginx达成目的,而这些内容在各操作系统上基本是相通的(除了第9章关于事件驱动方式以及第14章的进程间同步方式在类UNIX操作系统上略有不同以外). 1.3.1 Linux操作系统 首先我们需要一个内核为Linux 2.6及以上版本的操作系统,因为Linux 2.6及

《深入理解Nginx：模块开发与架构解析》一3.4　HTTP模块的数据结构

3.4 HTTP模块的数据结构 定义HTTP模块方式很简单,例如: ngx_module_t ngx_http_mytest_module; 其中,ngx_module_t 是一个Nginx模块的数据结构(详见8.2节).下面来分析一下Nginx模块中所有的成员,如下所示: typedef struct ngx_module_s ngx_module_t; struct ngx_module_s { /* 下面的ctx_index.index.spare0.spare1.spare2.spare

《深入理解Nginx：模块开发与架构解析》一3.1　如何调用HTTP模块

3.1 如何调用HTTP模块 在开发HTTP模块前,首先需要了解典型的HTTP模块是如何介入Nginx处理用户请求流程的.图3-1是一个简化的时序图,这里省略了许多异步调用,忽略了多个不同的HTTP处理阶段,仅标识了在一个典型请求的处理过程中主要模块被调用的流程,以此帮助读者理解HTTP模块如何处理用户请求.完整的流程将在第11章中详细介绍.从图3-1中看到,worker进程会在一个for循环语句里反复调用事件模块检测网络事件.当事件模块检测到某个客户端发起的TCP请求时(接收到SYN包),将会

《深入理解Nginx：模块开发与架构解析》一3.9　用C++语言编写HTTP模块

3.9 用C++语言编写HTTP模块 Nginx及其官方模块都是由C语言开发的,那么能不能使用C++语言来开发Nginx模块呢?C语言是面向过程的编程语言,C++则是面向对象的编程语言,面向对象与面向过程的优劣这里暂且不论,存在即合理.当我们由于各种原因需要使用C++语言实现一个Nginx模块时(例如,某个子功能是用C++语言写成,或者开发团队对C++语言更熟练,又或者就是喜欢使用C++语言),尽管Nginx本身并没有提供相应的方法支持这样做,但由于C语言与C++语言的近亲特性,我们还是可以比较

《深入理解Nginx：模块开发与架构解析》一3.2　准备工作

3.2 准备工作 Nginx模块需要使用C(或者C++)语言编写代码来实现,每个模块都要有自己的名字.按照Nginx约定俗成的命名规则,我们把第一个HTTP模块命名为ngx_http_mytest_module.由于第一个模块非常简单,一个C源文件就可以完成,所以这里按照官方惯例,将唯一的源代码文件命名为ngx_http_mytest_module.c. 实际上,我们还需要定义一个名称,以便在编译前的configure命令执行时显示是否执行成功(即configure脚本执行时的ngx_addon

《深入理解Nginx：模块开发与架构解析》一3.3　如何将自己的HTTP模块编译进Nginx

3.3 如何将自己的HTTP模块编译进Nginx Nginx提供了一种简单的方式将第三方的模块编译到Nginx中.首先把源代码文件全部放到一个目录下,同时在该目录中编写一个文件用于通知Nginx如何编译本模块,这个文件名必须为config.它的格式将在3.3.1节中说明.这样,只要在configure脚本执行时加入参数--add-module=PATH(PATH就是上面我们给定的源代码.config文件的保存目录),就可以在执行正常编译安装流程时完成Nginx编译工作.有时,Nginx提供的这种

《深入理解Nginx：模块开发与架构解析》一2.2　Nginx配置的通用语法

2.2 Nginx配置的通用语法 Nginx的配置文件其实是一个普通的文本文件.下面来看一个简单的例子. user nobody; worker_processes 8; error_log /var/log/nginx/error.log error; #pid logs/nginx.pid; events { use epoll; worker_connections 50000; } http { include mime.types; default_type application/o

《深入理解Nginx：模块开发与架构解析》一2.6　小结

2.6 小结 Nginx由少量的核心框架代码和许多模块组成,每个模块都有它独特的功能.因此,读者可以通过查看每个模块实现了什么功能,来了解Nginx可以帮我们做些什么.Nginx的Wiki网站(http://wiki.nginx.org/Modules)上列出了官方提供的所有模块及配置项,仔细观察就会发现,这些配置项的语法与本章的内容都是很相近的,读者只需要弄清楚模块说明中每个配置项的意义即可.另外,网页http://wiki.nginx.org/3rdPartyModules中列出了Wiki上

《深入理解Nginx：模块开发与架构解析》一1.6　Nginx的命令行控制

1.6 Nginx的命令行控制 在Linux中,需要使用命令行来控制Nginx服务器的启动与停止.重载配置文件.回滚日志文件.平滑升级等行为.默认情况下,Nginx被安装在目录/usr/local/nginx/中,其二进制文件路径为/usr/local/nginc/sbin/nginx,配置文件路径为/usr/local/nginx/conf/nginx.conf.当然,在configure执行时是可以指定把它们安装在不同目录的.为了简单起见,本节只说明默认安装情况下的命令行的使用情况,如果读者