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協議中的連接屬於非持久連接，且服務器不跟蹤和記錄任何次請求與響應。
客戶端與服務端每次建立和關閉連接都是一個相對比較費時的過程，會嚴重影響客戶端和服務端的性能。
Http1.1版本
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）測試訪問
