1. 入門示例：虛擬主機提供web服務

該示例通過設置虛擬主機來提供web服務，因為是入門示例，所以設置極其簡單，只需修改$CATALINA_HOME/conf/server.xml文件為如下內容即可。其中大部分都采用了默認設置，只是在engine容器中添加了兩個Host容器。

除了engine中定義的默認localhost虛擬主機，另外布置了兩個虛擬主機www.longshuai.com和www.xiaofang.com，它們的程序目錄分別為/www/longshuai和/www/xiaofang，所以需要提前建立好這兩個目錄。另外，在context中定義了docBase，對于uri路徑/xuexi，它的文件系統路徑為/www/{longshuai,xiaofang}/xuexi目錄，所以也要在上面兩個程序根目錄中定義好xuexi目錄。除此之外，還分別為這3個虛擬主機定義了日志，它們的路徑為相對路徑logs，相對于$CATALINA_HOME。

再提供appBase目錄和docBase目錄。

再提供測試用的index.jsp文件。內容大致如下，分別復制到/www/{longshuai,xiaofang}/和/www/{longshuai,xiaofang}/xuexi/下，并將out.println的輸出內容分別稍作修改，使能夠區分讀取的是哪個index.jsp。

最后重啟catalina。

再測試主機上添加www.{longshuai,xiaofang}.com的host記錄。例如在windows上，在C:\Windows\System32\drivers\etc\hosts中添加如下記錄：

在瀏覽器中進行測試，結果如下：

2. tomcat體系結構基本說明

如下圖：

tomcat高度模塊化，各個模塊之間有嵌套的父子關系。如果使用配置文件來描述，可以大致簡化為如下：

其中server組件是工作在后臺管理tomcat實例的組件，可以監聽一個端口，從此端口上可以遠程向該實例發送shutdown關閉命令。

service組件是一個邏輯組件，綁定connector和containor，有了service表示可以向外提供服務，就像是一般的daemon類服務的service。

connector組件是服務監聽組件，用于監聽外界請求并建立TCP連接，然后將連接交給containor，之后可以從此連接傳輸數據，例如接收http請求，發送http響應等。

containor是容器，在配置文件中沒有體現出來，它包含4個容器類組件：engine容器、host容器、context容器和wrapper容器。

engine容器用于從connector組件處接收已建立的TCP連接，還用于接收客戶端發送的http請求并分析請求，然后按照分析的結果將相關參數傳遞給匹配出的虛擬主機。engine還用于指定默認的虛擬主機。

host容器定義虛擬主機，由于tomcat主要是作為servlet容器的，所以為每個web應用程序指定了它們的根目錄appBase。

context容器對應servlet容器的處理過程。還可以指定相關的wrapper容器類，當然一般都采用默認的標準wrapper類。

最后當請求處理完畢后，context將響應數據返回給host，再返回給engine，再返回給connector，最后返回給客戶端。

撇開tomcat作為servlet容器的行為。它和apache、nginx的功能大致都能對應上。例如以nginx為例，以下是nginx提供web服務時的配置結構：

connetcor組件類似于nginx的listen指令。host容器類似于nginx的server指令，host容器中的name屬性相當于nginx的server_name指令。engine組件則沒有對應配置項，不過在nginx同樣有engine的功能，例如默認的虛擬主機，分析URL來判斷請求交給哪個虛擬主機處理等。context容器相當于location指令，context容器的path屬性相當于location的uri匹配路徑，docBase相當于location的中的root指令，即DocumentRoot。

tomcat作為簡單的web服務程序大致如此，但它的核心畢竟是處理servlet和jsp，它必須得管理好每個webapp。因此，對于tomcat來說，必須要掌握部署webapp的方式。在tomcat上部署webapp時，必須要理解context的概念，對于tomcat而言，每個context都應該算是一個webapp，其路徑由docBase決定，該目錄存放的是歸檔的war文件或未歸檔的webapp相關文件，而host容器中的appBase則是虛擬主機整理webapp的地方，一個appBase下可以有多個webapp，即多個context。

3. tomcat的appBase和docBase詳細說明

這兩貨雖然意義很明確，但"潛規則"很嚴重。以下面的配置為例。

