圖解Spring：HTTP請求的處理流程與機制【2】

2. HTTP 請求在 Web 容器中的處理流程

Web 容器以進程的方式在計算機上運行，我們知道進程是系統(tǒng)資源分配的最小單元，線程是系統(tǒng)任務執(zhí)行的最小單元。從這個角度看，Web 容器就像是郵包收件人所居住的樓宇或小區(qū)，HTTP 這套物流快遞體系只能將郵包投遞到樓宇前臺或者小區(qū)物業(yè)等處，而樓宇前臺或小區(qū)物業(yè)并不屬于物流快遞體系，就像 Web 容器并不屬于計算機網(wǎng)絡基礎設施一樣。之所以這樣分工，原因是網(wǎng)絡路由信息由域名服務器 DNS、路由器等設備掌握，Web 容器內(nèi)部體系結(jié)構(gòu)信息只有它自己知道。從 Web 容器接收到 HTTP 請求，到將其投送至特定的應用，這期間還會經(jīng)歷一個復雜的過程，了解這個過程對于日常開發(fā)和問題分析都會有所幫助。接下來，老兵哥我將陪著你一起來剖析這個過程。

創(chuàng)新互聯(lián)建站是專業(yè)的二道網(wǎng)站建設公司，二道接單;提供成都做網(wǎng)站、網(wǎng)站建設、外貿(mào)營銷網(wǎng)站建設,網(wǎng)頁設計,網(wǎng)站設計,建網(wǎng)站,PHP網(wǎng)站建設等專業(yè)做網(wǎng)站服務;采用PHP框架,可快速的進行二道網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團隊,希望更多企業(yè)前來合作!

JAVA 語言領(lǐng)域的 Web 容器類型非常多，包括 Tomcat、Jetty、Resin、Websphere、Weblogic、JBoss、Glassfish、GonAS 等，其中 Tomcat 是由 Apache Software Foundation 維護的開源 Web 容器。Tomcat 市場占用率接近 60%，截止目前是最受歡迎的 Web 容器，如下圖所示橫跨 Web 服務器和 Java 應用服務器。
圖解 Spring：HTTP 請求的處理流程與機制【2】
我們就以 Tomcat 為例來看看 Web 容器的內(nèi)部結(jié)構(gòu)，作為符合 JAVA Servlet 標準規(guī)范的容器，Tomcat 是一款基于組件的 Java Web 應用服務器，核心組件都是靈活可配的。Tomcat 最外層是 Catalina Servlet 容器，其他組件是按照特定格式要求配置在這個頂層容器當中，配置文件就是安裝目錄下的：/conf/server.xml。通過這份配置文件，我們就可以了解 Tomcat 的體系結(jié)構(gòu)，示例文件如下所示（快速瀏覽一遍，后面詳細剖析）：

<Server port="8005" shutdown="SHUTDOWN">
  <Listener className="org.apache.catalina.startup.VersionLoggerListener" />
  <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
  <Listener className="org.apache.catalina.core.JasperListener" />
  <Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
  <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
  <Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />

  <GlobalNamingResources>
    <Resource name="UserDatabase" auth="Container"
              type="org.apache.catalina.UserDatabase"
              description="User database that can be updated and saved"
              factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
              pathname="conf/tomcat-users.xml" />
  </GlobalNamingResources>

  <Service name="Catalina">
    <Connector port="8080" protocol="HTTP/1.1" maxThreads=”150″ 
               connectionTimeout="20000"
               redirectPort="8443" />
    <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
    <Connector port=”8443″ maxThreads=”150″ minSpareThreads=”25″ 
               maxSpareThreads=”75″ enableLookups=”false” acceptCount=”100″ 
               debug=”0″ scheme=”https” secure=”true” 
               clientAuth=”false” sslProtocol=”TLS” />
    <Engine name="Catalina" defaultHost="localhost">
      <Realm className="org.apache.catalina.realm.LockOutRealm">
        <Realm className="org.apache.catalina.realm.UserDatabaseRealm"
               resourceName="UserDatabase"/>
      </Realm>

      <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true">
        <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
               prefix="localhost_access_log." suffix=".txt"
               pattern="%h %l %u %t "%r" %s %b" />
      </Host>
    </Engine>
  </Service>
</Server>

2.1 Tomcat 核心組件簡介

