1.要求プロセス
多層容器ように設計、Tomcatは、各要求は、サーブレット・アップによって処理された容器をラッパーべきかを決定する方法は？マッパー成分とTomcatは、このタスクを完了します。
機能マッパーコンポーネントは、ユーザーのリクエストURLがサーブレットを探している場合、その動作原理は次のとおりです。Webアプリケーションの構成情報を保存中マッパーコンポーネント、実際には、そのようなドメイン名ホストコンテナ設定などコンテナコンポーネントおよびアクセス・パスとの間のマッピング関係、 Webアプリケーションのコンテキスト・コンテナは、構成情報は、多層マップとして理解することができ、パスとパスラッパー容器サーブレットマッピングを設定します。
リクエストが来ると、解像度によってマッパーコンポーネントは、ドメイン名とパスのURLを要求し、その後、自分のを探しに行くために地図を保存し、サーブレットに見つけることができるようになります。これは、ことは注目に値する、リクエストがサーブレットでURLのみラッパーのコンテナを、見つけることです。
アプリケーションレベルの分析プロセスから1.1の要求
ユーザーがブラウザにURLを入力します。http：// localhost：Tomcatの中に8080 / servlet_demo01 /掲示板/ findAllの要求プロセス
コネクタを介して1コネクタの要求
server.xml構成ファイルでは、コネクタポートは8080をリッスンしてあります
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />2.コネクタ対応サービス/エンジンを見つけるに
エンジン下のエンジンでは、コネクタは、デフォルトのホストアドレスを持ってそこに設定
<Engine name="Catalina" defaultHost="localhost">name属性の値は、ホストのローカルホストノードを指します。
3.エンジンの複数のエンジンを見ホストは、ホストです。ホストが仮想サイトの同等であり、我々はホストのアドレスを設定するには、ホストの時間を設定することができます。
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true">4.のappBaseは、リクエストパスの適用下で名付けservlet_demo01（コンテキスト）を見つけるために、Webアプリケーションに入りますホストの経路に配置されました
/ BBS後ろ経路における特定の用途の位置決め後、5 /のfindAll（ラッパー）、web.xml構成に、ターゲット特定サーブレット
図タイミング解決要求流量1.2
1.アクセプタコネクタアセンブリのソケットクライアントが接続されている耳を傾け、エンドポイントのソケットを受けます
スレッドプールエグゼキュータ・プロセスへ2. Connectには、要求タスクに応じて開始しました。
前記プロセッサコンポーネントは、メッセージ、パケット、ライン解像度リクエスト、リクエストボディ、リクエストヘッダ、カプセル化された要求オブジェクトを読み出します
リクエストラインとホスト要求のヘッダのURLに基づいて、前記マッパー成分値の値と一致するホストコンテナ、コンテキスト容器、ラッパーコンテナ処理要求によって
5. coyoteAdaptor成分は、パイプラインを呼び出して、送信された応答エンジン容器に応答して、責任と関連するコンポーネントコネクタエンジン容器、生成された要求オブジェクトとオブジェクトです。
導管6エンジンは、容器、値の複数を含むパイプライン処理を開始処理ロジック値の一部を担うそれぞれ、基本値の実行値行った後 - StandardEngineValueを、容器ホストパイプラインを呼び出すための責任があります
7.ホスト・パイプラインは、容器、同様のプロセス、最終的な実装コネクタ容器パイプライン処理を開始します
8.コネクタパイプライン処理容器、同様のプロセス、及び最終的に容器パイプライン実行ラッパーを開始
ラッパーは、プロセスに類似した容器を、処理9スタート導管、及び最終的にラッパーに対応する方法サーブレットコンテナオブジェクトの処理を行います。
ソースコードレベルから1.3解決要求フロー
私たちは、その後、どのようにソースコードにTomcatにデプロイすることができ、ソースコードへのアクセスTOMCATデバッグするために、ソースに私たちのプロジェクトを展開する必要がありますか？
図：我々は唯一のソースパッケージの次のホーム/ webappsににプロジェクトをコピーする必要があります
次に、ブートストラップ、デバッグモードでは、Tomcatのソースプログラムを再起動して見つけます。
注：Firefoxブラウザ、一度サイトは、アイコンを要求されると、HTTPリクエストは二回、リソース要求たら、そのためにはGoogle Chromeを使用して私たちの要求の追跡プロセスを助長されていません送信しますので。
要求フローダイアグラム：
1. 在浏览器输入连接，回车之后，程序首先经过NioEndpoind，接收浏览器的请求
2. 接收到请求之后，进行请求的处理
3. 然后将连接交给线程池Executor处理，开始执行请求响应任务
3.1 获取Processor对象
3.2 然后调用Processor的process方法
4. 将浏览器的请求解析成Request与Response对象
5. 解析完成之后，调用adaptor对象中的service方法，将request与response对象传递过去
这个是adaptor就是coyoteAdaptor
6. 调用容器并执行
7. 进入StandardEngineValve，拿到Host主机
8. host再获取管道，调用StandardHostValve
9. 进去StandardHostValve，拿到Context
10. context再获取管道，调用StandardContextValve
11. 进去StandardContextValve，拿到Wrapper，并获取管道，调用StandardWrapperValve
12. 然后在StandardWrapperValve中有Servlet的初始化与赋值
因为，Wrapper中封装的就是Servlet
13. 接着将Servlet封装到过滤器类中
14. 执行过滤器
15. 执行Servlet的service方法
注意：这里的servlet就是请求的Servlet对象
总结：
tomcat中的各个组件各司其职，组件之间松耦合，确保了整体架构的可伸缩性和可扩展性，那么在组件内部，如何增强组件的灵活性和扩展性了？在tomcat中，每个Catalina组件采用责任链来完成具体的请求处理。
在Tomcat中定了Pipeline和Valve两个接口，Pipeline用于构建责任链，后者代表责任链上的每个处理器，Pipeline中维护了一个基础的Valve，它始终位于Pipeline的末端（最后执行），封装了具体的请求处理和输出响应的过程。当然，我们也可以调用addValve()方法，为Pipeline添加其他的Valve，后添加的Valve位于基础的Valve之前，并按照添加顺序执行。Pipeline通过获取首个Valve来启动整个链条的执行。
tomcat的请求可以解析为两部分，一部分是Connector的请求解析，交给CoyoteAdaptor，将路径映射，在交给后面的Catalina容器去处理。