appBase是虛擬主機存放webapp的目錄，它可以是相對路徑，也可以是絕對路徑。如果是相對路徑，則相對于$CATALINA_HOME，嚴格地說是$CATALINA_BASE。

path是URI的匹配路徑，相當于nginx的location后的路徑。tomcat要求每個虛擬主機必須配置一個空字符串的path，該條context作為URI無法被明確匹配時的默認context，它相當于nginx中location / {}的作用。

docBase則是每個webapp的存放目錄(或者是已歸檔的war文件)，它可以是相對路徑，也可以是絕對路徑，提供相對路徑時它相對于appBase。該目錄一般在appBase的目錄下，但并不規定一定要放在appBase下。對于web服務來說，它相當于nginx的root指令，但對于webapp來說，一個context就相當于一個webapp，而docBase正是webapp的路徑。

"潛規則"在于默認的context如何提供。有以下幾種情況：

1.明確定義了，此時默認context的處理路徑為webappPATH。

2.明確定義了，但卻沒給定docBase屬性，此時該默認context處理路徑為appBase/ROOT目錄，注意ROOT為大寫。

3.完全沒有定義path=""的context時，即host容器中沒有明確的path=""，此時將隱式定義一個默認context，處理路徑為appBase/ROOT目錄。

4.定義了path但沒有定義docBase屬性時，docBase將根據path推斷出它的路徑。推斷的規則如下：

以下是幾個定義示例：

4. tomcat配置文件server.xml詳解

tomcat配置文件中配置的是各個組件的屬性，全局配置文件為$CATALINA_HOME/conf/server.xml，主要的組件有以下幾項：Server,Service,Connector,Engine,Host,Alias,Context,Valve等。配置完配置文件后需要重啟tomcat，但在啟動后一定要檢查tomcat是否啟動成功，因為即使出錯，很多時候它都不會報錯，可從監聽端口判斷。

配置方法見官方手冊，在頁面的左邊有各個組件的鏈接。

tomcat的配置文件都是xml文件，以下是xml文件的常見規則：

1.文件第一行設置xml標識，表示該文件是xml格式的文件。例如。

2.xml文件的注釋方法為，這可以是單行注釋，也可以多行注釋，只要前后注釋符號能對應上，中間的內容都是注釋。

3.定義屬性時有兩種方式：單行定義和多行定義。例如：

下面個組件的配置中有些地方使用了相對于$CATALINA_BASE的相對路徑，它和$CATALINA_HOME小有區別，如果只有一個tomcat實例，則它們是等價的，都是tomcat的安裝路徑。如果有多個tomcat實例，則$CATALINA_HOME表示的是安裝路徑，而$CATALINA_BASE表示的是各實例所在根目錄。關于tomcat多實例，見running.txt中對應的說明。

4.1 頂級元素server

server組件定義的是一個tomcat實例。默認定義如下：

它默認監聽在8005端口以接收shutdown命令。要啟用多個tomcat實例，將它們監聽在不同的端口即可。這個端口的定義為管理員提供一個關閉實例的便捷途徑，可以直接telnet至此端口使用SHUTDOWN命令關閉此實例。不過基于安全角度的考慮，通常不允許遠程進行。

Server的相關屬性：

className：用于實現此組件的java類的名稱，這個類必須實現接口org.apache.catalina.Server。不給定該屬性時將采用默認的標準類org.apache.catalina.core.StandardServer；

address：監聽端口綁定的地址。如不指定，則默認為Localhost，即只能在localhost上發送SHUTDOWN命令；

port：接收shutdown指令的端口，默認僅允許通過本機訪問，默認為8005；

shutdown：通過TCP/IP連接發往此Server用于實現關閉tomcat實例的命令字符串。

在server組件中可嵌套一個或多個service組件。

4.2 頂級元素service

定義了service就能提供服務了。service組件中封裝connector和containor，它同時也表示將此service中的connector和containor綁定起來，即由它們組成一個service向外提供服務。默認定義如下：

Service相關的屬性：

className：用于實現service的類名，這個類必須實現org.apache.catalina.Service接口。不給定該屬性時將采用默認的標準類org.apache.catalina.core.StandardService。

name：此service的顯示名稱，該名稱主要用于在日志中進行標識service。一般來說無關緊要，默認為Catalina。

4.3 執行器executor