如果經(jīng)常使用配置 Tomcat，那么你對上述配置文件一定非常熟悉。為了方便大家理解，結(jié)合本文的主題，我們把上述這份配置文件中的關(guān)鍵節(jié)點提取出來，然后再逐一分析介紹：

<Server>                             ?
    <Service>
        <Connector />
        <Connector />
        <Engine>
            <Host>
                <Context />
            </Host>
        </Engine>        
    </Service>
</Server>

上述結(jié)構(gòu)中包含了 Tomcat 的核心組件：Server 組件在最頂層，代表整個 Tomcat 容器。一個 Server 組件中可以包含一個或多個 Service 組件。Service 在 Connector 和 Engine 外面包了一層，把它們組裝在一起對外提供服務。一個 Service 可以包含多個 Connector，但是只能包含一個 Engine。不同 Connector 負責接收不同端口上相應協(xié)議的請求，而 Engine 負責處理請求。Engine 包含一個或多個 Host，Host 包含一個或多個 Context，Engine、Host、Context 都屬于容器組件，一個 Host 組件代表一個虛擬主機，一個 Context 組件代表在隸屬 Host 上運行的一個 Web 應用。
圖解 Spring：HTTP 請求的處理流程與機制【2】

2.1.1 頂層類組件 Server

它是整個配置文件的唯一根元素，代表整個 Tomcat 容器，內(nèi)部可以包含多個 Service。Server 主要職責就是管理多個 Service，對外提供給客戶端訪問，同時維護所有 Service 的生命周期，包括初始化服務、結(jié)束服務、定位客戶端要訪問的 Service 等等。所有 Tomcat 組件的生命周期都是通過 Lifecycle 接口來控制的，組件只要繼承這個接口并實現(xiàn)其中的方法就可以統(tǒng)一被父組件控制了，這樣層層遞進 Server 組件就可以控制所有組件的生命周期了，而控制 Server 就是通過啟動和關(guān)停 Tomcat。在前面配置示例中，Server 的配置如下所示：

<Server port="8005" shutdown="SHUTDOWN">

其中，屬性 shutdown 指定關(guān)閉 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 負責監(jiān)管其下屬 Connector 所綁定的端口。

2.1.3 連接器組件 Connector

Tomcat 的工作模式可以分為下面兩類：

  • 作為 Web 服務器：請求是直接來自于客戶端 HTTP 請求（或瀏覽器）。
  • 作為 Java Web 應用服務器：請求來自于前置 Web 服務器，通常包括：Apache、IIS、Nginx 等。Tomcat 主要優(yōu)勢是作為 JSP/Servlet 容器，在處理靜態(tài)資源方面效率偏低。因此，它通常要跟 Apache、IIS、Nginx 等 Web 服務器集成使用。AJP 協(xié)議主要負責 Tomcat 和集成 Web 服務器的交互連接。
    圖解 Spring：HTTP 請求的處理流程與機制【2】
    每個 Service 可以有一個或多個 Connector，不同工作模式下，Tomcat 需要為各種類型的請求分別定義相應的 Connector，這樣才能正確接收客戶端對應協(xié)議的請求。定義 Connector 可以使用多種屬性，某些屬性只適用于某種特定的 Connector 類型。一般說來，常見的 Connector 有 4 種類型：HTTP、SSL、AJP、Proxy。
    圖解 Spring：HTTP 請求的處理流程與機制【2】
    作為通信接口，Connector 為其所屬特定的 Service 接收外部客戶端請求，以及回送應答至外部客戶端。具體職責包括創(chuàng)建 Request、Response 對象用于跟外部客戶端交換數(shù)據(jù)，并將 Request 交給配套的 Engine 來處理。通過修改 Connector 的屬性取值，我們可以控制 Service 所監(jiān)聽的網(wǎng)絡協(xié)議及端口號，具體示例如下：
<Connector port="8080" protocol="HTTP/1.1" maxThreads=”150″ 
           connectionTimeout="20000" 
           redirectPort="8443" />
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
<Connector port=”8443″ maxThreads=”150″ minSpareThreads=”25″ 
           maxSpareThreads=”75″ enableLookups=”false” acceptCount=”100″ 
           debug=”0″ scheme=”https” secure=”true” 
           clientAuth=”false” sslProtocol=”TLS” />
  • 配置一，客戶端可以通過 8080 端口號使用 HTTP 協(xié)議訪問 Tomcat。
  • 配置二，客戶端可以通過 8009 端口使用 AJP 協(xié)議訪問 Tomcat。AJP 協(xié)議主要用于跟其他的 HTTP 服務器連接協(xié)作。當 Tomcat 與其他 HTTP 服務器集成時，我們就要用到這個連接器。
  • 配置三，客戶端可以通過 8443 端口號使用 HTTPS 協(xié)議訪問 Tomcat。

