今天 本是懷著無比激動的心情來讀原始碼。可是，tomcat一層套一層的 ， 卻搞的我暈頭轉向，不知所云。

還是對Tomcat的整體架構，有一定的瞭解後在來讀吧！

另外，今天發現，tomcat webapp目錄下的docs目錄，有很多幹貨啊。

1. 介面 ： Server ， Service ， Engine ,Host ,Context , Wrapper , Connnector，實現LifeCycle管理生命週期

   元件的層次關係 ： 分析server.xml ， 體會這種巢狀關係

  面向元件的架構！

                    、

目錄 ：

1.元件分類
2.架構的好處
3.頂級元件 server and service
4.聯結器 Connector
5.容器元件
     Engine
     Host (虛擬主機相關)
     Context
     Wrapper
6.巢狀元件
     Value
     Realm
     Executor
     Listener
     SessionManager
7.tomcat類載入

     下面讓我們來看看Tomcat

容器的整體結構：

 

本文的目的是覆蓋這張圖中所涉及的主要請求處理元件。而上圖中的一些高階主題如叢集和安全則不是在本文討論的範圍之內。

本圖中，Service, Host, Context以及Wrapper例項之後的符號“+”表示這些物件能存在一個或多個。例如一個Service可能只有一個Engine，但是一個Engine可以包含一個或多個Host；另外，圖中旋轉的圓圈代表請求處理器的執行緒池。

1、元件分類

Tomcat架構採用類似俄羅斯巢狀娃娃（譯註：一層套一層）的設計方式。換句話說，就是一個容器包含另一個容器，而這個被包含的容器實體反過來再包含別的實體。

而在Tomcat中，“容器

”是對任何包含有其他元件的元件的通稱，如Server、Service、Engine、Host以及Context都稱為容器。 其中Server和Service元件比較特殊些，被設計為頂級元素，代表Tomcat執行例項。而Tomcat其他所有的元件都屬於這些頂級元素。其中Engine、Host以及Contex都被官方稱為容器並依賴處理傳入請求和生成適當資料響應的相關元件。

而被巢狀的元件可以作為子元素來嵌入頂級元素或其他容器之中來配置這些元件的工作方式。這其中，巢狀元件包括代表可重用的工作單元的Valve元件、代表Valve鏈的Pipeline元件以及幫助特定容器建立容器管理安全的Realm元件。

此外，巢狀元件中還包括用來強制servlet中的類使用指定的規範來載入類的載入器；為每個web應用提供session管理的管理器；代表web應用中靜態資源以及提供機制來訪問這些資源的資源管理元件；以及在容器的生命週期內允許在重要的點插入自定義處理程式的監聽器元件，例如當某個元件啟動或停止時就可以使用監聽器。

值得注意的是，並不是所有的前臺元件都可以被巢狀在每個容器中。

這裡還有最後一個主要元件，那就是聯結器（Connector）；它代表一個連線點，通過這個連線點外部客戶端可以（比如網頁瀏覽器）可以連線至Tomcat容器。

在我們去學習這些元件之前，讓我們快速看下這些元件的大體結構：

請注意，上圖只展示了每個容器的關鍵屬性。

啟動Tomcat時，它執行的Java虛擬機器（JVM）例項中包含一個伺服器頂級元素，該元素代表了一個完整Tomcat伺服器。一個Tomcat伺服器通常只包含一個Service物件，這個物件是一種包含一個或多個聯結器（Connector，如HTTP、HTTPS聯結器）的結構化元素，正是這些Connector通過一個Catalina的Servlet引擎來處理傳入的請求。

引擎（Engine）表示Tomcat中處理請求的核心程式碼，並且它還支援在其下定義多個虛擬主機（Host）。虛擬主機允許Tomcat引擎在將配置在一臺機器上的多個域名（如www.my-site.com、www.your-site.com）分割開來互不干擾。

反過來，每個虛擬主機又可以支援多個web應用部署在它下邊，這就是我們所熟知的上下文物件（Context）。上下文（Context）是使用由Servlet規範中指定的Web應用程式格式表示,不論是壓縮過的war包形式的檔案還是未壓縮的目錄形式。此外，上下文一般是在web.xml檔案中配置，並且該配置是根據servlet規範定義的。

