擅长篮球、跑步、游泳、羽毛球、编程、看书、写书的顾家好男人! Java深度、大数据、中间件、搜索引擎、机器学习、深度学习、Python、C++、开源! 《Tomcat内核设计剖析》作者。
继《如何设计开发一个可用的web容器》之后又一如何系列文章,《如何设计一个数据库中间件》 ==========广告时间========== 鄙人的新书《Tomcat内核设计剖析》已经在京东预售了,有需要的朋友可以到 https://item.jd.com/12185360.html 进行预定。
如今web服务随处可见,成千上万的web程序被部署到公网上供用户访问,有些系统只针对指定用户开放,属于安全级别较高的web应用,他们需要有一种认证机制以保护系统资源的安全,本文将探讨五种常用的认证机制及优缺点。
一般的过程:①如果还没有库先用 git clone 克隆一个库。②使用 git checkout master切换到master分支。③使用 git pull 同步远程master分支(即git fetch + git merge,可用git pull -rebase避免merge垃圾提交信息)。
Web服务器与浏览器之间的认证流程没有规定的步骤,根据不同的认证模式及鉴权方式可能会有不同的执行步骤。下图用一个最简单的流程了解整个认证过程是如何工作的,首先浏览器向服务器发起请求,然后服务器向浏览器质问用户名及密码,浏览器带上用户名及密码重新请求,服务器根据用户名获取相应角色并判断是否有权限访问该资源,最后通过认证后返回受保护资源。
Realm域,其实可以看成是一个包含了用户及密码的数据库,而且每个用户还会包含了若干角色。也就是包含了用户名、密码、角色三个列的数据记录集合,如下图,最下面椭圆内的包含的整块即可以看成realm域。
在了解了认证模式及Realm域后,我们看看Tomcat是如何设计实现资源安全管理的。在认证模式上,必须要支持多种认证模式,包括Basic模式、Digest模式、Form模式、Spnego模式、SSL模式及NonLogin模式。
大多数Web系统都有权限需求,前面已经了解了它的整个认证过程的原理,这节将讲述如何在Tomcat中配置web资源的权限。先以Tomcat默认的认证模式Basic和默认的域UserDatabaseRealm为例,看看如何完成整个配置的。
SSL模式是基于SSL通信的一种认证模式,使用它的前提是浏览器和web服务器之间必须使用https协议,因为它必须走SSL协议通道才能完成认证流程。它的大体流程是这样的:客户端与服务器之间通过SSL协议建立起SSL通道,这个过程比较复杂,涉及到客户端服务端证书互相交互验证,协商通信密钥等过程,细节可以前往SSL章节阅读。
Spnego模式是一种由微软提出的使用GSS-API接口的认证模式,它扩展了Kerberos协议,在了解Spnego协议之前必须先了解Kerberos协议,Kerberos协议主要解决身份认证及通信密钥协商问题,它大致的工作流程如下: ①客户端根据自己用户名向密钥分发中心KDC的身份认证服务AS请求TGS票证。
上面介绍的两种模式都属于HTTP协议规范范畴,由于它的规范使得很多东西无法自定义,例如登录窗口、错误展示页面。所以需要另外一种模式提供更加灵活的认证,也就是基于Form的认证模式。
TTP协议规范的另一种认证模式是Digest模式,在HTTP1.1时被提出来,它主要是为了解决Basic模式安全问题,用于替代原来的Basic认证模式,Digest认证也是采用challenge/response认证模式,基本的认证流程比较类似,整个过程如下: ①浏览器发送http报文请求一个受保护的资源。
HTTP协议规范中有两种认证方式,一种是Basic认证,另外一种是Digest认证,这两种方式都属于无状态认证方式,所谓无状态即服务端都不会在会话中记录相关信息,客户端每次访问都需要将用户名和密码放置报文一同发送给服务端,但这并不表示你在浏览器中每次访问都要自己输入用户名和密码,可能是你第一次输入账号后浏览器就保留在内存中供后面的交互使用。
总的来说,Jasper的自动检测实现的机制比较简单,依靠某后台线程不断检测JSP文件与编译后的class文件的最后修改时间是否相同,若相同则认为没有改动,但倘若不同则需要重新编译。
通过JSP编译器编译后生成了对应的java文件,接下去要把Java文件编译成class文件。对于这部分完全没有必要重新造轮子,常见的优秀编译工具有Eclipse JDT Java编译器和Ant编译器。
我们知道java虚拟机只认识class文件,要在虚拟机上运行就必须要遵守class文件格式,所以JSP编译成servlet后还需要进一步编译成class文件,但从JSP文件到java文件再到class文件的过程需要考虑的事情比较多,其中一个比较重要的就是调试问题,由于语法不一样,jsp某行执行的逻辑怎样与java文件对应起来,这样在JVM执行过程发生异常或错误才能找到JSP对应的行,提供一个友好的调试信息。
JSP编译后的Servlet类会是怎样的呢?他们之间有着什么样的映射关系?在探讨JSP与Servlet之间的关系时先看一个简单的HelloWorld.jsp编译成HelloWorld.java后会是什么样。
语法树可以理解成是一种数据结构,假如某些语句已经被解析成一棵语法树,那么接下来就是要对此语法树进行处理,但考虑到不将处理操作与数据结构混合在一块,我们需要一种方法将其分离。
一般来说,语句按一定规则进行推导后会形成一个语法树,这种树状结构有利于对语句结构层次的描述。同样Jasper对JSP语法解析后也会生成一棵树,这棵树各个节点包含了不同的信息,但对于JSP来说解析后的语法树比较简单,只有一个父节点和n个子节点。
开发一个web容器涉及很多不同方面不同层面的技术,例如通信层的知识,程序语言层面的知识等等,且一个可用的web容器是一个比较庞大的系统,要说清楚需要很长的篇幅,本文旨在介绍如何设计一个web容器,只探讨实现的思路,并不涉及过多的具体实现。
基本情况 l AWS覆盖全世界12个国家区域 1. 每个区域都对应着世界上的一个物理位置,每个位置都有弹性计算云提供多个可用区域(Availability Zones),这些区域包含北美、南美、欧洲、中东、非洲、亚太等地区。
非阻塞通道 非阻塞通道用于负责将数据读到缓冲区中,或将数据从缓冲区中写入,这个类的作用主要是用于屏蔽非SSL与SSL读写操作细节的不同,这个类实现了ByteChannel接口,此接口只有write、read两个操作字节流的方法,细节正是屏蔽在这两个操作中,例如非SSL通信时,报文本来就是明文,可直接读取,而对于SSL通信,报文属于加密后的密文,解密后才是真正需要的报文。
JVM设置 l 一般使用HotSpot JVM。 l 加上-server。 l -Xms/-Xmx:设置java堆初始化和最大值,默认是1/64物理内存和1/4物理内存,一般不超过物理内存的80%,且这两个应该设置成一样,,够用就好,太高会导致浪费内存和GC回收周期长。
NIO模式主要优势是体现在对多连接的管理,对众多连接各种事件的转发让处理变得更加高效,所以一般是服务器端才会使用NIO模式,而对于客户端为了方便及习惯使用阻塞模式的Socket进行通信。
========广告时间========鄙人的新书《Tomcat内核设计剖析》已经在京东销售了,有需要的朋友可以到 https://item.jd.com/12185360.html 进行预定。
RPC即远程过程调用,它的提出旨在消除通信细节、屏蔽繁杂且易错的底层网络通信操作,像调用本地服务一般地调用远程服务,让业务开发者更多关注业务开发而不必考虑网络、硬件、系统的异构复杂环境。
单机时代对会话的管理主要有两种方式——非持久化方式和持久化方式。非持久化方式指会话直接由tomcat管理并保存在机器内存上,它是最简单的方式,如下图,所有的会话集合都保存在内存上,客户端访问时根据自己的会话id直接在服务器内存中寻找,查找简单且速度快,但同时也存在两个缺点:一是容量比较小,当数据量大时容易导致内存不足;一是机器意外停止会导致会话数据丢失缺点。
目标 提供一个oracle数据库统一访问代理层,统一管理所有oracle数据库用户名的连接池,让多个应用系统相同的数据库用户公用连接池以节省oracle服务器的总连接数,并且提供统一管理oracle能力。
DeltaManager会话管理器是tomcat默认的集群会话管理器,它主要用于集群中各个节点之间会话状态的同步维护,由于相关内容涉及到集群,可能会需要一些集群通信相关知识,如果有疑问可结合集群相关章节。
在集群环境中为了使集群中各个节点的会话状态都同步,同步操作是集群重点解决的问题,一般来说有两种同步策略,其一是每次同步都把整个会话对象传给集群中其他节点,其他节点更新整个会话对象;其二是对会话中增量修改的属性进行同步。
之前在另外一个平台(http://www.jointforce.com/jfperiodical/article/1035)发表的一篇文章,现在发布到自己的博客上。
前面提到的标准会话管理器已经提供了基础的会话管理功能,但在持久化方面做得还是不够,或者说在某些情景下无法满足要求,例如把会话以文件或数据库形式存储到存储介质中,这些都是标准会话管理器无法做到的,于是另外一种会话管理器被设计出来——持久化会话管理器。
用于保存状态的会话对象已经有了,现在就需要一个管理器来管理所有会话,例如会话id生成、根据会话id找出对应的会话、对于过期的会话进行销毁等等操作。用一句话描述标准会话管理器:提供一个专门管理某个web应用所有会话的容器,并且会在web应用启动停止时刻进行会话重加载和持久化。
Tomcat使用了一个StandardSession对象用来表示标准的会话结构,用来封装需要存储的状态信息。标准会话对象StandardSession实现了Session、Serializable、HttpSession等几个接口,为什么需要实现这几个接口呢?Session接口定义了tomcat内部用来操作会话的一些方法;Serializable则是序列化接口,实现它是为了方便传输及持久化;HTTPSession是Servlet规范中为会话操作而定义的一些方法,作为一个标准web容器实现它是必然的。
基本所有web应用开发的朋友都很熟悉session会话这个概念,在某个特定时间内,我们说可以在一个会话中存储某些状态,需要的时候又可以把状态取出来,这整个过程的时间空间可以抽象成“会话”这个概念。
http协议在设计之初被设计成无状态特性,客户端的每次请求在服务端看来都是独立且无任何相关性,同一个客户端第一次请求不会与第二次请求有任何关联,即使相隔时间很短。
上面已经对tribes的内部实现机制及原理进行了深入的剖析,在理解它的设计原理后看看如何使用tribes,整个使用相当简单便捷,只需要四步: ① 定义一个消息对象,由于这个消息对象是要在网络之间传递的,网络传输涉及到序列化,所以需要实现Serializable接口。
Tribes为了更清晰更好地划分职责,它被设计成用IO层和应用层,IO层专心负责网络传输方面的逻辑处理,把接收到的数据往应用层传送,当然应用层发送的数据也是通过此IO层发送,数据传往应用层后必须要留一些处理入口供应用层进行逻辑处理,而考虑系统解耦,这个入口最好的方式是使用监听器模式,在底层发生各种事件时触发所有安装好的监听器,使之执行监听器里面的处理逻辑。
hazelcast作为一个内存数据网格工具,还算比较优秀,听说有Apache顶级项目使用它,值得研究下,使用文档可以直接看官方文档,但机制原理相关的资料基本没有,本人硬撸源码写的一些东西,跟大家分享一下。
拦截器应该可以说是一个很经典的设计模式,它有点类似于过滤器,当某信息从一个地方流向目的地的过程中,可能需要统一对信息进行处理,如果考虑到系统的可扩展性和灵活性通常就会使用拦截器模式,它就像一个个关卡被设置在信息流动的通道中,并且可以按照实际需要添加和减少关卡。
与消息发送通道对应,发送的消息需要一个接收端接收消息,它就是ChannelReceiver。接收端负责接收处理其他节点从消息发送通道发送过来的消息,实际情况如图每个节点都有一个ChannelSender和ChannelReceiver,ChannelSender向其他节点的ChannelReceiver发送消息。
前面的集群成员维护服务为我们提供了集群内所有成员的地址端口等信息,可以通过MembershipService可以轻易从节点本地的成员列表获取集群所有的成员信息,有了这些成员信息后就可以使用可靠的TCP/IP协议进行通信了。
一个集群包含若干成员,要对这些成员进行管理就必须要有一张包含所有成员的列表,当要对某个节点做操作时通过这个列表可以准确找到该节点的地址进而对该节点发送操作消息。
接下来一系列文章会对集群通信框架tribes进行源码级别的分析,欢迎讨论。 把若干机器组合成一个集群,集群为了能协同工作,成员之间的通信是必不可少的,当然可以说这也是集群实现中重点需要解决的核心问题,一个强大的通信协同机制是集群的基础。
集群 现在如果要构造一个真正在生产环境上可使用的可靠的系统,基本都离不开集群的概念,总的来说集群是指由若干互相独立的机器通过高速网络组成的一个整体服务,整个集群的内部实现相对外部是透明的,对外部而言它就像一个独立的服务器。
在第一小节中经过几步一个访问日志组件已成型,但为了增加用户自定义能力我们还是要继续做点事,对于用户自定义的实现最经典的做法就是引入变量表示,例如定义%a表示远程主机IP、%A表示本机IP等等,然后在写入之前用相应逻辑把变量替换成相应的值写入日志。
对任何一个系统,一个强大的日志记录功能是相当重要且必要的,根据日志的记录可以及时掌握系统运行时的健康状态及故障定位。然而作为web容器存在另外一种日志——访问日志。
在单播模式中有服务器端和客户端之分,而组播模式与单播模式不同,每个端都是以路由器或交换机做为中转广播站,任意一端向路由器或交换机发送消息,路由或交换机负责发送其他节点,每个节点都是同等的。
我们说管道机制给我们带来了更好的扩展性,Tomcat中在扩展性方面具体如何体现,这便是本节讨论的内容。从上节了解到基础阀门是必须执行的,假如你需要一个额外的逻辑处理阀门,可以添加一个非基础阀门。
Tomcat中按照包含关系一共有四个容器——StandardEngine、StandardHost、StandardContext和StandardWrapper,对这四个容器的详细解析后面会涉及,请求对象及响应对象将分别被此四个容器处理,请求响应对象在四个容器之间通过管道机制进行传递。
如果把整个tomcat内核最高抽象程度模块化,可以看成是由连接器Connector和容器Container组成,连接器负责HTTP请求接收及响应,生成请求对象及响应对象并交由容器处理,而容器则根据请求路径找到相应的servlet进行处理。