連接器的定義可以配置的屬性非常多，下面是常用屬性的說明：

  • address：指定連接器監(jiān)聽的地址，默認為所有地址，即：0.0.0.0。
  • maxThreads：支持最大的并發(fā)連接數(shù)，默認為：200。
  • port：監(jiān)聽端口，默認為：0。
  • protocol：連接器使用的協(xié)議，默認為：HTTP/1.1，定義 AJP 協(xié)議時通常為：AJP/1.3。
  • redirectPort：在強制要求 HTTPS 的情況下，如果請求時 HTTP，則將會被重定向至 8443 端口。
  • connectionTimeout：連接的超時時間，單位為毫秒，默認為 60000，即 1 分鐘；
  • enableLookups：是否通過 request.getRemoteHost() 進行 DNS 查詢以獲取客戶端的主機名。
  • acceptCount：設置等待隊列的最大長度。通常，在 Tomcat 所有處理線程均處于繁忙狀態(tài)時，新請求將被放置于等待隊列中。
2.1.4 容器類組件 Engine

Engine 內(nèi)部可以包含多個 Host，它是 Service 組件中負責請求處理的組件。它從一個或多個 Connector 中接收請求并處理，并將處理結(jié)果封裝成應答交給 Connector，最終回傳給外部客戶端。在前文配置文件示例中，Engine 的配置如下所示：

<Engine name="Catalina" defaultHost="localhost">

其中，屬性 name 用于日志和錯誤信息，其取值在整個 Server 中保證唯一。屬性 defaultHost 指定了默認的Host 名稱，當 HTTP 請求所指定的 Host 名稱不存在時，一律使用 defaultHost 指定的 Host 來處理。因此，defaultHost 的值，必須與 Engine 中的某個 Host 組件的屬性 name 取值匹配。

2.1.5 容器類組件 Host

Host 代表一個虛擬主機，它對應計算機網(wǎng)絡上的一個實體，即某個在 DNS 服務器上注冊過的域名或者 IP 地址，例如：www.abc.com 或 201.187.10.21。Host 內(nèi)部可以包含多個 Context，每個 Context 表示一個 Web 應用。Host 負責安裝、展開、啟動和結(jié)束每個 Web 應用。

客戶端在填寫收件人地址時會通過主機名來標識它希望訪問的服務器，Tomcat 將從 HTTP 請求頭的 Host 字段提取主機名，然后再匹配對應的虛擬主機。如果沒有找到匹配的，HTTP 請求將被發(fā)送至默認主機 defaultHost。因此，默認主機不需要是在 DNS 服務器上注冊的網(wǎng)絡名，例如：localhost。在前面配置示例中，Host 的配置如下所示：

<Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true">

其中，屬性 name 指定虛擬主機的名稱。屬性 appBase 指定 Web 應用所在的目錄，默認值是 webapps，這是一個相對路徑，標識 Tomcat 安裝根目錄下的 webapps 文件夾。屬性 unpackWARs 指定是否將 Web 應用的 WAR 文件解壓。如果取值為 true，Tomcat 將以解壓后的文件結(jié)構(gòu)運行該 Web 應用；如果為 false，Tomcat 將直接使用 WAR 文件運行 Web 應用。屬性 autoDeploy 指定是否自動部署 Web 應用。

2.1.6 容器類組件 Context

Context 代表在特定虛擬主機上運行的一個 Web 應用，負責處理某個特定 Web 應用的所有請求。每個 Web 應用要么基于 WAR 文件，要么基于 WAR 文件解壓后對應的文件目錄。在前文配置文件示例中，我們沒有看到 Context 的配置，這是因為 Host 開啟了自動部署，Web 應用沒有在配置文件中配置靜態(tài)部署，而是由 Tomcat 通過特定的規(guī)則自動部署，Context 組件也將被自動創(chuàng)建。Context 通過屬性 path 來唯一標識自身?？紤]到 Web 應用自動部署與本文主題關(guān)系不大，老兵哥我就不再展開，如果你對此內(nèi)容感興趣，可以找資料做擴展閱讀。

