tomcat訪問控制

① 伺服器如何關閉埠

問題一：怎樣關閉伺服器埠 如果瑞星還提示有漏洞攻擊，就沒辦法了。註：關閉的埠有，135、137、138、139、445、1025、2475、 3127、6129、3389、593，還有tcp. 具體操作如下：默認情況下，Windows 有很多埠是鍵塵罩開放的，在你上網的時候，網路病毒和黑客可以通過這些埠連上你的電腦。 為了讓你的系統變為銅牆鐵壁，應該封閉這些埠，主要有：TCP 135、 139、445、593、1025 埠和UDP 135、137、138、445 埠，一些流行病毒的後門埠(如TCP 2745、3127、6129 埠)，以及遠程服務訪問埠3389。下面介紹如何在WindowsXP/2000/2003 下關閉這些網路埠： 第一步，點擊開始菜單/設置/控制面板/管理工具，雙擊打開本地安全策略，選中IP 安全策略，在本地計算機，在右邊窗格的稿鬧空白位置右擊滑鼠，彈出快捷菜單，選擇創建IP 安全策略，於是彈出一個向導。在向導中點擊 下一步按鈕，為新的安全策略命名；再按下一步，則顯示安全通信請求畫面，在畫面上把激活默認相應規則左邊的鉤去掉，點擊完成按鈕就創建了一個新的IP 安全策略。 第二步，右擊該IP 安全策略，在屬性對話框中，把使用添加向導左邊的鉤去掉，然後單擊添加按鈕添加新的規則，隨後彈出新規則屬性對話框，在畫面上點擊添加按鈕，彈出IP 篩選器列表窗口；在列表中，首先把使用添加向導左邊的鉤去掉，然後再點擊右邊的添加按鈕添加新的篩選器。 第三步，進入篩選器屬性對話框，首先看到的是定址，源地址選任何 IP 地址，目標地址選我的IP 地址；點擊協議選項卡，在選擇協議類型 的下拉列表中選擇TCP，然後在到此埠下的文本框中輸入135，點擊確定按鈕，這樣就添加了一個屏蔽TCP 135(RPC)埠的篩選器，它可以防止外界通過135 埠連上你的電腦。 點擊確定後回到篩選器列表的對話框，可以看到已經添加了一條策略，重復以上步驟繼續添加TCP 137、139、445、593 埠和UDP 135、139、445 埠，為它們建立相應的篩選器。 重復以上步驟添加TCP 1025、2745、3127、6129、3389 埠的屏蔽策略，建立好上述埠的篩選器，最後點擊確定按鈕。 第四步，在新規則屬性對話框中，選擇新IP 篩選器列表，然後點擊其左邊的圓圈上加一個點，表示已經激活，最後點擊篩選器操作選項卡。在篩選器操作選項卡中，把使用添加向導左邊的鉤去掉，點擊添加按鈕，添加 阻止操作：在新篩選器操作屬性......>>

問題二：window伺服器怎麼關閉埠 網路安全專家建議，用戶要斷網開機，即先拔掉網線再開機，這樣基本可以避免被勒索軟體感染。開機後應盡快想辦法打上安全補丁，或安裝各家網路安全公司針對此事推出的防禦工具，才可以聯網。建議盡快備份電腦中的重要文件資料到移動硬碟、U 盤，備份完後離線保存該磁兄塌盤，同時對於不明鏈接、文件和郵件要提高警惕，加強防範。
臨時解決方案：
1、開啟系統防火牆
2、利用系統防火牆高級設置阻止向445埠進行連接（該操作會影響使用445埠的服務）
3、打開系統自動更新，並檢測更新進行安裝
Win7、Win8、Win10的處理流程
1、打開控制面板-系統與安全-Windows防火牆，點擊左側啟動或關閉Windows防火牆。
2、選擇啟動防火牆，並點擊確定
3、點擊高級設置
4、點擊入站規則，新建規則
5、選擇埠，下一步
6、特定本地埠，輸入445，下一步
7、選擇阻止連接，下一步
8、配置文件，全選，下一步
9、名稱，可以任意輸入，完成即可。
XP系統的處理流程
1、依次打開控制面板，安全中心，Windows防火牆，選擇啟用
2、點擊開始，運行，輸入cmd，確定執行下面三條命令：net stop rdr 、net stop srv 、net stop netbt

問題三：如何關閉與開啟埠 如何關閉與開啟埠？