執行器定義tomcat各組件之間共享的線程池。在以前，每個connector都會獨自創建自己的線程池，但現在，可以定義一個線程池，各組件都可以共享該線程池，不過主要是為各connector之間提供共享。注意，executor創建的是共享線程池，如果某個connector不引用executor創建的線程池，那么該connector仍會根據自己指定的屬性創建它們自己的線程池。

連接器必須要實現org.apache.catalina.Executor接口。它是一個嵌套在service組件中的元素，為了挑選所使用的connector，該元素還必須定義在connector元素之前。

默認的定義如下：

其中該組件的屬性有：

className：用于實現此組件的java類的名稱，這個類必須實現接口org.apache.catalina.Executor。不給定該屬性時將采用默認的標準類org.apache.catalina.core.StandardThreadExecutor；

name：該線程池的名稱，其他組件需要使用該名稱引用該線程池。

標準類的屬性包括：

threadPriority：線程優先級，默認值為5。

daemon：線程是否以daemon的方式運行，默認值為true。

namePrefix：執行器創建每個線程時的名稱前綴，最終線程的名稱為:namePrefix+threadNumber。

maxThreads：線程池激活的最大線程數量。默認值為200。

minSpareThreads：線程池中最少空閑的線程數量。默認值為25。

maxIdleTime：在空閑線程關閉前的毫秒數。除非激活的線程數量小于或等于minSpareThreads的值，否則會有空閑線程的出現。默認值為60000，即空閑線程需要保留1分鐘的空閑時間才被殺掉。

maxQueueSize：可執行任務的最大隊列數，達到隊列上限時的連接請求將被拒絕。

prestartminSpareThreads：在啟動executor時是否立即創建minSpareThreads個線程數，默認為false，即在需要時才創建線程。

例如在connector中指定所使用的線程池，方式如下：

4.4 連接器connector

連接器用于接收客戶端發送的請求并返回響應給客戶端。一個service中可以有多個connector。有多種connector，常見的為http/1.1,http/2和ajp(apache jserv protocol)。在tomcat中，ajp連接協議類型專用于tomcat前端是apache反向代理的情況下。

因此tomcat可以扮演兩種角色：

1.Tomcat僅作為應用程序服務器：請求來自于前端的web服務器，這可能是Apache, IIS, Nginx等；

2.Tomcat既作為web服務器，也作為應用程序服務器：請求來自于瀏覽器。

Tomcat應該考慮工作情形并為相應情形下的請求分別定義好需要的連接器才能正確接收來自于客戶端的請求。

此處暫先介紹HTTP/1.1連接器的屬性設置。ajp后文再做介紹。

HTTP連接器表示支持HTTP/1.1協議的組件。設置了該連接器就表示catalina啟用它的獨立web服務功能，當然，肯定也提供它必須的servlets和jsp執行功能。在一個service中可以配置一個或多個連接器，每個連接器都可以將請求轉發給它們相關聯的engine以處理請求、創建響應。

如果想要配置某個web server的連接器，則使用AJP協議。

每個流入的請求都需要一個獨立的線程來接收。當并發請求數量超出maxThreads指定的值時，多出的請求將被堆疊在套接字中，直到超出acceptCount指定的值。超出accpetCount的請求將以"connection refused"錯誤進行拒絕。

默認的定義如下：

HTTP連接器的屬性實在太多，詳細配置方法見官方手冊。通常定義HTTP連接器時必須定義的屬性只有"port"。

address：指定連接器監聽的地址，默認為所有地址，即0.0.0.0。

maxThreads：支持的最大并發連接數，默認為200；如果引用了executor創建的共享線程池，則該屬性被忽略。

acceptCount：設置等待隊列的最大長度；通常在tomcat所有處理線程均處于繁忙狀態時，新發來的請求將被放置于等待隊列中；

maxConnections：允許建立的最大連接數。acceptCount和maxThreads是接受連接的最大線程數。存在一種情況，maxConnections小于acceptCount時，超出maxConnections的連接請求將被接收，但不會與之建立連接。

port：監聽的端口，默認為0，此時表示隨機選一個端口，通常都應該顯式指定監聽端口。

protocol：連接器使用的協議，用于處理對應的請求。默認為HTTP/1.1，此時它會自動在基于Java NIO或APR/native連接器之間進行切換。定義AJP協議時通常為AJP/1.3。

