Tomcat隸屬于Apache基金會，是開源的輕量級Web應用伺服器，使用非常廣泛。server.xml是Tomcat中最重要的配置檔案，server.xml的每一個元素都對應了Tomcat中的一個元件；通過對xml檔案中元素的配置，可以實作對Tomcat中各個元件的控制。是以，學習server.xml檔案的配置，對于了解和使用Tomcat至關重要。
本文将通過執行個體，介紹server.xml中各個元件的配置，并詳細說明Tomcat各個核心元件的作用以及各個元件之間的互相關系。
說明：由于server.xml檔案中元素與Tomcat中元件的對應關系，後文中為了描述友善，“元素”和“元件”的使用不嚴格區分。
如果覺得文章對你有幫助，歡迎點贊或轉載。文章有疏漏之處，歡迎批評指正。
一、一個server.xml配置執行個體
二、server.xml文檔的元素分類和整體結構
1、整體結構
2、元素分類
三、核心元件
1、Server
2、Service
3、Connector
4、Engine
5、Host
6、Context
四、核心元件的關聯
1、整體關系
2、如何确定請求由誰處理？
3、如何配置多個服務
五、其他元件
1、Listener
2、GlobalNamingResources與Realm
3、Valve
六、參考文獻
server.xml位于$TOMCAT_HOME/conf目錄下；下面是一個server.xml執行個體。後文中将結合該執行個體講解server.xml中，各個元素的含義和作用；在閱讀後續章節過程中，可以對照該xml文檔便于了解。
server.xml的整體結構如下：
該結構中隻給出了Tomcat的核心元件，除了核心元件外，Tomcat還有一些其他元件，下面介紹一下元件的分類。
server.xml檔案中的元素可以分為以下4類：
（1）頂層元素：<Server>和<Service>
<Server>元素是整個配置檔案的根元素，<Service>元素則代表一個Engine元素以及一組與之相連的Connector元素。
（2）連接配接器：<Connector>
<Connector>代表了外部用戶端發送請求到特定Service的接口；同時也是外部用戶端從特定Service接收響應的接口。
（3）容器：<Engine><Host><Context>
容器的功能是處理Connector接收進來的請求，并産生相應的響應。Engine、Host和Context都是容器，但它們不是平行的關系，而是父子關系：Engine包含Host，Host包含Context。一個Engine元件可以處理Service中的所有請求，一個Host元件可以處理發向一個特定虛拟主機的所有請求，一個Context元件可以處理一個特定Web應用的所有請求。
（4）内嵌元件：可以内嵌到容器中的元件。實際上，Server、Service、Connector、Engine、Host和Context是最重要的最核心的Tomcat元件，其他元件都可以歸為内嵌元件。
下面将詳細介紹Tomcat中各個核心元件的作用，以及互相之間的關系。
本部分将分别介紹各個核心元件的作用、特點以及配置方式等。
Server元素在最頂層，代表整個Tomcat容器，是以它必須是server.xml中唯一一個最外層的元素。一個Server元素中可以有一個或多個Service元素。
在第一部分的例子中，在最外層有一個<Server>元素，shutdown屬性表示關閉Server的指令；port屬性表示Server接收shutdown指令的端口号，設為-1可以禁掉該端口。
Server的主要任務，就是提供一個接口讓用戶端能夠通路到這個Service集合，同時維護它所包含的所有的Service的聲明周期，包括如何初始化、如何結束服務、如何找到用戶端要通路的Service。
Service的作用，是在Connector和Engine外面包了一層，把它們組裝在一起，對外提供服務。一個Service可以包含多個Connector，但是隻能包含一個Engine；其中Connector的作用是從用戶端接收請求，Engine的作用是處理接收進來的請求。
在第一部分的例子中，Server中包含一個名稱為“Catalina”的Service。實際上，Tomcat可以提供多個Service，不同的Service監聽不同的端口，後文會有介紹。
Connector的主要功能，是接收連接配接請求，建立Request和Response對象用于和請求端交換資料；然後配置設定線程讓Engine來處理這個請求，并把産生的Request和Response對象傳給Engine。
通過配置Connector，可以控制請求Service的協定及端口号。在第一部分的例子中，Service包含兩個Connector：
（1）通過配置第1個Connector，用戶端可以通過8080端口号使用http協定通路Tomcat。其中，protocol屬性規定了請求的協定，port規定了請求的端口号，redirectPort表示當強制要求https而請求是http時，重定向至端口号為8443的Connector，connectionTimeout表示連接配接的逾時時間。
在這個例子中，Tomcat監聽HTTP請求，使用的是8080端口，而不是正式的80端口；實際上，在正式的生産環境中，Tomcat也常常監聽8080端口，而不是80端口。這是因為在生産環境中，很少将Tomcat直接對外開放接收請求，而是在Tomcat和用戶端之間加一層代理伺服器(如nginx)，用于請求的轉發、負載均衡、處理靜态檔案等；通過代理伺服器通路Tomcat時，是在區域網路中，是以一般仍使用8080端口。
（2）通過配置第2個Connector，用戶端可以通過8009端口号使用AJP協定通路Tomcat。AJP協定負責和其他的HTTP伺服器(如Apache)建立連接配接；在把Tomcat與其他HTTP伺服器內建時，就需要用到這個連接配接器。之是以使用Tomcat和其他伺服器內建，是因為Tomcat可以用作Servlet/JSP容器，但是對靜态資源的處理速度較慢，不如Apache和IIS等HTTP伺服器；是以常常将Tomcat與Apache等內建，前者作Servlet容器，後者處理靜态資源，而AJP協定便負責Tomcat和Apache的連接配接。Tomcat與Apache等內建的原理如下圖(圖檔來源)：
關于Connector的更多内容，可以參考我的另一篇文章：詳解tomcat的連接配接數與線程池
Engine元件在Service元件中有且隻有一個；Engine是Service元件中的請求處理元件。Engine元件從一個或多個Connector中接收請求并處理，并将完成的響應傳回給Connector，最終傳遞給用戶端。
前面已經提到過，Engine、Host和Context都是容器，但它們不是平行的關系，而是父子關系：Engine包含Host，Host包含Context。
在第一部分的例子中，Engine的配置語句如下：
其中，name屬性用于日志和錯誤資訊，在整個Server中應該唯一。defaultHost屬性指定了預設的host名稱，當發往本機的請求指定的host名稱不存在時，一律使用defaultHost指定的host進行處理；是以，defaultHost的值，必須與Engine中的一個Host元件的name屬性值比對。
Host是Engine的子容器。Engine元件中可以内嵌1個或多個Host元件，每個Host元件代表Engine中的一個虛拟主機。Host元件至少有一個，且其中一個的name必須與Engine元件的defaultHost屬性相比對。
Host虛拟主機的作用，是運作多個Web應用（一個Context代表一個Web應用），并負責安裝、展開、啟動和結束每個Web應用。
Host元件代表的虛拟主機，對應了伺服器中一個網絡名實體(如”www.test.com”，或IP位址”116.25.25.25”)；為了使使用者可以通過網絡名連接配接Tomcat伺服器，這個名字應該在DNS伺服器上注冊。
用戶端通常使用主機名來辨別它們希望連接配接的伺服器；該主機名也會包含在HTTP請求頭中。Tomcat從HTTP頭中提取出主機名，尋找名稱比對的主機。如果沒有比對，請求将發送至預設主機。是以預設主機不需要是在DNS伺服器中注冊的網絡名，因為任何與所有Host名稱不比對的請求，都會路由至預設主機。
在第一部分的例子中，Host的配置如下：
下面對其中配置的屬性進行說明：
name屬性指定虛拟主機的主機名，一個Engine中有且僅有一個Host元件的name屬性與Engine元件的defaultHost屬性相比對；一般情況下，主機名需要是在DNS伺服器中注冊的網絡名，但是Engine指定的defaultHost不需要，原因在前面已經說明。
unpackWARs指定了是否将代表Web應用的WAR檔案解壓；如果為true，通過解壓後的檔案結構運作該Web應用，如果為false，直接使用WAR檔案運作Web應用。
Host的autoDeploy和appBase屬性，與Host内Web應用的自動部署有關；此外，本例中沒有出現的xmlBase和deployOnStartup屬性，也與Web應用的自動部署有關；将在下一節(Context)中介紹。
Context元素代表在特定虛拟主機上運作的一個Web應用。在後文中，提到Context、應用或Web應用，它們指代的都是Web應用。每個Web應用基于WAR檔案，或WAR檔案解壓後對應的目錄（這裡稱為應用目錄）。
Context是Host的子容器，每個Host中可以定義任意多的Context元素。
在第一部分的例子中，可以看到server.xml配置檔案中并沒有出現Context元素的配置。這是因為，Tomcat開啟了自動部署，Web應用沒有在server.xml中配置靜态部署，而是由Tomcat通過特定的規則自動部署。下面介紹一下Tomcat自動部署Web應用的機制。
Host的配置
要開啟Web應用的自動部署，需要配置所在的虛拟主機；配置的方式就是前面提到的Host元素的deployOnStartup和autoDeploy屬性。如果deployOnStartup和autoDeploy設定為true，則tomcat啟動自動部署：當檢測到新的Web應用或Web應用的更新時，會觸發應用的部署(或重新部署)。二者的主要差別在于，deployOnStartup為true時，Tomcat在啟動時檢查Web應用，且檢測到的所有Web應用視作新應用；autoDeploy為true時，Tomcat在運作時定期檢查新的Web應用或Web應用的更新。除此之外，二者的處理相似。
通過配置deployOnStartup和autoDeploy可以開啟虛拟主機自動部署Web應用；實際上，自動部署依賴于檢查是否有新的或更改過的Web應用，而Host元素的appBase和xmlBase設定了檢查Web應用更新的目錄。
其中，appBase屬性指定Web應用所在的目錄，預設值是webapps，這是一個相對路徑，代表Tomcat根目錄下webapps檔案夾。
xmlBase屬性指定Web應用的XML配置檔案所在的目錄，預設值為conf/<engine_name>/<host_name>，例如第一部分的例子中，主機localhost的xmlBase的預設值是$TOMCAT_HOME/conf/Catalina/localhost。
檢查Web應用更新
一個Web應用可能包括以下檔案：XML配置檔案，WAR包，以及一個應用目錄(該目錄包含Web應用的檔案結構)；其中XML配置檔案位于xmlBase指定的目錄，WAR包和應用目錄位于appBase指定的目錄。
Tomcat按照如下的順序進行掃描，來檢查應用更新：
A、掃描虛拟主機指定的xmlBase下的XML配置檔案
B、掃描虛拟主機指定的appBase下的WAR檔案
C、掃描虛拟主機指定的appBase下的應用目錄
<Context>元素的配置
Context元素最重要的屬性是docBase和path，此外reloadable屬性也比較常用。
docBase指定了該Web應用使用的WAR包路徑，或應用目錄。需要注意的是，在自動部署場景下，docBase不在appBase目錄中，才需要指定；如果docBase指定的WAR包或應用目錄就在appBase中，則不需要指定，因為Tomcat會自動掃描appBase中的WAR包和應用目錄，指定了反而會造成問題。
path指定了通路該Web應用的上下文路徑，當請求到來時，Tomcat根據Web應用的 path屬性與URI的比對程度來選擇Web應用處理相應請求。例如，Web應用app1的path屬性是”/app1”，Web應用app2的path屬性是”/app2”，那麼請求/app1/index.html會交由app1來處理；而請求/app2/index.html會交由app2來處理。如果一個Context元素的path屬性為””，那麼這個Context是虛拟主機的預設Web應用；當請求的uri與所有的path都不比對時，使用該預設Web應用來處理。
但是，需要注意的是，在自動部署場景下，不能指定path屬性，path屬性由配置檔案的檔案名、WAR檔案的檔案名或應用目錄的名稱自動推導出來。如掃描Web應用時，發現了xmlBase目錄下的app1.xml，或appBase目錄下的app1.WAR或app1應用目錄，則該Web應用的path屬性是”app1”。如果名稱不是app1而是ROOT，則該Web應用是虛拟主機預設的Web應用，此時path屬性推導為””。
reloadable屬性訓示tomcat是否在運作時監控在WEB-INF/classes和WEB-INF/lib目錄下class檔案的改動。如果值為true，那麼當class檔案改動時，會觸發Web應用的重新加載。在開發環境下，reloadable設定為true便于調試；但是在生産環境中設定為true會給伺服器帶來性能壓力，是以reloadable參數的預設值為false。
下面來看自動部署時，xmlBase下的XML配置檔案app1.xml的例子：
在該例子中，docBase位于Host的appBase目錄之外；path屬性沒有指定，而是根據app1.xml自動推導為”app1”；由于是在開發環境下，是以reloadable設定為true，便于開發調試。
自動部署舉例
最典型的自動部署，就是當我們安裝完Tomcat後，$TOMCAT_HOME/webapps目錄下有如下檔案夾：
當我們啟動Tomcat後，可以使用http://localhost:8080/來通路Tomcat，其實通路的就是ROOT對應的Web應用；我們也可以通過http://localhost:8080/docs來通路docs應用，同理我們可以通路examples/host-manager/manager這幾個Web應用。
除了自動部署，我們也可以在server.xml中通過<context>元素靜态部署Web應用。靜态部署與自動部署是可以共存的。在實際應用中，并不推薦使用靜态部署，因為server.xml 是不可動态重加載的資源，伺服器一旦啟動了以後，要修改這個檔案，就得重新開機伺服器才能重新加載。而自動部署可以在Tomcat運作時通過定期的掃描來實作，不需要重新開機伺服器。
server.xml中使用Context元素配置Web應用，Context元素應該位于Host元素中。舉例如下：
docBase：靜态部署時，docBase可以在appBase目錄下，也可以不在；本例中，docBase不在appBase目錄下。
path：靜态部署時，可以顯式指定path屬性，但是仍然受到了嚴格的限制：隻有當自動部署完全關閉(deployOnStartup和autoDeploy都為false)或docBase不在appBase中時，才可以設定path屬性。在本例中，docBase不在appBase中，是以path屬性可以設定。
reloadable屬性的用法與自動部署時相同。
核心元件之間的整體關系，在上一部分有所介紹，這裡總結一下：
Server元素在最頂層，代表整個Tomcat容器；一個Server元素中可以有一個或多個Service元素。
Service在Connector和Engine外面包了一層，把它們組裝在一起，對外提供服務。一個Service可以包含多個Connector，但是隻能包含一個Engine；Connector接收請求，Engine處理請求。
Engine、Host和Context都是容器，且 Engine包含Host，Host包含Context。每個Host元件代表Engine中的一個虛拟主機；每個Context元件代表在特定Host上運作的一個Web應用。
當請求被發送到Tomcat所在的主機時，如何确定最終哪個Web應用來處理該請求呢？
Service中的Connector元件可以接收特定端口的請求，是以，當Tomcat啟動時，Service元件就會監聽特定的端口。在第一部分的例子中，Catalina這個Service監聽了8080端口（基于HTTP協定）和8009端口（基于AJP協定）。當請求進來時，Tomcat便可以根據協定和端口号標明處理請求的Service；Service一旦標明，Engine也就确定。
通過在Server中配置多個Service，可以實作通過不同的端口号來通路同一台機器上部署的不同應用。
Service确定後，Tomcat在Service中尋找名稱與域名/IP位址比對的Host處理該請求。如果沒有找到，則使用Engine中指定的defaultHost來處理該請求。在第一部分的例子中，由于隻有一個Host（name屬性為localhost），是以該Service/Engine的所有請求都交給該Host處理。
這一點在Context一節有詳細的說明：Tomcat根據應用的 path屬性與URI的比對程度來選擇Web應用處理相應請求，這裡不再贅述。
以請求http://localhost:8080/app1/index.html為例，首先通過協定和端口号（http和8080）標明Service；然後通過主機名（localhost）標明Host；然後通過uri（/app1/index.html）標明Web應用。
通過在Server中配置多個Service服務，可以實作通過不同的端口号來通路同一台機器上部署的不同Web應用。
在server.xml中配置多服務的方法非常簡單，分為以下幾步：
（1）複制<Service>元素，放在目前<Service>後面。
（2）修改端口号：根據需要監聽的端口号修改<Connector>元素的port屬性；必須確定該端口沒有被其他程序占用，否則Tomcat啟動時會報錯，而無法通過該端口通路Web應用。
以Win7為例，可以用如下方法找出某個端口是否被其他程序占用：netstat -aon|findstr "8081"發現8081端口被PID為2064的程序占用，tasklist |findstr "2064"發現該程序為FrameworkService.exe(這是McAfee防毒軟體的程序)。
（3）修改Service和Engine的name屬性
（4）修改Host的appBase屬性（如webapps2）
（5）Web應用仍然使用自動部署
（6）将要部署的Web應用(WAR包或應用目錄)拷貝到新的appBase下。
以第一部分的server.xml為例，多個Service的配置如下：
再将原webapps下的docs目錄拷貝到webapps2中，則通過如下兩個接口都可以通路docs應用：
http://localhost:8080/docs/
http://localhost:8084/docs/
除核心元件外，server.xml中還可以配置很多其他元件。下面隻介紹第一部分例子中出現的元件，如果要了解更多内容，可以檢視Tomcat官方文檔。
Listener(即監聽器)定義的元件，可以在特定事件發生時執行特定的操作；被監聽的事件通常是Tomcat的啟動和停止。
監聽器可以在Server、Engine、Host或Context中，本例中的監聽器都是在Server中。實際上，本例中定義的6個監聽器，都隻能存在于Server元件中。監聽器不允許内嵌其他元件。
監聽器需要配置的最重要的屬性是className，該屬性規定了監聽器的具體實作類，該類必須實作了org.apache.catalina.LifecycleListener接口。
下面依次介紹例子中配置的監聽器：
VersionLoggerListener：當Tomcat啟動時，該監聽器記錄Tomcat、Java和作業系統的資訊。該監聽器必須是配置的第一個監聽器。
AprLifecycleListener：Tomcat啟動時，檢查APR庫，如果存在則加載。APR，即Apache Portable Runtime，是Apache可移植運作庫，可以實作高可擴充性、高性能，以及與本地伺服器技術更好的內建。
JasperListener：在Web應用啟動之前初始化Jasper，Jasper是JSP引擎，把JVM不認識的JSP檔案解析成java檔案，然後編譯成class檔案供JVM使用。
JreMemoryLeakPreventionListener：與類加載器導緻的記憶體洩露有關。
GlobalResourcesLifecycleListener：通過該監聽器，初始化< GlobalNamingResources>标簽中定義的全局JNDI資源；如果沒有該監聽器，任何全局資源都不能使用。< GlobalNamingResources>将在後文介紹。
ThreadLocalLeakPreventionListener：當Web應用因thread-local導緻的記憶體洩露而要停止時，該監聽器會觸發線程池中線程的更新。當線程執行完任務被收回線程池時，活躍線程會一個一個的更新。隻有當Web應用(即Context元素)的renewThreadsWhenStoppingContext屬性設定為true時，該監聽器才有效。
第一部分的例子中，Engine元件下定義了Realm元件：
Realm，可以把它了解成“域”；Realm提供了一種使用者密碼與web應用的映射關系，進而達到角色安全管理的作用。在本例中，Realm的配置使用name為UserDatabase的資源實作。而該資源在Server元素中使用GlobalNamingResources配置：
GlobalNamingResources元素定義了全局資源，通過配置可以看出，該配置是通過讀取$TOMCAT_HOME/ conf/tomcat-users.xml實作的。
關于Tomcat域管理的更多内容，可以參考：Realm域管理
在第一部分的例子中，Host元素内定義了Valve元件：
單詞Valve的意思是“閥門”，在Tomcat中代表了請求處理流水線上的一個元件；Valve可以與Tomcat的容器(Engine、Host或Context)關聯。
不同的Valve有不同的特性，下面介紹一下本例中出現的AccessLogValve。
AccessLogValve的作用是通過日志記錄其所在的容器中處理的所有請求，在本例中，Valve放在Host下，便可以記錄該Host處理的所有請求。AccessLogValve記錄的日志就是通路日志，每天的請求會寫到一個日志檔案裡。AccessLogValve可以與Engine、Host或Context關聯；在本例中，隻有一個Engine，Engine下隻有一個Host，Host下隻有一個Context，是以AccessLogValve放在三個容器下的作用其實是類似的。
本例的AccessLogValve屬性的配置，使用的是預設的配置；下面介紹AccessLogValve中各個屬性的作用：
（1）className：規定了Valve的類型，是最重要的屬性；本例中，通過該屬性規定了這是一個AccessLogValve。
（2）directory：指定日志存儲的位置，本例中，日志存儲在$TOMCAT_HOME/logs目錄下。
（3）prefix：指定了日志檔案的字首。
（4）suffix：指定了日志檔案的字尾。通過directory、prefix和suffix的配置，在$TOMCAT_HOME/logs目錄下，可以看到如下所示的日志檔案。
（5）pattern：指定記錄日志的格式，本例中各項的含義如下：
%h：遠端主機名或IP位址；如果有nginx等反向代理伺服器進行請求分發，該主機名/IP位址代表的是nginx，否則代表的是用戶端。後面遠端的含義與之類似，不再解釋。
%l：遠端邏輯使用者名，一律是”-”，可以忽略。
%u：授權的遠端使用者名，如果沒有，則是”-”。
%t：通路的時間。
%r：請求的第一行，即請求方法(get/post等)、uri、及協定。
%s：響應狀态，200,404等等。
%b：響應的資料量，不包括請求頭，如果為0，則是””-。
例如，下面是通路日志中的一條記錄
pattern的配置中，除了上述各項，還有一個非常常用的選項是%D，含義是請求處理的時間(機關是毫秒)，對于統計分析請求的處理速度幫助很大。
開發人員可以充分利用通路日志，來分析問題、優化應用。例如，分析通路日志中各個接口被通路的比例，不僅可以為需求和營運人員提供資料支援，還可以使自己的優化有的放矢；分析通路日志中各個請求的響應狀态碼，可以知道伺服器請求的成功率，并找出有問題的請求；分析通路日志中各個請求的響應時間，可以找出慢請求，并根據需要進行響應時間的優化。
Tomcat官方文檔
《How Tomcat Works》
《深入分析Java Web技術内幕》
Tomcat 6 —— Realm域管理
Tomcat Port 8009 與AJP13協定
使用Jasper引擎解析JSP
創作不易，如果文章對你有幫助，就點個贊、評個論呗~