Tomcat 底层实现原理
一、Tomcat运行原理分析
1.Tomcat是运行在JVM中的一个进程。它定义为【中间件】,顾名思义,是一个在Java项目与JVM之间的中间容器。
2.Web项目的本质,是一大堆的资源文件和方法。Web项目没有入口方法(main方法),,意味着Web项目中的方法不会自动运行起来。
3.Web项目部署进Tomcat的webapp中的目的是很明确的,那就是希望Tomcat去调用
写好的方法去为客户端返回需要的资源和数据。
4. Tomcat可以运行起来,并调用写好的方法。那么,Tomcat一定有一个main方法。
5. 对于Tomcat而言,它并不知道我们会有什么样的方法,这些都只是在项目被部署进webapp下后才确定的,由此分析,必然用到了Java的反射来实现类的动态加载、实例化、获取方法、调用方法。但是我们部署到Tomcat的中的Web项目必须是按照规定好的接口来进行编写,以便进行调用
6.Tomcat如何确定调用什么方法呢。这取却于客户端的请求,http://127.0.0.1:8080/JayKing.Tomcat.Study/index.java?show这样的一个请求,通过http协议,在浏览器发往本机的8080端口,携带的参数show方法,包含此方法的路径为JayKing.Tomcat.Study,文件名为:index.java。
二Tomcat顶层架构
此处借鉴 https://blog.csdn.net/u010870518/article/details/79006434
Tomcat中最顶层的容器是Server,代表着整个服务器,从上图中可以看出,一个Server可以包含至少一个Service,用于具体提供服务。
Service主要包含两个部分:Connector和Container。从上图中可以看出 Tomcat 的心脏就是这两个组件,他们的作用如下:
1、Connector用于处理连接相关的事情,并提供Socket与Request和Response相关的转化;
2、Container用于封装和管理Servlet,以及具体处理Request请求;
一个Tomcat中只有一个Server,一个Server可以包含多个Service,一个Service只有一个Container,但是可以有多个Connectors,这是因为一个服务可以有多个连接,如同时提供Http和Https链接,也可以提供向相同协议不同端口的连接,示意图如下(Engine、Host、Context下边会说到)
多个 Connector 和一个 Container 就形成了一个 Service,有了 Service 就可以对外提供服务了,但是 Service 还要一个生存的环境,必须要有人能够给她生命、掌握其生死大权,那就非 Server 莫属了!所以整个 Tomcat 的生命周期由 Server 控制。
三 Tomcat顶层架构小结
(1)Tomcat中只有一个Server,一个Server可以有多个Service,一个Service可以有多个Connector和一个Container;
(2) Server掌管着整个Tomcat的生死大权;
(4)Service 是对外提供服务的;
(5)Connector用于接受请求并将请求封装成Request和Response来具体处理;
(6)Container用于封装和管理Servlet,以及具体处理request请求;
Connector和Container的微妙关系
由上述内容我们大致可以知道一个请求发送到Tomcat之后,首先经过Service然后会交给我们的Connector,Connector用于接收请求并将接收的请求封装为Request和Response来具体处理,Request和Response封装完之后再交由Container进行处理,Container处理完请求之后再返回给Connector,最后在由Connector通过Socket将处理的结果返回给客户端,这样整个请求的就处理完了!
Connector最底层使用的是Socket来进行连接的,Request和Response是按照HTTP协议来封装的,所以Connector同时需要实现TCP/IP协议和HTTP协议!
四 Tomcat原理总结
1. Tomcat需要main方法启动。
2. Tomcat需要监听本机上的某个端口。
3. Tomcat需要抓取此端口上来自客户端的链接并获得请求调用的方法与参数。
4. Tomcat需要根据请求调用的方法,动态地加载方法所在的类,完成累的实例化并通过该实例获得需要的方法最终将请求传入方法执行。
5. 将结果返回给客户端(jsp/html页面、json/xml字符串)。
五 HTTP协议
Java Web 服务器是如何运行的, Web 服务器也称为超文本传输协议( HyperText Transfer Protocol, HTTP)服务器, 因为它使用 Http 与其客户端(通常是 Web 浏览器)进行通信, 基于 Java 的 Web 服务器会使用两个重要的类: java.net.Socket 类和 java.net.ServerSocket 类, 并通过发送 Http 消息进行通信.
-
HTTP协议概述
本文将介绍 Java Web 服务器是如何运行的, Web 服务器也称为超文本传输协议( HyperText Transfer Protocol, HTTP)服务器, 因为它使用 Http 与其客户端(通常是 Web 浏览器)进行通信, 基于 Java 的 Web 服务器会使用两个重要的类: java.net.Socket 类和 java.net.ServerSocket 类, 并通过发送 Http 消息进行通信.
在http中,始终都是客户端发起一个请求,服务器接受到请求之后,然后处理逻辑,处理完成之后再发送响应数据,客户端收到响应数据,然后请求结束。在这个过程中,客户端和服务器都可以对建立的连接进行中断操作。比如可以通过浏览器的停止按钮。
2 http协议-请求
一个http协议的请求包含三部分:
- 请求消息行
-
GET /day08_02/1.html HTTP/1.1
请求方式:Get(默认) POST DELETE HEAD等
GET:明文传输 不安全,数据量有限,不超过1kb
GET /day08_02/1.html?uName=tom&pwd=123 HTTP/1.1
POST: 暗文传输,安全。数据量没有限制。
URI:统一资源标识符。去协议和IP地址。
协议/版本 :
- 请求消息头
-
从第2行到空行处,都叫消息头
Accept:浏览器可接受的MIME类型
告诉服务器客户端能接收什么样类型的文件。
Accept-Charset: 浏览器通过这个头告诉服务器,它支持哪种字符集
Accept-Encoding:浏览器能够进行解码的数据编码方式,比如gzip
Accept-Language:浏览器所希望的语言种类,当服务器能够提供一种以上的语言版本时要用到。 可以在浏览器中进行设置。
Host:初始URL中的主机和端口
Referrer:包含一个URL,用户从该URL代表的页面出发访问当前请求的页面
Content-Type:内容类型
告诉服务器浏览器传输数据的MIME类型,文件传输的类型
application/x-www-form-urlencoded
If-Modified-Since: Wed, 02 Feb 2011 12:04:56 GMT利用这个头与服务器的文件进行比对,如果一致,则从缓存中直接读取文件。
User-Agent:浏览器类型.
Content-Length:表示请求消息正文的长度
Connection:表示是否需要持久连接。如果服务器看到这里的值为“Keep -Alive”,或者看到请求使用的是HTTP 1.1(HTTP 1.1默认进行持久连接
Cookie:这是最重要的请求头信息之一 (在讲会话时解析)
Date:Date: Mon, 22 Aug 2011 01:55:39 GMT请求时间GMT
- 消息正文: 当请求方式是POST方式时,才能看见消息正文
-
uName=tom&pwd=123
3响应部分
- 响应消息行
第一行:
HTTP/1.1 200 OK
协议/版本 响应状态码 对响应码的描述(一切正常)
响应状态码:
常用的就40多个。
200(正常) 一切正常
302/307(临时重定向)
304(未修改)
表示客户机缓存的版本是最新的,客户机可以继续使用它,无需到服务器请求。
404(找不到) 服务器上不存在客户机所请求的资源。
500(服务器内部错误)
- 响应消息头
Location: http://www.it315.org/index.jsp指示新的资源的位置
通常和302/307一起使用,完成请求重定向
Server:apache tomcat指示服务器的类型
Content-Encoding: gzip服务器发送的数据采用的编码类型
Content-Length: 80 告诉浏览器正文的长度
Content-Language: zh-cn服务发送的文本的语言
Content-Type: text/html; charset=GB2312服务器发送的内容的MIME类型
Last-Modified: Tue, 11 Jul 2000 18:23:51 GMT文件的最后修改时间
Refresh: 1;url=http://www.it315.org指示客户端刷新频率。单位是秒
Content-Disposition: attachment; filename=aaa.zip指示客户端下载文件
Set-Cookie:SS=Q0=5Lb_nQ; path=/search服务器端发送的Cookie
Expires: -1
Cache-Control: no-cache (1.1)
Pragma: no-cache (1.0) 表示告诉客户端不要使用缓存
Connection: close/Keep-Alive
Date: Tue, 11 Jul 2000 18:23:51 GMT
- 响应正文
和网页右键“查看源码”看到的内容一样。
六 HTTP与HTTPS的区别
1HTTPS,
全名叫安全的超文本传输协议(HyperText Transfer Protocol Secure),为啥是安全的超文本传输协议呢
其实HTTPS就是在常规的TCP协议层之上加入了一层TLS或者SSL协议。所以其端口也不是常规的HTTP的80端口,变成了443端口
2http与https的区别
1、https协议需要到ca申请证书,一般免费证书较少,因而需要一定费用。
2、http是超文本传输协议,信息是明文传输,https则是具有安全性的ssl加密传输协议。
3、http和https使用的是完全不同的连接方式,用的端口也不一样,前者是80,后者是443。
4、http的连接很简单,是无状态的;HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议,比http协议安全。
3.https的工作流程
1、客户端发起HTTPS请求
这个没什么好说的,就是用户在浏览器里输入一个https网址,然后连接到server的443端口。
2、服务端的配置
采用HTTPS协议的服务器必须要有一套数字证书,可以自己制作,也可以向组织申请,区别就是自己颁发的证书需要客户端验证通过,才可以继续访问,而使用受信任的公司申请的证书则不会弹出提示页面(startssl就是个不错的选择,有1年的免费服务)。这套证书其实就是一对公钥和私钥,如果对公钥和私钥不太理解,可以想象成一把钥匙和一个锁头,只是全世界只有你一个人有这把钥匙,你可以把锁头给别人,别人可以用这个锁把重要的东西锁起来,然后发给你,因为只有你一个人有这把钥匙,所以只有你才能看到被这把锁锁起来的东西。
3、传送证书
这个证书其实就是公钥,只是包含了很多信息,如证书的颁发机构,过期时间等等。
4、客户端解析证书
这部分工作是有客户端的TLS来完成的,首先会验证公钥是否有效,比如颁发机构,过期时间等等,如果发现异常,则会弹出一个警告框,提示证书存在问题。如果证书没有问题,那么就生成一个随机值,然后用证书对该随机值进行加密,就好像上面说的,把随机值用锁头锁起来,这样除非有钥匙,不然看不到被锁住的内容。
5、传送加密信息
这部分传送的是用证书加密后的随机值,目的就是让服务端得到这个随机值,以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。
6、服务段解密信息
服务端用私钥解密后,得到了客户端传过来的随机值(私钥),然后把内容通过该值进行对称加密,所谓对称加密就是,将信息和私钥通过某种算法混合在一起,这样除非知道私钥,不然无法获取内容,而正好客户端和服务端都知道这个私钥,所以只要加密算法够彪悍,私钥够复杂,数据就够安全。
7、传输加密后的信息
这部分信息是服务段用私钥加密后的信息,可以在客户端被还原。
8、客户端解密信息
客户端用之前生成的私钥解密服务段传过来的信息,于是获取了解密后的内容,整个过程第三方即使监听到了数据,也束手无策。