Tomcat處理HTTP請求源碼分析（上）

fmms 12年前發布 | 71K 次閱讀 Tomcat 應用服務器

很多開源應用服務器都是集成tomcat作為web container的，而且對于tomcat的servlet container這部分代碼很少改動。這樣，這些應用服務器的性能基本上就取決于Tomcat處理HTTP請求的connector模塊的性能。本文首先從應用層次分析了tomcat所有的connector種類及用法，接著從架構上分析了connector模塊在整個tomcat中所處的位置，最后對 connector做了詳細的源代碼分析。并且我們以Http11NioProtocol為例詳細說明了tomcat是如何通過實現 ProtocolHandler接口而構建connector的。

1 Connector介紹

1.1 Connector的種類

Tomcat源碼中與connector相關的類位于org.apache.coyote包中，Connector分為以下幾類：

Http Connector, 基于HTTP協議，負責建立HTTP連接。它又分為BIO Http Connector與NIO Http Connector兩種，后者提供非阻塞IO與長連接Comet支持。
AJP Connector, 基于AJP協議，AJP是專門設計用來為tomcat與http服務器之間通信專門定制的協議，能提供較高的通信速度和效率。如與Apache服務器集成時，采用這個協議。
APR HTTP Connector, 用C實現，通過JNI調用的。主要提升對靜態資源（如HTML、圖片、CSS、JS等）的訪問性能。現在這個庫已獨立出來可用在任何項目中。Tomcat在配置APR之后性能非常強勁。

1.2 Connector的配置

對Connector的配置位于conf/server.xml文件中。

1.2.1 BIO HTTP/1.1 Connector配置

一個典型的配置如下：





   




    HTTP/1.1” maxThreads=”150” 
connectionTimeout=”20000” redirectPort=”8443”

其它一些重要屬性如下：

acceptCount : 接受連接request的最大連接數目，默認值是10
address : 綁定IP地址，如果不綁定，默認將綁定任何IP地址
allowTrace : 如果是true,將允許TRACE HTTP方法
compressibleMimeTypes : 各個mimeType, 以逗號分隔，如text/html,text/xml
compression : 如果帶寬有限的話，可以用GZIP壓縮
connectionTimeout : 超時時間，默認為60000ms (60s)
maxKeepAliveRequest : 默認值是100
maxThreads : 處理請求的Connector的線程數目，默認值為200

如果是SSL配置，如下：





   




    keystoreFile="E:/java/jonas-full-5.1.0-RC3/conf/keystore.jks" 





    keystorePass="changeit" />

其中，keystoreFile為證書位置，keystorePass為證書密碼

1.2.2 NIO HTTP/1.1 Connector配置





   




    org.apache.coyote.http11.Http11NioProtocol” 
    maxThreads=”150” connectionTimeout=”20000” redirectPort=”8443”

1.2.3 Native APR Connector配置

ARP是用C/C++寫的，對靜態資源（HTML，圖片等）進行了優化。所以要下載本地庫
tcnative-1.dll與openssl.exe，將其放在%tomcat%\bin目錄下。

下載地址是：http://tomcat.heanet.ie/native/1.1.10/binaries/win32/
在server.xml中要配置一個Listener,如下圖。這個配置tomcat是默認配好的。
```
      




      




     
```

配置使用APR connector





     




      org.apache.coyote.http11.Http11AprProtocol” 




      maxThreads=”150” connectionTimeout=”20000” redirectPort=”8443”
 </connector></pre></li> 

