Tomcat-結構原理
客戶端使用者點選瀏覽器服務連線,瀏覽器通過客戶端底層服務通過路由傳送報文,目標伺服器獲取解析報文,Tomcat監聽程式觸發處理請求
一、Tomcat 軟體目錄結構及功能
bin: 服務相關指令碼,例如:啟動、關閉等
conf: 存放不同的配置檔案,列如:server.xml、web.xml
lib: tomcat 執行需要的庫檔案
logs: 執行的日誌檔案
webapps: web部署的根目錄
work :存放jsp編譯後的class檔案
二、server分析系統結構
server
提供一個介面讓其它程式能夠訪問到這個 Service 集合、同時要維護它所包含的所有 Service 的生命週期,包括如何初始化、如何結束服務、如何找到別人要訪問的 Service
service
service 是server下一個集合,service包含多個接收請求的connector並有一個處理所有連線的容器container
connector
connector 作用是監聽客戶端請求,並將請求封裝提交container處理,然後將處理結果返回客戶端
tomcat有兩個典型的connector,一個用來監聽瀏覽器的http,另一個是用來監聽webservice
Coyote Http/1.1 Connector 在埠8080處偵聽來自客戶browser的http請求
Coyote AJP/1.3 Connector 在埠8009處偵聽來自其它WebServer(Apache)的servlet/jsp代理請求
container
4.1 Engine
Engine下可以配置多個虛擬主機Virtual Host,每個虛擬主機都有一個域名
當Engine獲得一個請求時,它把該請求匹配到某個Host上,然後把該請求交給該Host來處理
Engine有一個預設虛擬主機,當請求無法匹配到任何一個Host上的時候,將交給該預設Host來處理
4.2 Host
代表一個Virtual Host,虛擬主機,每個虛擬主機和某個網路域名Domain Name相匹配
每個虛擬主機下都可以部署(deploy)一個或者多個Web App,每個Web App對應於一個Context,有一個Context path
當Host獲得一個請求時,將把該請求匹配到某個Context上,然後把該請求交給該Context來處理
匹配的方法是“最長匹配”,所以一個path==""的Context將成為該Host的預設Context
所有無法和其它Context的路徑名匹配的請求都將最終和該預設Context匹配
4.3 Context
一個Context對應於一個Web Application,一個Web Application由一個或者多個Servlet組成
Context在建立的時候將根據配置檔案$CATALINA_HOME/conf/web.xml和$WEBAPP_HOME/WEB-INF/web.xml載入Servlet類
當Context獲得請求時,將在自己的對映表(mapping table)中尋找相匹配的Servlet類
如果找到,則執行該類,獲得請求的迴應,並返回
5 - Context的部署配置檔案web.xml的說明
一個Context對應於一個Web App,每個Web App是由一個或者多個servlet組成的
當一個Web App被初始化的時候,它將用自己的ClassLoader物件載入“部署配置檔案web.xml”中定義的每個servlet類
它首先載入在$CATALINA_HOME/conf/web.xml中部署的servlet類
然後載入在自己的Web App根目錄下的WEB-INF/web.xml中部署的servlet類
web.xml檔案有兩部分:servlet類定義和servlet對映定義
每個被載入的servlet類都有一個名字,且被填入該Context的對映表(mapping table)中,和某種URL PATTERN對應
當該Context獲得請求時,將查詢mapping table,找到被請求的servlet,並執行以獲得請求迴應
分析一下所有的Context共享的web.xml檔案,在其中定義的servlet被所有的Web App載入
三、例子
Tomcat Server處理一個http請求的過程
假設來自客戶的請求為:
http://localhost:8080/wsota/wsota_index.jsp
請求被髮送到本機埠8080,被在那裡偵聽的Coyote HTTP/1.1 Connector獲得
Connector把該請求交給它所在的Service的Engine來處理,並等待來自Engine的迴應
Engine獲得請求localhost/wsota/wsota_index.jsp,匹配它所擁有的所有虛擬主機Host
Engine匹配到名為localhost的Host(即使匹配不到也把請求交給該Host處理,因為該Host被定義為該Engine的預設主機)
localhost Host獲得請求/wsota/wsota_index.jsp,匹配它所擁有的所有Context
Host匹配到路徑為/wsota的Context(如果匹配不到就把該請求交給路徑名為""的Context去處理)
path="/wsota"的Context獲得請求/wsota_index.jsp,在它的mapping table中尋找對應的servlet
Context匹配到URL PATTERN為*.jsp的servlet,對應於JspServlet類
構造HttpServletRequest物件和HttpServletResponse物件,作為引數呼叫JspServlet的doGet或doPost方法
Context把執行完了之後的HttpServletResponse物件返回給Host
Host把HttpServletResponse物件返回給Engine
Engine把HttpServletResponse物件返回給Connector
Connector把HttpServletResponse物件返回給客戶browser
相關文章
- SSD結構與工作原理
- Tomcat結構原理詳解Tomcat
- redis 儲存結構原理 2Redis
- jMeter結構體系及執行原理JMeter結構體
- JAVA常用資料結構及原理分析Java資料結構
- HP EVA系列儲存結構原理研究
- 【資料結構】ArrayList原理及實現資料結構
- What?Tomcat-竟然也算中介軟體?Tomcat
- Redis核心原理與實踐--列表實現原理之quicklist結構RedisUI
- 放大器內部結構原理圖解圖解
- MySQL效能結構優化原理(技術核心)MySql優化
- Hadoop框架:Yarn基本結構和執行原理Hadoop框架Yarn
- Attention的基本原理與模型結構模型
- Java HashMap原理及內部儲存結構JavaHashMap
- 求索資料結構的第一性原理資料結構
- Redis資料結構SortedSet底層原理詳解Redis資料結構
- struts2的工作原理與檔案結構
- HashMap的底層結構、原理、擴容機制HashMap
- 圖解:Java 中的資料結構及原理圖解Java資料結構
- tomcat-啟動報錯Multiple Contexts have a path of "/xxxx"TomcatContext
- Redis List 底層三種資料結構原理剖析Redis資料結構
- TiDB 底層儲存結構 LSM 樹原理介紹TiDB
- 詳細瞭解 InnoDB 記憶體結構及其原理記憶體
- WordPress模板層次02:模板層次結構和原理
- 學習tomcat-如何建立連線,處理請求Tomcat
- MySQL的varchar儲存原理:InnoDB記錄儲存結構MySql
- iOS進階之路 (三)OC物件的原理 - isa 結構 & 走位iOS物件
- 淺析CPU結構對程式的影響以及熔斷原理
- 資料結構高階--二叉搜尋樹(原理+實現)資料結構
- 詳解Redis核心資料結構和高效能原理分析(一)Redis資料結構
- 計算機組成與系統結構 cache 原理與計算計算機
- 結構化與非結構化
- StarRocks基本架構原理架構
- React Fiber架構原理React架構
- storm 架構和原理ORM架構
- Nginx 原理和架構Nginx架構
- RocketMQ(1)-架構原理MQ架構
- HDFS架構及原理架構