httpd.conf文件詳解（上）

    Apache服務器的設置文件位於/etc/httpd/conf/目錄下，傳統上使用三個配置文件httpd.conf,access.conf和srm.conf，來配置Apache服務器的行爲。

    httpd.conf提供了最基本的服務器配置，是對守護程序httpd如何運行的技術描述；srm.conf是服務器的資源映射文件，告訴服務器各類文件的MIME類型，以及如何支持這些文件；access.conf用於配置服務器的訪問權限，控制不一樣用戶和計算機的訪問限制；這三個配置文件控制着服務器的各個方面的特性，所以爲了正常運行服務器便須要設置好這三個文件。

    除了這三個設置文件以外，Apache還使用mime.types文件用於標識不一樣文件對應的MIME類型， magic文件設置不一樣MIME類型文件的一些特殊標識，使得Apache 服務器從文檔後綴不能判斷出文件的MIME 類型時，能經過文件內容中的這些特殊標記來判斷文檔的MIME類型。

    事實上當前版本的Apache將原來httpd.conf、srm.conf與access.conf中的全部配置參數均放在了配置文件 httpd.conf和conf/extra/httpd-default.conf中，只是爲了與之前的版本兼容的緣由（使用這三個設置文件的方式來源於NCSA-httpd），才使用三個配置文件。而提供的access.conf和srm.conf文件中沒有具體的設置。

     因爲在新版本的Apache中，全部的設置都被放在了httpd.conf和conf/extra/httpd-default.conf中，所以只須要調整這個文件中的設置。

    如下使用缺省提供的 httpd.conf爲例，解釋Apache服務器的各個設置選項。然而沒必要由於它提供設置的參數太多而煩惱，基本上這些參數都很明確，也能夠不加改動運行Apache服務器。但若是須要調整Apache服務器的性能，以及增長對某種特性的支持，就須要瞭解這些設置參數的含義。

    關於Apache服務器的性能，在Internet上存在很大的爭議，基本上使用Apache的使用者幾乎都不懷疑它的優秀性能， Apache也支撐了不少著名的高負載的網站，可是在商業機構的評測中，Apache每每得分不高。

    不少人指出，在這些評測中，商業Web服務器及其操做系統每每由其專業公司的工程師進行過性能調整，而Free 的操做系統和Web服務器每每就使用其缺省配置或僅僅做很小的更改。

    須要指出的是，除了操做系統的性能調整以外，Apache 服務器自己的缺省配置毫不是最優化和最高效的，而是要適應幾乎全部種類操做系統、全部種類硬件下的設置，多平臺的軟件不可能爲特定平臺和特定硬件提供最優化的缺省配置。所以要使用Apache的時候，性能調整是必不可少的。

HTTP守護進程的運行參數

     httpd.conf中首先定義了一些httpd守護進程運行時須要的參數，來決定其運行方式和運行環境。

　　ServerType standalone

　　ServerType定義服務器的啓動方式，缺省值爲獨立方式standalone，httpd服務器將由其自己啓動，並駐留在主機中監視鏈接請求。在Linux下將在啓動文件 /etc/rc.d/rc.local/init.d/apache中自動啓動Web服務器，這種方式是推薦設置。

　　啓動Apache服務器的另外一種方式是inet方式，使用超級服務器inetd監視鏈接請求並啓動服務器。當須要使用inetd啓動方式時，便須要更改成這個設置，並屏蔽/etc/rc.d/rc.local/init.d/apache文件，以及更改/etc/inetd.conf並重起 inetd，那麼Apache就能從inetd中啓動了。

　　兩種方式的區別是獨立方式是由服務器自身管理本身的啓動進程，這樣在啓動時能當即啓動服務器的多個副本，每一個副本都駐留在內存中，一有鏈接請求不須要生成子進程就能夠當即進行處理，對於客戶瀏覽器的請求反應更快，性能較高。而 inetd方式要由inetd發現有鏈接請求後纔去啓動http服務器，因爲inetd 要監聽太多的端口，所以反應較慢、效率較低，但節約了沒有鏈接請求時Web服務器佔用的資源。所以inetd方式只用於偶爾被訪問而且不要求訪問速度的服務器上。事實上inetd方式不適合http的突發和多鏈接的特性，由於一個頁面可能包含多個圖象，而每一個圖象都會引發一個鏈接請求，即便雖然訪問人數形成教少，但瞬間的鏈接請求並很多，這就受到inetd性能的限制，甚至會影響由inetd啓動的其餘服務器程序。