從上下問角度看，在上下文中又可以部署多個servlet，並且每個servlet都會被一個包裝元件所包含。

至此，我們以上所說的Server、Service、Connector、Engine、Host、Context元素都會通過server.xml配置檔案在tomcat例項中被使用。

2、架構的好處

這種架構有一些很實用的功能。它不僅便於元件的生命週期管理（每個元件管理生命週期並通知其子節點），而且便於在Tcomat啟動時根據從配置檔案中讀取的配置檔案來動態組裝出Tomcat伺服器例項。尤其是server.xml在啟動時就會被解析，其內容正是用來例項化和配置被定義的元素，並隨後組裝到正在執行的Tomcat例項中。

server.xml檔案只會被讀取一次，對server.xml的修改只有在Tomcat重啟後才會起作用。

同時這種架構簡化配置，允許子容器繼承父容器的配置。例如Realm定義了一個可驗證許可權的資料儲存，並且可以授權使用者通過web應用來訪問受保護資源。為了便於配置，針對引擎定義的Realm適用於它所有的host和context配置。同時，某一個特定的子元素如context也可以通過繼承父類的realm來實現自定義realm。

3、頂級元件

Server和Service容器元件存在的目的是儘可能的方便結構化。Server表示正在執行的Tomcat例項，可包含一個或多個Service子容器；其中每個Service代表一組請求處理元件。

Server

Server代表完整的Tomcat例項在Java虛擬集中是單例，主要是用來管理容器下各個Serivce元件的生命週期。

下圖描述了Server元件的關鍵方面。如圖所示，Server例項是通過server.xml配置檔案來配置的；其根元素<Server>所代表的正是Tomcat例項，預設實現為org.apache.catalina.core.StandardServer。但是，你也可以通過<Server>標籤的class屬性來自定義伺服器實現。

伺服器可重要的一方面就是它打開了8005埠（預設埠）來監聽關閉服務命令（預設情況下命令為SHUTDOWN）。當收到shutdown命令後，伺服器會優雅的關閉自己。同時出於安全考慮，發起關閉請求的連線必須來自同一臺機器上的同一個執行中的Tomcat例項。

此外，Server還提供了一個Java命名服務和JNDI服務，可以通過這兩個服務可以使用名稱來註冊專用物件（如資料來源配置）。在執行期，單個元件（如Servlet）可以使用物件名稱來通過伺服器的JNDI繫結服務來查詢需要的物件相關資訊。

雖然JNDI實現並不是Servlet容器的功能，但是它屬於JavaEE規範一部分，並且可以為Servlet從應用伺服器或者servlet容器中獲取所需要的資訊提供服務。

雖然在一個JVM中通常只有一個伺服器例項，但是完全可以在同一臺物理機器中執行多個伺服器例項，每個例項對應一個JVM例項；這種做法將執行在一個JVM中的應用中的錯誤與其他JVM中應用的錯誤隔離開來互不影響，這也簡化了維護使得JVM的重啟與其他獨立開來。這是一個共享主機環境的機制（另一種是虛擬主機機制,很快我們將會看到），這種機制下需要將執行在同一物理主機下的多個web應用隔離開來。

Service

Server代表Tomcat例項本身，Service則代表Tomcat中一組請求處理的元件。

Server可以包含一個或多個Service，但每個Service則將一組Connector元件和Engine關聯了起來。

客戶端請求首先到達聯結器(connector),聯結器在再將這些請求輪流傳入引擎中處理，而Engine也是Tomcat中請求處理的關鍵元件。上圖中展示了HTTP聯結器、HTTPS連線以及AJP元件。

一般很少會修改這個元素，而且預設的Service例項通常就足夠使用了。

值得注意的是上圖中可能有多個Service例項。如圖所示，一個Service集中了一些聯結器，每個聯結器監控一個指定的IP及埠並通過指定的協議做出響應。所以，一個關於多個服務的使用示例就是當你希望通過IP地址或者埠號來區分不同服務（包括這些服務中所包含的engine、host、web應用）時。

例如，當需要配置防火牆來為使用者開放某一個服務而該主機上託管的其他服務仍然只是對內部使用者可見，這將確保外部使用者無法訪問內部應用程式，因為對應訪問會被防火牆攔截。

因此，Service僅僅是一個分組結構，它並不包含任何其他的附加功能。