埠概念、什麼是埠在網路技術中，埠（Port）大致有兩種意思：一是物理意義上的埠，比如，ADSL Modem、集線器、交換機、路由器用於連接其他網路設備的介面，如RJ-45埠、SC埠等等。二是邏輯意義上的埠，一般是指TCP/IP協議中的埠，埠號的范圍從0到65535，比如用於瀏覽網頁服務的80埠，用於ftp服務的21埠等等。我們這里將要介紹的就是邏輯意義上的埠。
查看埠在Windows 2000/XP/Server 2003中要查看埠，可以使用Netstat命令：依次點擊「開始→運行」，鍵入「cmd」並回車，打開命令提示符窗口。在命令提示符狀態下鍵入「netstat -a -n」，按下回車鍵後就可以看到以數字形式顯示的TCP和UDP連接的埠號及狀態。
關閉/開啟埠在Windows中如何關閉/打開埠，因為默認的情況下，有很多不安全的或沒有什麼用的埠是開啟的，比如Telnet服務的23埠、FTP服務的21埠、SMTP服務的25埠、RPC服務的135埠等等。為了保證系統的安全性，我們可以通過下面的方法來關閉/開啟埠。
1.關閉埠比如在Windows 2000/XP中關閉SMTP服務的25埠，可以這樣做：首先打開「控制面板」，雙擊「管理工具」，再雙擊「服務」。接著在打開的服務窗口中找到並雙擊「Simple Mail Transfer Protocol（SMTP）」服務，單擊「停止」按鈕來停止該服務，然後在「啟動類型」中選擇「已禁用」，最後單擊「確定」按鈕即可。這樣，關閉了SMTP服務就相當於關閉了對應的埠。
2.開啟埠如果要開啟該埠只要先在「啟動類型」選擇「自動」，單擊「確定」按鈕，再打開該服務，在「服務狀態」中單擊「啟動」按鈕即可啟用該埠，最後，單擊「確定」按鈕即可。提示：在Windows 98中沒有「服務」選項，你可以使用防火牆的規則設置功能來關閉/開啟埠。
各種埠的作用埠：0服務：Reserved說明：通常用於分析操作系統。這一方法能夠工作是因為在一些系統中「0」是無效埠，當你試圖使用通常的閉合埠連接它時將產生不同的結果。一種典型的掃描，使用IP地址為0.0.0.0，設置ACK位並在乙太網層廣播。
埠：1服務：tcpmux說明：這顯示有人在尋找SGI Irix機器。Irix是實現tcpmux的主要提供者，默認情況下tcpmux在這種系統中被打開。Irix機器在發布是含有幾個默認的無密碼的帳戶，如：IP、GUEST UUCP、NUUCP、DEMOS、TUTOR、DIAG、OUTOFBOX等。許多管理員在安裝後忘記刪除這些帳戶。因此HACKER在INTERNET上搜索tcpmux並利用這些帳戶。
埠：7服務：Echo說明：能看到許多人搜索Fraggle放大器時，發送到X.X.X.0和X.X.X.255的信息。
埠：19服務：Character Generator說明：這是一種僅僅發送字元的服務。UDP版本將會在收到UDP包後回應含有垃圾字元的包。TCP連接時會發送含有垃圾字元的數據流直到連接關閉。HACKER利用IP欺騙可以發動DoS攻擊。偽造兩個chargen伺服器之間的UDP包。同樣Fraggle DoS攻擊向目標地址的這個埠廣播一個帶有偽造受害者IP的數據包，受害者為了回應這些數據而過載。
埠：21服務：FTP說明：FTP伺服器......>>

問題四：伺服器可以關閉3389埠嗎 可以關閉，但伺服器就無法遠程桌面登錄了，一些遠程應用程序或者平台就無法登錄

問題五：如何關閉伺服器其他埠 查看開放埠: netstat -na關閉埠貌似伺服器沒有這類命令.可以使用IPSEC過濾和埠過濾功能實現.

問題六：伺服器如何關閉一些安全埠啊 設置安全策略：「控制面板」――〉「管理工具」――〉「本地安全策略」選擇IP安全策略―創建IP安全策略―建立名稱―默認下一步中國_網管聯盟OK 建立新的策略完成選擇你新建的策略 C屬性然後填加下一步中國網管聯盟選擇WIN2000默認值（Kerberos V5協議） 繼續下一步選擇是選擇所有IP通訊繼續下一步完成選中「所有 IP 通訊」――〉點「編輯」按鈕，打開「IP篩選器列表」――〉繼續點「編輯」按鈕，打開「篩選器 屬性」_bits_完成上面配置後在你剛配置的策略有鍵指派驗證安全策略指派「控制面板」――〉「網路和撥號連接」――〉選中本機使用的網卡，比如「本地連接」――〉雙擊打開「屬性」――〉選中「Internet 協議(TCP/IP)」，打開其「屬性」――〉「高級」看到「高級 TCP/IP 設置」――〉選中「選項」標簽――〉選中「IP 安全機制」――〉打開其「屬性」中國網管論壇――〉「使用此 IP 安全策略」的下拉框中選中是否就是剛才設置的「SQL 1433」配置完成後重新啟動機器。方法二：區域網內找一個機器（非本機），在dos控制台下，輸入telnet EP伺服器IP 1433如果安全策略應用成功的話，應該不能夠連接，會出現如下的話：正在連接到xxxxxxx...無法打開到主機的連接 在埠 : 連接失敗。

問題七：如何打開和關閉常用埠 關閉伺服器埠具體方法如下： 1、 本地連接的屬性中，選擇intelnet協議再尋屬性」如下圖： 2、進入 網路屬性 後 點底部的「高級」，進入高級屬性後，切換到「選項」選項卡，選擇 ICP/IP 再進入屬性： 3、填寫需要關閉的埠

問題八：高分！！！求教如何關掉伺服器埠。 每一項服務都對應相應的埠，比如眾如周知的WWW服務的埠是80， *** tp是25，ftp是21，win2000安裝中默認的都是這些服務開啟的。對於個人用戶來說確實沒有必要，關掉埠也就是關閉無用的服務。 「控制面板」的「管理工具」中的「服務」中來配置。
1、關閉7.9等等埠：關閉Simple TCP/IP Service,支持以下 TCP/IP 服務：Character Generator, Daytime, Discard, Echo, 以及 Quote of the Day。
2、關閉80口：關掉WWW服務。在「服務」中顯示名稱為World Wide Web Publishing Service，通過 Internet 信息服務的管理單元提供 Web 連接和管理。
3、關掉25埠：關閉Simple Mail Transport Protocol (SMTP)服務，它提供的功能是跨網傳送電子郵件。
4、關掉21埠：關閉FTP Publishing Service,它提供的服務是通過 Internet 信息服務的管理單元提供 FTP 連接和管理。
5、關掉23埠：關閉Telnet服務，它允許遠程用戶登錄到系統並且使用命令行運行控制台程序。
6、還有一個很重要的就是關閉server服務，此服務提供 RPC 支持、文件、列印以及命名管道共享。關掉它就關掉了win2k的默認共享，比如ipc$、c$、admin$等等，此服務關閉不影響您的共他操作。
7、還有一個就是139埠，139埠是NetBIOS Session埠，用來文件和列印共享，注意的是運行samba的unix機器也開放了139埠，功能一樣。以前流光2000用來判斷對方主機類型不太准確，估計就是139埠開放既認為是NT機，現在好了。 關閉139口聽方法是在「網路和撥號連接」中「本地連接」中選取「Internet協議(TCP/IP)」屬性，進入「高級TCP/IP設置」「WINS設置」裡面有一項「禁用TCP/IP的NETBIOS」，打勾就關閉了139埠。 對於個人用戶來說，可以在各項服務屬性設置中設為「禁用」，以免下次重啟服務也重新啟動，埠也開放了。
每一項服務都對應相應的埠，比如眾如周知的WWW服務的埠是80， *** tp是25，ftp是21，win2000安裝中默認的都是這些服務開啟的。對於個人用戶來說確實沒有必要，關掉埠也就是關閉無用的服務。
「控制面板」的「管理工具」中的「服務」中來配置。
1、關閉7.9等等埠：關閉Simple TCP/IP Service,支持以下 TCP/IP 服務：Character Generator, Daytime, Discard, Echo, 以及 Quote of the Day。
2、關閉80口：關掉WWW服務。在「服務」中顯示名稱為World Wide Web Publishing Service，通過 Internet 信息服務的管理單元提供 Web 連接和管理。
3、關掉25埠：關閉Simple Mail Transport Protocol (SMTP)服務，它提供的功能是跨網傳送電子郵件。
4、關掉21埠：關閉FTP Publishing Service,它提供的服務是通過 Internet 信息服務的管理單元提供 FTP 連接和管理。
5、關掉23埠：關閉Telnet服務，它允許遠程......>>

