Tomcat伺服器
Tomcat配置與部署（IDEA）
https://www.cnblogs.com/gonghr/p/14731266.html
Tomcat手工建立和打包第一個Web工程
在apache-tomcat-9.0.30目錄下的webapps資料夾下新建工程目錄起名為MyWeb
在MyWeb中編寫html檔案
開啟Tomcat後，進入瀏覽器，輸入http://localhost:8080/MyWeb/welcome.html進入網頁，第一個網頁就部署好了
如果想要只輸入http://localhost:8080/MyWeb就能進入歡迎介面，則需要在MyWeb目錄下新建WEB-INF資料夾，在該資料夾下新建web.xml的配置檔案
（注意這裡的WEB-INF和web.xml的寫法是固定的，是Tomcat的標準，不能亂寫）
在web.xml中編寫配置資訊
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd"
version="4.0">
<welcome-file-list>
<welcome-file>welcome.html</welcome-file> <!--新增歡迎頁面-->
</welcome-file-list>
</web-app>
這樣就可以了
在命令列打war包
在web專案的目錄下開啟命令列，輸入 jar cvf E:\DevTols\apache-tomcat-9.0.30\webapps\MyWeb.war . (注意最後是一個空格和一個點）
E:\DevTols\apache-tomcat-9.0.30\webapps\MyWeb.war是war包的目標儲存位置和名稱
如果把MyWeb的資料夾刪除，把打好的war包放在webapps目錄下，重新啟動Tomcat後，war包會自動解壓成資料夾。
解讀server.xml
核心程式碼
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true">
</Host>
name：主機名，及域名。
appBase：主機指定的目錄
unpackWARs：是否自動解壓war包。若為true則自動解壓
autoDeploy：在伺服器執行狀態下，將一個專案放入當前目錄，是否自動部署到伺服器，由Tomcat來管理。若為true，則自動部署。
例子：
將war包移到webapps目錄以外，並將webapps內原專案資料夾刪除，開啟Tomcat伺服器，將war包移入webapps內則可以看到war包自動解壓並被部署到伺服器上。
Tomcat核心結構
Host為訪問的主機域名，Host中的Context為主機中的應用名稱。若要連線主機，則需要通過聯結器Connector。主機的執行基於服務引擎Engine所構建的執行環境。一個伺服器Server可以提供多種服務Service。
建立虛擬目錄
第一種方式：在主機配置中新增Context標籤（不推薦）
將專案目錄放到任意一個位置，比如E盤下。
在主機下新增一個應用，在server.xml中新增應用
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true">
<Context path="/xxx" docBase="E:/MyWeb"/> <!--path是隨便寫的一個訪問路徑，docBase是專案在本地的路徑-->
</Host>
重啟Tomcat，即可訪問
但是這個方法重啟了伺服器，這在大型的專案中是不可能的，重啟伺服器會造成鉅額損失。所以不要使用這種方法！
第二種方法：在主機目錄中新增配置
Tomcat啟動後，會在安裝目錄的conf中自動建立一個 目錄，該目錄與server.xml的<Engine/>標籤對應，目錄名與該標籤的name屬性相同，預設為Catalina.
該目錄為引擎目錄。開啟可以看到localhost主機目錄。
在localhost主機目錄中新建一個xml檔案，任意名稱即可，配置應用資訊。
<?xml version="1.0" ?>
<Context docBase="E:/MyWeb"/>
不需重啟伺服器即可訪問
建立虛擬主機
DNS(Domain Name Service) 域名解析服務：將域名與ip地址建立對映。目的是為了方便訪問。
比如百度的域名是www.baidu.com ，而百度的ip用ping www.baidu.com得到是104.193.88.77。怎麼可能去記住ip地址，所以域名就是ip的別名，方便好記，利於人們訪問。
本機的域名是localhost，ip是127.0.0.1
C:\Windows\System32\drivers\etc\hosts在此路徑下可以檢視本機ip和域名
# Copyright (c) 1993-2009 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
# 102.54.94.97 rhino.acme.com # source server
# 38.25.63.10 x.acme.com # x client host
# localhost name resolution is handled within DNS itself.
# 127.0.0.1 localhost
# ::1 localhost
第一步：建立存放應用的目錄
第二部：修改server.xml
在server.xml檔案中新增主機，在原Host標籤後面新增<Host>標籤
<Host name="www.hahaha.com" appBase="E://web"
unpackWARs="true" autoDeploy="true">
</Host>
第三步：修改Host檔案
開啟C:\Windows\System32\drivers\etc\下的hosts檔案，在最後新增
127.0.0.1 www.hahaha.com
注意hosts檔案是無法直接修改的，會讓另存為。
解決方案一：複製hosts到其他目錄，修改完後再複製回去替換原檔案。
解決方案二：用notepad++以管理員身份開啟。
第四步：
重啟伺服器，開啟網址。
Catalina目錄下自動配置了主機
修改預設主機
再考慮一個問題，hosts中本機ip地址127.0.0.1的對映有兩個，如果用ip地址訪問的話，會訪問哪個域名對映呢？
這時發現在server.xml配置檔案中明確了預設的主機
<Engine name="Catalina" defaultHost="localhost">
可以通過修改server.xml檔案的defaultHost來修改127.0.0.1的預設域名。
修改預設埠號
還有一個問題，每次訪問都要寫埠號8080很煩啊，如何才能不寫埠號就能訪問呢？
還是server.xml檔案中，將port修改為80及可，提交請求時不寫埠號，瀏覽器預設埠號是80
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
重啟伺服器即可
注意可能會出現更改埠號無法訪問的情況
解決80埠占用的方法
管理員執行CMD 輸入netstat -ano 檢視是哪個應用佔用了80埠
如圖：我的是PID為4的應用佔用了80埠
接著開啟工作管理員找到PID為4的應用
這時如果佔用80埠的應用不是System的話，看下該應用是否必須要經常用到，否則可以結束任務，
如果和我情況一樣佔用80埠的是System無法結束任務
這時候就要開啟開始選單找到IIS管理器
如圖點選停止就可以解決80埠被佔用的問題了
停止之後只需要重啟tomcat服務在瀏覽器上輸入http://localhost、就能夠看到測試頁面瞭如果繫結了域名同理只需要輸入域名就可以訪問tomcat的預設訪問頁面
如圖我的修改了埠為80後輸入域名顯示的頁面
配置預設應用
原預設應用是localhost:8080，也就是小貓的介面
apache-tomcat-9.0.30\webapps\ROOT webapps目錄下的ROOT應用是預設應用
如果想在訪問localhost:8080的時候開啟某個其他的應用，
只要把原來的ROOT隨便改個名，把目標應用的名稱改為ROOT，重啟伺服器即可。
批量管理應用
以後的應用名稱可能很長，不好輸入，那麼如何檢視一個主機下的所有應用呢？
進入小貓頁面，點選右側的Manage App
會提示輸入賬號密碼
點選取消，彈出介面
需要配置conf/tomcat-users.xml檔案
在<tomcat-users>標籤的最後新增
<role rolename="manager-gui"/>
<user username="1" password="1" roles="manager-gui"/>
返回小貓介面進入Manager App，左側為所有應用，點選即可進入，可批量管理。
HTTP協議
HTTP協議概述
HTTP協議概念
HTTP的全稱是：Hyper Text Transfer Protocol，意為 超文字傳輸協議。它指的是伺服器和客戶端之間互動必須遵循的一問一答的規則。形容這個規則：問答機制、握手機制。
它規範了請求和響應內容的型別和格式。
HTTP協議是由W3C組織管理和維護的。
HTTP協議版本
目前HTTP協議主要是1.0版本和1.1版本。這兩個版本的區別主要是兩個方面。
第一：HTTP1.1版本比1.0版本多了一些訊息頭。
第二：HTTP1.1版本和1.0版本的執行過程不一樣。執行過程如下：
| HTTP1.0 | HTTP1.1 |
|---|---|
| 建立連線（TCP/IP） | 建立連線（TCP/IP） |
| 傳送請求 | 傳送請求1 |
| 得到響應 | 得到響應1 |
| 關閉連線 | 傳送請求2 |
| 建立連線（TCP/IP） | 得到響應2 |
| 傳送請求 | ....... |
| 得到響應 | ....... |
| 關閉連線 | 連線超時或手動關閉連線 |
Http1.0版本
HTTP10協議規定，客戶端若要向服務端發出請求，必須首先在它們之間建立一個TCP( Transfer Control Protocal,傳輸控制協議)連線。而當客戶端接收到服務端所發出的響應後服務端將關閉TCP連線。只有等待上一次的請求所對應的響應被客戶端接收到後，客戶端才可發出第二次請求。HTTP1.0協議中的連線屬於非持久連線，且伺服器不跟蹤和記錄任何次請求與響應。
客戶端與服務端每次建立和關閉連線都是一個相對比較費時的過程，會嚴重影響客戶端和服務端的效能。
Http2.0版本
HTTP 1.1版本是目前瀏覽器預設採用的HTTP協議版本，是一種持久連線，在一個TCP連線上可以傳送多個HTTP 請求和響應，減少了建立和關閉連線的消耗和延遲。一個包含有許多CSS、JS、圖片等資源的頁面，其所發出的多個請求和響應可以在一個連線中傳輸。但每個單獨的頁面檔案的請求和響應仍然需要使用各自的連線。
HTTP 1.1還允許客戶端不用等待上一次請求結果返回，就可以發出下一次請求，但伺服器端必須按照接收到客戶端請求的先後順序依次回送響應結果,以保證客戶端能夠區分出每次請求的響應內容，這樣也顯著地減少了整個下載過程所需要的時間。
HTTP1.0在客戶端接收到服務端傳送來的響應後，TCP連線馬上關閉。而HTTP1.1的連線是什麼時候關閉呢?客戶端在傳送建立TCP連線請求之前首先計算出本次連線瀏覽器所要傳送的請求數量,即一次手工請求加上其所攜帶的所有自動請求數量。當所有瀏覽器所發出的請求全部傳送完畢後，客戶端會再自動傳送一個關閉TCP連線的請求。這個請求在HttpWatch中是看不到的。
為了防止伺服器主動將TCP 連線關閉，在每一個請求中都攜帶了一個引數Connection用於告訴伺服器是否關閉連線。在HttpWatch中可以看到的這些請求中，其Connection引數值均為Keep-Alive保持連線。只有當客戶端傳送了關閉TCP連線請求時，伺服器才會將TCP連線關閉。
當然，除了改進了HTTP1.0協議的效能問題外，HTTP 1.1還通過增加更多的請求頭和響應頭來改進和擴充HTTP 1.0的功能。
例如，由於HTTP 1.0不支援Host 請求頭屬性，WEB瀏覽器無法使用主機域名來明確表示要訪問伺服器上的哪個WEB站點，這樣就無法使用wEB伺服器在同一個IP地址和埠號上配置多個虛擬WEB站點。在 HTTP 1.1中增加Host 請求頭欄位後，WEB瀏覽器可以使用主機域名來明確表示要訪問伺服器上的哪個WEB站點，這才實現了在一臺WEB伺服器上可以在同一個IP地址和埠號上使用不同的主機名來建立多個虛擬WEB站點。
HTTP 1.1的持續連線，也需要增加新的請求頭來幫助實現，例如，Connection請求頭的值為Keep-Alive時，客戶端通知伺服器返回本次請求的響應後仍然保持連線;Connectio請求頭的值為close時,客戶端通知伺服器關閉連線。
Http1.0與Http1.1版本的對比
它們的共同點是請求和響應成對存在，客戶端的一次請求一定會對應服務端的一次響應。它們的區別如下：
(1)HTTP1.0
HTTP1.0協議中的連線屬於非持久連線，一次TCP連線只能進行一次請求與響應。一次請求與響應對應一個TCP連線。
客戶端只有在接收到服務端對上一次請求的響應後，客戶端才可發出第二次請求。HTTP1.0不支援對虛擬主機的訪問。因為其沒有HOST請求頭屬性，會將使用者所發出的域名直接通過DNS轉換為IP後，傳送到服務端。也就是說，服務端接收到的直接就是個IP而非域名。這樣 HTTP1.0的請求就不支援對虛擬主機的訪問了。
HTTP1.0協議中在客戶端接收到服務端的響應後，馬上傳送關閉TCP連線的請求，服務端關閉連線。
(2）HTTP1.1
HTTP 1.1支援持久連線，在一個TCP連線上可以傳送多個請求和響應。一般情況下，一個頁面中的請求與響應對應一個TCP連線。
HTTP 1.1還允許客戶端不用等待上一次請求結果返回，就可以發出下一次請求。HTTP1.1支援對虛擬主機的訪問。其在請求頭屬性中增加了HOST屬性，用於記錄請求所要訪問的虛擬域名。當然，請求中所攜帶的域名，肯定會通過 DNS將其轉換為IP然後查詢到相應的主機。但由於請求中還攜帶有HOST屬性，即要訪問的域名仍然在請求中，這樣的話，伺服器就可以從請求中解析出請求所要訪問的虛擬主機名。
HTTP1.1協議中在客戶端接收到對最後一次請求的響應後,馬上傳送關閉TCP連線請求，服務端關閉連線。
HTTP協議相關說明
HTTP協議概念是客戶瀏覽器和伺服器一種一問一答的規則，那麼必須要有問有答，而且要先問後答。
但是我們使用<script>,<link>和<img>標籤，沒有手動發起請求，但是仍然能從伺服器端拿到資料，原因就是：在瀏覽器遇到<script>,<link>,<img>標籤時會自動發出請求。
HTTP協議組成
由HTTP協議的概念可知，它分為問和答兩部分。其中問指的就是請求部分，而答指的就是響應部分。
請求部分
在學習請求協議格式之前，首先要了解兩個概念:URL與URI。
URL: Uniform Resource Locator,統一資源定位符。是網際網路上標準資源的地址，可以
在全球範圍內唯一的確定一個資源
URl: Uniform Resource ldentifier，統一資源識別符號，用於標識一個資源的名稱。通過這種名稱命名的資源可以被網際網路定位和訪間。
請求行： 永遠位於請求的第一行
請求訊息頭： 從第二行開始，到第一個空行結束
空白行：用於分離請求報頭和請求正文
請求的正文： 從第一個空行後開始，到正文的結束
響應部分
響應行： 永遠位於響應的第一行
響應訊息頭： 從第二行開始，到第一個空行結束
空白行：用於分離響應報頭和響應正文
響應的正文： 從第一個空行後開始，到正文的結束
訊息頭的共性分析
訊息頭名稱首字母大寫，多個單詞每個單詞的首字母都大寫。
多個單詞用-分隔
名稱和值之間用冒號加空格分隔
多個值之間用逗號加空格分隔
兩個頭之間用回車分隔
請求部分詳解
請求行詳解
請求行：GET /myapp/2.html HTTP/1.1
| 內容 | 說明 |
|---|---|
| GET | 請求的方式。（還有POST） |
| /myapp/2.html | 請求的資源。 |
| HTTP/1.1 | 使用的協議，及協議的版本。 |
請求訊息頭詳解
| 內容 | 說明 |
|---|---|
| Accept | 告知伺服器，客戶瀏覽器所支援的MIME型別。 |
| Accept-Encoding | 告知伺服器，客戶瀏覽器所支援的壓縮編碼格式。最常用的就是gzip壓縮。 |
| Accept-Language | 告知伺服器，客戶瀏覽器所支援的語言。一般都是zh_CN或en_US等。 |
| Referer | 告知伺服器，當前請求的來源。 只有當前請求有來源的時候，才有這個訊息頭。從位址列輸入的沒有來源。 作用：1 投放廣告 2 防盜鏈 |
| Content-Type | 告知伺服器，請求正文的MIME型別。 |
| Content-Length | 告知伺服器，請求正文的長度。 |
| User-Agent | 瀏覽器相關資訊 |
| Connection: Keep-Alive | 連線的狀態：保持連線 |
| If-Modified-Since | 告知伺服器，客戶瀏覽器快取檔案的最後修改時間。 |
| Cookie（********） | 會話管理相關，非常的重要。 |
請求正文詳解
第一：只有post請求方式，才有請求的正文。get方式的正文是在位址列中的。
第二：表單的輸入域有name屬性的才會被提交。不分get和post的請求方式。
第三：表單的enctype屬性取值決定了請求正文的體現形式。概述的含義是：請求正文的MIME編碼型別。
| enctype取值 | 請求正文體現形式 | 示例 |
|---|---|---|
| application/x-www-form-urlencoded | key=value&key=value | username=test&password=1234 |
| multipart/form-data | 此時變成了多部分表單資料。多部分是靠分隔符分隔的。 | -----------------------------7df23a16c0210 Content-Disposition: form-data; name="username" test -----------------------------7df23a16c0210 Content-Disposition: form-data; name="password" 1234 -----------------------------7df23a16c0210 Content-Disposition: form-data; name="headfile"; filename="C:\Users\zhy\Desktop\請求部分.jpg" Content-Type: image/pjpeg -----------------------------7df23a16c0210 |
響應部分詳解
響應行詳解
響應行：HTTP/1.1 200 OK
| 內容 | 說明 |
|---|---|
| HTTP/1.1 | 使用協議的版本。 |
| 200 | 響應狀態碼 |
| OK | 狀態碼描述 |
常用狀態碼介紹
| 狀態碼 | 說明 |
|---|---|
| 200 | 一切都OK> |
| 302/307 | 請求重定向(客戶端行為，兩次請求，位址列發生改變) |
| 304 | 請求資源未發生變化，使用快取 |
| 404 | 請求資源未找到 |
| 500 | 伺服器錯誤 |
常用的狀態碼以2、4、5開頭，分別表示的意義為:
2xx：表示對請求計算與響應成功。其中常用的狀態碼是200。
4xx：表示請求錯誤。其中常見的狀態碼是404，表示資源找不到。一般都是請求路徑
書寫有問題。
5xx：表示服務端錯誤。其中常見的狀態碼是500，表示伺服器內部錯誤。一般都是服
務端的Java程式碼發生錯誤。
響應訊息頭詳解
| 訊息頭 | 說明 |
|---|---|
| Location | 請求重定向的地址，常與302,307配合使用。 |
| Server | 伺服器相關資訊。 |
| Content-Type | 告知客戶瀏覽器，響應正文的MIME型別。 |
| Content-Length | 告知客戶瀏覽器，響應正文的長度。 |
| Content-Encoding | 告知客戶瀏覽器，響應正文使用的壓縮編碼格式。常用的gzip壓縮。 |
| Content-Language | 告知客戶瀏覽器，響應正文的語言。zh_CN或en_US等等。 |
| Content-Disposition | 告知客戶瀏覽器，以下載的方式開啟響應正文。 |
| Refresh | 定時重新整理 |
| Last-Modified | 伺服器資源的最後修改時間。 |
| Set-Cookie（*******） | 會話管理相關，非常的重要 |
| Expires:-1 | 伺服器資源到客戶瀏覽器後的快取時間 |
| Catch-Control: no-catch | 不要快取，//針對http協議1.1版本 |
| Pragma:no-catch | 不要快取，//針對http協議1.0版本 |
響應正文詳解
就和我們在瀏覽器上右鍵檢視原始檔看到的內容是一樣的。
<html>
<head>
<link rel="stylesheet" href="css.css" type="text/css">
<script type="text/javascript" src="demo.js"></script>
</head>
<body>
<img src="1.jpg" />
</body>
</html>
指定預設錯誤頁面
當發生諸如404、500錯誤時，Web容器給出一個英文提示的頁面。若系統給出這樣的頁面，則說明系統設計的介面不友好。
不過，在 web.xml中允許應用指定預設的錯誤碼所對應的錯誤頁面。只要服務端向客戶端瀏覽器發出指定的狀態碼，則系統就會自動跳轉到指定頁面。
GET和POST請求方式
GET請求
由於GET請求會將請求所攜帶的引數作為請求URL中的一部分出現，所以請求引數會顯示在位址列。而這就導致了GET提交的三點不足:
1.引數值只能是字串，而不能是其它型別
2.可以攜帶的資料量少
3.資料安全性低
但GET請求有一個很重要的特徵：客戶端一旦接收到“伺服器向GET請求傳送的響應”後，瀏覽器會自動快取響應。當客戶再次進行相同請求提交時，將直接讀取本地瀏覽器快取中資料，而不再向服務端真正傳送資料，讓使用者感覺服務端的響應很快，提升使用者體驗，減輕了伺服器壓力。
POST請求
POST請求會將請求所攜帶的資料以請求正文的形式出現，所以與GET方式相比，就顯示出了三點長處:
1.資料型別可以是任意型別，還可以是聲音、視訊、圖片等檔案
2.請求可以攜帶的資料量大
3.資料安全性高
但發出 POST請求的客戶端瀏覽器不會對接收到的“伺服器向POST 請求傳送的響應”進行快取。
當使用者再次進行相同請求時，仍是真正向伺服器傳送的請求，從伺服器讀取的資料。
為什麼要設計為“GET請求的響應結果會被瀏覽器快取，POST請求的響應結果不會被瀏覽器快取”呢？主要有兩點原因。
一個原因是，以不同的方式提交請求其目的也是不同的。
GET請求的目的一般是客戶端要從服務端下載資源，傳送相同的請求就代表要下載相同的資源。既然要下載相同的資源而這些資源已經被下載到了客戶端，那麼就無需再下載了所以也就無需再向伺服器傳送真正的下載請求了。所以就將GET提交方式設計為了“GET請求的響應結果會被瀏覽器快取”。
但POS請求的的一般是客戶端要向伺服器端上傳資源。對於向伺服器端上傳資源後響應結果，瀏覽器是無需快取的。
另一個原因是，是否是相同的請求，兩種提交方式的比較難易程度是不同的。
GET提交方式的請求只包含請求行、請求頭與空行三部分，請求體為空。所以第二次請求與前一次請求是否相同，瀏覽器很好做出比較。
但POST提交方式所包含的資料量比較大，主要體現在請求正文內容較多上。請求正文可以是圖片、音訊、視訊等檔案，而對第二次請求與前一次請求是否相同的比較，僅從這些內容來看就已經很不好比較了。即對於POST提交，是否是相同請求的提交是不好做出比較的，或者說是無法進行比較的。所以將POST提交方式設計為了“POST請求的響應結果不會被瀏覽器快取”。
預設請求提交方式
瀏覽器向伺服器提交請求的方法常見的有五種，這五種方法所採用的提交方式要麼是GET方式，要麼是POST方式。具體提交方式如下表:
請求提交方式的選擇
根據以上敘述，具有以下幾種情況之一的，選擇POST 提交方式。其它均採用GET提交方式。
1.提交時所攜帶的資料型別不是字串
2.提交時所攜帶的資料量比較大
3.提交時所攜帶的資料具有敏感性，安全性要求較高
為什麼POST提交的安全性就高?
因為能夠實現 POST提交的方式只有兩種：通過表單的POST提交，與通過AJAX的Post提交。其它方式均為GET提交方式。對於一個提供了POST登入頁面的系統,若使用者試圖通過位址列等方式進行登入,則說明其一定是非法登入
也就是說，只要我們設定系統的登入請求提交方式是POST，那麼就會出現以下兩種情況：若使用者以POST方式提交登入請求，我們無法判斷其是否是非法登入。因為他有可能是通過其它表單的POST方式提交的登入請求。
若使用者以GET方式提交登入請求，則馬上就可以判斷其是非法登入。基於以上原因，POST提交方式的安全性要高於GET提交方式。
綜合案例-Tomcat的具體應用
靜態資源案例-門戶類網站的部署和訪問
案例介紹
需求：
在瀏覽器中輸入地址，訪問靜態HTML頁面。
細節說明：
把HTML和CSS課程中製作的頁面加入到JavaWeb工程中，在Tomcat中部署工程，然後啟動Tomcat伺服器，並使用瀏覽器訪問。
實現步驟
第一步：建立工程並選擇使用的Tomcat版本
第二步：拷貝資源到工程的web目錄中
第三步：在web.xml中配置預設主頁
第四步：部署工程到Tomcat伺服器
第五步：測試瀏覽器訪問
動態資源的案例-學生管理系統的部署和訪問
案例介紹
需求：
把JavaSE進階階段的學生管理系統的伺服器改用Tomcat實現。
細節說明：
把學生管理系統涉及的HTML和樣式以及圖片檔案拷貝到JavaWeb工程中，在Tomcat中部署工程，然後啟動Tomcat伺服器，並使用瀏覽器訪問。
實現步驟
第一步：建立工程
第二步：拷貝資源
第三步：配置預設主頁
第四步：部署專案
建立案例中的動態資源-Servlet
1） Servlet簡介
Servlet翻譯成中文是服務端指令碼，它是SUN公司推出的一套規範，稱為Servlet規範。Servlet規範是JavaEE規範中的一部分。我們可以通過查閱JavaEE規範的API來了解Servlet的基本概念。通過點選JavaEE8官方文件，就可以看到關於Servlet的內容介紹。
2） 按步驟編寫Servlet
前期準備：在IDEA建立Javaweb工程
第一步：編寫一個普通類實現Servlet介面或者繼承GenericServlet類或者繼承HttpServlet
第二步：重寫service方法，輸出一句話
第三步：在web.xml配置Servlet
第四步：啟動tomcat伺服器測試
在位址列輸入：http://localhost:8585/crm/studentServlet 測試訪問結果
3）測試訪問
