剖析-1

Bertha 。 2022-03-16 12:05 135阅读 0赞

Method URI Version(/r/n)  
request headers(/r/n)  
(/r/n)  
request body

Version code msg(/r/n)  
response headers(/r/n)  
(/r/n)  
response body

考虑Servlet的 service(ServletRequest req, ServletResponse res)方法，  
1 Request implements ServletRequest , RequestFacade implements ServletRequest，响应同理  
2 HttpRequest implements HttpServletRequest , HttpRequestFacade implements HttpServletRequest，响应同理  
3 Request  
读取输入流  
解析请求行（uri存在查询字符串需要提出，jsessionid若存在需提出）  
解析请求头：特殊处理：content-length, content-type, cookie（需单独解析cookie）  
参数解析：查询字符串中提取，post且content-length大于0且content-type为application/x-www-form-urlencoded时需从请求体提取  
根据uri判断是访问静态资源还是servlet（调用不同processor），访问servlet需要生成类加载器加载servlet类（类名uri传入），调用service方法。

StringManager：错误码- 错误描述的映射  
1 按package区分，每个package一个StringManager，每个package下多个资源文件，StringManager读取哪一个呢？根据服务器语言环境来判别。  
2 输入错误码获取错误描述

http 1.1  
默认持久连接  
分块编码 (响应头Transfer-Encoding: chunked），一般我们用content-length来界定请求或响应边界，但假设我们需要动态生成内容，很难获取内容长度，按照如下格式发送，浏览器就可以在无content-length下识别数据边界了。

HTTP/1.1 200 OK  
Content-Type: text/plain  
Transfer-Encoding: chunked

1C\\r\\n  
and this is the second one\\r\\n

8\\r\\n  
sequence\\r\\n

0\\r\\n  
\\r\\n

状态码100：请求头Expect:100-continue 客户端表明自己要发很长的请求体（Post大量数据），服务端若可以接收返回响应行HTTP/1.1 100 Continue

考虑Connector, （运行在自己的线程，implements Runnable, 不断accept，负责创建且含processor池（stack），取一processor并将socket安全发布给processor所运行线程，继续下一次accept）  
processor（运行在自己的线程，循环：1获取socket，2处理socket，3将自己放回processor池），通过wait notifyAll 获取到socket，(可通过Processor对象的成员变量保存一个socket，然后processor run方法内局部变量指向正在处理的socket)  
connector 线程阻塞：Processor对象的成员变量已有socket，需等待processor处理完当前socket并从成员变量取走socket才可唤醒  
processor 线程阻塞：当前无正在处理的socket，成员变量内也无socket，需connector给成员变量设置一socket才可唤醒  
processor 的设置需从connector（暴露给用户设置）获取  
processor 解析完毕后交给connector.getContainer().invoke(request,response);  
processor 解析：

boolean keepAlive = true;
    	while (!stopped && ok && keepAlive) { // processor实例未被终止，上次解析未出现错误
    	    // 获取输入流，构建和解析请求和响应
    	    // connector.getContainer().invoke(request,response);
    	    keepAlive = false; // 1 http1.0 且请求头未带来Connection： keep-alive 2 http1.1 但是请求头Connection：close
    			                       // 3响应头Connection：close
    	}
    	socket.close();

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2tvYmV4emY_size_16_color_FFFFFF_t_70]

Valve：first，basic（最后一个，一般是StandardXXXValve，多用于调度下一级容器（一般从请求中获取）来处理）  
StandardWrapperValve : 获取Wrapper，wrapper.allocate()获取Servlet，调用Servlet的service方法

Lifecycle( 定义各种eventType ，增加，移除LifecycleListener方法，init,start,stop,destroy方法， 获取LifecycleState方法 )  
LifecycleListener （唯一方法lifecycleEvent(LifecycleEvent event);）  
LifecycleEvent（含Lifecycle, eventType, data）  
LifecycleState （enum，含available和eventType ，如STARTED状态available为true，eventType为AFTER\_START\_EVENT）  
LifecycleBase （Lifecycle的实现，含LifecycleSupport（将Listener相关方法委托给它 ），实现生命周期方法如init等，其子类需实现initInternal等方法，如start内STARTING\_PREP，子类startInternal内STARTING，start内STARTED ）  
LifecycleSupport（含Listener数组，负责Listener相关方法最终调用）

Container扩展自Lifecycle，关联了Logger，Loader，Manager，Cluster，Pipeline，Realm

Loader：  
Context关联的WebappLoader和WebappClassLoader  
为什么Loader，不直接使用AppClassLoader（环境变量CLASSPATH）？1 保护作用，避免servlet能访问所有类，如Catalina ClassLoader所加载类(/server)servlet就不能访问。2 支持自动重载，线程不断检查时间戳看WEB-INF/classes或WEB-INF/lib是否改变  
Loader: classLoader,container, delegete (boolean, 是否优先委托给父类载入器),  
reloadable：设置container时会用context的reloadable设置，当然也可以直接设置  
repository,：loader启动时创建classloader实例并将WEB-INF/classes和WEB-INF/lib设置入classloader，当然也可以手动将其他repository设置入classloader  
modified（委托给classloader的modified方法，检查并返回是否改变）