問題九：怎樣查看伺服器的那些埠是開的，那些是關閉的？ 查看開放埠: netstat -na
關閉埠貌似伺服器沒有這類命令.
可以使用IPSEC過濾和埠過濾功能實現.

問題十：怎樣關閉tomcat伺服器埠 如何修改Tomcat的埠號 Tomcat的默認埠號為8080，假如我們使用伺服器安裝Tomcat，使用網址訪問的時候，總是需要在後面加上8080埠，如何修改埠號。讓其和其他的網站一樣，直接輸入網址即可訪問呢？ 方法/步驟 首先我們需要知道，的默認埠是80，也就是說，如果我們將埠號修改為80，輸入網址的時候就可以不用輸入埠了，直接輸入網址即可。 首先我們需要找到Tomcat目錄下面的Conf文件夾。找到server.xml文件，將其打開。 找到63行的 這句話 假如找不到，可以搜索8080等關鍵性詞語 只需要將這個8080修改為80即可 修改成功後，重新啟動伺服器。看看，只需要輸入localhost即可訪問Tomcat主頁了。

② Tomcat篇02-整體架構和I/O模型

本文主要包括tomcat伺服器的目錄結構、工作模式、整體架構、I/O模型以及NIO、NIO2、APR三者的對比介紹。

我們先來看一下tomcat8.5和tomcat9中的home目錄中的文件：

可以看到除掉一些說明文件之後，還有7個目錄：

實際上除了主目錄里有lib目錄，在webapps目錄下的web應用中的WEB-INF目錄下也存在一個lib目錄：

兩者的區別在於：

●Tomcat主目錄下的lib目錄：存放的JAR文件 不僅能被Tomcat訪問，還能被所有在Tomcat中發布的java Web應用訪問
●webapps目錄下的Java Web應用的lib目錄：存放的JAR文件 只能被當前Java Web應用訪問

既然有多個lib目錄，那麼肯定就有使用的優先順序，Tomcat類載入器的目錄載入優先順序如下：

Tomcat的類載入器負責為Tomcat本身以及Java Web應用載入相關的類。假如Tomcat的類載入器要為一個Java Web應用載入一個類，類載入器會按照以下優先順序到各個目錄中去查找該類的.class文件，直到找到為止，如果所有目錄中都不存在該類的.class文件，則會拋出異常：

Tomcat不僅可以單獨運行，還可以與其他的Web伺服器集成，作為其他Web伺服器的進程內或進程外的servlet容器。集成的意義在於：對於不支持運行Java Servlet的其他Web伺服器，可通過集成Tomcat來提供運行Servlet的功能。

Tomcat有三種工作模式：

我們先從tomcat的源碼目錄來分析一下tomcat的整體架構，前面我們配置jsvc運行tomcat的時候，我們知道tomcat中啟動運行的最主要的類是 org.apache.catalina.startup.Bootstrap ，那麼我們在tomcat的源碼中的java目錄下的org目錄的apache目錄可以找到主要的源碼的相對應的類。

圖中的目錄如果畫成架構圖，可以這樣表示：

Tomcat 本質上就是一款Servlet 容器，因此 catalina 才是Tomcat的核心 ，其他模塊都是為 catalina 提供支撐的。

單線程阻塞I/O模型是最簡單的一種伺服器I/O模型，單線程即同時只能處理一個客戶端的請求，阻塞即該線程會一直等待，直到處理完成為止。對於多個客戶端訪問，必須要等到前一個客戶端訪問結束才能進行下一個訪問的處理，請求一個一個排隊，只提供一問一答服務。

如上圖所示：這是一個同步阻塞伺服器響應客戶端訪問的時間節點圖。

這種模型的特點在於單線程和阻塞I/O。 單線程即伺服器端只有一個線程處理客戶端的所有請求，客戶端連接與伺服器端的處理線程比是 n:1 ，它無法同時處理多個連接，只能串列處理連接。而阻塞I/O是指伺服器在讀寫數據時是阻塞的，讀取客戶端數據時要等待客戶端發送數據並且把操作系統內核復制到用戶進程中，這時才解除阻塞狀態。寫數據回客戶端時要等待用戶進程將數據寫入內核並發送到客戶端後才解除阻塞狀態。 這種阻塞帶來了一個問題，伺服器必須要等到客戶端成功接收才能繼續往下處理另外一個客戶端的請求，在此期間線程將無法響應任何客戶端請求。

該模型的特點：它是最簡單的伺服器模型，整個運行過程都只有一個線程，只能支持同時處理一個客戶端的請求(如果有多個客戶端訪問，就必須排隊等待)， 伺服器系統資源消耗較小，但並發能力低，容錯能力差。

多線程阻塞I/O模型在單線程阻塞I/O模型的基礎上對其進行改進，加入多線程，提高並發能力，使其能夠同時對多個客戶端進行響應，多線程的核心就是利用多線程機制為每個客戶端分配一個線程。

