tomcat架构分析(connector BIO 实现)【转】
原文地址：https://www.iteye.com/blog/gearever-1841586
在tomcat架構(gòu)分析(概覽)中已經(jīng)介紹過，connector組件是service容器中的一部分。它主要是接收，解析http請求，然后調(diào)用本service下的相關(guān)servlet。由于tomcat從架構(gòu)上采用的是一個分層結(jié)構(gòu)，因此根據(jù)解析過的http請求，定位到相應的servlet也是一個相對比較復雜的過程。?
?
整個connector實現(xiàn)了從接收socket到調(diào)用servlet的全部過程。先來看一下connector的功能邏輯；?
- 接收socket
- 從socket獲取數(shù)據(jù)包，并解析成HttpServletRequest對象
- 從engine容器開始走調(diào)用流程，經(jīng)過各層valve，最后調(diào)用servlet完成業(yè)務邏輯
- 返回response，關(guān)閉socket
可以看出，整個connector組件是tomcat運行主干，之前介紹的各個模塊都是tomcat啟動時，靜態(tài)創(chuàng)建好的，通過connector將這些模塊串了起來。?
通常在實際運行中，特別是對于一些互聯(lián)網(wǎng)應用而言，網(wǎng)絡(luò)吞吐一直是整個服務的瓶頸所在，因此，connector的運行效率在一定程度上影響了tomcat的整體性能。相對來說，tomcat在處理靜態(tài)頁面方面一直有一些瓶頸，因此通常的服務架構(gòu)都是前端類似nginx的web服務器，后端掛上tomcat作為應用服務器(當然還有些其他原因，例如負載均衡等)。Tomcat在connector的優(yōu)化上做了一些特殊的處理，這些都是可選的，通過部署，配置方便完成，例如APR（Apache Portable Runtime），BIO，NIO等。?
目前connector支持的協(xié)議是HTTP和AJP。AJP是Apache與其他服務器之間的通信協(xié)議。通常在集群環(huán)境中，例如前端web服務器和后端應用服務器或servlet容器，使用AJP會比HTTP有更好的性能，這里引述apache官網(wǎng)上的一段話“ If integration with the native webserver is needed for any reason, an AJP connector will provide faster performance than proxied HTTP. AJP clustering is the most efficient from the Tomcat perspective. It is otherwise functionally equivalent to HTTP clustering.”?
本篇主要是針對HTTP協(xié)議的connector進行闡述。先來看一下connector的配置，在server.xml里；?
熟悉的80端口不必說了。“protocol”這里是指這個connector支持的協(xié)議。針對HTTP協(xié)議而言，這個屬性可以配置的值有：?
- HTTP/1.1
- org.apache.coyote.http11.Http11Protocol –BIO實現(xiàn)
- org.apache.coyote.http11.Http11NioProtocol –NIO實現(xiàn)
- 定制的接口
配置“HTTP/1.1”和“org.apache.coyote.http11.Http11Protocol”的效果是一樣的，因此connector的HTTP協(xié)議實現(xiàn)缺省是支持BIO的。無論是BIO還是NIO都是實現(xiàn)一個org.apache.coyote.ProtocolHandler接口，因此如果需要定制化，也必須實現(xiàn)這個接口。?
本篇就來看看缺省狀態(tài)下HTTP connector的架構(gòu)及其消息流。?
?
可以看見connector中三大塊?
- Http11Protocol
- Mapper
- CoyoteAdapter
Http11Protocol?
類全路徑org.apache.coyote.http11.Http11Protocol，這是支持http的BIO實現(xiàn)。 Http11Protocol包含了JIoEndpoint對象及Http11ConnectionHandler對象。?
Http11ConnectionHandler對象維護了一個Http11Processor對象池，Http11Processor對象會調(diào)用CoyoteAdapter完成http request的解析和分派。?
JIoEndpoint維護了兩個線程池，Acceptor及Worker。Acceptor是接收socket，然后從Worker線程池中找出空閑的線程處理socket，如果worker線程池沒有空閑線程，則Acceptor將阻塞。Worker是典型的線程池實現(xiàn)。Worker線程拿到socket后，就從Http11Processor對象池中獲取Http11Processor對象，進一步處理。除了這個比較基礎(chǔ)的Worker線程池，也可以通過基于java concurrent 系列的java.util.concurrent.ThreadPoolExecutor線程池實現(xiàn)，不過需要在server.xml中配置相應的節(jié)點，即在connector同級別配置<Executor>，配置完后，使用ThreadPoolExecutor與Worker在實現(xiàn)上沒有什么大的區(qū)別，就不贅述了。?
圖中的箭頭代表了消息流。?
Mapper?
類全路徑org.apache.tomcat.util.http.mapper.Mapper，此對象維護了一個從Host到Wrapper的各級容器的快照。它主要是為了，當http request被解析后，能夠?qū)ttp request綁定到相應的servlet進行業(yè)務處理。前面的文章中已經(jīng)說明，在加載各層容器時，會將它們注冊到JMX中。?
?
所以當connector組件啟動的時候，會從JMX中查詢出各層容器，然后再創(chuàng)建這個Mapper對象中的快照。?
CoyoteAdapter?
全路徑org.apache.catalina.connector.CoyoteAdapter，此對象負責將http request解析成HttpServletRequest對象，之后綁定相應的容器，然后從engine開始逐層調(diào)用valve直至該servlet。在session管理中，已經(jīng)說明，根據(jù)request中的jsessionid綁定服務器端的相應session。這個jsessionid按照優(yōu)先級或是從request url中獲取，或是從cookie中獲取，然后再session池中找到相應匹配的session對象，然后將其封裝到HttpServletRequest對象。所有這些都是在CoyoteAdapter中完成的。看一下將request解析為HttpServletRequest對象后，開始調(diào)用servlet的代碼；?
connector的容器就是StandardEngine，代碼的可讀性很強，獲取StandardEngine的pipeline，然后從第一個valve開始調(diào)用邏輯，相應的過程請參照tomcat架構(gòu)分析(valve機制)。
轉(zhuǎn)載于:https://www.cnblogs.com/davidwang456/articles/11452627.html
總結(jié)
以上是生活随笔為你收集整理的tomcat架构分析(connector BIO 实现)【转】的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： tomcat架构分析(概览)【转】
- 下一篇： tomcat架构分析(容器类)【转】