APACHE工做原理详解 （三）

Apache HTTP服务器是一个模块化的软件，使管理者能够选择核心中包含的模块以裁剪功能。能够在编译时选择被静态包含进httpd二进制映象的模块，也能够编译 成独立于主httpd二进制映象的动态共享对象DSO，DSO模块能够在编译服务器以后编译，也能够用Apache扩展工具(apxs)编译并增长。

　　本文阐述如何使用DSO模块及其工做原理。

　　工做原理

　　DSO是Dynamic Shared Objects（动态共享目标）的缩写，它是现代Unix派生出来的操做系统都存在着的一种动态链接机制。它提供了一种在运行时将特殊格式的代码，在程序 运行须要时，将须要的部分从外存调入内存执行的方法。Apache在1.3之后的版本后开始支持它。由于Apache早就使用一个模块概念来扩展它的功能 而且在内部使用一个基于调度的列表来连接扩展模块到Apache核心模块.因此,Apache早就注定要使用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子系统。

　　

　　图1 apache模块功能分层

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

　　现代类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来进行，而不是在编译中使用configure 来进行，所以显得更灵活。好比：只须要安装一个Apache，就能够运行多个不一样的服务器实例(如标准&SSL版本，浓缩的&功能增强版 本[mod_perl, PHP3]，等等)。

　　服务器包能够在安装后使用第三方模块被轻易地扩展。这至少对厂商发行包的维护者有巨大的好处，他能够创建一个Apache核心包，而为诸如PHP3, 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()来加载此代码。

　　模块实现

　　相关模块 相关指令

　　mod_so <IfModule>

　　LoadModule

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

　　用命令行参数-l能够查看已经编译到服务器中的模块。

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

　　用法概要

　　Apache 2.0的DSO功能简要说明：

　　编译并安装已发布的Apache模块，好比编译mod_foo.c为mod_foo.so的DSO模块：

　　$ ./configure --prefix=/path/to/install --enable-foo=shared

　　$ make install

　　编译并安装第三方Apache模块, 好比编译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源代码树之外编译并安装第三方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激活该模块。

　　参考资料：

　　Ralf S. Engelschall-- Apache 1.3 Dynamic Shared Object (DSO) Support

　　Apache2.0 文档-- 动态共享对象