如上圖所示，伺服器端開始監聽客戶端的訪問，假如有兩個客戶端同時發送請求過來，伺服器端在接收到客戶端請求後分別創建兩個線程對它們進行處理，每條線程負責一個客戶端連接，直到響應完成。 期間兩個線程並發地為各自對應的客戶端處理請求 ，包括讀取客戶端數據、處理客戶端數據、寫數據回客戶端等操作。

這種模型的I/O操作也是阻塞的 ，因為每個線程執行到讀取或寫入操作時都將進入阻塞狀態，直到讀取到客戶端的數據或數據成功寫入客戶端後才解除阻塞狀態。盡管I/O操作阻塞，但這種模式比單線程處理的性能明顯高了，它不用等到第一個請求處理完才處理第二個，而是並發地處理客戶端請求，客戶端連接與伺服器端處理線程的比例是 1:1 。

多線程阻塞I/O模型的特點：支持對多個客戶端並發響應，處理能力得到大幅提高，有較大的並發量，但伺服器系統資源消耗量較大，而且如果線程數過多，多線程之間會產生較大的線程切換成本，同時擁有較復雜的結構。

在探討單線程非阻塞I/O模型前必須要先了解非阻塞情況下套接字事件的檢測機制，因為對於單線程非阻塞模型最重要的事情是檢測哪些連接有感興趣的事件發生。一般會有如下三種檢測方式。

當多個客戶端向伺服器請求時，伺服器端會保存一個套接字連接列表中，應用層線程對套接字列表輪詢嘗試讀取或寫入。如果成功則進行處理，如果失敗則下次繼續。這樣不管有多少個套接字連接，它們都可以被一個線程管理，這很好地利用了阻塞的時間，處理能力得到提升。

但這種模型需要在應用程序中遍歷所有的套接字列表，同時需要處理數據的拼接，連接空閑時可能也會佔用較多CPU資源，不適合實際使用。

這種方式將套接字的遍歷工作交給了操作系統內核，把對套接字遍歷的結果組織成一系列的事件列表並返回應用層處理。對於應用層，它們需要處理的對象就是這些事件，這是一種事件驅動的非阻塞方式。

伺服器端有多個客戶端連接，應用層向內核請求讀寫事件列表。內核遍歷所有套接字並生成對應的可讀列表readList和可寫列表writeList。readList和writeList則標明了每個套接字是否可讀/可寫。應用層遍歷讀寫事件列表readList和writeList，做相應的讀寫操作。

內核遍歷套接字時已經不用在應用層對所有套接字進行遍歷，將遍歷工作下移到內核層，這種方式有助於提高檢測效率。 然而，它需要將所有連接的可讀事件列表和可寫事件列表傳到應用層，假如套接字連接數量變大，列表從內核復制到應用層也是不小的開銷。 另外，當活躍連接較少時， 內核與應用層之間存在很多無效的數據副本 ，因為它將活躍和不活躍的連接狀態都復制到應用層中。

通過遍歷的方式檢測套接字是否可讀可寫是一種效率比較低的方式，不管是在應用層中遍歷還是在內核中遍歷。所以需要另外一種機制來優化遍歷的方式，那就是 回調函數 。內核中的套接字都對應一個回調函數，當客戶端往套接字發送數據時，內核從網卡接收數據後就會調用回調函數，在回調函數中維護事件列表，應用層獲取此事件列表即可得到所有感興趣的事件。

內核基於回調的事件檢測方式有兩種

第一種是用 可讀列表readList 和 可寫列表writeList 標記讀寫事件， 套接字的數量與 readList 和 writeList 兩個列表的長度一樣 。

上面兩種方式由操作系統內核維護客戶端的所有連接並通過回調函數不斷更新事件列表，而應用層線程只要遍歷這些事件列表即可知道可讀取或可寫入的連接，進而對這些連接進行讀寫操作，極大提高了檢測效率，自然處理能力也更強。

單線程非阻塞I/O模型最重要的一個特點是，在調用讀取或寫入介面後立即返回，而不會進入阻塞狀態。雖然只有一個線程，但是它通過把非阻塞讀寫操作與上面幾種檢測機制配合就可以實現對多個連接的及時處理，而不會因為某個連接的阻塞操作導致其他連接無法處理。在客戶端連接大多數都保持活躍的情況下，這個線程會一直循環處理這些連接，它很好地利用了阻塞的時間，大大提高了這個線程的執行效率。

單線程非阻塞I/O模型的主要優勢體現在對多個連接的管理，一般在同時需要處理多個連接的發場景中會使用非阻塞NIO模式，此模型下只通過一個線程去維護和處理連接，這樣大大提高了機器的效率。一般伺服器端才會使用NIO模式，而對於客戶端，出於方便及習慣，可使用阻塞模式的套接字進行通信。

在多核的機器上可以通過多線程繼續提高機器效率。最朴實、最自然的做法就是將客戶端連接按組分配給若干線程，每個線程負責處理對應組內的連接。比如有4個客戶端訪問伺服器，伺服器將套接字1和套接字2交由線程1管理，而線程2則管理套接字3和套接字4，通過事件檢測及非阻塞讀寫就可以讓每個線程都能高效處理。

多線程非阻塞I/O模式讓伺服器端處理能力得到很大提高，它充分利用機器的CPU，適合用於處理高並發的場景，但它也讓程序更復雜，更容易出現問題（死鎖、數據不一致等經典並發問題）。

最經典的多線程非阻塞I/O模型方式是Reactor模式。首先看單線程下的Reactor，Reactor將伺服器端的整個處理過程分成若干個事件，例如分為接收事件、讀事件、寫事件、執行事件等。Reactor通過事件檢測機制將這些事件分發給不同處理器去處理。在整個過程中只要有待處理的事件存在，即可以讓Reactor線程不斷往下執行，而不會阻塞在某處，所以處理效率很高。

基於單線程Reactor模型，根據實際使用場景，把它改進成多線程模式。常見的有兩種方式：一種是在耗時的process處理器中引入多線程，如使用線程池；另一種是直接使用多個Reactor實例，每個Reactor實例對應一個線程。