2.1.7 內(nèi)嵌類元素

除了前面介紹的核心組件外，Tomcat 還提供了 Listener、GlobalNamingResources、Realm、Valve 等組件，這些組件都是嵌入到核心組件當中來使用，我們將它們歸為內(nèi)嵌組件，考慮到不涉及主題就不再贅述。

2.2 Tomcat 處理 HTTP 請求的流程

在前面各個章節(jié)介紹的各種核心組件基礎上，我們一起來看看，當 HTTP 請求被投遞到 Tomcat 所在主機之后，Tomcat 是如何將 HTTP 請求派發(fā)給特定的 Web 應用來處理的：

  • 根據(jù)協(xié)議類型和端口號選定 Service 和 Engine：Service 下屬的 Connector 組件負責監(jiān)聽接收特定協(xié)議和特定端口的請求。因此，當 Tomcat 啟動時，Service 組件就開始監(jiān)聽特定的端口，如前文配置文件示例，Catalina 這個 Service 監(jiān)聽了 HTTP 協(xié)議 8080 端口和 AJP 協(xié)議的 8009 端口。當 HTTP 請求抵達主機網(wǎng)卡的特定端口之后，Tomcat 就會根據(jù)協(xié)議類型和端口號選定處理請求的 Service，隨即 Engine 也就確定了。通過在 Server 中配置多個 Service，可以實現(xiàn)通過不同端口訪問同一主機上的不同應用。
  • 根據(jù)域名或 IP 地址選定 Host：待 Service 被選定之后，Tomcat 將在 Service 中尋找與 HTTP 請求頭中指定的域名或 IP 地址匹配的 Host 來處理該請求。如果沒有匹配成功，則采用 Engine 中配置的默認虛擬主機 defaultHost 來處理該請求。
  • 根據(jù) URI 選定 Context：URI 中的 context-path 指定了 HTTP 請求將要訪問的 Web 應用。當請求抵達時，Tomcat 將根據(jù) Context 的屬性 path 取值與 URI 中的 context-path 的匹配程度來選擇 Web 應用處理相應請求，例如：Web 應用 spring-demo 的 path 屬性是”/spring-demo”，那么請求“/spring-demo/user/register”將交由 spring-demo 來處理。
    圖解 Spring：HTTP 請求的處理流程與機制【2】
    最終，我們還是繼續(xù)用向下文這個地址發(fā)送 HTTP 請求為例，將整個處理流程串一遍：

http://201.187.10.21:8080/spring-demo/user/register

  1. 客戶端（或瀏覽器）發(fā)送請求至主機（201.187.10.21）的端口 8080，被在該端口上監(jiān)聽的 Coyote HTTP/1.1 Connector 所接收。
  2. Connector 將該請求交給它所在 Service 的 Engine 來負責處理，并等待 Engine 的回應。
  3. Engine 獲得請求之后從報文頭中提取主機名稱（201.187.10.21），在所有虛擬主機 Host 當中尋找匹配。
  4. 在未匹配到同名虛擬主機的情況下，Engine 將該請求交給名為 localhost 的默認虛擬主機 Host 處理。
  5. Host 獲得請求之后將根據(jù) URI（/spring-demo/user/register）中的 context-path 的取值“/spring-demo” 去匹配它所擁有的所有 Context，將請求交給代表應用 spring-demo 的 Context 來處理。
  6. Context 構(gòu)建 HttpServletRequest、HttpServletResponse 對象，將其作為參數(shù)調(diào)用應用 spring-demo，由應用完成業(yè)務邏輯執(zhí)行、結(jié)果數(shù)據(jù)存儲等過程，等待應答數(shù)據(jù)。
  7. Context 接收到應用返回的 HttpServletResponse 對象之后將其返回給 Host。
  8. Host 將 HttpServletResponse 對象返回給 Engine。
  9. Engine 將 HttpServletResponse 對象返回 Connector。
  10. Connector 將 HttpServletResponse 對象返回給客戶端（或瀏覽器）。

2.3 Tomcat 體系結(jié)構(gòu)演進的趨勢剖析