　　ServerRoot "/usr/local"

　　ServerRoot用於指定守護進程httpd的運行目錄，httpd在啓動以後將自動將進程的當前目錄改變爲這個目錄，所以若是設置文件中指定的文件或目錄是相對路徑，那麼真實路徑就位於這個ServerRoot定義的路徑之下。

　　因爲httpd會常常進行併發的文件操做，就須要使用加鎖的方式來保證文件操做不衝突，因爲NFS文件系統在文件加鎖方面能力有限，所以這個目錄應該是本地磁盤文件系統，而不該該使用NFS文件系統。

 

　　#LockFile /var/run/httpd.lock

　　LockFile參數指定了httpd守護進程的加鎖文件，通常不須要設置這個參數， Apache服務器將自動在ServerRoot下面的路徑中進行操做。但若是ServerRoot爲NFS文件系統，便須要使用這個參數指定本地文件系統中的路徑。

 

　　PidFile /var/run/httpd.pid

　　PidFile指定的文件將記錄httpd守護進程的進程號，因爲httpd能自動複製其自身，所以系統中有多個httpd進程，但只有一個進程爲最初啓動的進程，它爲其餘進程的父進程，對這個進程發送信號將影響全部的httpd進程。PidFILE定義的文件中就記錄httpd父進程的進程號。

 

　　ScoreBoardFile /var/run/httpd.scoreboard

　　httpd使用ScoreBoardFile來維護進程的內部數據，所以一般不須要改變這個參數，除非管理員想在一臺計算機上運行幾個 Apache服務器，這時每一個Apache服務器都須要獨立的設置文件htt pd.conf，並使用不一樣的ScoreBoardFile。

 

　　#ResourceConfig conf/srm.conf

　　#AccessConfig conf/access.conf

　　這兩個參數ResourceConfig和AccessConfig，就用於和使用 srm.conf 和 access.conf 設置文件的老版本Apache兼容。若是沒有兼容的須要，能夠將對應的設置文件指定爲/dev/null，這將表示不存在其餘設置文件，而僅使用 httpd.conf 一個文件來保存全部的設置選項。

 

　　Timeout 300

　　Timeout定義客戶程序和服務器鏈接的超時間隔，超過這個時間間隔（秒）後服務器將斷開與客戶機的鏈接。

 

　　KeepAlive On

　　在HTTP 1.0中，一次鏈接只能做傳輸一次HTTP請求，而KeepAlive參數用於支持HTTP 1.1版本的一次鏈接、屢次傳輸功能，這樣就能夠在一次鏈接中傳遞多個HTTP請求。雖然只有較新的瀏覽器才支持這個功能，但仍是打開使用這個選項。

　

　　MaxKeepAliveRequests 100

　　MaxKeepAliveRequests爲一次鏈接能夠進行的HTTP請求的最大請求次數。將其值設爲0將支持在一次鏈接內進行無限次的傳輸請求。事實上沒有客戶程序在一次鏈接中請求太多的頁面，一般達不到這個上限就完成鏈接了。

 

　　KeepAliveTimeout 15

　　KeepAliveTimeout測試一次鏈接中的屢次請求傳輸之間的時間，若是服務器已經完成了一次請求，但一直沒有接收到客戶程序的下一次請求，在間隔超過了這個參數設置的值以後，服務器就斷開鏈接。

  　 MinSpareServers 5

　　MaxSpareServers 10

　　在使用子進程處理HTTP請求的Web服務器上，因爲要首先生成子進程才能處理客戶的請求，所以反應時間就有一點延遲。可是，Apache服務器使用了一個特殊技術來擺脫這個問題，這就是預先生成多個空餘的子進程駐留在系統中，一旦有請求出現，就當即使用這些空餘的子進程進行處理，這樣就不存在生成子進程形成的延遲了。在運行中隨着客戶請求的增多，啓動的子進程會隨之增多，但這些服務器副本在處理完一次HTTP請求以後並不當即退出，而是停留在計算機中等待下次請求。可是空餘的子進程副本不能光增長不減小，太多的空餘子進程沒有處理任務，也佔用服務器的處理能力，所以也要限制空餘副本的數量，使其保持一個合適的數量，使得既能及時迴應客戶請求，又能減小沒必要要的進程數量。