4、聯結器（Connector）

Connector是客戶端連線到Tomcat容器的服務點它為引擎提供協議服務來將引擎與客戶端各種協議隔離開來，如HTTP、HTTPS、AJP協議。

Tomcat有兩種可配的工作模式--獨立模式或在同一web伺服器中共享模式。

在獨立模式下，Tomcat會配置HTTP和HTTPS聯結器，這可以使Tomcat看起來更像完整的web伺服器以處理靜態請求內容同時還委託Catalina引擎來處理動態內容。

釋出時，Tomcat為這種運作模式提供了3種可能實現，即HTTP、HTTP1.1以及HTTPS。

Tomcat中最常見的聯結器為標準聯結器，也就是通過java標準I／O實現的Coyote聯結器。

你也許希望使用一些技術實現，這其中就包括使用Java1.4中引入的非阻塞特性NIO，另一方面可能是通過APR充分利用原生代碼來優化特定的作業系統。

值得注意的是，Connector和Engine不僅執行在同一個JVM中，而且還執行在同一個Tomcat服務例項中。

在共享模式中，Tomcat扮演著對web伺服器如Apache httpd和微軟的IIS支撐的角色。這裡web伺服器充當客戶端通過Apache模組或者通過dll格式ISAPI模組來和Tomcat通訊。當該模組判定一個請求需要傳入Tomcat處理時，它將使用AJP協議來與Tomcat通訊，該協議為二進位制協議，在web伺服器和Tomcat通訊時比基於文字的Http協議更高效。

在Tomcat端，通過AJP聯結器來接收wen伺服器的請求，並將請求解釋為Catalina引擎可處理的格式。

這種模式下Tomcat作為來自web伺服器的單獨程序執行在自身獨立的JVM中。

不論在哪種模式中，Connector的基本屬性都是它所需要監聽的IP地址及埠號，以及所支援的協議。還有一個關鍵屬性就是併發處理傳入請求的最大執行緒數。一旦所有的處理執行緒都忙，那麼傳入的請求都將被忽略，直到有執行緒空閒為止。

預設情況下，聯結器會監聽指定物理機器上的所有IP（address屬性預設值為0.0.0.0）；但也可以配置為只監聽某一個IP，這將限制它只接收指定ip的連線請求。

任意一個聯結器接收到的請求都會被傳入單一的服務引擎中，而這個引擎，就是眾所周知的catalina，它負責處理請求並生成響應結果。

引擎將生成的結果返回給聯結器，聯結器再通過指定的協議將結果回傳至客戶端。

5、容器元件

這一小節中我們將討論請求處理元件：引擎（engine）、虛擬主機、上下文（context）元件。

5.1、引擎（engine）

引擎表示可執行的Catalina的servlet引擎例項並且包含了servlet容器的核心功能。在一個服務中只能有一個引擎。同時，作為一個真正的容器，Engine元素之下可以包含一個或多個虛擬主機。

作為請求處理的主要元件，它接收代表傳入請求的物件以及輸出相應結果。它主要功能是將傳入請求委託給適當的虛擬主機處理。如果根據名稱沒有找到可處理的虛擬主機，那麼將根據預設的Host來判斷該由哪個虛擬主機處理。

5.2、虛擬主機

虛擬主機在Tomcat中使用Host元件表示。

在虛擬主機中有兩個概念非常重要--主機的域名和根目錄。

·域名：每個虛擬主機是由它註冊的域名來標識的（例：www.host1.com）。域名是您預期的在客戶端瀏覽器位址列輸入的值，對虛擬主機來說就是請求頭部。一臺虛擬主機的名稱在包含它的引擎內必須是唯一的。

·根目錄：根目錄所在的資料夾包含將被部署到此主機的上下文。根目錄可以是一個絕對路徑，也可以是對CATALINA_BASE來說的一個相對路徑。

CATALINA_HOME是一個環境變數，它引用了tomcat二進位制檔案的位置。通過CATALINA_BASE環境變數僅僅使用一個tomcat安裝資訊的二進位制檔案，就可以根據不同的配置執行多個tomcat例項（這主要由conf資料夾的內容決定）。

此外，使用一個CATALINA_BASE引用的位置（和CATALINA_HOME不同）保持標準的二進位制分配獨立於您的安裝。這是有好處的，使tomcat升級到一個新版本變得容易，而不必擔心影響已經發布的web應用程式和相關的配置檔案 。

