全体的なアーキテクチャ
我々は、我々はすべて知っている、我々は最初、それが何であるかTomcatを理解する必要があり、フレームワークを学びたい、ソケット接続要求を介して治療するために使用されます。Tomcatは、2つの機能を持っています。
-
- 外国処理接続は、あなたがしたいリクエストとレスポンスオブジェクトにバイトストリームを受信します
- 内部処理サーブレットは、対応する要求は、サーブレットへの要求は、対応する配布します
その後、我々は全体的なフレームワーク、Tomcatは実際には二つの部分に分かれて出てきた、一方の部分は、外部接続と内部管理の容器(コンテナ)のためServeletを処理するコネクタ(Connnector)です。
次のように図は、一般的に次のとおりです。
説明:
大型ボックスの最外層は、サービスが複数のTomcatのサービスに対応することができる、Tomcatサービスを表すことです。各サービスは、コネクタおよびコンテナを持っています。
我々はまた、Tomcatのディレクトリに設定ファイルを開くことができ、対応する関係server.xml
それを見て。
< サーバーのポート= "8006" シャットダウン= "SHUTDOWN" > < サービス名= "カタリナ" > < コネクタポート= "8080" プロトコル= "HTTP / 1.1" のConnectionTimeout = "20000" にredirectPort = "8443" /> < コネクタポート= "8010" プロトコル= "AJP / 1.3" にredirectPort = "8443" /> < エンジン名= "カタリナ" のdefaultHost = "localhost"を> < レルムクラス名= "org.apache.catalina.realm.LockOutRealm" > < レルムクラス名= "org.apache.catalina.realm.UserDatabaseRealm" resourceNameは= "でユーザデータベース" /> </ レルム> < ホスト名= "localhost"をのappBase = "webappsに" > </ ホスト> </ エンジン> </ サービス> </ サーバー>
ここでは、実際には、コネクタを見ることができConnector
、サービスは複数のコネクタを持つことができ、コンテナは実際の対応ですEngine
。
Tomcatのの全体的なアーキテクチャとの間のこのような対応は単純です。次に、我々は全体的な構造とコンテナのコネクタの全体的なアーキテクチャをブリーフィング。
コネクタ
我々は、コネクタ上図は、コンテナに渡される確認することができServletRequest
、容器は、コネクタに渡され、オブジェクトServletResponse
ネットワーク転送、伝送ネットワークに送信されるようバイトストリームに確かにないオブジェクト、。
コネクタの機能要件だから我々は以下の点をまとめることができるだろう。
-
- ソケット接続
- ネットワークバイトストリームは、読み出し要求
- (HTTP / AJP)対応のプロトコルに従ってバイトストリームを解析し、統一された発生
TomcatRequest
Tオブジェクトを TomcatReques
パス・コンテナ- コンテナの返却
TomcatResponse
オブジェクト TomcatResponse
オブジェクトは、バイトストリームに変換され、- バイトストリームは、クライアントに返されます
実際には、上記セグメントは、以下の3点に要約することができます。
-
- ネットワーク通信
- 分析アプリケーション層プロトコル
- Tomcatはある オブジェクトの変換
Request/Response
ServletRequest/ServletResponse
また、以下に、それぞれ、対応する上記3つの機能を実現するためのTomcatに3つのクラスが使用されています
-
- 終点
- プロセッサ
- アダプタ
図に示すとの関係はその後、そうです
容器
コンテナは、定義によって物事器具を保持することで、これはTomcatコンテナがそれをインストールし何ですか?実際には、キーは、サーブレットのインストールされています。
その後、コンテナはそれを設計する方法ですか?Tomcatコンテナの設計は、( - 組み合わせたモードを使用すると、デザインパターンの組み合わせは、私の以前の記事は、多くを学ぶことはありません理解していない見ることができます)、実際のデザインパターンの組み合わせです。
実際には、からServer.xml
、我々は彼らの関係を見ることができます。
< エンジン名= "カタリナ" のdefaultHost = "localhost"を> < ホスト名= "localhost"をのappBase = "は、のwebapps" unpackWARs = "true"を自動デプロイ= "true"を</> ホスト> </ エンジン>
その中に、我々は2つのだけのモジュール、1つのトップレベルモジュールの容器を見ることができEngine
、そして他方はHost
、
実際には、2つのモジュールがあります。
一つはContext
、各アプリケーションフォルダ内の当社のWebアプリケーションの対応、各フォルダ1に対応することContext
、
モジュールもありWrapper
、私たちに対応しContext
、すべてのサーブレットでは、Wrapper
特定のサーブレットの持つアクセス対応関係を管理します。この下には、図で表されます。
Tomcatコンテナすべてのモジュールが実装するContainer
インターフェイスが、有意性は組み合わせパターンが均一オブジェクトの単一ユーザ・オブジェクトおよびそれらの組み合わせを使用することです、
即无论添加多少个 Context
其使用就是为了找到其下面的Servlet,而无论添加多少个Host也是为了找个下面的Servlet。
而在容器中设计了这么多的模块,一个请求过来Tomcat如何找到对应的Servlet进行处理呢?
请求如何定位
我们就举个最简单的例子,我们本机应用上启动了一个Tomcat,webapp下有我们部署的一个应用 buxuewushu
。
我们在浏览器上输入 http://localhost:8080/buxuewushu/add.do
是如何找到对应Servlet进行处理呢?
在我们启动Tomcat的时候,连接器就会进行初始化监听所配置的端口号,这里我们配置的是8080端口对应的协议是HTTP。
-
- 请求发送到本机的8080端口,被在那里监听的HTTP/1.1的连接器Connector获得
- 连接器Connector将字节流转换为容器所需要的
ServletRequest
对象给同级Service
下的容器模块Engine进行处理 - Engine获得地址
http://localhost:8080/buxuewushu/add
。匹配他下面的Host主机 - 匹配到名为localhost的Host(就算此时请求为具体的ip,没有配置相应的Host,也会交给名为localhost的Host进行处理,因为他是默认的主机)
- Host匹配到路径为
/buxuewushu
的Context,即在webapp下面找到相应的文件夹 - Context匹配到URL规则为*.do的servlet,对应为某个Servlet类
- 调用其
doGet
或者doPost
方法 - Servlet执行完以后将对象返回给Context
- Context返回给Host
- Host返回给Engine
- Engine返回给连接器Connector
- 连接器Connector将对象解析为字节流发送给客户端