　　所以就可使用參數MinSpareServers來設置最少的空餘子進程數量， 以及使用參數MaxSpareServers 來限制最多的空閒子進程數量，多餘的服務器進程副本就會退出。根據服務器的實際狀況來進行設置，若是服務器性能較高，而且也被頻繁訪問，就應該增大這兩個參數的設置。對於高負載的專業網站，這兩個值應該大體相同，而且等同於系統支持的最多服務器副本數量，也減小沒必要要的副本退出。

 

　　StartServers 5

　　StartServers參數就是用來設置httpd啓動時啓動的子進程副本數量，這個參數與上面定義的MinSpareServers和 MaxSpareServers參數相關，都是用於啓動空閒子進程以提升服務器的反應速度的。這個參數應該設置爲前兩個值之間的一個數值，小於 MinSpareServers和大於MaxS pareServers都沒有意義。

 

　　MaxClients 150

　　在另外一方面，服務器的能力畢竟是有限的，不可能同時處理無限多的鏈接請求，所以參數Maxclient s就用於規定服務器支持的最多併發訪問的客戶數，若是這個值設置得過大，系統在繁忙時不得不在過多的進程之間進行切換來爲太多的客戶進行服務，這樣對每一個客戶的反應就會減慢，並下降了總體的效率。若是這個值設置的較小，那麼系統繁忙時就會拒絕一些客戶的鏈接請求。當服務器性能較高時，就能夠適當增長這個值的設置。對於專業網站，應該使用提升服務器效率的策略，所以這個參數不能超過硬件自己的限制，若是頻繁出現拒絕訪問現象，就說明須要升級服務器硬件了。對於非專業網站，不太在乎對客戶瀏覽器的反應速度，或者認爲反應速度較慢也比拒絕鏈接好，就也能夠略微超過硬件條件來設置這個參數。

　　這個參數限制了MinSpareServers和MaxSpareServers的設置，它們不該該大 於這個參數的設置。

     MaxClients指令設置了容許同時伺服的最大接入請求數量。任何超過MaxClients限制的請求都將進入等候隊列，直到達到ListenBacklog指令限制的最大值爲止。一旦一個連接被釋放，隊列中的請求將獲得服務。

    對於非線程型的MPM(也就是prefork)，MaxClients表示能夠用於伺服客戶端請求的最大子進程數量，默認值是256。要增大這個值，你必須同時增大ServerLimit 。

    對於線程型或者混合型的MPM(也就是beos或worker)，MaxClients表示能夠用於伺服客戶端請求的最大線程數量。線程型的beos的默認值是50。對於混合型的MPM默認值是16(ServerLimit)乘以25(ThreadsPerChild)的結果。所以要將MaxClients增長到超過16個進程才能提供的時候，你必須同時增長ServerLimit的值

　　MaxRequestsPerChild 30

　　使用子進程的方式提供服務的Web服務，經常使用的方式是一個子進程爲一次鏈接服務，這樣形成的問題就是每次鏈接都須要生成、退出子進程的系統操做，使得這些額外的處理過程佔據了計算機的大量處理能力。所以最好的方式是一個子進程能夠爲屢次鏈接請求服務，這樣就不須要這些生成、退出進程的系統消耗，Apache就採用了這樣的方式，一次鏈接結束後，子進程並不退出，而是停留在系統中等待下一次服務請求，這樣就極大的提升了性能。

　　但因爲在處理過程當中子進程要不斷的申請和釋放內存，次數多了就會形成一些內存垃圾，就會影響系統的穩定性，而且影響系統資源的有效利用。所以在一個副本處理過必定次數的請求以後，就可讓這個子進程副本退出，再從原始的httpd進程中從新複製一個乾淨的副本，這樣就能提升系統的穩定性。這樣，每一個子進程處理服務請求次數由MaxRe questPerChild定義。缺省的設置值爲30，這個值對於具有高穩定性特色的Linux系統來說是過於保守的設置，能夠設置爲1000甚至更高，設置爲0支持每一個副本進行無限次的服務處理。

        MaxRequestsPerChild指令設置每一個子進程在其生存期內容許伺服的最大請求數量。到達MaxRequestsPerChild的限制後，子進程將會結束。若是MaxRequestsPerChild爲"0"，子進程將永遠不會結束。將MaxRequestsPerChild設置成非零值有兩個好處：

• 能夠防止(偶然的)內存泄漏無限進行，從而耗盡內存。

