本文來源

http://www.cnblogs.com/kismetv/p/7228274.html

(本文版權歸原作者所有。轉載文章僅為傳播更多資訊之目的，如有侵權請與我們聯絡，我們將及時處理。)

前言

Tomcat隸屬於Apache基金會，是開源的輕量級Web應用伺服器，使用非常廣泛。server.xml是Tomcat中最重要的配置檔案，server.xml的每一個元素都對應了Tomcat中的一個元件；透過對xml檔案中元素的配置，可以實現對Tomcat中各個元件的控制。因此，學習server.xml檔案的配置，對於瞭解和使用Tomcat至關重要。

本文將透過例項，介紹server.xml中各個元件的配置，並詳細說明Tomcat各個核心元件的作用以及各個元件之間的相互關係。

說明：由於server.xml檔案中元素與Tomcat中元件的對應關係，後文中為了描述方便，“元素”和“元件”的使用不嚴格區分。

如果覺得文章對你有幫助，歡迎點贊或轉載。文章有疏漏之處，歡迎批評指正。

一、一個server.xml配置例項

server.xml位於$TOMCAT_HOME/conf目錄下；下面是一個server.xml例項。後文中將結合該例項講解server.xml中，各個元素的含義和作用；在閱讀後續章節過程中，可以對照該xml文件便於理解。

二、server.xml文件的元素分類和整體結構

1、整體結構

server.xml的整體結構如下：

該結構中只給出了Tomcat的核心元件，除了核心元件外，Tomcat還有一些其他元件，下面介紹一下元件的分類。

2、元素分類

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中各個核心元件的作用，以及相互之間的關係。點此檢視一分鐘配置tomcat的https教程。

三、核心元件

本部分將分別介紹各個核心元件的作用、特點以及配置方式等。

1、Server

Server元素在最頂層，代表整個Tomcat容器，因此它必須是server.xml中唯一一個最外層的元素。一個Server元素中可以有一個或多個Service元素。

在第一部分的例子中，在最外層有一個<Server>元素，shutdown屬性表示關閉Server的指令；port屬性表示Server接收shutdown指令的埠號，設為-1可以禁掉該埠。

Server的主要任務，就是提供一個介面讓客戶端能夠訪問到這個Service集合，同時維護它所包含的所有的Service的宣告週期，包括如何初始化、如何結束服務、如何找到客戶端要訪問的Service。

2、Service

Service的作用，是在Connector和Engine外面包了一層，把它們組裝在一起，對外提供服務。一個Service可以包含多個Connector，但是隻能包含一個Engine；其中Connector的作用是從客戶端接收請求，Engine的作用是處理接收進來的請求。

在第一部分的例子中，Server中包含一個名稱為“Catalina”的Service。實際上，Tomcat可以提供多個Service，不同的Service監聽不同的埠，後文會有介紹。

3、Connector

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的https教程。

在這個例子中，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的連線數與執行緒池

4、Engine

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屬性值匹配。

5、Host

（1）Engine與Host

Host是Engine的子容器。Engine元件中可以內嵌1個或多個Host元件，每個Host元件代表Engine中的一個虛擬主機。Host元件至少有一個，且其中一個的name必須與Engine元件的defaultHost屬性相匹配。

（2）Host的作用

Host虛擬主機的作用，是執行多個Web應用（一個Context代表一個Web應用），並負責安裝、展開、啟動和結束每個Web應用。

Host元件代表的虛擬主機，對應了伺服器中一個網路名實體(如””，或IP地址”116.25.25.25”)；為了使使用者可以透過網路名連線Tomcat伺服器，這個名字應該在DNS伺服器上註冊。

客戶端通常使用主機名來標識它們希望連線的伺服器；該主機名也會包含在HTTP請求頭中。Tomcat從HTTP頭中提取出主機名，尋找名稱匹配的主機。如果沒有匹配，請求將傳送至預設主機。因此預設主機不需要是在DNS伺服器中註冊的網路名，因為任何與所有Host名稱不匹配的請求，都會路由至預設主機。

（3）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)中介紹。

6、Context

（1）Context的作用

Context元素代表在特定虛擬主機上執行的一個Web應用。在後文中，提到Context、應用或Web應用，它們指代的都是Web應用。每個Web應用基於WAR檔案，或WAR檔案解壓後對應的目錄（這裡稱為應用目錄）。

Context是Host的子容器，每個Host中可以定義任意多的Context元素。

在第一部分的例子中，可以看到server.xml配置檔案中並沒有出現Context元素的配置。這是因為，Tomcat開啟了自動部署，Web應用沒有在server.xml中配置靜態部署，而是由Tomcat透過特定的規則自動部署。下面介紹一下Tomcat自動部署Web應用的機制。