redirectPort：如果某連接器支持的協議是HTTP，當接收客戶端發來的HTTPS請求時，則轉發至此屬性定義的端口。

connectionTimeout：等待客戶端發送請求的超時時間，單位為毫秒，默認為60000，即1分鐘；注意，這時候連接已經建立。

keepAliveTimeout：長連接狀態的超時時間。超出該值時，長連接將關閉。

enableLookups：是否通過request.getRemoteHost()進行DNS查詢以獲取客戶端的主機名；默認為true，應設置為false防止反解客戶端主機；

compression：是否壓縮數據。默認為off。設置為on時表示只壓縮text文本，設置為force時表示壓縮所有內容。應該在壓縮和sendfile之間做個權衡。

useSendfile：該屬性為NIO的屬性，表示是否啟用sendfile的功能。默認為true，啟用該屬性將會禁止compression屬性。

當協議指定為HTTP/1.1時，默認會自動在NIO/APR協議處理方式上進行按需切換，如要顯式指定協議，方式如下：

其中NIO是C/C++的非阻塞IO復用模型在JAVA中的IO實現，NIO2即AIO是異步NIO，即異步非阻塞IO：

它們之間的異同點如下表所示：

下面是一個定義了多個屬性的SSL連接器：

4.5 容器類engine

engine是service組件中用來分析協議的引擎機器，它從一個或多個connector上接收請求，并將請求交給對應的虛擬主機進行處理，最后返回完整的響應數據給connector，通過connector將響應數據返回給客戶端。

只有一個egine元素必須嵌套在每個service中，且engine必須在其所需要關聯的connector之后，這樣在engine前面的connector都可以被此engine關聯，而在engine后面的connector則被忽略，因為一個service中只允許有一個engine。

定義方式大致如下：

常用的engine屬性有：

className：實現engine的類，該類必須實現org.apache.catalina.Engine接口。不給定該屬性時將采用默認的標準類org.apache.catalina.core.StandardEngine。

defaultHost：指定處理請求的默認虛擬主機。在Engine中定義的多個虛擬主機的主機名稱中至少有一個跟defaultHost定義的主機名稱同名。

name：Engine組件的名稱，用于記錄日志和錯誤信息，無關緊要的屬性，可隨意給定。

jvmRoute：在啟用session粘性時指定使用哪種負載均衡的標識符。所有的tomcat server實例中該標識符必須唯一，它會追加在session標識符的尾部，因此能讓前端代理總是將特定的session轉發至同一個tomcat實例上。

注意，jvmRoute同樣可以使用jvmRoute的系統屬性來設置。如果此處設置了jvmRoute，則覆蓋jvmRoute系統屬性。關于jvmRoute的使用，在后面tomcat ajp負載均衡的文章中介紹。

engine是容器中的頂級子容器，其內可以嵌套一個或多個Host作為虛擬主機，且至少一個host要和engine中的默認虛擬主機名稱對應。除了host，還可以嵌套releam和valve組件。

4.6 容器類host

host容器用來定義虛擬主機。engine從connector接收到請求進行分析后，會將相關的屬性參數傳遞給對應的(篩選方式是從請求首部的host字段和虛擬主機名稱進行匹配)虛擬host進行處理。如果沒有合適的虛擬主機，則傳遞給默認虛擬主機。因此每個容器中必須至少定義一個虛擬主機，且必須有一個虛擬主機和engine容器中定義的默認虛擬主機名稱相同。

大致定義方式如下：

常用屬性說明：

className：實現host容器的類，該類必須實現org.apache.catalina.Host接口。不給定該屬性時將采用默認的標準類org.apache.catalina.core.StandardHost。

name：虛擬主機的主機名，忽略大小寫(初始化時會自動轉換為小寫)。可以使用前綴星號通配符，如"*.a.com"。使用了星號前綴的虛擬主機的匹配優先級低于精確名稱的虛擬主機。

appBase：此Host的webapps目錄，即webapp部署在此虛擬主機上時的存放目錄。包括非歸檔的web應用程序目錄和歸檔后的WAR文件的目錄。使用相對路徑時基于$CATALINA_BASE。

xmlBase：部署在此虛擬主機上的context xml目錄。

