原文地址：https://www.iteye.com/blog/gearever-1841586

在tomcat架構分析(概覽)中已經介紹過，connector組件是service容器中的一部分。它主要是接收，解析http請求，然后調用本service下的相關servlet。由于tomcat從架構上采用的是一個分層結構，因此根據解析過的http請求，定位到相應的servlet也是一個相對比較復雜的過程。?
?
整個connector實現了從接收socket到調用servlet的全部過程。先來看一下connector的功能邏輯；?

• 接收socket
• 從socket獲取數據包，并解析成HttpServletRequest對象
• 從engine容器開始走調用流程，經過各層valve，最后調用servlet完成業務邏輯
• 返回response，關閉socket

可以看出，整個connector組件是tomcat運行主干，之前介紹的各個模塊都是tomcat啟動時，靜態創建好的，通過connector將這些模塊串了起來。?
通常在實際運行中，特別是對于一些互聯網應用而言，網絡吞吐一直是整個服務的瓶頸所在，因此，connector的運行效率在一定程度上影響了tomcat的整體性能。相對來說，tomcat在處理靜態頁面方面一直有一些瓶頸，因此通常的服務架構都是前端類似nginx的web服務器，后端掛上tomcat作為應用服務器(當然還有些其他原因，例如負載均衡等)。Tomcat在connector的優化上做了一些特殊的處理，這些都是可選的，通過部署，配置方便完成，例如APR（Apache Portable Runtime），BIO，NIO等。?
目前connector支持的協議是HTTP和AJP。AJP是Apache與其他服務器之間的通信協議。通常在集群環境中，例如前端web服務器和后端應用服務器或servlet容器，使用AJP會比HTTP有更好的性能，這里引述apache官網上的一段話“ 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協議的connector進行闡述。先來看一下connector的配置，在server.xml里；?

Xml代碼??

<Connector?port="80"?URIEncoding="UTF-8"?protocol="HTTP/1.1"???

???????????????connectionTimeout="20000"???

???????????????redirectPort="7443"?/>??

熟悉的80端口不必說了。“protocol”這里是指這個connector支持的協議。針對HTTP協議而言，這個屬性可以配置的值有：?

• HTTP/1.1
• org.apache.coyote.http11.Http11Protocol –BIO實現
• org.apache.coyote.http11.Http11NioProtocol –NIO實現
• 定制的接口

配置“HTTP/1.1”和“org.apache.coyote.http11.Http11Protocol”的效果是一樣的，因此connector的HTTP協議實現缺省是支持BIO的。無論是BIO還是NIO都是實現一個org.apache.coyote.ProtocolHandler接口，因此如果需要定制化，也必須實現這個接口。?
本篇就來看看缺省狀態下HTTP connector的架構及其消息流。?
?
可以看見connector中三大塊?

• Http11Protocol
• Mapper
• CoyoteAdapter

Http11Protocol?
類全路徑org.apache.coyote.http11.Http11Protocol，這是支持http的BIO實現。 Http11Protocol包含了JIoEndpoint對象及Http11ConnectionHandler對象。?
Http11ConnectionHandler對象維護了一個Http11Processor對象池，Http11Processor對象會調用CoyoteAdapter完成http request的解析和分派。?
JIoEndpoint維護了兩個線程池，Acceptor及Worker。Acceptor是接收socket，然后從Worker線程池中找出空閑的線程處理socket，如果worker線程池沒有空閑線程，則Acceptor將阻塞。Worker是典型的線程池實現。Worker線程拿到socket后，就從Http11Processor對象池中獲取Http11Processor對象，進一步處理。除了這個比較基礎的Worker線程池，也可以通過基于java concurrent 系列的java.util.concurrent.ThreadPoolExecutor線程池實現，不過需要在server.xml中配置相應的節點，即在connector同級別配置<Executor>，配置完后，使用ThreadPoolExecutor與Worker在實現上沒有什么大的區別，就不贅述了。?

Xml代碼??

<Executor?name="tomcatThreadPool"?namePrefix="catalina-exec-"???

????????maxThreads="150"?minSpareThreads="4"/>??

圖中的箭頭代表了消息流。?
Mapper?
類全路徑org.apache.tomcat.util.http.mapper.Mapper，此對象維護了一個從Host到Wrapper的各級容器的快照。它主要是為了，當http request被解析后，能夠將http request綁定到相應的servlet進行業務處理。前面的文章中已經說明，在加載各層容器時，會將它們注冊到JMX中。?
?
所以當connector組件啟動的時候，會從JMX中查詢出各層容器，然后再創建這個Mapper對象中的快照。?
CoyoteAdapter?
全路徑org.apache.catalina.connector.CoyoteAdapter，此對象負責將http request解析成HttpServletRequest對象，之后綁定相應的容器，然后從engine開始逐層調用valve直至該servlet。在session管理中，已經說明，根據request中的jsessionid綁定服務器端的相應session。這個jsessionid按照優先級或是從request url中獲取，或是從cookie中獲取，然后再session池中找到相應匹配的session對象，然后將其封裝到HttpServletRequest對象。所有這些都是在CoyoteAdapter中完成的。看一下將request解析為HttpServletRequest對象后，開始調用servlet的代碼；?

Java代碼??

connector.getContainer().getPipeline().getFirst().invoke(request,?response);??

connector的容器就是StandardEngine，代碼的可讀性很強，獲取StandardEngine的pipeline，然后從第一個valve開始調用邏輯，相應的過程請參照tomcat架構分析(valve機制)。

轉載于:https://www.cnblogs.com/davidwang456/articles/11452627.html

總結

以上是生活随笔為你收集整理的tomcat架构分析(connector BIO 实现)【转】的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。