Apache之DSO小解

对DSO的理解还不是特别深刻，所以把自己查来的资料整理一下并想就此作一个总结。暂时先把资料堆到blog里面了，有时间再整理总结。

 

一、以下源于《Apache HTTP Server Version 2.2 文档》

 

动态共享对象(DSO)支持

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

本文阐述如何使用 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 启用该模块。

 

背景知识

现代的类 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 的功能有如下优点：

由于服务器包的装配工作可以在运行时使用 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系统管理实用技巧集（2）》

 

在网上的中文Apche技术资料里基本没有这方面的内容--而它在Apache的体系结构中占据越来越重要的地位（在Apache1.3.17 for win32版本中-DSO已经是默认的安装模式了）。

      那么DSO究竟是什么？事实上DSO是Dynamic Shared Objects（动态共享目标）的缩写，它是现代Unix派生出来的操作系统都存在着的一种动态连接机制。它提供了一种在运行时将特殊格式的代码，在程序运行需要时，将需要的部分从外存调入内存执行的方法。Apache在1.3以后的版本后开始支持它。因为Apache早就使用一个模块概念来扩展它的功能并且在内部使用一个基于调度的列表来链接扩展模块到Apache核心模块.所以,Apache早就注定要使用DSO来在运行时加载它的模块。

      在mod_ssl和mod_rewrite的作者Ralf S. Engelschall（在我看来他是真正的Apache大师和主要开发者之一，他的个人主页上 的名篇“Apache 1.3 Dynamic Shared Object (DSO) Support”中对DSO模式的原理有着比较详尽的叙述（本文基本基于此）。

让我们先来看一下Apache本身的程序结构：这是一个很复杂的四层结构--每一层构建在下一层之上。

第四层是用Apache模块开发的第三方库--比如open ssl一般来说在Apache的官方发行版中这层是空的，但是在实际的Apache结构中这些库构成的层结构肯定是存在的。

第三层是一些可选的附加功能模块--如mod_ssl,mod_perl。这一层的每个模块通常实现的是Apache的一个独立的分离的功能而事实上这些模块没有一个是必须的，运行一个最小的Apache不需要任何一个此层的模块。

第二层是Apache的基本功能库-这也是Apache的核心本质层--这层包括Apache内核，http_core(Apache的核心模块）,它们实现了基本HTTP功能（比如资源处理（通过文件描述符和内存段等等），保持预生成（pre-forked)子进程模型，监听已配置的虚拟服务器的TCP/IP套接字，传输HTTP请求流到处理进程，处理HTTP协议状态，读写缓冲，此外还有附加的许多功能比如URL和MIME头的解析及DSO的装载等），也提供了Apache的应用程序接口（API)（其实Apache的真正功能还是包含在内部模块中的，为了允许这些模块完全控制Apache进程，内核必须提供API接口）,这层也包括了一般性的可用代码库（libap)和实现正则表达式匹配的库（libregex)还有就是一个小的操作系统的抽象库（libos)。

最低层是与OS相关的平台性应用函数，这些OS可以是不同现代UNIX的变种，win32,os/2,MacOS甚至只要是一个POSIX子系统。

在这个复杂的程序结构中有趣的部分是---事实上第三层和第四层与第二层之间是松散的连接，而另一方面第三层的模块间是互相依赖的--因这种结构造成的显著影响就是第三层和第四层的代码不能静态地连接到最低层平台级的代码上。因此DSO模式就成了解决它的一种手段。结合DSO功能，这个结构就变得很灵活了，可以让Apache内核（从技术上说应该是mod_so模块而不是内核）在启动时（而不是安装时）装载必要的部分以实现第三层和第四层的功能。

DSO在程序运行时将需要的部分从外存调入内存执行存取通常会有两种途径：一种是ld由系统在程序开始时自动载入，这种载入可以由两种途径实现:一种是自动由系统在可执行程序开始时调用ld.so来执行。另一种是手动，是通过在执行程序里程序系统界面到Unix装载程序通过系统调用tdlopen()/dlsym()来执行的.

那么具体来说Apache是怎么实现DSO功能的呢？DSO支持调用特别的Apache模块是基于一个名叫mod_so.c的模块，这个模块必须静态的编译Apache的核心。这是除了http_core.c以外仅有的模块不可以被放到DSO自己(bootstrapping!)。 实际上所有的别的发布的Apache模块都可以被放置到DSO，通过个别的通过设置被DSO建立允许--允许可能的-共享设置(看顶层的INSTALL文件)或者通过改变AddModule命令在你的src/Configuration到SharedModule命令(看src/INSTALL文件)。

