圖解 Spring：HTTP 請求的處理流程與機制【2】
2. HTTP 請求在 Web 容器中的處理流程
Web 容器以程序的方式在計算機上執行，我們知道程序是系統資源分配的最小單元，執行緒是系統任務執行的最小單元。從這個角度看，Web 容器就像是郵包收件人所居住的樓宇或小區，HTTP 這套物流快遞體系只能將郵包投遞到樓宇前臺或者小區物業等處，而樓宇前臺或小區物業並不屬於物流快遞體系，就像 Web 容器並不屬於計算機網路基礎設施一樣。
之所以這樣分工，原因是網路路由資訊由域名伺服器 DNS、路由器等裝置掌握，Web 容器內部體系結構資訊只有它自己知道。從 Web 容器接收到 HTTP 請求，到將其投送至特定的應用，這期間還會經歷一個複雜的過程，瞭解這個過程對於日常開發和問題分析都會有所幫助。接下來，老兵哥我將陪著你一起來剖析這個過程。
Java 語言領域的 Web 容器型別非常多，包括 Tomcat、Jetty、Resin、Websphere、Weblogic、JBoss、Glassfish、GonAS 等，其中 Tomcat 是由 Apache Software Foundation 維護的開源 Web 容器。Tomcat 市場佔用率接近 60%，截止目前是最受歡迎的 Web 容器，如下圖所示橫跨 Web 伺服器和 Java 應用伺服器。
我們就以 Tomcat 為例來看看 Web 容器的內部結構，作為符合 JAVA Servlet 標準規範的容器，Tomcat 是一款基於元件的 Java Web 應用伺服器，核心元件都是靈活可配的。Tomcat 最外層是 Catalina Servlet 容器，其他元件是按照特定格式要求配置在這個頂層容器當中，配置檔案就是安裝目錄下的：/conf/server.xml。
通過這份配置檔案，我們就可以瞭解 Tomcat 的體系結構，示例檔案如下所示（快速瀏覽一遍，後面詳細剖析）：
1 <Server port="8005" shutdown="SHUTDOWN"> 2 <Listener className="org.apache.catalina.startup.VersionLoggerListener" /> 3 <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" /> 4 <Listener className="org.apache.catalina.core.JasperListener" /> 5 <Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" /> 6 <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" /> 7 <Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" /> 8 9 <GlobalNamingResources> 10 <Resource name="UserDatabase" auth="Container" 11 type="org.apache.catalina.UserDatabase" 12 description="User database that can be updated and saved" 13 factory="org.apache.catalina.users.MemoryUserDatabaseFactory" 14 pathname="conf/tomcat-users.xml" /> 15 </GlobalNamingResources> 16 17 <Service name="Catalina"> 18 <Connector port="8080" protocol="HTTP/1.1" maxThreads=”150″ 19 connectionTimeout="20000" 20 redirectPort="8443" /> 21 <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" /> 22 <Connector port=”8443″ maxThreads=”150″ minSpareThreads=”25″ 23 maxSpareThreads=”75″ enableLookups=”false” acceptCount=”100″ 24 debug=”0″ scheme=”https” secure=”true” 25 clientAuth=”false” sslProtocol=”TLS” /> 26 <Engine name="Catalina" defaultHost="localhost"> 27 <Realm className="org.apache.catalina.realm.LockOutRealm"> 28 <Realm className="org.apache.catalina.realm.UserDatabaseRealm" 29 resourceName="UserDatabase"/> 30 </Realm> 31 32 <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true"> 33 <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" 34 prefix="localhost_access_log." suffix=".txt" 35 pattern="%h %l %u %t "%r" %s %b" /> 36 </Host> 37 </Engine> 38 </Service> 39 </Server>
2.1 Tomcat 核心元件簡介
如果經常使用配置 Tomcat，那麼你對上述配置檔案一定非常熟悉。為了方便大家理解，結合本文的主題，我們把上述這份配置檔案中的關鍵節點提取出來，然後再逐一分析介紹：
1 <Server> 2 <Service> 3 <Connector /> 4 <Connector /> 5 <Engine> 6 <Host> 7 <Context /> 8 </Host> 9 </Engine> 10 </Service> 11 </Server>
上述結構中包含了 Tomcat 的核心元件：Server 元件在最頂層，代表整個 Tomcat 容器。一個 Server 元件中可以包含一個或多個 Service 元件。Service 在 Connector 和 Engine 外面包了一層，把它們組裝在一起對外提供服務。一個 Service 可以包含多個 Connector，但是隻能包含一個 Engine。不同 Connector 負責接收不同埠上相應協議的請求，而 Engine 負責處理請求。Engine 包含一個或多個 Host，Host 包含一個或多個 Context，Engine、Host、Context 都屬於容器元件，一個 Host 元件代表一個虛擬主機，一個 Context 元件代表在隸屬 Host 上執行的一個 Web 應用。
2.1.1 頂層類元件 Server
它是整個配置檔案的唯一根元素，代表整個 Tomcat 容器，內部可以包含多個 Service。Server 主要職責就是管理多個 Service，對外提供給客戶端訪問，同時維護所有 Service 的生命週期，包括初始化服務、結束服務、定位客戶端要訪問的 Service 等等。所有 Tomcat 元件的生命週期都是通過 Lifecycle 介面來控制的，元件只要繼承這個介面並實現其中的方法就可以統一被父元件控制了，這樣層層遞進 Server 元件就可以控制所有元件的生命週期了，而控制 Server 就是通過啟動和關停 Tomcat。在前面配置示例中，Server 的配置如下所示：
<Server port="8005" shutdown="SHUTDOWN">
其中，屬性 shutdown 指定關閉 Server 的指令。屬性 port 指定 Server 接收 shutdown 指令的埠號，設定為“-1”可以禁掉該埠。
2.1.2 頂層類元件 Service
Service 主要職責就是將 Engine 與 Connector 裝配在一起對外提供服務，一個 Service 可以包含多個 Connector，但只能包含一個 Engine，其中 Connector 負責從客戶端接收請求，Engine 負責處理 Connector 接收進來的請求。如前面配置示例中，Service 的配置如下所示：
<Service name="Catalina">
我們可以通過屬性 name 為 Service 指定名稱，不同的 Service 負責監管其下屬 Connector 所繫結的埠。
2.1.3 聯結器元件 Connector
Tomcat 的工作模式可以分為下面兩類：
- 作為 Web 伺服器：請求是直接來自於客戶端 HTTP 請求（或瀏覽器）。
- 作為 Java Web 應用伺服器：請求來自於前置 Web 伺服器，通常包括：Apache、IIS、Nginx 等。Tomcat 主要優勢是作為 JSP/Servlet 容器，在處理靜態資源方面效率偏低。因此，它通常要跟 Apache、IIS、Nginx 等 Web 伺服器整合使用。AJP 協議主要負責 Tomcat 和整合 Web 伺服器的互動連線。
每個 Service 可以有一個或多個 Connector，不同工作模式下，Tomcat 需要為各種型別的請求分別定義相應的 Connector，這樣才能正確接收客戶端對應協議的請求。定義 Connector 可以使用多種屬性，某些屬性只適用於某種特定的 Connector 型別。一般說來，常見的 Connector 有 4 種類型：HTTP、SSL、AJP、Proxy。
作為通訊介面，Connector 為其所屬特定的 Service 接收外部客戶端請求，以及回送應答至外部客戶端。具體職責包括建立 Request、Response 物件用於跟外部客戶端交換資料，並將 Request 交給配套的 Engine 來處理。通過修改 Connector 的屬性取值，我們可以控制 Service 所監聽的網路協議及埠號，具體示例如下：
1 <Connector port="8080" protocol="HTTP/1.1" maxThreads=”150″ 2 connectionTimeout="20000" 3 redirectPort="8443" /> 4 <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" /> 5 <Connector port=”8443″ maxThreads=”150″ minSpareThreads=”25″ 6 maxSpareThreads=”75″ enableLookups=”false” acceptCount=”100″ 7 debug=”0″ scheme=”https” secure=”true” 8 clientAuth=”false” sslProtocol=”TLS” />
- 配置一，客戶端可以通過 8080 埠號使用 HTTP 協議訪問 Tomcat。
- 配置二，客戶端可以通過 8009 埠使用 AJP 協議訪問 Tomcat。AJP 協議主要用於跟其他的 HTTP 伺服器連線協作。當 Tomcat 與其他 HTTP 伺服器整合時，我們就要用到這個聯結器。
- 配置三，客戶端可以通過 8443 埠號使用 HTTPS 協議訪問 Tomcat。
聯結器的定義可以配置的屬性非常多，下面是常用屬性的說明。
- address：指定聯結器監聽的地址，預設為所有地址，即 0.0.0.0。
- maxThreads：支援最大的併發連線數，預設為 200。
- port：監聽埠，預設為 0。
- protocol：聯結器使用的協議，預設為：HTTP/1.1，定義 AJP 協議時通常為 AJP/1.3。
- redirectPort：在強制要求 HTTPS 的情況下，如果請求時 HTTP，則將會被重定向至 8443 埠。
- connectionTimeout：連線的超時時間，單位為毫秒，預設為 60000，即 1 分鐘。
- enableLookups：是否通過 request.getRemoteHost() 進行 DNS 查詢以獲取客戶端的主機名。
- acceptCount：設定等待佇列的最大長度。通常，在 Tomcat 所有處理執行緒均處於繁忙狀態時，新請求將被放置於等待佇列中。
2.1.4 容器類元件 Engine
Engine 內部可以包含多個 Host，它是 Service 元件中負責請求處理的元件。它從一個或多個 Connector 中接收請求並處理，並將處理結果封裝成應答交給 Connector，最終回傳給外部客戶端。在前文配置檔案示例中，Engine 的配置如下所示：
<Engine name="Catalina" defaultHost="localhost">
其中，屬性 name 用於日誌和錯誤資訊，其取值在整個 Server 中保證唯一。屬性 defaultHost 指定了預設的Host 名稱，當 HTTP 請求所指定的 Host 名稱不存在時，一律使用 defaultHost 指定的 Host 來處理。因此，defaultHost 的值，必須與 Engine 中的某個 Host 元件的屬性 name 取值匹配。
2.1.5 容器類元件 Host
Host 代表一個虛擬主機，它對應計算機網路上的一個實體，即某個在 DNS 伺服器上註冊過的域名或者 IP 地址，例如：www.abc.com 或 201.187.10.21。Host 內部可以包含多個 Context，每個 Context 表示一個 Web 應用。Host 負責安裝、展開、啟動和結束每個 Web 應用。
客戶端在填寫收件人地址時會通過主機名來標識它希望訪問的伺服器，Tomcat 將從 HTTP 請求頭的 Host 欄位提取主機名，然後再匹配對應的虛擬主機。如果沒有找到匹配的，HTTP 請求將被髮送至預設主機 defaultHost。因此，預設主機不需要是在 DNS 伺服器上註冊的網路名，例如：localhost。在前面配置示例中，Host 的配置如下所示：
<Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true">
其中，屬性 name 指定虛擬主機的名稱。屬性 appBase 指定 Web 應用所在的目錄，預設值是 webapps，這是一個相對路徑，標識 Tomcat 安裝根目錄下的 webapps 資料夾。屬性 unpackWARs 指定是否將 Web 應用的 WAR 檔案解壓。如果取值為 true，Tomcat 將以解壓後的檔案結構執行該 Web 應用；如果為 false，Tomcat 將直接使用 WAR 檔案執行 Web 應用。屬性 autoDeploy 指定是否自動部署 Web 應用。
2.1.6 容器類元件 Context
Context 代表在特定虛擬主機上執行的一個 Web 應用，負責處理某個特定 Web 應用的所有請求。每個 Web 應用要麼基於 WAR 檔案，要麼基於 WAR 檔案解壓後對應的檔案目錄。在前文配置檔案示例中，我們沒有看到 Context 的配置，這是因為 Host 開啟了自動部署，Web 應用沒有在配置檔案中配置靜態部署，而是由 Tomcat 通過特定的規則自動部署，Context 元件也將被自動建立。Context 通過屬性 path 來唯一標識自身。考慮到 Web 應用自動部署與本文主題關係不大，老兵哥我就不再展開，如果你對此內容感興趣，可以找資料做擴充套件閱讀。
2.1.7 內嵌類元素
除了前面介紹的核心元件外，Tomcat 還提供了 Listener、GlobalNamingResources、Realm、Valve 等元件，這些元件都是嵌入到核心元件當中來使用，我們將它們歸為內嵌元件，考慮到不涉及主題就不再贅述。
2.2 Tomcat 處理 HTTP 請求的流程
在前面介紹的各種核心元件基礎上，我們一起來看看，當 HTTP 請求被投遞到 Tomcat 所在主機之後，Tomcat 是如何將 HTTP 請求派發給特定的 Web 應用來處理的：
- 根據協議型別和埠號選定 Service 和 Engine：Service 下屬的 Connector 元件負責監聽接收特定協議和特定埠的請求。因此，當 Tomcat 啟動時，Service 元件就開始監聽特定的埠，如前文配置檔案示例，Catalina 這個 Service 監聽了 HTTP 協議 8080 埠和 AJP 協議的 8009 埠。當 HTTP 請求抵達主機網絡卡的特定埠之後，Tomcat 就會根據協議型別和埠號選定處理請求的 Service，隨即 Engine 也就確定了。通過在 Server 中配置多個 Service，可以實現通過不同埠訪問同一主機上的不同應用。
- 根據域名或 IP 地址選定 Host：待 Service 被選定之後，Tomcat 將在 Service 中尋找與 HTTP 請求頭中指定的域名或 IP 地址匹配的 Host 來處理該請求。如果沒有匹配成功，則採用 Engine 中配置的預設虛擬主機 defaultHost 來處理該請求。
- 根據 URI 選定 Context：URI 中的 context-path 指定了 HTTP 請求將要訪問的 Web 應用。當請求抵達時，Tomcat 將根據 Context 的屬性 path 取值與 URI 中的 context-path 的匹配程度來選擇 Web 應用處理相應請求，例如：Web 應用 spring-demo 的 path 屬性是”/spring-demo”，那麼請求“/spring-demo/user/register”將交由 spring-demo 來處理。
最終，我們還是繼續用向下文這個地址傳送 HTTP 請求為例，將整個處理流程串一遍：
http://201.187.10.21:8080/spring-demo/user/register
- 客戶端（或瀏覽器）傳送請求至主機（201.187.10.21）的埠 8080，被在該埠上監聽的 Coyote HTTP/1.1 Connector 所接收。
- Connector 將該請求交給它所在 Service 的 Engine 來負責處理，並等待 Engine 的迴應。
- Engine 獲得請求之後從報文頭中提取主機名稱（201.187.10.21），在所有虛擬主機 Host 當中尋找匹配。
- 在未匹配到同名虛擬主機的情況下，Engine 將該請求交給名為 localhost 的預設虛擬主機 Host 處理。
- Host 獲得請求之後將根據 URI（/spring-demo/user/register）中的 context-path 的取值“/spring-demo” 去匹配它所擁有的所有 Context，將請求交給代表應用 spring-demo 的 Context 來處理。
- Context 構建 HttpServletRequest、HttpServletResponse 物件，將其作為引數呼叫應用 spring-demo，由應用完成業務邏輯執行、結果資料儲存等過程，等待應答資料。
- Context 接收到應用返回的 HttpServletResponse 物件之後將其返回給 Host。
- Host 將 HttpServletResponse 物件返回給 Engine。
- Engine 將 HttpServletResponse 物件返回 Connector。
- Connector 將 HttpServletResponse 物件返回給客戶端（或瀏覽器）。
2.3 Tomcat 體系結構演進的趨勢剖析
從上述體系結構剖析來看，Tomcat 這款 Java Web 應用伺服器的功能還是非常強大的，它可以在一個例項程序當中同時支援多種協議，同時支援多個虛擬主機，每個虛擬主機下還支援部署多款應用，具備強大的擴充套件性和靈活性。
為什麼它具備這樣一種體系結構呢？這其實跟 Tomcat 誕生時的基礎架構相匹配的，當時伺服器是以小型機或 PC 伺服器為主，缺乏現在容器這種切分資源的虛擬技術，程序是系統資源分配的最小單元。為了更加充分地利用每臺計算機上的資源，我們通常要在同一臺計算機上部署多款應用，但是在一臺計算機上執行多個 Tomcat 例項所帶來的複雜度是非常高的，不如在同一個 Tomcat 例項中部署多款 Web 應用，這樣在配置運維等管理上面更加便利。
在這種架構下，Tomcat 處理 HTTP 請求就需要經過上述複雜的過程，這也再次印證老兵哥我堅信的一個觀點：不存在絕對好或壞的架構，匹配當時業務場景的架構就是好架構！隨著網際網路業務的發展和雲端計算的興起，為了更好地管理大規模應用叢集，我們需要藉助容器等虛擬化技術將大顆粒資源分割成更小的、標準的單元，每個容器中只安裝一個 Web 容器，每個 Web 容器中只部署一個應用，在標裝化下我們就可以採用雲端計算的自動化操作。
按照這個趨勢發展下去，Web 容器的架構用不著這麼複雜了，其價值也會不斷弱化。以前，Tomcat 都是需要單獨安裝的，應用是後續再部署到 Tomcat 當中的。但目前在 Spring Boot 的開發模式下，Tomcat 是以 Starter 方式作為內嵌 Web 容器，它已經不再需要獨立安裝部署了。在越來越標裝化的趨勢下，Tomcat 基本上採用預設配置，使用者基本上不用太關注它了。剖析瞭解它的原因，就是老兵哥我在開題中所說的：知其然，知其所以然。
這個演進過程就像住宅樣式的變遷，古代城市人口密度沒有這麼大，每家每戶都是獨門獨院的平房。隨著近代人口不斷湧入城市，早前住宅的空間利用率太低，無法支撐快速增長的居住需求，這時候高層樓房就應運而生了，每棟樓房都有多個樓層，每個樓層分割成多套房子，每套房子居住一戶家庭，Tomcat 的體系結構就類似這種高層樓房。但現代城市的人口還在不斷增長，早前的高層樓房也無法滿足居住需求了，不夠標準化，缺乏物業管理，周邊配套不全，空間利用率還有待於提高，在這種情況下樓盤小區誕生了，標準化得到了提升，也配套了物業管理，這就類似雲端計算。
本文主要價值是幫助大家梳理出端到端的全流程框架，也就是我們常說的全域性視角或者上帝視角。有了這個框架之後，我們可以根據自己的需要按圖索驥找相關節點的資料來研究學習，不至於陷入細節找不到方向。當然，考慮到我們每個人的工作學習情況不同，平時遇到的問題也不同，本文內容無法覆蓋所有人遇到的問題，歡迎大家留言提問，也歡迎關注我的微信公眾號“IT老兵哥”交流互動，我會盡力盡快解答大家提出的問題，謝謝！
本系列其他文章索引如下：
- 圖解 Spring：HTTP 請求的處理流程與機制【1】
- 圖解 Spring：HTTP 請求的處理流程與機制【3】
- 圖解 Spring：HTTP 請求的處理流程與機制【4】
- 圖解 Spring：HTTP 請求的處理流程與機制【5】