大家好，現在小編來為大家解答以上問題。Tomcat核心組件及應用架構詳解相信很多人還不知道，現在讓我們一起來看看吧！

Web 容器是什么？

讓我們先來簡單回顧一下 Web 技術的發展歷史，可以幫助你理解 Web 容器的由來。

早期的 Web 應用主要用于瀏覽新聞等靜態頁面，HTTP 服務器（比如 Apache、Nginx）向瀏覽器返回靜態 HTML，瀏覽器負責解析 HTML，將結果呈現給用戶。

隨著互聯網的發展，我們已經不滿足于僅僅瀏覽靜態頁面，還希望通過一些交互操作，來獲取動態結果，因此也就需要一些擴展機制能夠讓 HTTP 服務器調用服務端程序。

于是 Sun 公司推出了 Servlet 技術。你可以把 Servlet 簡單理解為運行在服務端的 Java 小程序，但是 Servlet 沒有 main 方法，不能獨立運行，因此必須把它部署到 Servlet 容器中，由容器來實例化并調用 Servlet。

而 Tomcat 就是一個 Servlet 容器。為了方便使用，它們也具有 HTTP 服務器的功能，因此 Tomcat 就是一個“HTTP 服務器 + Servlet 容器”，我們也叫它們 Web 容器。

HTTP 的本質

HTTP 協議是瀏覽器與服務器之間的數據傳送協議。作為應用層協議，HTTP 是基于 TCP/IP 協議來傳遞數據的（HTML 文件、圖片、查詢結果等），HTTP 協議不涉及數據包（Packet）傳輸，主要規定了客戶端和服務器之間的通信格式。

假如瀏覽器需要從遠程 HTTP 服務器獲取一個 HTML 文本，在這個過程中，瀏覽器實際上要做兩件事情。

• 與服務器建立 Socket 連接。
• 生成請求數據并通過 Socket 發送出去。

HTTP 請求響應實例

用戶在登陸頁面輸入用戶名和密碼，點擊登陸后，瀏覽器發出了這樣的 HTTP 請求：

HTTP 請求數據由三部分組成，分別是請求行、請求報頭、請求正文。當這個 HTTP 請求數據到達 Tomcat 后，Tomcat 會把 HTTP 請求數據字節流解析成一個 Request 對象，這個 Request 對象封裝了 HTTP 所有的請求信息。接著 Tomcat 把這個 Request 對象交給 Web 應用去處理，處理完后得到一個 Response 對象，Tomcat 會把這個 Response 對象轉成 HTTP 格式的響應數據并發送給瀏覽器。

HTTP 的響應也是由三部分組成，分別是狀態行、響應報頭、報文主體。同樣，我還以極客時間登陸請求的響應為例。

Cookie 和 Session

我們知道，HTTP 協議有個特點是無狀態，請求與請求之間是沒有關系的。這樣會出現一個很尷尬的問題：Web 應用不知道你是誰。因此 HTTP 協議需要一種技術讓請求與請求之間建立起聯系，并且服務器需要知道這個請求來自哪個用戶，于是 Cookie 技術出現了。

Cookie 是 HTTP 報文的一個請求頭，Web 應用可以將用戶的標識信息或者其他一些信息（用戶名等）存儲在 Cookie 中。用戶經過驗證之后，每次 HTTP 請求報文中都包含 Cookie，這樣服務器讀取這個 Cookie 請求頭就知道用戶是誰了。Cookie 本質上就是一份存儲在用戶本地的文件，里面包含了每次請求中都需要傳遞的信息。

由于 Cookie 以明文的方式存儲在本地，而 Cookie 中往往帶有用戶信息，這樣就造成了非常大的安全隱患。而 Session 的出現解決了這個問題，Session 可以理解為服務器端開辟的存儲空間，里面保存了用戶的狀態，用戶信息以 Session 的形式存儲在服務端。當用戶請求到來時，服務端可以把用戶的請求和用戶的 Session 對應起來。那么 Session 是怎么和請求對應起來的呢？答案是通過 Cookie，瀏覽器在 Cookie 中填充了一個 Session ID 之類的字段用來標識請求。