基本概念

當涉及到主機名對映到網際網路協議地址時，最簡單的場景，一個給定的完全合格的主機名(FQHN)，例如www.swengsol.com與對映到特定主機的IP地址相關聯。

這種方法的缺點是，主機連線到網際網路是相當昂貴的。這是真實存在的，尤其是當您考慮到頻寬成本、網路基礎設施建設(例如：資料庫/郵件伺服器、防火牆、不間斷電源ups、容錯等)以及維護(包括人員配置、管理和備份)，更不用說首先要獲得一個IP地址。

因此，許多小企業認為最好的方法是從託管服務提供商那裡租賃空間和基礎設施。託管服務可能是提供單個的物理伺服器，它可以連線到網際網路並由特定的IP地址標識。這臺物理伺服器可以託管多個域名，每個域名代表一個提供商的客戶。

什麼是虛擬主機？

例如，我們假設Acme Widgets Inc.和Vertico LLC擁有它們的域名，www.acme-widgets.com和www.vertico.com，這些域名被託管在同一臺物理伺服器上。應用程式被部署到各自對應的域，並且互不干擾。

在這種情況下，這些域被稱為虛擬主機，從這種意義上來講，每一個域看起來都是一個獨立的“物理主機”。然而，事實上，他們(域)僅僅是同一臺物理主機上不同的邏輯分割槽。

5.3、虛擬主機技術

有兩種常用的方法來設定虛擬主機：

·基於獨立IP地址的虛擬主機服務

·基於名稱的虛擬主機服務

5.3.1基於獨立IP地址的虛擬主機服務

使用這種技術，每個FQHN(完全合格的主機名)被解析為一個單獨的IP地址。然而，這些IP中的每一個被解析後都對映到同一臺物理機器上。

您可以使用以下的機制來實現此技術：

·多宿主伺服器，也就是說它安裝了多個網絡卡(NICs),每一個網絡卡都分配了IP地址

·使用作業系統功能來設定虛擬網路介面，為單個物理NIC（網絡卡）動態分配多個IP地址

無論在哪一種情況下，缺點是我們要獲得多個IP地址，而且這些地址(至少對於IPv4來說)是一種有限的資源。

Web伺服器監聽為這些IP地址分配的埠，當Web伺服器在一個特定的IP地址檢測到傳入的請求時，它會生成該IP地址的響應資訊。

例如，您有一個web伺服器，它執行在一個特定的在80埠監聽 11.156.33.345 和 11.156.33.346 IP地址請求的物理主機上。此web伺服器用以下方式響應請求：當收到來自主機域名www.host1.com的請求時，則對映到11.156.33.345 IP地址；反之當收到來自主機域名www.host2.com的請求時則對映到後面的 IP地址 11.156.33.346 。

當接收到一個來自11.156.33.346 IP地址的請求時，web伺服器知道它應當為ww.host2.com對應的域準備響應資訊。對使用者來說，這是一個完全獨立的物理伺服器在為他提供服務。

5.3.2基於名稱的虛擬主機服務

這是一種比較新的技術，它允許您把不同的域名對映到同一個IP地址。這些都是經過註冊的正常的域名，多個DNS條目將這些域名對映到同一IP地址。

HTTP 1.1協議要求每個請求必須包含一個主機頭：帶有完全合格的主機域名，以及使用者希望連線的埠號(如果已指定)。主機上執行的web伺服器接收到此請求，解析此請求中的主機頭資訊，以確定相應的虛擬主機來響應此請求。簡單、而且不使用不必要的IP地址，基於名稱的虛擬主機服務是我們的首選。

然而，當您同時使用SSL(安全套接層)和虛擬主機時，您也許不得不使用基於IP地址的虛擬主機服務。原因是，在特定的虛擬主機響應請求之前，協商協議要進行證書認證。這是因為：SSL協議層位於HTTP協議層的下方，而且在握手訊息認證完成之前，與客戶端請求進行安全認證的模組無法讀取HTTP請求頭資訊。