startStopThreads：啟動context容器時的并行線程數。如果使用了自動部署功能，則再次部署或更新時使用相同的線程池。

autoDeploy：在Tomcat處于運行狀態時放置于appBase目錄中的應用程序文件是否自動進行deploy或自動更新部署狀態。這等于同時開啟了deployOnStartup屬性和reload/redeploy webapp的功能。觸發自動更新時將默認重載該webapp。默認為true。

unpackWars：在執行此webapps時是否先對歸檔格式的WAR文件解壓再運行，設置為false時則直接執行WAR文件；默認為true。設置為false時會損耗性能。

workDir：該虛擬主機的工作目錄。每個webapp都有自己的臨時IO目錄，默認該工作目錄為$CATALINA_BASE/work。

大多數時候都只需設置虛擬主機名稱name和webBase屬性即可，其余采用默認，默認時會自動部署webapp。有時候還需要管理多個站點名稱，即主機別名。可以使用Alias為Host指定的主機名定義主機別名。如：

自動部署指的是自動裝載webapp以提供相關webapp的服務。

4.7 容器類context

connector和containor是整個tomcat的心臟，而context則是containor的心臟，更是tomcat心臟的心臟。它是真正管理servlet的地方，它的配置影響了servlet的工作方式。

一個context代表一個webapp。servlet中規定，每個webapp都必須基于已歸檔的WAR(WEB application archive)文件或基于非歸檔相關內容所在目錄。

catalina基于對請求URI與context中定義的path進行最大匹配前綴的規則進行挑選，從中選出使用哪個context來處理該HTTP請求。這相當于nginx的location容器，catalina的path就相當于location的path，它們的作用是相同的。

每個context都必須在虛擬主機容器host中有一個唯一的context name。context的path不需要唯一，因為允許同一個webapp不同版本的共存部署。此外，必須要有一個context的path為0長度的字符串(即)，該context是該虛擬主機的默認webapp，用于處理所有無法被虛擬主機中所有context path匹配的請求。

關于context name，它是從context path推斷出來的，不僅如此，其余幾個屬性如context basefile name也是由此推斷出來的。規則如下：

如果path不為空，則context name等于context path，basefile name取path中去除前綴"/"后的路徑，且所有"/"替換為"#"。

如果path為空，則context name也為空，而basefile為ROOT(注意是大寫)。

例如：

配置context時，強烈建議不要定義在server.xml中，因為定義conf/server.xml中時，只能通過重啟tomcat來重載生效，也就是說無法自動部署應用程序了。雖說官方如此推薦，但大多數人出于習慣和方便，還是會直接寫在server.xml中，這并沒有什么問題，無非是重啟一下而已。

可以考慮定義在/META-INF/context.xml中，如果此時設置了copyXML屬性，在部署時會將此context.xml復制到$CATALINA_BASE/conf/enginename/hostname/下，并重命名為"basefile name.xml"。也可以直接定義在$CATALINA_BASE/conf/enginename/hostname/下的.xml文件中，該路徑的xml優先級高于/META-INF/context.xml。

還可以定義默認的context.xml文件，包括兩種：(1)定義在$CATALINA_BASE/conf/context.xml中，該默認context對所有webapp都生效；(2)定義在$CATALINA_BASE/conf/[enginename]/[hostname]/context.xml.default中，該默認context只對該虛擬主機中的所有webapp生效。

定義方式大致如下：

其中第一個context的path為空字符串，表示它是默認的context。當瀏覽器中輸入www.a.com時，由于無法匹配第二個context，所以被默認即第一個context處理，當瀏覽器中輸入www.a.com/bbs時，將被第二個context處理，它將執行web/bbs所對應的webapp，并返回相關內容。

在context容器中可以定義非常多的屬性，詳細內容見官方手冊，以下是常見的幾個屬性：

className：實現host容器的類，該類必須實現org.apache.catalina.Context接口。不給定該屬性時將采用默認的標準類org.apache.catalina.core.StandardContext。

cookies：默認為true，表示啟用cookie來標識session。

docBase：即DocumentRoot，是該webapp的context root，即歸檔WAR文件所在目錄或非歸檔內容所在目錄。可以是絕對路徑，也可以是相對于該webapp appBase的相對路徑。