具體工作過程是這樣的：服務器在創建 Session 的同時，會為該 Session 生成唯一的 Session ID，當瀏覽器再次發送請求的時候，會將這個 Session ID 帶上，服務器接受到請求之后就會依據 Session ID 找到相應的 Session，找到 Session 后，就可以在 Session 中獲取或者添加內容了。而這些內容只會保存在服務器中，發到客戶端的只有 Session ID，這樣相對安全，也節省了網絡流量，因為不需要在 Cookie 中存儲大量用戶信息。

那么 Session 在何時何地創建呢？當然還是在服務器端程序運行的過程中創建的，不同語言實現的應用程序有不同的創建 Session 的方法。在 Java 中，是 Web 應用程序在調用 HttpServletRequest 的 getSession 方法時，由 Web 容器（比如 Tomcat）創建的。

Tomcat 的 Session 管理器提供了多種持久化方案來存儲 Session，通常會采用高性能的存儲方式，比如 Redis，并且通過集群部署的方式，防止單點故障，從而提升高可用。同時，Session 有過期時間，因此 Tomcat 會開啟后臺線程定期的輪詢，如果 Session 過期了就將 Session 失效。

Servlet規范

HTTP 服務器怎么知道要調用哪個 Java 類的哪個方法呢。最直接的做法是在 HTTP 服務器代碼里寫一大堆 if else 邏輯判斷：如果是 A 請求就調 X 類的 M1 方法，如果是 B 請求就調 Y 類的 M2 方法。但這樣做明顯有問題，因為 HTTP 服務器的代碼跟業務邏輯耦合在一起了，如果新加一個業務方法還要改 HTTP 服務器的代碼。

那該怎么解決這個問題呢？我們知道，面向接口編程是解決耦合問題的法寶，于是有一伙人就定義了一個接口，各種業務類都必須實現這個接口，這個接口就叫 Servlet 接口，有時我們也把實現了 Servlet 接口的業務類叫作 Servlet。

但是這里還有一個問題，對于特定的請求，HTTP 服務器如何知道由哪個 Servlet 來處理呢？Servlet 又是由誰來實例化呢？顯然 HTTP 服務器不適合做這個工作，否則又和業務類耦合了。

于是，還是那伙人又發明了 Servlet 容器，Servlet 容器用來加載和管理業務類。HTTP 服務器不直接跟業務類打交道，而是把請求交給 Servlet 容器去處理，Servlet 容器會將請求轉發到具體的 Servlet，如果這個 Servlet 還沒創建，就加載并實例化這個 Servlet，然后調用這個 Servlet 的接口方法。因此 Servlet 接口其實是 Servlet 容器跟具體業務類之間的接口。下面我們通過一張圖來加深理解。

Servlet 接口和 Servlet 容器這一整套規范叫作 Servlet 規范。Tomcat 和 Jetty 都按照 Servlet 規范的要求實現了 Servlet 容器，同時它們也具有 HTTP 服務器的功能。作為 Java 程序員，如果我們要實現新的業務功能，只需要實現一個 Servlet，并把它注冊到 Tomcat（Servlet 容器）中，剩下的事情就由 Tomcat 幫我們處理了。

Servlet 接口定義了下面五個方法：

其中最重要是的 service 方法，具體業務類在這個方法里實現處理邏輯。這個方法有兩個參數：ServletRequest 和 ServletResponse。ServletRequest 用來封裝請求信息，ServletResponse 用來封裝響應信息，因此本質上這兩個類是對通信協議的封裝。

HTTP 協議中的請求和響應就是對應了 HttpServletRequest 和 HttpServletResponse 這兩個類。你可以通過 HttpServletRequest 來獲取所有請求相關的信息，包括請求路徑、Cookie、HTTP 頭、請求參數等。此外， 我們還可以通過 HttpServletRequest 來創建和獲取 Session。而 HttpServletResponse 是用來封裝 HTTP 響應的。