您也許可以同時使用SSL和基於名稱的虛擬主機服務，如果您的web伺服器和客戶機支援RFC3546(傳輸層安全性擴充套件http://www.ietf.org/rfc/rfc3546.txt) 指定的伺服器名稱標識擴充套件。使用此擴充套件，在SSL協商期間，客戶端會傳輸主機名稱給它嘗試連線的物件，從而使web伺服器能夠處理握手資訊併為正確的主機名返回證書。

虛擬主機別名

當 web伺服器解析別名資訊時，例如它在主機頭裡看到了域名的別名，那麼web伺服器會把此別名當作虛擬主機的域名來處理。 例如，您把swengsol.com設定為虛擬主機域名www.swengsol.com的別名，那麼在客戶端url裡無論是輸入域名還是別名，您都會收 到來自同一個虛擬主機的響應資訊。 這種方式效果不錯，當一個物理主機有多個域名時，而且您不想弄亂配置檔案在為每個別名建立一組條目時。

5.4、上下文（Context）

上下文或者web應用是應用自定義程式碼（servlet、jsp）所存活的地方。它為web應用組織資源提供了便利。

同時context容器為servlet提供了一個ServletContext例項。在許多方面,servlet規範主要是關心這個上下文元件。例如，它規定了部署上下文的格式以及部署內容的描述符。

以下是上下文的一些重要屬性：

·根目錄（document base）：這個路徑是指war包或者未壓縮的專案檔案所存放的目錄，可以是相對的，也可以是絕對的。

·上下文路徑（context path）：它是指在一個host下url中唯一標識一個web應用的部分。它幫助host容器來判斷該由哪一個已部署的上下文來處理傳入的請求。

也許你可能配置了預設context，它可以在找不到匹配的context的情況下來處理傳入請求。該預設context可以通過將其上下文路徑配置為空來標記的，因此，可以通過只有主機名的路徑來訪問它（譯註：如http://localhost:8080/來訪問）。並且該context已被tomcat預設定義為根目錄下的ROOT目錄。

·自動重載入（automic reload）：上下文中的資源會被tomcat監控，一旦資源發生改變Tomcat就會自動重新載入資原始檔。雖然該功能在開發過程中非常有用，但是在生產環境這個操作代價非常高，通常需要重啟產品應用。

Context配置

Context是唯一的，這主要是因為它的配置包含多個選項。而我們之前已經注意到的conf/server.xml是用來配置Tomcat例項中一些全域性性的引數。雖然在這個檔案中可以配置context相關的東西，但是不推薦這樣做。

相反，Tomcat推薦大家將context相關的配置從server.xml中提取出來，配置到上下文段檔案中，該檔案會被Tomcat監控並且可以在執行過程中重新載入。

請再次注意，server.xml只有在啟動時被載入一次。

同時需要確保在context中配置一個獨立明確的host和engine，因為Tomcat會在CATALINA_HOME/conf///目錄下查詢context相關配置。而該目錄下為特定主機配置的上下文段檔案則是以名稱.xml命名。

預設情況下，會有一個引擎Catalina和一個名稱為localhost的主機，對應的工作目錄為CATALINA_HOME/conf/Catalina/localhost。但是該目錄也可以是有效域名，如www.swengsol.com，那麼對應目錄就是CATALINA_HOME/conf/Catalina/www.swengsol.com。

另外，context片段也可以在war或部署目錄中被包含在META-INF目錄下。這種情況下，context檔名稱必須為context.xml。

此外，Context還可以被配置在web應用描述符檔案web.xml中。雖然這個片段檔案是Tomcat專用的，但是由於該描述符是通過Servlet規範來描述的，因此它也適用與JavaEE下的其他輕量級servlet容器。

包裝器（Wrapper）

包裝器wrapper物件是context容器的子容器，表示一個單獨的servlet（或者由jsp檔案轉換而來的servlet），他就不能在包含其他容器了。它之所以稱為包裝器是因為它包裝了java.servlet.Servlet例項。

這是容器層次結構的最底層，新增任何子類都會導致異常。

同時包裝器還對它所包裝的servlet負責，包括載入、例項化servlet以及呼叫控制servlet生命週期相關的函式，如init()、service()和destroy()方法。

此外包裝器還通過它基本的Valve來呼叫和其包裝的servlet相關的過濾器。

巢狀元件

這些元件是針對Tocmat做的特定實現，他們的主要目的是使各種Tomcat容器可以完成各自的工作。

1、閥（Valve）

valve是處理元素，它可以被包含在每個Tomcat容器的處理路徑中--如engine、host、context以及servelt包裝器。若要增加Valve到Tomcat容器則需要在server.xml中使用<Valve>標籤。在server.xml中這些標籤的執行順序與其物理順序相同。

而在Tomcat中也分佈這大量預先編譯好的valve。包括：

•在請求日誌元素中將請求（如遠端客戶端ip地址）寫入日誌檔案或資料庫時

•根據遠端客戶端ip或主機名來控制某一特定web應用的訪問許可權時

•記錄每個請求和響應頭資訊日誌時

•在同一個虛擬主機下為多個應用配置單點登入時

如果以上這些都不能滿足你的要求，那麼你可以通過繼承org.apache.catalina.Valve來實現自定義的Valve並將其配置到對應服務中。

// 管道過濾器的軟體體系結構

 

但是對於一個容器來說，它並不會持有某個單獨valve的引用；相反，它會持有一個稱作管道（Pipeline）的單一實體的引用，並用這個管道來表示與該容器所關聯的一系列valve。

當一個容器被呼叫來處理一個請求時，它會委託與其關聯的管道來處理對應請求。

在管道中，這些valve則是基於他們在server.xml中的定義作順序排列。其中排在佇列中排在最後的valve被稱為管道的基本valve，該valve用來完成去執行容器的核心功能的任務。

與單個valve不同，管道在server . xml不是一個明確的元素，而是含蓄的按照valve在給定容器中所定義的順序組成。

並且在管道中，每個valve都知道其下一個valve；在它執行完前置處理以後，接下來它會呼叫鏈中的下一個valve，當該呼叫返回以後，它會在return之前執行他自身的處理任務。

這種方式和servlet規範中的過濾器鏈所做的事情非常相似。

在這幅圖中，當接收到傳入請求時引擎所配置的valve首先被觸發。其中引擎中基本的valve負責確定目標主機委託該主機來處理；接下來目標主機(www.host1.com)的valve被按順序觸發。而該主機的基本valve則又決定了目標context(在這裡是Context1)並且委託該context來處理該請求。最後Context1中所配置的valve被觸發，然後通過context中配置的基本valve委託給適當的包裝器來處理；而包裝器的基本valve又將處理轉交至被包裝的servlet來處理。

處理完成以後，響應結果會按照以上的路徑反方向返回。

由於Valve就成了Tomcat伺服器實現中的一部分，並且可以為開發者提供一種方式將自定義的程式碼注入到處理請求的servlet容器中。因此，自定的valve類檔案需要釋出到CATALINA_HOME/lib目錄下而不是應用的釋出目錄WEB-INF/classes。

由於它們並不是servlet規範中的部分，所以valve在企業級一用中屬於不可移植元素。因此，如果已經依賴了一個特定的valve時，你必須在不同的應用伺服器上找到對等的選擇方案。

還有很重要的一點就是，為了不影響請求處理的效率必須要保證valve的程式碼高效執行。

2、Realm

容器管理安全方面的工作通過容器處理應用程式的身份驗證和授權方面來解決。

身份驗證存在的主要任務就是確保使用者所說的就是她自己，而授權的主要任務是決定一個使用者是否可以在某個應用下執行特定操作。

由容器來管理安全的優勢是可以通過應用的釋出者直接來配置安全措施。也就是說，為使用者分配密碼以及為使用者分配角色都可以使用者配置來完成，而這些配置也可以在修改任何程式碼的情況下來供多個web應用共用。

應用管理安全

還有一種可選方案就是通過應用來管理安全問題。這種情況下，我的web應用程式程式碼就是唯一的仲裁者來決定使用者在我們的應用下是否有訪問特定功能或資源的許可權。

想要使容器來管理安全問題起作用，我們需要組裝一下元件：

•安全約束：在我們的web應用部署描述器web.xml中，我們必須確定限制資源訪問的url表示式以及可以訪問這些資源的使用者角色。

•憑證輸入機制：在web.xml部署檔案中，我們需要指定容器應該如何提示使用者通過憑證來驗證。這通常是通過彈出一個對話方塊提示使用者輸入使用者名稱和密碼來完成，但也可以配置使用其他機制,如一個定製的登入表單等。

相關推薦