Apache的动态共享对象(DSO)

出自站长百科

动态共享对象(DSO)支持 Apache HTTP服务器是一个模块化的软件，管理员可以通过选择服务器中包含的模块进行功能增减。模块可以在编译时被静态包含进httpd二进制文件，也可以编译成独立于httpd二进制文件的动态共享对象(DSO)。DSO模块可以与服务器一起编译，也可以用Apache扩展工具(apxs)单独编译。

背景知识

现代的类Unix系统都有一种叫动态共享对象(DSO)的动态连接/加载的巧妙的机制，从而可以在运行时将编译成特殊格式的代码加载到一个可执行程序的地址空间。

加载的方法通常有两种：其一是在可执行文件启动时由系统程序ld.so自动加载；其二是在可执行程序中手动地通过Unix加载器的系统接口执行系统调用dlopen()/dlsym()进行加载。

按第一种方法，DSO通常被称为共享库(shared libraries)或者DSO库(DSO libraries)，使用libfoo.so或libfoo.so.1.2的文件名，存储在系统目录中(通常是/usr/lib)，并在编译安装时使用连接器参数 -lfoo 建立了指向可执行程序的连接。通过设置连接器参数 -R 或者环境变量LD_LIBRARY_PATH ，库中硬编码了可执行文件的路径，使Unix加载器能够在可执行程序启动时定位到位于/usr/lib目录中的libfoo.so ，以解析可执行文件中尚未解析的位于DSO中的符号。

通常，DSO不会引用可执行文件中的符号(因为它是通用代码的可重用库)，也不会有后继的解析动作。可执行文件无须自己作任何动作以使用DSO中的符号，而完全由Unix加载器代办(事实上，调用ld.so的代码是被连入每个可执行文件的非静态运行时启动代码的一部分)。动态加载公共库代码的优点是明显的：只需要在系统库libc.so中存储一次库代码，从而为每个程序节省了磁盘存储空间。

按第二种方法，DSO通常被称为共享对象(shared objects)或DSO文件(DSO files)，可以使用任何文件名(但是规范的名称是foo.so)，被存储在程序特定的目录中，也不会自动建立指向其所用的可执行文件的连接，而由可执行文件在运行时自己调用dlopen()来加载DSO到其地址空间，同时也不会进行为可执行文件解析DSO中符号的操作。Unix加载器会根据可执行程序的输出符号表和已经加载的DSO库自动解析DSO中尚未解析的符号(尤其是无所不在的libc.so中的符号)，如此DSO就获得了可执行程序的符号信息，就好象是被静态连接一样。

最后，为了利用DSO API的优点，可执行程序必须用dlsym()解析DSO中的符号，以备稍后在诸如指派表等等中使用。也就是说，可执行程序必须自己解析其所需的符号。这种机制的优点是允许不加载可选的程序部件，直到程序需要的时候才被动态地加载(也就不需要内存开销)，以扩展程序的功能。

虽然这种DSO机制看似很直接，但至少有一个难点，就是在用DSO扩展程序功能(第二种方法)时为DSO对可执行程序中符号的进行解析，这是因为，"反向解析"可执行程序中的DSO符号在所有标准平台上与库的设计都是矛盾的(库不会知道什么程序会使用它)。实际应用中，可执行文件中的全局符号通常不是重输出的，因此不能为DSO所用。所以在运行时用DSO来扩展程序功能，就必须找到强制连接器输出所有全局符号的方法。

共享库是一种典型的解决方法，因为它符合DSO机制，而且为操作系统所提供的几乎所有类型的库所使用。另一方面，使用共享对象并不是许多程序为扩展其功能所采用的方法。

截止到1998年，只有少数的软件包使用DSO机制在运行时扩展其功能，诸如 Perl 5(通过其XS机制和DynaLoader模块)，Netscape Server等。从1.3版本开始，Apache也加入此列，因为Apache已经用了基于指派表(dispatch-list-based)的方法来连接外部模块到Apache的核心。所以Apache也就当然地在运行时用DSO来加载其模块。

使用DSO模块及其工作原理

相关模块``mod_so
相关指令``LoadModule

Apache对独立模块的DSO支持是建立在只能被静态编译进Apache核心的mod_so基础之上的，这是core以外唯一不能作为DSO存在的模块，而其他所有已发布的Apache模块，都可以通过安装文档中阐述中的编译选项 --enable-module=shared 被独立地编译成DSO并使之生效。一个被编译为mod_foo.so的DSO模块，可以在httpd.conf中使用mod_so的LoadModule指令，在服务器启动或重新启动时被加载。

新提供的支持程序apxs(APache eXtenSion)可以在Apache源代码树之外编译基于DSO的模块，从而简化了Apache DSO模块的建立过程。其原理很简单：安装Apache时，configure的 make install 命令会安装Apache C头文件，并把依赖于特定平台的编译器和连接器参数传给apxs程序，使用户可以脱离Apache的发布源代码树编译其模块源代码，而不改变支持DSO的编译器和连接器的参数。

用法概要

Apache2.0 的DSO功能简要说明：

编译并安装已发布的Apache模块，比如编译mod_foo.c为mod_foo.so的DSO模块：
$ ./configure --prefix=/path/to/install --enable-foo=shared
$ make install

编译并安装第三方模块，比如编译mod_foo.c为mod_foo.so的DSO模块：
$ ./configure --add-module=module_type:/path/to/3rdparty/mod_foo.c --enable-foo=shared
$ make install

配置Apache以便以后安装共享模块：
$ ./configure --enable-so
$ make install

