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