path：定義webapp path。注意，當path=""時，表示默認的context；另外只有在server.xml中才需要定義該屬性，其他所有情況下都不能定義該屬性，因為會根據docBase和context的xml文件名推斷出path。

reloadable：是否監控/WEB-INF/class和/WEB-INF/lib兩個目錄中文件的變化，變化時將自動重載。在測試環境下該屬性很好，但在真實生產環境部署應用時不應該設置該屬性，因為監控會大幅增加負載，因此該屬性的默認值為false。

wrapperClass：實現wrapper容器的類，wrapper用于管理該context中的servlet，該類必須實現org.apache.catalina.Wrapper接口，如果不指定該屬性則采用默認的標準類。

xmlNamespaceAware：和web.xml的解析方式有關。默認為true，設置為false可以提升性能。

xmlValidation：和web.xml的解析方式有關。默認為true，設置為false可以提升性能。

4.8 被嵌套類realm

realm定義的是一個安全上下文，就像是以哪種方式存儲認證時的用戶和組相關的數據庫。有多種方式可以實現數據存放：

JAASRealm：基于Java Authintication and Authorization Service實現用戶認證；

JDBCRealm：通過JDBC訪問某關系型數據庫表實現用戶認證；

JNDIRealm：基于JNDI使用目錄服務實現認證信息的獲取；

MemoryRealm：查找tomcat-user.xml文件實現用戶信息的獲取；

UserDatabaseRealm：基于UserDatabase文件(通常是tomcat-user.xml)實現用戶認證，它實現是一個完全可更新和持久有效的MemoryRealm，因此能夠跟標準的MemoryRealm兼容；它通過JNDI實現；

下面是一個常見的使用UserDatabase的配置：

下面是一個使用JDBC方式獲取用戶認證信息的配置：

4.9 被嵌套類valve

Valve中文意思是閥門，類似于過濾器，它可以工作于Engine和Host/Context之間、Host和Context之間以及Context和Web應用程序的某資源之間。一個容器內可以建立多個Valve，而且Valve定義的次序也決定了它們生效的次序。

有多種不同的Valve：

AccessLogValve：訪問日志Valve；

ExtendedAccessValve：擴展功能的訪問日志Valve；

JDBCAccessLogValve：通過JDBC將訪問日志信息發送到數據庫中；

RequestDumperValve：請求轉儲Valve；

RemoteAddrValve：基于遠程地址的訪問控制；

RemoteHostValve：基于遠程主機名稱的訪問控制；

SemaphoreValve：用于控制Tomcat主機上任何容器上的并發訪問數量；

JvmRouteBinderValve：在配置多個Tomcat為以Apache通過mod_proxy或mod_jk作為前端的集群架構中，當期望停止某節點時，可以通過此Valve將用記請求定向至備用節點；使用此Valve，必須使用JvmRouteSessionIDBinderListener；

ReplicationValve：專用于Tomcat集群架構中，可以在某個請求的session信息發生更改時觸發session數據在各節點間進行復制；

SingleSignOn：將兩個或多個需要對用戶進行認證webapp在認證用戶時連接在一起，即一次認證即可訪問所有連接在一起的webapp；

ClusterSingleSingOn：對SingleSignOn的擴展，專用于Tomcat集群當中，需要結合ClusterSingleSignOnListener進行工作；

其中RemoteHostValve和RemoteAddrValve可以分別用來實現基于主機名稱和基于IP地址的訪問控制，控制本身可以通過allow或deny來進行定義，這有點類似于Apache的訪問控制功能。如下面的Valve實現了僅允許本機訪問/probe：

其中相關屬性定義有:

className：在對應位置的后綴上加上".valves.RemoteHostValve"或".valves.RemoteAddrValve"；

allow：以逗號分開的允許訪問的IP地址列表，支持正則，點號“.”用于IP地址時需要轉義；僅定義allow項時，非明確allow的地址均被deny；

deny: 以逗號分開的禁止訪問的IP地址列表，支持正則；使用方式同allow；僅定義deny項時，非明確deny的地址均被allow；

另外一個常用的Valve為AccessLogValve，定義方式大致如下：

其中prefix和suffix表示日志文件的前綴名稱和后綴名稱。pattern表示記錄日志時的信息和格式。