public void backgroundProcess() { // loader 的后台处理方法   
            if (reloadable && modified()) {
                try {
                    Thread.currentThread().setContextClassLoader
                        (WebappLoader.class.getClassLoader());
                    if (container instanceof StandardContext) {
                        ((StandardContext) container).reload(); // reload 先调用stop后start
                    }
                } finally {
                    if (container.getLoader() != null) {
                        Thread.currentThread().setContextClassLoader
                            (container.getLoader().getClassLoader());
                    }
                }
            } else {
                closeJARs(false);
            }
        }

WebappClassLoader：重写了loadClass  
1 查找本地缓存，根据类名查找ResourceEntry（含Class）的Map  
2 查找ClassLoader自带缓存，native方法  
3 用j2seClassLoader（bootstrap，但问题是bootstrap多为null，那么用extClassLoader）进行加载，防止类似Object类被自定义加载器加载了  
4 确定是否代理（delegete或类的包名以packageTriggers之一开头，即某些类一定要先双亲委托给parent加载）  
5 若代理（双亲委托），先代理给parent，不行再自己加载，若非代理，先自己加载（findClass），不行再代理给parent

container start时可能会开启后台线程，取决于backgroundProcessorDelay（<=0, 不开启由父容器的线程执行自己的后台方法，>0开启）  
后台线程根据backgroundProcessorDelay周期执行自己的或未开启后台线程（<=0）的children的backgroundProcess方法  
backgroundProcess: 一般实现为执行cluster，loader，manager，realm，各valve的backgroundProcess方法

实际情况：一般只有engine有后台线程（代码里设置了backgroundProcessorDelay为10），engine下所有子容器都不开（代码未设置，默认-1，但你可以server.xml 配置）

Manager：Session管理器，与Context关联  
用户通过request获取session，  
Session接口：tomcat内session的功能，含getSession方法返回HttpSession，expire方法  
HttpSession：api规范表明了提供到用户的功能  
StandardSession：实现Session，HttpSession接口，返回StandardSessionFacade给用户，  
Manager：backgroundProcess调用每个session的isValid方法（内部判断是否过期，过期则内部调用expire方法）  
StandardManager: 关闭时(stopInternal调用unload) 将session写入文件SESSIONS.ser，启动时（load）从文件中读取session  
PersistentManagerBase：实现DistributedManager接口，含Store，提供换出（内存中太多了或空闲超过了一定时间，放入Store，内存不放）和备份（session空闲时间超过了一定时间，内存中和Store中都保存），换出和备份都在backgroundProcess中调用，换入在用户查找session或Manager启动时进行。  
PersistentManager: 基本上就是继承PersistentManagerBase  
Store接口：最重要save（session），load（id）  
StoreBase：PersistentManagerBase的backgroundProcess会调用StoreBase的processExpires（查看Store内的session是否过期，并清除过期session，此session若内存中也有也需清除）  
FileStore: 每个session用sessionid.session文件存放，目录可自定，session所含所有对象都需实现Serializable接口（jdk序列化，深复制）  
JDBCStore

Realm: authenticate方法 ，一般和Context对象关联，身份验证，tomcat-user.xml  
RealmBase：  
MemoryRealm：默认实现，第一次调用读取tomcat-user.xml，内含 用户名-Principal的map  
JDBCRealm ,JNDIRealm ,UserDatabaseRealm

Principal  
GenericPrincipal：name，password，roles

LoginConfig：authMethod(basic,digest,form,client-cert), errorPage(form才有，String), loginPage(form才有，String), realmName，web.xml含login-config元素才创建此对象放入Context

Authenticator：authenticate方法  
AuthenticatorBase: 继承ValveBase，因此我们所用的Authenticator都是valve  
BasicAuthenticator  
FormAuthenticator  
DigestAuthenticator  
SSLAuthenticator（对应client-cert）  
NonLoginAuthenticator：auth-method没有设置

context的start方法发出configure\_start事件，ContextConfig（listener）调用authenticatorConfig方法根据LoginConfig的authMethod（来自于login-config元素内的auth-method元素）生成相应的Authenticator加入Pipeline（org/apache/catalina/startup/Authenticators.properties存放authMethod和其相应的Authenticator的className）

request到达Context的Authenticator类型Valve，调用Valve的invoke方法，调用Authenticator的authenticate方法，调用Realm的authenticate方法，不同Authenticator可能用户名密码的获取方式，处理失败的方式不一样。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2tvYmV4emY_size_16_color_FFFFFF_t_70]: /images/20220316/b647bec0df454b049f44e3fa2e72fb41.png