你可以看到接口中還有兩個跟生命周期有關的方法 init 和 destroy，這是一個比較貼心的設計，Servlet 容器在加載 Servlet 類的時候會調用 init 方法，在卸載的時候會調用 destroy 方法。我們可能會在 init 方法里初始化一些資源，并在 destroy 方法里釋放這些資源，比如 Spring MVC 中的 DispatcherServlet，就是在 init 方法里創建了自己的 Spring 容器。

你還會注意到 ServletConfig 這個類，ServletConfig 的作用就是封裝 Servlet 的初始化參數。你可以在web.xml給 Servlet 配置參數，并在程序里通過 getServletConfig 方法拿到這些參數。

我們知道，有接口一般就有抽象類，抽象類用來實現接口和封裝通用的邏輯，因此 Servlet 規范提供了 GenericServlet 抽象類，我們可以通過擴展它來實現 Servlet。雖然 Servlet 規范并不在乎通信協議是什么，但是大多數的 Servlet 都是在 HTTP 環境中處理的，因此 Servet 規范還提供了 HttpServlet 來繼承 GenericServlet，并且加入了 HTTP 特性。這樣我們通過繼承 HttpServlet 類來實現自己的 Servlet，只需要重寫兩個方法：doGet 和 doPost。

Servlet 容器

當客戶請求某個資源時，HTTP 服務器會用一個 ServletRequest 對象把客戶的請求信息封裝起來，然后調用 Servlet 容器的 service 方法，Servlet 容器拿到請求后，根據請求的 URL 和 Servlet 的映射關系，找到相應的 Servlet，如果 Servlet 還沒有被加載，就用反射機制創建這個 Servlet，并調用 Servlet 的 init 方法來完成初始化，接著調用 Servlet 的 service 方法來處理請求，把 ServletResponse 對象返回給 HTTP 服務器，HTTP 服務器會把響應發送給客戶端

Web 應用

Servlet 容器會實例化和調用 Servlet，那 Servlet 是怎么注冊到 Servlet 容器中的呢？一般來說，我們是以 Web 應用程序的方式來部署 Servlet 的，而根據 Servlet 規范，Web 應用程序有一定的目錄結構，在這個目錄下分別放置了 Servlet 的類文件、配置文件以及靜態資源，Servlet 容器通過讀取配置文件，就能找到并加載 Servlet。Web 應用的目錄結構大概是下面這樣的：

Servlet 規范里定義了 ServletContext 這個接口來對應一個 Web 應用。Web 應用部署好后，Servlet 容器在啟動時會加載 Web 應用，并為每個 Web 應用創建唯一的 ServletContext 對象。你可以把 ServletContext 看成是一個全局對象，一個 Web 應用可能有多個 Servlet，這些 Servlet 可以通過全局的 ServletContext 來共享數據，這些數據包括 Web 應用的初始化參數、Web 應用目錄下的文件資源等。由于 ServletContext 持有所有 Servlet 實例，你還可以通過它來實現 Servlet 請求的轉發。

擴展機制

引入了 Servlet 規范后，你不需要關心 Socket 網絡通信、不需要關心 HTTP 協議，也不需要關心你的業務類是如何被實例化和調用的，因為這些都被 Servlet 規范標準化了，你只要關心怎么實現的你的業務邏輯。這對于程序員來說是件好事，但也有不方便的一面。所謂規范就是說大家都要遵守，就會千篇一律，但是如果這個規范不能滿足你的業務的個性化需求，就有問題了，因此設計一個規范或者一個中間件，要充分考慮到可擴展性。Servlet 規范提供了兩種擴展機制：Filter 和 Listener。

Filter 是過濾器，這個接口允許你對請求和響應做一些統一的定制化處理，比如你可以根據請求的頻率來限制訪問，或者根據國家地區的不同來修改響應內容。過濾器的工作原理是這樣的：Web 應用部署完成后，Servlet 容器需要實例化 Filter 并把 Filter 鏈接成一個 FilterChain。當請求進來時，獲取第一個 Filter 并調用 doFilter 方法，doFilter 方法負責調用這個 FilterChain 中的下一個 Filter。