從上述體系結(jié)構(gòu)剖析來看，Tomcat 這款 Java Web 應用服務器的功能還是非常強大的，它可以在一個實例進程當中同時支持多種協(xié)議，同時支持多個虛擬主機，每個虛擬主機下還支持部署多款應用，具備強大的擴展性和靈活性。為什么它具備這樣一種體系結(jié)構(gòu)呢？這其實跟 Tomcat 誕生時的基礎架構(gòu)相匹配的，當時服務器是以小型機或 PC 服務器為主，缺乏現(xiàn)在容器這種切分資源的虛擬技術(shù)，進程是系統(tǒng)資源分配的最小單元。為了更加充分地利用每臺計算機上的資源，我們通常要在同一臺計算機上部署多款應用，但是在一臺計算機上運行多個 Tomcat 實例所帶來的復雜度是非常高的，不如在同一個 Tomcat 實例中部署多款 Web 應用，這樣在配置運維等管理上面更加便利。

在這種架構(gòu)下，Tomcat 處理 HTTP 請求就需要經(jīng)過上述復雜的過程，這也再次印證老兵哥我堅信的一個觀點：不存在絕對好或壞的架構(gòu)，匹配當時業(yè)務場景的架構(gòu)就是好架構(gòu)！隨著互聯(lián)網(wǎng)業(yè)務的發(fā)展和云計算的興起，為了更好地管理大規(guī)模應用集群，我們需要借助容器等虛擬化技術(shù)將大顆粒資源分割成更小的、標準的單元，每個容器中只安裝一個 Web 容器，每個 Web 容器中只部署一個應用，在標裝化下我們就可以采用云計算的自動化操作。

按照這個趨勢發(fā)展下去，Web 容器的架構(gòu)用不著這么復雜了，其價值也會不斷弱化。以前，Tomcat 都是需要單獨安裝的，應用是后續(xù)再部署到 Tomcat 當中的。但目前在 Spring Boot 的開發(fā)模式下，Tomcat 是以 Starter 方式作為內(nèi)嵌 Web 容器，它已經(jīng)不再需要獨立安裝部署了。在越來越標裝化的趨勢下，Tomcat 基本上采用默認配置，用戶基本上不用太關(guān)注它了。剖析了解它的原因，就是老兵哥我在開題中所說的：知其然，知其所以然。

這個演進過程就像住宅樣式的變遷，古代城市人口密度沒有這么大，每家每戶都是獨門獨院的平房。隨著近代人口不斷涌入城市，早前住宅的空間利用率太低，無法支撐快速增長的居住需求，這時候高層樓房就應運而生了，每棟樓房都有多個樓層，每個樓層分割成多套房子，每套房子居住一戶家庭，Tomcat 的體系結(jié)構(gòu)就類似這種高層樓房。但現(xiàn)代城市的人口還在不斷增長，早前的高層樓房也無法滿足居住需求了，不夠標準化，缺乏物業(yè)管理，周邊配套不全，空間利用率還有待于提高，在這種情況下樓盤小區(qū)誕生了，標準化得到了提升，也配套了物業(yè)管理，這就類似云計算。

本文主要價值是幫助大家梳理出端到端的全流程框架，也就是我們常說的全局視角或者上帝視角。有了這個框架之后，我們可以根據(jù)自己的需要按圖索驥找相關(guān)節(jié)點的資料來研究學習，不至于陷入細節(jié)找不到方向。當然，考慮到我們每個人的工作學習情況不同，平時遇到的問題也不同，本文內(nèi)容無法覆蓋所有人遇到的問題，歡迎大家留言提問，也歡迎關(guān)注我的博客或公號“IT老兵哥”交流互動，我會盡力盡快解答大家提出的問題，謝謝！

本系列其他文章索引如下：

  • 圖解 Spring：HTTP 請求的處理流程與機制【1】
  • 圖解 Spring：HTTP 請求的處理流程與機制【3】
  • 圖解 Spring：HTTP 請求的處理流程與機制【4】
  • 圖解 Spring：HTTP 請求的處理流程與機制【5】

本文標題：圖解Spring：HTTP請求的處理流程與機制【2】
文章網(wǎng)址：http://www.muchs.cn/article26/jiohcg.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供微信小程序、域名注冊、全網(wǎng)營銷推廣、做網(wǎng)站、App開發(fā)、小程序開發(fā)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)

網(wǎng)站優(yōu)化排名