在编译一个模块到一个名字叫mod_foo.so的DSO以后，你能够使用mod_so的LoadModule命令在你的httpd.conf文件里在服务程序开始时或重新启动以后调用这个模块。

为了简化这种为了Apache模块而创建DSO文件的方法(尤其是第三方模块)，一个新的名叫apxs的支持程序(APache eXtenSion)被使用.它可以用来建立基于DSO的模块，模块位于Apache源码树以外。这个思路很简单:当安装Apache时，设置使安装程序安装Apache C 头文件并且放置平台支持的编译器和链接程序标志，用来建立DSO文件到apxs程序。通过这种方法，用户可以使用apxs来编译它的Apache模块源代码而不用Apache发布源代码树并且不用手动的添加平台支持的编译程序和谅解程序的标志来获得DSO支持。

为了放置编译好的apache核心程序到一个DSO库(仅仅在一些支持的平台上需要强迫链接程序输出Apache核心的地址码--一个DSO模块化的先决条件)规定的SHARED_CORE必须能够通过设置--允许-规定=SHARED_CORE设置(看顶层的INSTALL文件)或者通过改变Rule命令，在你的Configuration 文件里规定SHARED_CORE=yes (看src/INSTALL文件).Apache核心代码接着被放置到一个名叫libhttpd.so的DSO库。因为静态库不能够在所有的平台上被链接成为一个DSO，一个附加的名叫 libhttpd.ep的可执行程序被创建，这个程序不但包含这个静态代码而且有提供main()剩余部分 的功能.最后，httpd程序自己被用bootstrapping代码替换，后者自动确定Unix调度程序能够装载并且开始libhttpd.ep，它通过提供LD_LIBRARY_PATH到libhttpd.so的方法实现.

最后我们再来说说Apache DSO模式支持的平台和它的优缺点--应该说目前DSO模式基本可运行在任何unix平台上--除了ultrix(因为它没有动态（库）装载器即：No dlopen-style interface under this platform).它的优点是服务器包能够在运行时更加灵活并且服务器包能够简单的用第三方模块来扩展，那怕是在安装之后。但同时DSO模式也有一些缺点如：

1、不能工作在所有平台下比如刚才说的不支持动态连接的ultrix。
2、Apache会在启动时慢大约20%,因为要做一些前置作业，而地址码的解决现在需要UNIX调度程序来做。 服务器在某些平台在执行时会慢5%，因为相对地址代码(PIC)有时在不必要时也会需要重新编译相对寻址,所以没有绝对地址快.因此有时DSO不会提高速度。
3、因为DSO模块会在个别平台上与别的基于DSO的库(ld -lfoo)发生冲突(例如a.out-based 平台经常不支持这个功能，但是ELF-based平台支持)你不能为所有类型的模块使用DSO机制(即不是所有的DSO模块都能被加载）。 或者换一句话说，模块作为DSO文件编译是受限制，只能使用APACHE核心地址码，APACHE核心使用的C库(libc)和所有的别的动态和静态的库，或者静态库档案(libfoo.a)包含的独立的代码。唯一使用别的代码的办法是或者确定APACHE核心自己早就包含自己的参考，通过dlopen（）调用代码自己，或者在建立APACHE时允许SHARED_CHAIN规则（当你的平台支持不用DSO库链接DSO文件）。

在一些平台下(许多SVR4系统)在链接Apache httpd可执行程序时没有办法强迫链接程序输出所有全部的DSO所用的地址.但是没有可见的Apache核心地址码就没有标准的Apache模块能够作为DSO使用.唯一的办法是使用SHARED_CORE特性，因为这种方法使全部的地址码都被强制输出。作为结果，Apache src/Configure script自动强制SHARED_CORE在这些平台上，当DSO特性被用在Configuration文件或者在configure命令行.

谈了这么多--都是原理性的东西-其实DSO在Apache中是很重要的方面-也是比较高端的内容-要用好它需要对它的原理有所了解-另本文不足之处请大家指教批评。

-----注：参考文献

Ralf S. Engelschall--
Apache 1.3 Dynamic Shared Object (DSO) Support 软件屋linux之家的中文翻译。