• 給進程一個有限壽命，從而有助於減輕服務器負載，減小活動進程的數量。

注意：

    對於KeepAlive連接，只有第一個請求會被計數。事實上，它改變了每一個子進程限制最大連接數量的行爲

　　#Listen 3000

　　#Listen 12.34.56.78:80

　　#BindAddress *

　　Listen參數能夠指定服務器除了監視標準的80端口以外，還監視其餘端口的HTTP請求。因爲FreeBSD系統能夠同時擁有多個IP地址，所以也能夠指定服務器只聽取對某個BindAddress< /B>的IP地址的HTTP請求。若是沒有配置這一項，則服務器會迴應對全部IP的請求。

　　即便使用了BindAddress參數，使得服務器只回應對一個IP地址的請求，可是經過使用擴展的Listen參數，仍然可讓HTTP守護進程迴應對其餘IP地址的請求。此時Listen參數的用法與上面的第二個例子相同。這種比較複雜的用法主要用於設置虛擬主機。此後能夠用 VirtualHost參數定義對不一樣IP的虛擬主機，然而這種用法是較早的HTTP 1.0標準中設置虛擬主機的方法，每針對一個虛擬主機就須要一個IP地址，實際上用處並不大。在HTTP 1.1中，增長了對單IP地址多域名的虛擬主機的支持，使得虛擬主機的設置具有更大的意義。

　　LoadModule mime_magic_module libexec/apache/mod_mime_magic.so

　　LoadModule info_module libexec/apache/mod_info.so

　　LoadModule speling_module libexec/apache/mod_speling.so

　　LoadModule proxy_module libexec/apache/libproxy.so

　　LoadModule rewrite_module libexec/apache/mod_rewrite.so

　　LoadModule anon_auth_module libexec/apache/mod_auth_anon.so

　　LoadModule db_auth_module libexec/apache/mod_auth_db.so

　　LoadModule digest_module libexec/apache/mod_digest.so

　　LoadModule cern_meta_module libexec/apache/mod_cern_meta.so

　　LoadModule expires_module libexec/apache/mod_expires.so

　　LoadModule headers_module libexec/apache/mod_headers.so

　　LoadModule usertrack_module libexec/apache/mod_usertrack.so

　　LoadModule unique_id_module libexec/apache/mod_unique_id.so

　　ClearModuleList

　　AddModule mod_env.c

　　AddModule mod_log_config.c

　　AddModule mod_mime_magic.c

　　AddModule mod_mime.c

　　AddModule mod_negotiation.c

　　AddModule mod_status.c

　　AddModule mod_info.c

　　AddModule mod_include.c

　　AddModule mod_autoindex.c

　　AddModule mod_dir.c

　　AddModule mod_cgi.c

　　AddModule mod_asis.c

　　AddModule mod_imap.c

　　AddModule mod_actions.c

　　AddModule mod_speling.c

　　AddModule mod_userdir.c

　　AddModule mod_proxy.c

　　AddModule mod_alias.c

　　AddModule mod_rewrite.c

　　AddModule mod_access.c

　　AddModule mod_auth.c

　　AddModule mod_auth_anon.c

　　AddModule mod_auth_db.

　　AddModule mod_digest.c

　　AddModule mod_cern_meta.c

　　AddModule mod_expires.c

 　　AddModule mod_headers.c

 　　AddModule mod_usertrack.c

 　　AddModule mod_unique_id.c

 　　AddModule mod_so.c

 　　AddModule mod_setenvif.c

 　　Apache服務器的一個重要特性就是其模塊化的結構，這不但表現爲其能在編譯時能經過新的模塊加入新的功能，還表現爲其模塊能夠動態加載入 http服務程序中，而沒必要載入不須要的模塊。使用Apache的動態加載模塊只須要設置好Load Module和AddModule參數就能夠了，這種特性就是Apache的 DSO（Dynamic Shared Object）特性，然而要想充分使用DSO特性仍然不是一個簡單的事情，不適當的改動這裏的設置就可能形成服務器不能正常啓動。所以若是不是要增長或減小服務器提供的功能，就不要改動這裏的設置。

　　上面這些列表就顯示了Linux下的缺省Apache服務器支持的模塊，事實上不少模塊是沒有必要的，沒必要要模塊不會被載入內存。模塊能夠靜態鏈接到apache 服務器內部，也能夠這樣動態加載，將Apache的特性都編譯成動態可加載模塊是該Port的作法，而不是Apache的缺省作法，這樣就以犧牲很小的性能的同時，帶來極大的靈活性。