Reactor模式的一種改進方式如下圖所示。其整體結構基本上與單線程的Reactor類似，只是引入了一個線程池。由於對連接的接收、對數據的讀取和對數據的寫入等操作基本上都耗時較少，因此把它們都放到Reactor線程中處理。然而，對於邏輯處理可能比較耗時的工作，可以在process處理器中引入線程池，process處理器自己不執行任務，而是交給線程池，從而在Reactor線程中避免了耗時的操作。將耗時的操作轉移到線程池中後，盡管Reactor只有一個線程，它也能保證Reactor的高效。

Reactor模式的另一種改進方式如下圖所示。其中有多個Reactor實例，每個Reactor實例對應一個線程。因為接收事件是相對於伺服器端而言的，所以客戶端的連接接收工作統一由一個accept處理器負責，accept處理器會將接收的客戶端連接均勻分配給所有Reactor實例，每個Reactor實例負責處理分配到該Reactor上的客戶端連接，包括連接的讀數據、寫數據和邏輯處理。這就是多Reactor實例的原理。

Tomcat支持的I/O模型如下表（自8.5/9.0 版本起，Tomcat移除了對BIO的支持），在 8.0 之前 ， Tomcat 默認採用的I/O方式為 BIO ， 之後改為 NIO。 無論 NIO、NIO2 還是 APR， 在性能方面均優於以往的BIO。

Tomcat中的NIO模型是使用的JAVA的NIO類庫，其內部的IO實現是同步的（也就是在用戶態和內核態之間的數據交換上是同步機制），採用基於selector實現的非同步事件驅動機制（這里的非同步指的是selector這個實現模型是使用的非同步機制）。 而對於Java來說，非阻塞I/O的實現完全是基於操作系統內核的非阻塞I/O，它將操作系統的非阻塞I/O的差異屏蔽並提供統一的API，讓我們不必關心操作系統。JDK會幫我們選擇非阻塞I/O的實現方式。

NIO2和前者相比的最大不同就在於引入了非同步通道來實現非同步IO操作，因此也叫AIO（Asynchronous I/O）。NIO.2 的非同步通道 APIs 提供方便的、平台獨立的執行非同步操作的標准方法。這使得應用程序開發人員能夠以更清晰的方式來編寫程序，而不必定義自己的 Java 線程，此外，還可通過使用底層 OS 所支持的非同步功能來提高性能。如同其他 Java API 一樣，API 可利用的 OS 自有非同步功能的數量取決於其對該平台的支持程度。

非同步通道提供支持連接、讀取、以及寫入之類非鎖定操作的連接，並提供對已啟動操作的控制機制。Java 7 中用於 Java Platform（NIO.2）的 More New I/O APIs，通過在 java.nio.channels 包中增加四個非同步通道類，從而增強了 Java 1.4 中的 New I/O APIs（NIO），這些類在風格上與 NIO 通道 API 很相似。他們共享相同的方法與參數結構體，並且大多數對於 NIO 通道類可用的參數，對於新的非同步版本仍然可用。主要區別在於新通道可使一些操作非同步執行。

非同步通道 API 提供兩種對已啟動非同步操作的監測與控制機制。第一種是通過返回一個 java.util.concurrent.Future 對象來實現，它將會建模一個掛起操作，並可用於查詢其狀態以及獲取結果。第二種是通過傳遞給操作一個新類的對象， java.nio.channels.CompletionHandler ，來完成，它會定義在操作完畢後所執行的處理程序方法。每個非同步通道類為每個操作定義 API 副本，這樣可採用任一機制。

Apache可移植運行時（Apache Portable Runtime，APR） 是Apache HTTP伺服器的支持庫，最初，APR是作為Apache HTTP伺服器的一部分而存在的，後來成為一個單獨的項目。其他的應用程序可以使用APR來實現平台無關性（跨平台）。APR提供了一組映射到下層操作系統的API，如果操作系統不支持某個特定的功能，APR將提供一個模擬的實現。這樣程序員使用APR編寫真正可在不同平台上移植的程序。

順利安裝完成後會顯示apr的lib庫路徑，一般都是 /usr/local/apr/lib

安裝完成之後我們還需要修改環境變數和配置參數

這里我們使用的是systemd調用jsvc來啟動tomcat，所以我們直接在systemd對應的tomcat的unit文件中的 ExecStart 中添加一個路徑參數 -Djava.library.path=/usr/local/apr/lib 指向apr庫的路徑：

然後我們在tomcat的home目錄下的conf子目錄中對server.xml文件進行修改

把8080埠對應的配置修改成apr：（其他埠配置也類似）

重啟tomcat服務我們從tomcat的日誌中就可以看到協議已經從默認的NIO變成了apr。

NIO性能是最差的這是毋庸置疑的，如果是考慮到高並發的情況，顯然非同步非阻塞I/O模式的NIO2和APR庫在性能上更有優勢，實際上NIO2的性能表現也和APR不相上下，但是NIO2要求Tomcat的版本要在8.0以上，而APR只需要5.5以上即可，但是APR需要額外配置庫環境，相對於內置集成的NIO2來說APR這個操作比較麻煩，兩者各有優劣。具體使用哪個還是需要結合實際業務需求和環境進行測試才能決定。

③ myeclipse中tomcat正常啟動，web也應用訪問也正常，但是myeclipse的控制台日誌不動，為什麼呢

你鎖定了面板。或者你面板沒有選擇正確

④ 取消tomcat 控制台所有日誌列印輸出

閑雜網上很多資料都是怎麼把tomcat的日誌輸出到指定文件，或者文件過大怎麼處理，方法到處都是！

而我遇到的問題是 tomcat 運行時輸出大量的（專業說法：各種級別的日誌），每次都輸出幾百行 當請求頻繁時就想瘋了一樣輸出刷屏，於是就想避免輸出這些信息；宴棗

1 這些信息的界別都有這些：

