# 動態共享對象(DSO)支持 Apache HTTP服務器是一個模塊化的軟件，管理員可以通過選擇服務器中包含的模塊進行功能增減。模塊可以在編譯時被靜態包含進`httpd`二進制文件，也可以編譯成獨立于`httpd`二進制文件的動態共享對象(DSO)。DSO模塊可以與服務器一起編譯，也可以用Apache擴展工具(`apxs`)單獨編譯。 本文闡述如何使用DSO模塊及其工作原理。 ## 實現 相關模塊 * `mod_so` 相關指令 * `LoadModule` Apache對獨立模塊的DSO支持是建立在只能被靜態編譯進Apache核心的`mod_so`基礎之上的，這是`core`以外唯一不能作為DSO存在的模塊，而其他所有已發布的Apache模塊，都可以通過[安裝文檔](#calibre_link-249)中闡述中的`編譯選項` `--enable-_module_=shared` 被獨立地編譯成DSO并使之生效。一個被編譯為`mod_foo.so`的DSO模塊，可以在`httpd.conf`中使用`mod_so`的`LoadModule`指令，在服務器啟動或重新啟動時被加載。 新提供的支持程序`apxs`(<dfn class="calibre27">APache eXtenSion</dfn>)可以在Apache源代碼樹_之外_編譯基于DSO的模塊，從而簡化了Apache DSO模塊的建立過程。其原理很簡單：安裝Apache時，`configure`的 `make install` 命令會安裝Apache C頭文件，并把依賴于特定平臺的編譯器和連接器參數傳給`apxs`程序，使用戶可以脫離Apache的發布源代碼樹編譯其模塊源代碼，而不改變支持DSO的編譯器和連接器的參數。 ## 用法概要 Apache2.0 的DSO功能簡要說明： 1. 編譯并安裝_已發布_的Apache模塊，比如編譯`mod_foo.c`為`mod_foo.so`的DSO模塊： ``` $ ./configure --prefix=/path/to/install --enable-foo=shared $ make install ``` 2. 編譯并安裝_第三方_模塊，比如編譯`mod_foo.c`為`mod_foo.so`的DSO模塊： ``` $ ./configure --add-module=module_type:/path/to/3rdparty/mod_foo.c --enable-foo=shared $ make install ``` 3. 配置Apache以便_以后安裝_共享模塊： ``` $ ./configure --enable-so $ make install ``` 4. 用`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()`來加載此代碼。