　　於是動態可加載的能力仍是對性能有輕微的影響，所以能夠從新編譯Apache，將本身所須要的功能編譯進Apache 服務器內部，可讓系統顯得更爲乾淨，效率也有輕微的提升。一般僅僅爲了這一個目的就從新編譯Apache是沒有必要的，若是須要增長其餘特性而從新編譯 Apache，不妨在增長其餘模塊的同時將全部的模塊都靜態鏈接入Apache 服務器。有的使用者更喜歡動態加載模塊，那麼也不妨所有都使用動態加載模塊。

　　這些模塊都被放置到/usr/local/apache/libexec/目錄下，每一個模塊對應Apache服務器的一個特性。詳細解釋每一個模塊的功能須要至關多的篇幅，其中比較重要的特性將在後面相應的地方中進行解釋，而具體每一個模塊的功能及用法就須要查看Apache的文檔。

　　#ExtendedStatus On

　　Apache服務器能夠經過特殊的HTTP請求，來報告自身的運行狀態，打開這個ExtendedStatus 參數可讓服務器報告更全面的運行狀態信息

 　　主服務器設置

　　Apache服務器須要各類設置，以定義本身使用各類參數以提供Web服務。對於使用虛擬主機的狀況，除了在虛擬主機的定義項中覆蓋的設置以外（有的設置必須從新定義），這裏的設置也是虛擬主機的缺省設置。

　　Port 80

　　Port定義了Standalone模式下httpd守護進程使用的端口，標準端口是80。這個選項只對於以獨立方式啓動的服務器纔有效，對於以inetd方式啓動的服務器則在inetd.conf中定義使用哪一個端口。

　　在Unix下使用80端口須要root權限，一些管理員爲了安全的緣由，認爲 httpd 服務器不可能沒有安全漏洞，於是更願意使用普通用戶的權限來啓動服務器，這樣就不能使用80端口及其餘小於1024的端口，而必須使用大於 1024的端口來啓動httpd，通常狀況下8000或8080也是經常使用的端口。而Apache httpd服務器自己能夠在以root權限打開80端口後再改變爲普通用戶身份進行運行，這樣就減小了危險性，於是就不須要考慮這個安全問題。可是若是普通用戶也想安裝配置本身的WWW服務器，那麼就不得不使用大於1024的端口。

　　User nobody

　　Group nogroup

　　User和Group配置是Apache的安全保證，Apache在打開端口以後，就將其自己設置爲這兩個選項設置的用戶和組權限進行運行，這樣就下降了服務器的危險性。這個選項也只用於 Standalone模式，inetd模式在inetd.conf中指定運行Apache的用戶。因爲服務器必須執行改變身份的setuid()操做，所以初始進程應該具有root權限，若是是使用非root用戶來啓動Aapche，這個配置就不會發揮做用。

　　缺省設置爲nobody和nogroup，這個用戶和組在系統中不擁有文件，保證了服務器自己和由它啓動的CGI 進程沒有權限更改文件系統。在某些狀況下，例如爲了運行CGI與Unix交互，也須要讓服務器來訪問服務器上的文件，若是仍然使用nobody和 nogroup，那麼系統中將會出現屬於nobody的文件，這對於系統安全是不利的，由於其餘程序也會以nobody和nogroup的權限執行某些操做，就有可能訪問這些nobody擁有的文件，形成安全問題。通常狀況下要爲Web服務設定一個特定的用戶和組，同時在這裏更改用戶和組設置。

　　ServerAdmin you@your.address

　　配置文件中應該改變的也許只有ServerAdmin，這一項用於配置WWW服務器的管理員的email地址，這將在HTTP服務出現錯誤的條件下返回給瀏覽器，以便讓Web使用者和管理員聯繫，報告錯誤。習慣上使用服務器上的webmaster做爲WWW服務器的管理員，經過郵件服務器的別名機制，將發送到webmaster 的電子郵件發送給真正的Web管理員。

　　#ServerName new.host.name

　　缺省狀況下，並不須要指定這個ServerName參數，服務器將自動經過名字解析過程來得到本身的名字，但若是服務器的名字解析有問題（一般爲反向解析不正確），或者沒有正式的DNS名字，也能夠在這裏指定IP地址。當ServerName設置不正確的時候，服務器不能正常啓動。