如果配置成功，啟動tomcat,會看到如下信息： org.apache.coyote.http11.Http11AprProtocol init  
  </ol> 
  2 Connector在Tomcat中所處的位置 
  2.1 Tomcat架構 
   
  圖2-1 Tomcat架構  
   
   Server(服務器)是Tomcat構成的頂級構成元素，所有一切均包含在Server中，Server的實現類StandardServer可以包含一個到多個Services; 
   次頂級元素Service的實現類為StandardService調用了容器(Container)接口，其實是調用了Servlet Engine(引擎)，而且StandardService類中也指明了該Service歸屬的Server； 
   接下來次級的構成元素就是容器(Container)，主機(Host)、上下文(Context)和引擎(Engine)均繼承自 Container接口，所以它們都是容器。但是，它們是有父子關系的，在主機(Host)、上下文(Context)和引擎(Engine)這三類容器 中，引擎是頂級容器，直接包含是主機容器，而主機容器又包含上下文容器，所以引擎、主機和上下文從大小上來說又構成父子關系，雖然它們都繼承自 Container接口。 
   連接器(Connector)將Service和Container連接起來，首先它需要注冊到一個Service，它的作用就是把來自客戶端的請求轉發到Container(容器)，這就是它為什么稱作連接器的原因。 
   
  故我們從功能的角度將Tomcat源代碼分成5個子模塊，它們分別是： 
   
   Jsper子模塊：這個子模塊負責jsp頁面的解析、jsp屬性的驗證，同時也負責將jsp頁面動態轉換為java代碼并編譯成class文件。在Tomcat源代碼中，凡是屬于org.apache.jasper包及其子包中的源代碼都屬于這個子模塊； 
   Servlet和Jsp規范的實現模塊：這個子模塊的源代碼屬于javax.servlet包及其子包，如我們非常熟悉的 javax.servlet.Servlet接口、javax.servet.http.HttpServlet類及 javax.servlet.jsp.HttpJspPage就位于這個子模塊中； 
   Catalina子模塊：這個子模塊包含了所有以org.apache.catalina開頭的java源代碼。該子模塊的任務是規范了 Tomcat的總體架構，定義了Server、Service、Host、Connector、Context、Session及Cluster等關鍵組 件及這些組件的實現，這個子模塊大量運用了Composite設計模式。同時也規范了Catalina的啟動及停止等事件的執行流程。從代碼閱讀的角度 看，這個子模塊應該是我們閱讀和學習的重點。 
   Connectors子模塊：如果說上面三個子模塊實現了Tomcat應用服務器的話，那么這個子模塊就是Web服務器的實現。所謂連接 器(Connector)就是一個連接客戶和應用服務器的橋梁，它接收用戶的請求，并把用戶請求包裝成標準的Http請求(包含協議名稱，請求頭 Head，請求方法是Get還是Post等等)。同時，這個子模塊還按照標準的Http協議，負責給客戶端發送響應頁面，比如在請求頁面未發現 時，connector就會給客戶端瀏覽器發送標準的Http 404錯誤響應頁面。 
   Resource子模塊：這個子模塊包含一些資源文件，如Server.xml及Web.xml配置文件。嚴格說來，這個子模塊不包含java源代碼，但是它還是Tomcat編譯運行所必需的。 
   
  2.2 Tomcat運行流程 
   
  圖2-2 tomcat運行流程  
  假設來自客戶的請求為：http://localhost:8080/test/index.jsp 
   
   請求被發送到本機端口8080，被在那里偵聽的Coyote HTTP/1.1 Connector獲得 
   Connector把該請求交給它所在的Service的Engine來處理，并等待Engine的回應 
   Engine獲得請求localhost:8080/test/index.jsp，匹配它所有虛擬主機Host 
   Engine匹配到名為localhost的Host（即使匹配不到也把請求交給該Host處理，因為該Host被定義為該Engine的默認主機） 
   localhost Host獲得請求/test/index.jsp，匹配它所擁有的所有Context 
   Host匹配到路徑為/test的Context（如果匹配不到就把該請求交給路徑名為""的Context去處理） 
   path="/test"的Context獲得請求/index.jsp，在它的mapping table中尋找對應的servlet 
   Context匹配到URL PATTERN為*.jsp的servlet，對應于JspServlet類 
   構造HttpServletRequest對象和HttpServletResponse對象，作為參數調用JspServlet的doGet或doPost方法 
   Context把執行完了之后的HttpServletResponse對象返回給Host 
   Host把HttpServletResponse對象返回給Engine 
   Engine把HttpServletResponse對象返回給Connector 
   Connector把HttpServletResponse對象返回給客戶browser 
   
  3 Connector源碼分析 
  3.1 Tomcat的啟動分析與集成設想 
  我們知道，啟動tomcat有兩種方式： 
   
   雙擊bin/startup.bat 
   運行bin/catalina.bat run 
   
  它們對應于Bootstrap與Catalina兩個類，我們現在只關心Catalina這個類，這個類使用Apache Digester解析conf/server.xml文件生成tomcat組件，然后再調用Embedded類的start方法啟動tomcat。 
  所以，集成Tomcat的方式就有以下兩種了： 
   
   沿用tomcat自身的server.xml 
   自己定義一個xml格式來配置tocmat的各參數，自己再寫解析這段xml，然后使用tomcat提供的API根據這些xml來生成Tomcat組件，最后調用Embedded類的start方法啟動tomcat 
   
  個人覺得第一種方式要優越，給開發者比較好的用戶體驗，如果使用這種，直接模仿Catalina類的方法即可實現集成。 
  目前，JOnAS就使用了這種集成方式，JBoss、GlassFish使用的第二種自定義XML的方式。 
  3.2 Connector類圖與順序圖 
   
  圖3-1 Connector相關類圖  
   
  圖3-2 Connector工作流程順序圖  
  從上面二圖中我們可以得到如下信息： 
   
   Tomcat中有四種容器(Context、Engine、Host、Wrapper)，前三者常見，第四個不常見但它也是實現了Container接口的容器 
   如果要自定義一個Connector的話，只需要實現ProtocolHander接口,該接口定義如下： 
   
   
  圖3-3 自定義connector時需實現的ProtocolHandler接口  
  Tomcat以HTTP（包括BIO與NIO）、AJP、APR、內存四種協議實現了該接口（它們分別是：AjpAprProtocol、 AjpProtocol、Http11AprProtocol、Http11NioProtocol、Http11Protocal、 JkCoyoteHandler、MemoryProtocolHandler），要使用哪種Connector就在conf/server.xml中配 置，在Connector的構造函數中會通過反射實例化所配置的實現類： 
  
    




</connector></pre> 
  
3.3 Connector的工作流程 
  下面我們以Http11AprProtocol為例說明Connector的工作流程。 
   
   它將工作委托給NioEndpoint類。在NioEndpoint類的init方法中構建一個SocketServer(當然，不同的實現類會有一些微小的變化，例如如果是NIO，它構建的就是SocketServerChannel) 
   在NioEndpoint.Acceptor類中會接收一個客戶端新的連接請求，如下圖： 
  
   在NioEndpoint類中，有一個內部接口Handle，該接口定義如下： 
  
   在Http11NioProtocol類中實現了Handle這個內部接口，并調用Http11NioProcessor類(該類實現了 ActionHook回調接口)。在Response類中會調用ActionHook實現類的相關方法的，Response類的action方法如下： 
  
   Http11NioProcessor的process實現方法中，會通過Adapter來調用Servler容器生成響應結果。 
   
  關于作者 
  張華，長期從事Java方面的開發工作，有搜索引擎、中間件應用服務器、互聯網、云計算等領域的行業經驗，目前正在從事基于Power的虛擬化技術研發。博客地址：http://blog.csdn.net/quqi99