一是運行中的日誌，它主要記錄運行的一些信息，尤其是一些異常錯誤日誌信息 。

二是訪問日誌信息，它記錄的訪問的時間，IP ，訪問的資料等相關信息。

其中訪問日誌：

｛默認 tomcat 不記錄訪問日誌，如晌鎮拆下方法可以使 tomcat 記錄訪問日誌

編輯 ${catalina}/conf/server.xml 文件. 注 :${catalina} 是 tomcat 的安裝目錄

把以下的注釋 () 去掉即可。

directory="logs"  prefix="localhost_access_log." suffix=".txt"

pattern="common" resolveHosts="false"/>｝

Tomcat 日誌分為下面5類：

catalina 、 localhost 、 manager 、 admin 、 host-manager

每類日誌的級別分為如下 7 種：

SEVERE (highest value) > WARNING > INFO > CONFIG > FINE > FINER > FINEST (lowest value)

3.2  日誌級別的設定方法

修改 conf/logging.properties 中的內容，設定某類日誌的級別

示例：

設置 catalina 日誌的級別為： FINE

1catalina.org.apache.juli.FileHandler.level = FINE

禁用 catalina 日誌的輸出：

1catalina.org.apache.juli.FileHandler.level = OFF

輸出 catalina 所有的日誌消息均輸出：

1catalina.org.apache.juli.FileHandler.level = ALL

那麼我的具體修改方法如下：在logging.properties修改設置

############################################################

隨後旅搜 我的tomcat就正常輸出自己大的日誌和警告界別的日誌  再也沒有其他信息瘋著出來了！

-->

⑤ java.lang.IllegalArgumentException: Property 'sessionFactory' is required

類似
<bean id="sessionFactory" class="org.springframework.orm.hibernate4.LocalSessionFactoryBean">
...
</bean>

<bean id="Dao" class="Dao">
<property name="sessionFactory" ref="sessionFactory"></悄物property>老迅
</bean>

都啟含液有了么，tomcat啟動的時候報的錯么

⑥ 請教一個Tomcat 6.0運行的問題

可能這次啟動tomcat的端梁枯衡口發生了變化不是8080了（因為那個埠被別的程序佔用了），你在訪問頁面http://localhost:8080/就訪問不到了。所以，你看一敗念下啟動的控制台，確認一下啟橡做動的埠，再進行訪問

⑦ Tomcat正常啟動，可以訪問tomcat主頁，卻不能訪問webapp中的項目的jsp文件，這是什麼原因

能訪問tomcat說明伺服器已經開啟了，不能訪問項目說明判脊你的項目可能沒部署上去。
如果不是，那麼就要看看你訪問項目的時候是報的什麼錯？
如果是404，那麼就是頁面的路徑不對，你要檢查一下友帆你的項目名稱和jsp頁面的名稱了。
如果是500，那麼就是你jsp頁面有錯誤，你要掘告滲檢查下了。。

⑧ tomcat有哪些性能調優方法