Listener 是監聽器，這是另一種擴展機制。當 Web 應用在 Servlet 容器中運行時，Servlet 容器內部會不斷的發生各種事件，如 Web 應用的啟動和停止、用戶請求到達等。 Servlet 容器提供了一些默認的監聽器來監聽這些事件，當事件發生時，Servlet 容器會負責調用監聽器的方法。當然，你可以定義自己的監聽器去監聽你感興趣的事件，將監聽器配置在web.xml中。比如 Spring 就實現了自己的監聽器，來監聽 ServletContext 的啟動事件，目的是當 Servlet 容器啟動時，創建并初始化全局的 Spring 容器。

Tomcat下載地址：https://tomcat.apache.org/download-80.cgi

打開 Tomcat 的日志目錄，也就是 Tomcat 安裝目錄下的 logs 目錄。Tomcat 的日志信息分為兩類 ：一是運行日志，它主要記錄運行過程中的一些信息，尤其是一些異常錯誤日志信息 ；二是訪問日志，它記錄訪問的時間、IP 地址、訪問的路徑等相關信息。

• catalina.***.log 主要是記錄 Tomcat 啟動過程的信息，在這個文件可以看到啟動的 JVM 參數以及操作系統等日志信息。
• catalina.out是 Tomcat 的標準輸出（stdout）和標準錯誤（stderr），這是在 Tomcat 的啟動腳本里指定的，如果沒有修改的話 stdout 和 stderr 會重定向到這里。所以在這個文件里可以看到我們在MyServlet.java程序里打印出來的信息
• localhost.**.log主要記錄 Web 應用在初始化過程中遇到的未處理的異常，會被 Tomcat 捕獲而輸出這個日志文件。
• localhost_access_log.**.txt存放訪問 Tomcat 的請求日志，包括 IP 地址以及請求的路徑、時間、請求協議以及狀態碼等信息。
• manager.***.log/host-manager.***.log存放 Tomcat 自帶的 Manager 項目的日志信息。

概要：

1. Tomcat各核心組件認知
2. server.xml 配置詳解

一、Tomcat各組件認知

知識點：

1. Tomcat架構說明
2. Tomcat組件及關系詳情介紹
3. Tomcat啟動參數說明
4. Tomcat架構說明

Tomcat是一個基于JAVA的WEB容器，其實現了JAVA EE中的 Servlet 與 jsp 規范，與Nginx apache 服務器不同在于一般用于動態請求處理。在架構設計上采用面向組件的方式設計。即整體功能是通過組件的方式拼裝完成。另外每個組件都可以被替換以保證靈活性。

2.Tomcat 各組件及關系

Server 和 Service
Connector 連接器
HTTP 1.1
SSL https
AJP（ Apache JServ Protocol） apache 私有協議，用于apache 反向代理Tomcat
Container 
Engine 引擎 catalina
Host 虛擬機 基于域名 分發請求
Context 隔離各個WEB應用 每個Context的 ClassLoader都是獨立
Component 
Manager （管理器）
logger （日志管理）
loader （載入器）
pipeline (管道)
valve （管道中的閥）

二、Tomcat server.xml 配置詳解

server

root元素：server 的頂級配置 主要屬性: port：執行關閉命令的端口號 shutdown：關閉命令

演示shutdown的用法 #基于telent 執行SHUTDOWN 命令即可關閉(必須大寫) telnet 127.0.0.1 8005 SHUTDOWN

service

服務：將多個connector 與一個Engine組合成一個服務，可以配置多個服務。

Connector

連接器：用于接收 指定協議下的連接 并指定給唯一的Engine 進行處理。 主要屬性：

• protocol 監聽的協議，默認是http/1.1
• port 指定服務器端要創建的端口號
• minSpareThreads服務器啟動時創建的處理請求的線程數
• maxThreads 最大可以創建的處理請求的線程數
• enableLookups 如果為true，則可以通過調用request.getRemoteHost()進行DNS查詢來得到遠程客戶端的實際主機名，若為false則不進行DNS查詢，而是返回其ip地址
• redirectPort 指定服務器正在處理http請求時收到了一個SSL傳輸請求后重定向的端口號
• acceptCount 指定當所有可以使用的處理請求的線程數都被使用時，可以放到處理隊列中的請求數，超過這個數的請求將不予處理
• connectionTimeout 指定超時的時間數(以毫秒為單位)
• SSLEnabled 是否開啟 sll 驗證，在Https 訪問時需要開啟。生成證書： keytool -genkey -v -alias testKey -keyalg RSA -validity 3650 -keystore D:\test.keystore
• [ ] 演示配置多個Connector

