apache1.3 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中是很重要的方面-也是比较高端的内容-要用好它需要对它的原理有所了解-另本文不足之处请大家指教批评-我会在下一篇DSO模式使用篇中说明如何使用及具体实现Apache的DSO模式。