Tomcat性能調優方案
一、操作系統調優
對於操作系統優化來說，是盡可能的增大可使用的內存容量、提高CPU的頻率，保證文件系統的讀寫速率等。經過壓力測試驗證，在並發連接很多的情況下，CPU的處理能力越強，系統運行速度越快。。
【適用場景】 任何項目。
二、Java虛擬機調優
應該選擇SUN的JVM，在滿足項目需要的前提下，盡量選用版本較高的JVM，一般來說高版本產品在速度和效率上比低版本會有改進。
JDK1.4比JDK1.3性能提高了近10%-20%，JDK1.5比JDK1.4性能提高25%-75%。
因此對性能要求較高的情況推薦使用 JDK1.6。
【適用場景】 任何項目。
三、Apache集成Tomcat
Web伺服器專門處理HTTP請求，應用伺服器是通過很多協議為應用提供商業邏輯。雖然Tomcat也可以作web伺服器，但其處理靜態html的速度比不上Apache，且其作為web伺服器的功能遠不如Apache，因此把Apache和Tomcat集成起來，將html和Jsp的功能部分進行明確分工，讓Tomcat只處理Jsp部分，其他的由Apache，IIS等web伺服器去處理，由此大大提高Tomcat的運行效率。
如果一個項目中大量使用了靜態頁面、大量的圖片等，並有有較大的訪問量，推薦使用Apache集成Tomcat的方式來提高系統的整體性能。
Apache和Tomcat的整合有三種方式，分別是JK、http_proxy和ajp_proxy.其中JK方式是最常見的方式，JK本身有兩個版本分別是1和2，目前1最新版本是1.2.8，而版本2早已經廢棄了。http_proxy是利用Apache自帶的mod_proxy模塊使用代理技術來連接Tomcat。Ajp_proxy連接方式其實跟http_proxy方式一樣，都是由mod_proxy所提供的功能。只需要把配置中的http://換成ajp://,同時連接的是Tomcat的AJP Connector所在的埠。
相對於JK的連接方式，後兩種在配置上比較簡單的，靈活性方面也一點都不遜色。但就穩定性而言不像JK這樣久經考驗，所以建議採用JK的連接方式。
Apache+JK+Tomcat配置：
使用到的兩個配置文件分別是：httpd.conf和mod_jk.conf。其中httpd.conf是Apache伺服器的配置文件，用來載入JK模塊以及指定JK配置文件信息。mod_jk.conf是到Tomcat伺服器的連接定義文件。
【部署步驟】
1.安裝Apache伺服器
2.部署Tomcat
3.將mod_jk.so拷貝到moles目錄下面
4.修改httpd.conf和mod_jk.conf
【適用場景】 大量使用靜態頁面的應用系統。
四、Apache和Tomcat集群
對於並發要求很高的系統，我們需要採取負載均衡的方式來分擔Tomcat伺服器的壓力。負載均衡實現大概有四種：第一是通過DNS，但只能簡單的實現輪流分配，不能處理故障；第二是基於MS IIS,windows 2003 server本身就帶了負載均衡服務；第三是硬體方式，通過交換機功能或專門的負載均衡設備來實現；第四種是軟體的方式，通過一台負載均衡伺服器進行，上面安裝軟體。使用Apache Httpd Server做負載均衡器，Tomcat集群節點使用Tomcat就可以做到上述第四種方式，這種方式比較靈活，成本相對比較低，另外一個很大的優點就是可以根據應用情況和伺服器的情況做一些靈活的配置。所以推薦使用Apache+Tomcat集群來實現負載均衡。
採用Tomcat集群可以最大程度的發揮伺服器的性能，可以在配置較高的伺服器上部署多個Tomcat，也可以在多台伺服器上分別部署Tomcat，Apache和Tomcat整合的方式還是JK方式。經過驗證，系統對大用戶量使用的響應方面，Apache+3Tomccat集群> Apache+2Tomcat集群 > Apache集成Tomcat > 單個Tomcat。並且採用Apache+多Tomcat集群的部署方式時，如果一個Tomcat出現宕機，系統可以繼續使用，所以在硬體系統性能足夠優越的情況下，需要盡量發揮軟體的性能，可以採用增加Tomcat集群的方式。
Apache+Tomcat集群的方式使用到得配置文件有httpd.conf、mod_jk.conf、workers.properties。其中mod_jk.conf是對JK信息的配置，包括JK的路徑等，workers.properties配置文件是對Tomcat伺服器的連接定義文件。
Apache需要調整運行參數，這樣才能構建一個適合相應網路環境的web服務。其中可進行的優化配置如下：
1. 設置MPM（Multi Processing Moles多道處理模塊）。ThreadPerChild,這個參數用於設置每個進程的線程數，在Windows環境下默認值是64，最大值是1920，建議設置為100-500之間，伺服器性能高的話值大一些，反之小一些。MaxRequestPerChild表示每個子進程能夠處理的最大請求數。這個參數的值更大程度上取決於伺服器的內存，如果內存比較大的話可以設置為很大的參數，否則設置一個較小的值，建議值是3000.
2. 關閉DNS和名字解析 HostnameLookups off
3. 打開UseCanonicalName模塊 UseCanonicalName on
4. 關閉多餘模塊 一般來說，不需要載入的模塊有，mod_include.so、mod_autoindex.so、mod_access.so、mod_auth.so.
5. 打開KeepAlive支持
KeepAlive on, KeepAliveTimeout 15 MaxKeepAliveRequests 1000
根據實際經驗，通過Apache和Tomcat集群的方式提高系統性能的效果十分明顯，這種方式可以最大化的利用硬體資源，通過多個Tomcat的處理來分擔單Tomcat時的壓力。
【部署步驟】
1.安裝Apache伺服器
2.部署Tomcat集群，即多個相同的Tomcat。
3.將mod_jk.so拷貝到moles目錄下面
4.修改httpd.conf、mod_jk.conf和workers.properties
【適用場景】 並發用戶量及在線使用用戶數量比較高的系統。
五、Tomcat自身優化
1. JVM參數調優：-Xms<size> 表示JVM初始化堆的大小，-Xmx<size>表示JVM堆的最大值。這兩個值的大小一般根據需要進行設置。當應用程序需要的內存超出堆的最大值時虛擬機就會提示內存溢出，並且導致應用服務崩潰。因此一般建議堆的最大值設置為可用內存的最大值的80%。在catalina.bat中，設置JAVA_OPTS='-Xms256m -Xmx512m'，表示初始化內存為256MB，可以使用的最大內存為512MB。
2. 禁用DNS查詢
當web應用程序向要記錄客戶端的信息時，它也會記錄客戶端的IP地址或者通過域名伺服器查找機器名轉換為IP地址。DNS查詢需要佔用網路，並且包括可能從很多很遠的伺服器或者不起作用的伺服器上去獲取對應的IP的過程，這樣會消耗一定的時間。為了消除DNS查詢對性能的影響我們可以關閉DNS查詢，方式是修改server.xml文件中的enableLookups參數值：
Tomcat4

<Connector className="org.apache.coyote.tomcat4.CoyoteConnector" port="80" minProcessors="5" maxProcessors="75" enableLookups="false" redirectPort="8443" acceptCount="100" debug="0" connectionTimeout="20000" useURIValidationHack="false" disableUploadTimeout="true" />

Tomcat5

<Connector port="80" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" redirectPort="8443" acceptCount="100" debug="0" connectionTimeout="20000" disableUploadTimeout="true"/>
3. 調整線程數
通過應用程序的連接器（Connector）進行性能控制的的參數是創建的處理請求的線程數。Tomcat使用線程池加速響應速度來處理請求。在Java中線程是程序運行時的路徑，是在一個程序中與其它控制線程無關的、能夠獨立運行的代碼段。它們共享相同的地址空間。多線程幫助程序員寫出CPU最大利用率的高效程序，使空閑時間保持最低，從而接受更多的請求。
Tomcat4中可以通過修改minProcessors和maxProcessors的值來控制線程數。這些值在安裝後就已經設定為默認值並且是足夠使用的，但是隨著站點的擴容而改大這些值。minProcessors伺服器啟動時創建的處理請求的線程數應該足夠處理一個小量的負載。也就是說，如果一天內每秒僅發生5次單擊事件，並且每個請求任務處理需要1秒鍾，那麼預先設置線程數為5就足夠了。但在你的站點訪問量較大時就需要設置更大的線程數，指定為參數maxProcessors的值。maxProcessors的值也是有上限的，應防止流量不可控制（或者惡意的服務攻擊），從而導致超出了虛擬機使用內存的大小。如果要加大並發連接數，應同時加大這兩個參數。web server允許的最大連接數還受制於操作系統的內核參數設置，通常Windows是2000個左右，Linux是1000個左右。
在Tomcat5對這些參數進行了調整，請看下面屬性：
maxThreads Tomcat使用線程來處理接收的每個請求。這個值表示Tomcat可創建的最大的線程數。
acceptCount 指定當所有可以使用的處理請求的線程數都被使用時，可以放到處理隊列中的請求數，超過這個數的請求將不予處理。
connnectionTimeout 網路連接超時，單位：毫秒。設置為0表示永不超時，這樣設置有隱患的。通常可設置為30000毫秒。
minSpareThreads Tomcat初始化時創建的線程數。