（2）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包路徑，或應用目錄。需要注意的是，在自動部署場景下(配置檔案位於xmlBase中)，docBase不在appBase目錄中，才需要指定；如果docBase指定的WAR包或應用目錄就在docBase中，則不需要指定，因為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應用來處理。

但是，需要注意的是，在自動部署場景下(配置檔案位於xmlBase中)，不能指定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後，可以使用來訪問Tomcat，其實訪問的就是ROOT對應的Web應用；我們也可以透過docs來訪問docs應用，同理我們可以訪問examples/host-manager/manager這幾個Web應用。

（3）server.xml中靜態部署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屬性的用法與自動部署時相同。

四、核心元件的關聯

1、整體關係

核心元件之間的整體關係，在上一部分有所介紹，這裡總結一下：

Server元素在最頂層，代表整個Tomcat容器；一個Server元素中可以有一個或多個Service元素。

Service在Connector和Engine外面包了一層，把它們組裝在一起，對外提供服務。一個Service可以包含多個Connector，但是隻能包含一個Engine；Connector接收請求，Engine處理請求。

Engine、Host和Context都是容器，且 Engine包含Host，Host包含Context。每個Host元件代表Engine中的一個虛擬主機；每個Context元件代表在特定Host上執行的一個Web應用。

2、如何確定請求由誰處理？

當請求被髮送到Tomcat所在的主機時，如何確定最終哪個Web應用來處理該請求呢？

（1）根據協議和埠號選定Service和Engine

Service中的Connector元件可以接收特定埠的請求，因此，當Tomcat啟動時，Service元件就會監聽特定的埠。在第一部分的例子中，Catalina這個Service監聽了8080埠（基於HTTP協議）和8009埠（基於AJP協議）。當請求進來時，Tomcat便可以根據協議和埠號選定處理請求的Service；Service一旦選定，Engine也就確定。

透過在Server中配置多個Service，可以實現透過不同的埠號來訪問同一臺機器上部署的不同應用。

（2）根據域名或IP地址選定Host

Service確定後，Tomcat在Service中尋找名稱與域名/IP地址匹配的Host處理該請求。如果沒有找到，則使用Engine中指定的defaultHost來處理該請求。在第一部分的例子中，由於只有一個Host（name屬性為localhost），因此該Service/Engine的所有請求都交給該Host處理。

（3）根據URI選定Context/Web應用

這一點在Context一節有詳細的說明：Tomcat根據應用的 path屬性與URI的匹配程度來選擇Web應用處理相應請求，這裡不再贅述。

（4）舉例

以請求app1/index.html為例，首先透過協議和埠號（http和8080）選定Service；然後透過主機名（localhost）選定Host；然後透過uri（/app1/index.html）選定Web應用。

3、如何配置多個服務

透過在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應用：

docs/

五、其他元件

除核心元件外，server.xml中還可以配置很多其他元件。下面只介紹第一部分例子中出現的元件，如果要了解更多內容，可以檢視Tomcat官方文件。

1、Listener

Listener(即監聽器)定義的元件，可以在特定事件發生時執行特定的操作；被監聽的事件通常是Tomcat的啟動和停止。

監聽器可以在Server、Engine、Host或Context中，本例中的監聽器都是在Server中。實際上，本例中定義的6個監聽器，都只能存在於Server元件中。監聽器不允許內嵌其他元件。

監聽器需要配置的最重要的屬性是className，該屬性規定了監聽器的具體實現類，該類必須實現了org.apache.catalina.LifecycleListener介面。

點此檢視一分鐘配置tomcat的https教程。

下面依次介紹例子中配置的監聽器：

• 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時，該監聽器才有效。

2、GlobalNamingResources與Realm

第一部分的例子中，Engine元件下定義了Realm元件：

Realm，可以把它理解成“域”；Realm提供了一種使用者密碼與web應用的對映關係，從而達到角色安全管理的作用。在本例中，Realm的配置使用name為UserDatabase的資源實現。而該資源在Server元素中使用GlobalNamingResources配置：

GlobalNamingResources元素定義了全域性資源，透過配置可以看出，該配置是透過讀取$TOMCAT_HOME/ conf/tomcat-users.xml實現的。

關於Tomcat域管理的更多內容，可以參考：Realm域管理

3、Valve

在第一部分的例子中，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，含義是請求處理的時間(單位是毫秒)，對於統計分析請求的處理速度幫助很大。

開發人員可以充分利用訪問日誌，來分析問題、最佳化應用。例如，分析訪問日誌中各個介面被訪問的比例，不僅可以為需求和運營人員提供資料支援，還可以使自己的最佳化有的放矢；分析訪問日誌中各個請求的響應狀態碼，可以知道伺服器請求的成功率，並找出有問題的請求；分析訪問日誌中各個請求的響應時間，可以找出慢請求，並根據需要進行響應時間的最佳化。