Apache HTTP服務(wù)器是一個模塊化的軟件，管理員可以通過選擇服務(wù)器中包含的模塊進行功能增減。
1:模塊可以在編譯時被靜態(tài)包含進httpd二進制文件，
2:也可以編譯成獨立于httpd二進制文件的動態(tài)共享對象(DSO)。
DSO模塊可以與服務(wù)器一起編譯，也可以用Apache擴展工具(apxs)單獨編譯。
本文闡述如何使用DSO模塊及其工作原理。
| 相關(guān)模塊 | 相關(guān)指令 |
|---|---|
Apache對獨立模塊的DSO支持是建立在只能被靜態(tài)編譯進Apache核心的mod_so基礎(chǔ)之上的，這是core以外唯一不能作為DSO存在的模塊，而其他所有已發(fā)布的Apache模塊，都可以通過安裝文檔中闡述中的編譯選項 --enable-module=shared 被獨立地編譯成DSO并使之生效。一個被編譯為mod_foo.so的DSO模塊，可以在httpd.conf中使用mod_so的LoadModule指令，在服務(wù)器啟動或重新啟動時被加載。
新提供的支持程序apxs(APache eXtenSion)可以在Apache源代碼樹之外編譯基于DSO的模塊，從而簡化了Apache DSO模塊的建立過程。其原理很簡單：安裝Apache時，configure的 make install 命令會安裝Apache C頭文件，并把依賴于特定平臺的編譯器和連接器參數(shù)傳給apxs程序，使用戶可以脫離Apache的發(fā)布源代碼樹編譯其模塊源代碼，而不改變支持DSO的編譯器和連接器的參數(shù)。
Apache2.0 的DSO功能簡要說明：
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
$ ./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啟用該模塊。
現(xiàn)代的類Unix系統(tǒng)都有一種叫動態(tài)共享對象(DSO)的動態(tài)連接/加載的巧妙的機制，從而可以在運行時將編譯成特殊格式的代碼加載到一個可執(zhí)行程序的地址空間。
加載的方法通常有兩種：其一是在可執(zhí)行文件啟動時由系統(tǒng)程序ld.so自動加載；其二是在可執(zhí)行程序中手動地通過Unix加載器的系統(tǒng)接口執(zhí)行系統(tǒng)調(diào)用dlopen()/dlsym()進行加載。
按第一種方法，DSO通常被稱為共享庫(shared libraries)或者DSO庫(DSO libraries)，使用libfoo.so或libfoo.so.1.2的文件名，存儲在系統(tǒng)目錄中(通常是/usr/lib)，并在編譯安裝時使用連接器參數(shù) -lfoo 建立了指向可執(zhí)行程序的連接。通過設(shè)置連接器參數(shù) -R 或者環(huán)境變量LD_LIBRARY_PATH ，庫中硬編碼了可執(zhí)行文件的路徑，使Unix加載器能夠在可執(zhí)行程序啟動時定位到位于/usr/lib目錄中的libfoo.so ，以解析可執(zhí)行文件中尚未解析的位于DSO中的符號。
通常，DSO不會引用可執(zhí)行文件中的符號(因為它是通用代碼的可重用庫)，也不會有后繼的解析動作。可執(zhí)行文件無須自己作任何動作以使用DSO中的符號，而完全由Unix加載器代辦(事實上，調(diào)用ld.so的代碼是被連入每個可執(zhí)行文件的非靜態(tài)運行時啟動代碼的一部分)。動態(tài)加載公共庫代碼的優(yōu)點是明顯的：只需要在系統(tǒng)庫libc.so中存儲一次庫代碼，從而為每個程序節(jié)省了磁盤存儲空間。
按第二種方法，DSO通常被稱為共享對象(shared objects)或DSO文件(DSO files)，可以使用任何文件名(但是規(guī)范的名稱是foo.so)，被存儲在程序特定的目錄中，也不會自動建立指向其所用的可執(zhí)行文件的連接，而由可執(zhí)行文件在運行時自己調(diào)用dlopen()來加載DSO到其地址空間，同時也不會進行為可執(zhí)行文件解析DSO中符號的操作。Unix加載器會根據(jù)可執(zhí)行程序的輸出符號表和已經(jīng)加載的DSO庫自動解析DSO中尚未解析的符號(尤其是無所不在的libc.so中的符號)，如此DSO就獲得了可執(zhí)行程序的符號信息，就好象是被靜態(tài)連接一樣。
最后，為了利用DSO API的優(yōu)點，可執(zhí)行程序必須用dlsym()解析DSO中的符號，以備稍后在諸如指派表等等中使用。也就是說，可執(zhí)行程序必須自己解析其所需的符號。這種機制的優(yōu)點是允許不加載可選的程序部件，直到程序需要的時候才被動態(tài)地加載(也就不需要內(nèi)存開銷)，以擴展程序的功能。
雖然這種DSO機制看似很直接，但至少有一個難點，就是在用DSO擴展程序功能(第二種方法)時為DSO對可執(zhí)行程序中符號的進行解析，這是因為，"反向解析"可執(zhí)行程序中的DSO符號在所有標(biāo)準(zhǔn)平臺上與庫的設(shè)計都是矛盾的(庫不會知道什么程序會使用它)。實際應(yīng)用中，可執(zhí)行文件中的全局符號通常不是重輸出的，因此不能為DSO所用。所以在運行時用DSO來擴展程序功能，就必須找到強制連接器輸出所有全局符號的方法。
共享庫是一種典型的解決方法，因為它符合DSO機制，而且為操作系統(tǒng)所提供的幾乎所有類型的庫所使用。另一方面，使用共享對象并不是許多程序為擴展其功能所采用的方法。
截止到1998年，只有少數(shù)的軟件包使用DSO機制在運行時擴展其功能，諸如 Perl 5(通過其XS機制和DynaLoader模塊)，Netscape Server等。從1.3版本開始，Apache也加入此列，因為Apache已經(jīng)用了基于指派表(dispatch-list-based)的方法來連接外部模塊到Apache的核心。所以Apache也就當(dāng)然地在運行時用DSO來加載其模塊。
上述基于DSO的功能有如下優(yōu)點：
httpd.conf中的配置命令LoadModule來進行，而不是在編譯中使用編譯選項來進行，因此顯得更靈活。比如，只需要安裝一個Apache，就可以運行多個不同的服務(wù)器實例(如標(biāo)準(zhǔn)&SSL版本，濃縮&功能加強版本[mod_perl、PHP])。 apxs，可以脫離Apache源代碼樹，僅需要一個 apxs -i 和一個 apachectl restart 命令，就可以把剛開發(fā)的新模塊納入到運行中的Apache服務(wù)器。 DSO有如下缺點：
ld -lfoo)，比如，基于a.out的平臺通常不提供此功能，而基于ELF的平臺則提供，因此DSO機制并不能被用于所有類型的模塊?；蛘呖梢赃@樣說，編譯為DSO文件的模塊只能使用由Apache核心、C庫(libc)和Apache核心所用的所有其他動態(tài)或靜態(tài)的庫、含有獨立位置代碼的靜態(tài)庫(libfoo.a)所提供的符號。而要使用其他代碼，就只能確保Apache核心本身包含對此代碼的引用，或者自己用dlopen()來加載此代碼。 