maxSpareThreads 一旦創建的線程超過這個值，Tomcat就會關閉不再需要的socket線程。
最好的方式是多設置幾次並且進行測試，觀察響應時間和內存使用情況。在不同的機器、操作系統或虛擬機組合的情況下可能會不同，而且並不是所有人的web站點的流量都是一樣的，因此沒有一刀切的方案來確定線程數的值。
六、APR庫使用
Tomcat中使用APR庫，其實就是在Tomcat中使用JNI的方式來讀取文件以及進行網路傳輸。可以大大提升Tomcat對靜態文件的處理性能，同時如果你使用了HTTPS方式傳輸的話，也可以提升SSL的處理性能。
一般在Windows下，可以直接下載編譯好的二進製版本的dll庫文件來使Tomcat啟用APR，一般建議拷貝庫文件tcnative-1.dll到Tomcat的bin目錄下。而在Linux下，可以直接解壓和安裝bin目錄下的tomcat_native.tar.gz文件，編譯之前要確保apr庫已經安裝。
怎麼才能判斷Tomcat是否已經啟用了APR庫呢？方法是通過看Tomcat的啟動日誌：
如果沒有啟用APR，則啟動日誌一般有這么一條：
org.apache.coyote.http11.Http11Protocol start
如果啟用了APR，則這條日誌就會變成：
org.apache.coyote.http11.Http11AprProtocol start
tcnative-1.dll 下載地址：http://tomcat.heanet.ie/native/
調優綜述
根據以上分析，如果想要Tomcat達到最優的效果，首先要爭取使得操作系統以及網路資源達到最優，並且最好使用高版本的JDK。對於有大量靜態頁面的系統，採用Apache集成Tomcat的方式，把靜態頁面交由Apache處理，動態部分交由Tomcat處理，能極大解放Tomcat的處理能力。使用ARP庫也能極大的提高Tomcat對靜態文件的處理能力。對於並發要求較高的系統，採用Apache加Tomcat集群的方式，將負載分別分擔到多個Tomcat上，能很大的提高系統的性能，充分利用硬體資源。同時需要對Tomcat自身進行優化，包括增大內存、調節並發線程數等。

⑨ 詳解 Tomcat 配置文件 server.xml

前言

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）頂層元素：和

元素是整個配置文件的根元素，元素則代表一個Engine元素以及一組與之相連的Connector元素。

（2）連接器：

代表了外部客戶端發送請求到特定Service的介面；同時也是外部客戶端從特定Service接收響應的介面。

（3）容器：

容器的功能是處理Connector接收進來的請求，並產生相應的響應。Engine、Host和Context都是容器，但它們不是平行的關系，而是父子關系：Engine包含Host，Host包含Context。一個Engine組件可以處理Service中的所有請求，一個Host組件可以處理發向一個特定虛擬主機的所有請求，一個Context組件可以處理一個特定Web應用的所有請求。

（4）內嵌組件：可以內嵌到容器中的組件。實際上，Server、Service、Connector、Engine、Host和Context是最重要的最核心的Tomcat組件，其他組件都可以歸為內嵌組件。

下面將詳細介紹Tomcat中各個核心組件的作用，以及相互之間的關系。

三、核心組件

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

1、Server

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

在第一部分的例子中，在最外層有一個元素，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：

在這個例子中，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等集成的原理如下圖(圖片來源)：

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組件代表的虛擬主機，對應了伺服器中一個網路名實體(如」www.test.com」，或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//，例如第一部分的例子中，主機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元素最重要的屬性是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後，可以使用http://localhost:8080/來訪問Tomcat，其實訪問的就是ROOT對應的Web應用；我們也可以通過http://localhost:8080/docs來訪問docs應用，同理我們可以訪問examples/host-manager/manager這幾個Web應用。

（3）server.xml中靜態部署Web應用

除了自動部署，我們也可以在server.xml中通過元素靜態部署Web應用。靜態部署與自動部署是可以共存的。在實際應用中，並不推薦使用靜態部署，因為server.xml 是不可動態重載入的資源，伺服器一旦啟動了以後，要修改這個文件，就得重啟伺服器才能重新載入。而自動部署可以在Tomcat運行時通過定期的掃描來實現，不需要重啟伺服器。

server.xml中使用Context元素配置Web應用，Context元素應該位於Host元素中。舉例如下：

1

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）舉例

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

3、如何配置多個服務

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

在server.xml中配置多服務的方法非常簡單，分為以下幾步：

（1）復制元素，放在當前後面。

（2）修改埠號：根據需要監聽的埠號修改元素的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的配置如下：

http://localhost:8080/docs/

http://localhost:8084/docs/

五、其他組件

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

1、Listener

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

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

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

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

VersionLoggerListener：當Tomcat啟動時，該監聽器記錄Tomcat、Java和操作系統的信息。該監聽器必須是配置的第一個監聽器。

AprLifecycleListener：Tomcat啟動時，檢查APR庫，如果存在則載入。APR，即Apache Portable Runtime，是Apache可移植運行庫，可以實現高可擴展性、高性能，以及與本地伺服器技術更好的集成。

JasperListener：在Web應用啟動之前初始化Jasper，Jasper是JSP引擎，把JVM不認識的JSP文件解析成java文件，然後編譯成class文件供JVM使用。

：與類載入器導致的內存泄露有關。

：通過該監聽器，初始化< GlobalNamingResources>標簽中定義的全局JNDI資源；如果沒有該監聽器，任何全局資源都不能使用。< GlobalNamingResources>將在後文介紹。

：當Web應用因thread-local導致的內存泄露而要停止時，該監聽器會觸發線程池中線程的更新。當線程執行完任務被收回線程池時，活躍線程會一個一個的更新。只有當Web應用(即Context元素)的屬性設置為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，含義是請求處理的時間(單位是毫秒)，對於統計分析請求的處理速度幫助很大。

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