用apxs在Apache源码树以外编译并安装第三方模块，比如编译mod_foo.c为mod_foo.so的DSO模块：
$ cd /path/to/3rdparty
$ apxs -c mod_foo.c
$ apxs -i -a -n foo mod_foo.la

共享模块编译完毕后，必须在httpd.conf中用LoadModule指令使Apache启用该模块。

DSO下优点

由于服务器包的装配工作可以在运行时使用httpd.conf中的配置命令LoadModule来进行，而不是在编译中使用编译选项来进行，因此显得更灵活。比如，只需要安装一个Apache，就可以运行多个不同的服务器实例(如标准&SSL版本，浓缩&功能加强版本[mod_perl、PHP])。
服务器可以在安装后使用第三方模块被轻易地扩展。这至少对厂商发行包的维护者有巨大的好处，他可以建立一个Apache核心包，而为诸如PHP、mod_perl、mod_fastcgi等扩展另建附加的包。
更简单的Apache模块原型。使用DSO配合apxs，可以脱离Apache源代码树，仅需要一个 apxs -i 和一个 apachectl restart 命令，就可以把刚开发的新模块纳入到运行中的Apache服务器。

DSO下缺点

由于并不是所有操作系统都支持动态加载代码到一个程序的地址空间，因此DSO机制并不能用于所有平台。
由于Unix加载器必须进行符号解析，服务器的启动会慢20%左右。
在某些平台上，位置独立代码(positon independent code[PIC])需要复杂的汇编语言技巧来实现相对寻址，而绝对寻址则不需要，因此服务器在运行时会慢5%左右。
由于DSO模块不能在所有平台上被其他基于DSO的库所连接(ld -lfoo)，比如，基于a.out的平台通常不提供此功能，而基于ELF的平台则提供，因此DSO机制并不能被用于所有类型的模块。或者可以这样说，编译为DSO文件的模块只能使用由Apache核心、C库(libc)和Apache核心所用的所有其他动态或静态的库、含有独立位置代码的静态库(libfoo.a)所提供的符号。而要使用其他代码，就只能确保Apache核心本身包含对此代码的引用，或者自己用dlopen()来加载此代码。

Apache模块 mod_so

说明``允许运行时加载DSO模块
状态``扩展(E)
模块名``so_module
源文件``mod_so.c
兼容性``在Windows上这是一个基本模块(始终包含)

该模块在支持动态链接机制的操作系统上可以用来在Apache启动和重启时加载DSO模块，而不用重新编译。

在Unix上，被加载的可执行代码通常来自于共享对象文件(一般以.so为扩展名)，在Windows上则为.so或.dll扩展名。

警告用于Apache1.3的模块不能直接用于Apache2.0 。

为Windows创建可加载模块

注意从Apache1.3.15开始，Windows上的模块名规则发生了变化，现在使用mod_foo.so格式的名字。

Apache模块的API对于Unix和Windows是一样的。许多模块在这两个平台间移植几乎不需要什么修改，除非那些依赖于Unix特定属性而Windows没有提供的模块。

如果一个模块可用，那么有两种方法使用它。在Unix上，可以被静态编译进服务器。因为用于Windows的Apache并没有相应于Unix下的Configure编译配置程序，模块的源文件必须被加进ApacheCore项目文件，并且它的符号(symbols)必须被添加到os\win32\modules.c文件。

第二种方法是编译为一个动态链接库(DLL)，以便在运行期间使用LoadModule指令加载。这些模块DLL在Apache安装期间就已经安装好了，不需要你自己去编译。

为了将模块编译为DLL，需要对模块的源文件做一个小小的修改：模块记录(module record)必须从DLL导出(稍后将会创建，见下)。为了达到这个目的，请将AP_MODULE_DECLARE_DATA(在Apache头文件中定义的)添加到你的模块记录(module record)定义中。比如，如果你的模块有：

module foo_module;

将上述内容替换为：

module AP_MODULE_DECLARE_DATA foo_module;

注意，这仅在Windows上有效，因此该模块可以不加修改的直接在Unix上使用。另外，如果你对.DEF文件很熟悉，你也可以使用它代替前面的方法导出该模块。

要创建一个包含该模块的DLL文件，你还必须将它连接到在编译libhttpd.dll共享库时创建的libhttpd.lib导出库。你还可能需要修改编译器设置以确保Apache头文件被正确的加载了。
这些库位于服务器根目录下的"modules"目录中。最好是从中抓出一个已经存在的模块.dsp文件来看看以确保编译环境配置无误，或者按照.dsp文检查编译器和连接器的选项也可。

这样将会为你的模块创建一个DLL版本。只要将它放置到modules目录下，并使用LoadModule指令加载即可。

LoadFile 指令

说明``加载已命名的目标文件或库
语法``LoadFile filename [filename] ...
作用域``server config
状态``扩展(E)
模块``mod_so

该指令用于在服务器启动或者重启时加载已命名目标文件或库，以用于加载需要被某些模块使用的额外代码。Filename可以是一个绝对路径或者相对于ServerRoot的相对路径。

例如：

LoadFile libexec/libxmlparse.so

LoadModule 指令

说明``加载目标文件或库，并将其添加到活动模块列表
语法``LoadModule module filename
作用域``server config
状态``扩展(E)
模块``mod_so

该指令加载目标文件或库filename并将模块结构名module添加到活动模块列表。module就是源代码文件中用于拼写module的外部变量名，并作为模块标识符(Module Identifier)列在模块文档中。例如：

LoadModule status_module modules/mod_status.so

加载了位于ServerRoot下模块目录中指定的模块。