Engine

引擎：用于處理連接的執行器，默認的引擎是catalina。一個service 中只能配置一個Engine。 主要屬性：name 引擎名稱 defaultHost 默認host

Host

虛擬機：基于域名匹配至指定虛擬機。類似于nginx 當中的server,默認的虛擬機是localhost. 主要屬性：

演示配置多個Host

Context

應用上下文：一個host 下可以配置多個Context ，每個Context 都有其獨立的classPath。相互隔離，以免造成ClassPath 沖突。 主要屬性：

演示配置多個Context

Valve 閥門：可以理解成

的過濾器，具體配置要基于具體的Valve 接口的子類。以下即為一個訪問日志的Valve

三、Tomcat 部署腳本編寫

Tomcat啟動參數說明

我們平時啟動Tomcat過程是怎么樣的？

1. 復制WAR包至Tomcat webapp 目錄。
2. 執行starut.bat 腳本啟動。
3. 啟動過程中war 包會被自動解壓裝載。

但是我們在Eclipse 或idea 中啟動WEB項目的時候 也是把War包復雜至webapps 目錄解壓嗎？顯然不是，其真正做法是在Tomcat程序文件之外創建了一個部署目錄，在一般生產環境中也是這么做的 即：Tomcat 程序目錄和部署目錄分開 。 我們只需要在啟動時指定CATALINA_HOME 與 CATALINA_BASE 參數即可實現。

| 啟動參數 | 描述說明 | |:----|:----| | JAVA_OPTS | jvm 啟動參數 , 設置內存 編碼等 -Xms100m -Xmx200m -Dfile.encoding=UTF-8 | | JAVA_HOME | 指定jdk 目錄，如果未設置從java 環境變量當中去找。 | | CATALINA_HOME | Tomcat 程序根目錄 | | CATALINA_BASE | 應用部署目錄，默認為$CATALINA_HOME | | CATALINA_OUT | 應用日志輸出目錄：默認$CATALINA_BASE/log | | CATALINA_TMPDIR | 應用臨時目錄：默認：$CATALINA_BASE/temp |

可以編寫一個腳本 來實現自定義配置：

更新 啟動 腳本

docker 啟動tomcat

源碼構建

下載地址：https://tomcat.apache.org/download-80.cgi

配置

1.解壓源碼 apache-tomcat-8.5.57-src

2.apache-tomcat-8.5.57-src目錄下添加pom文件

3.在apache-tomcat-8.5.57-src 同級目錄新建 catalina-home并保證目錄下面文件如下

注意： 上面文件夾apache-tomcat-8.5.57-src里面有的，就剪切過來，沒有的就新建一個， bin conf webapps 應該是從apache-tomcat-8.5.57-src剪切過來的

4.idea引入項目

File->Open 選擇解壓的C:\Users\wukong\Downloads\apache-tomcat-8.5.57-src\apache-tomcat-8.5.57-src

配置啟動

MainClass: org.apache.catalina.startup.BootstrapVmOptions: -Dcatalina.home=C:\Users\wukong\Downloads\apache-tomcat-8.5.57-src\apache-tomcat-8.5.57-src\catalina-home

啟動報錯

TestCookieFilter 報錯找不到這個類CookieFilter

解決方法：

1. 刪除：TestCookieFilter

啟動后，訪問localhost:8080 報錯 org.apache.jasper.JasperException: java.lang.NullPointerException

解決方案：

org.apache.catalina.startup.Bootstrap 添加代碼塊

以上Tomcat核心組件及應用架構詳解就是小編為大家收集整理的全部內容了，希望對大家有所幫助。如果您喜歡這篇文章，可以收藏或分享給您的小伙伴們吧！歡迎持續關注我們的后續更新。