Tomcat内核设计剖析 - (EPUB全文下载)

文件大小：0.36 mb。
文件格式：epub 格式。
书籍内容：

Tomcat内核设计剖析
第1章 Web服务器机制
第2章 Servlet规范
第3章 Tomcat的启动与关闭
第4章 从整体预览Tomcat
第5章 Server组件与Service组件
第6章 Connector组件
第7章 Engine容器
第8章 Host容器
第9章 Context容器
第10章 Wrapper容器
第11章 生命周期管理
第12章 日志框架及其国际化
第13章 公共与隔离的类加载器
第14章 请求URI映射器Mapper
第15章 Tomcat的JNDI
第16章 JSP编译器Jasper
第17章 运行、通信及访问的安全管理
第18章 处理请求和响应的管道
第19章 多样化的会话管理器
第20章 高可用的集群实现
第21章 集群通信框架
第22章 监控与管理
欢迎来到异步社区！
第1章　Web服务器机制
所有的Web服务器都根据规定好的协议机制进行不同的实现及扩展。有的Web服务器只能处理静态资源，而有的可以完成动态处理。有的Web服务器用C++语言实现，而有的用Java语言实现。但不管Web服务器具体如何实现及扩展，它都必须要遵循基本的协议规定。在深入研究Tomcat之前很有必要先了解Web服务器的一些机制。
本章分别从通信协议、Socket通信、Web服务器模型三方面对Web服务器机制进行介绍。
1.1　通信协议
1.1.1　HTTP/HTTPS
HTTP是Hyper Text Transfer Protocol（超文本传输协议）的缩写。HTTP协议是用于从Web服务器传输超文本到本地浏览器的协议，它能使浏览器更加高效，使网络传输减少，保证计算机正确快速地传输超文本文档。现在我们普遍使用的版本是HTTP1.1。
HTTP是一个应用层协议，它由请求和响应组成，是一个标准的B/S模型。同时，它也是一个无状态的协议，即同一个客户端上，此次请求与上一次请求是没有对应关系的。
而HTTPS简单地说就是HTTP的安全版。通常，在安全性要求比较高的网站（例如银行网站）上会看到HTTPS，它本质上也是HTTP协议，只是在HTTP增加了一个SSL或TLS协议层。如图1.1所示，如果在TCP协议上加一层SSL或TLS协议，就构成HTTPS协议了。SSL/TLS协议提供了加解密的机制，所以它比HTTP明文传输更安全。从图1.1中可以看出，HTTP可以直接进入TCP传输层，也可以在TCP层上加一层SSL/TLS层，这样就先经过SSL/TLS再进入TCP传输层。这两种方式便是HTTP与HTTPS。一般HTTP的端口号为80，而HTTPS的端口号为443。
简单地说，SSL/TLS协议层主要的职责就是借助下层协议的信道安全地协商出一份加密密钥，并且用此密钥来加密HTTP请求响应报文。它解决了以下三个安全性方面的议题。
提供验证服务，验证本次会话实体身份的合法性。
提供加密服务，强加密机制能保证通信过程中的消息不会被破译。
提供防篡改服务，利用Hash算法对消息进行签名，通过验证签名保证通信内容不被篡改。
▲图1.1　HTTP与HTTPS
HTTPS运用越来越广泛，而且在安全场景中它是一个很好的解决方案，一般作为解决安全传输的首选解决方案。下面深入了解一下HTTPS的工作原理及流程。
在理解HTTPS工作原理前，先了解一些加密解密算法与Hash算法。
对称加密。密钥只有一个，加密、解密都是这个密码，加解密速度快，典型的对称加密算法有DES、AES、RC4等。
非对称加密。密钥成对出现，分别为公钥与私钥，从公钥无法推知私钥，反之，从私钥也不能推知公钥。加密、解密使用不同的密钥，公钥加密需要私钥解密，反之，私钥加密需要公钥解密。非对称加密速度较慢，典型的非对称加密算法有RSA、DSA、DSS等。
Hash算法，这是一种不可逆的算法，它常用于验证数据的完整性。
图1.2详细描述了HTTPS完成一次通信要做哪些事情。因为HTTPS是基于TCP/IP协议通信的，属于可靠传输，所以它必须要先进行三次握手，完成连接的建立。接着是SSL的握手协议，此协议非常有效地让客户和服务器之间完成相互之间的身份验证及密钥协商。
▲图1.2　HTTPS的工作原理及流程
① 客户端浏览器向服务器发送SSL/TLS协议的版本号、加密算法的种类、产生的随机数，以及其他需要的各种信息。
② 服务器从客户端支持的加密算法中选择一组加密算法与Hash算法，并且把自己的证书（包含网站地址、加密公钥、证书颁发机构等）也发送给客户端。
③ 浏览器获取服务器证书后验证其合法性，验证颁发机构是否合法，验证证书中的网址是否与正在访问的地址一致，通过验证的浏览器会显示一个小锁头，否则，提示证书不受信。
④ 客户端浏览器生成一串随机数并用服务器传来的公钥加密，再使用约定好的Hash算法计算握手消息，发送到服务器端。
⑤ 服务器接到握手消息后用自己的私钥解密，并用散列算法验证，这样双方都有了此次通信的密钥。
⑥ 服务器再使用密钥加密一段握手消息，返回给客户端浏览器。
⑦ 浏览器用密钥解密，并用散列算法验证，确定算法与密钥。
完成以上7步后双方就可以利用此次协商好的密钥进行通信。
1.1.2　HTTP请求/响应模型
从某种意义上来说，HTTP协议永远都由客户端发起请求，由服务器进行响应并发送回响应报文。如果没有客户端进行请求或曾经请求过，那么服务器是无法将消息推送到客户端的。HTTP采用了请求/响应模型，一个HTTP请求与响应一般如图1.3所示，客户端向服务器发送一个请求，请求头包含请求方法、URI、协议版本、请求修饰符、客户信息，以及类似于MIME结构的消息内容。服务器以一个状态行作为响应，内容包括消息协议版本、成功（或失败）编码、服务器信息、实体元信息及一些实体内容。这样就完成了一个请求/响应过程。
▲图1.3　HTTP请求/响应模型
通常，一个HTTP请求/响应的工作流程大概可以用以下4步来概括。
① 客户端浏览器先要与服务器建立连接，即通过三次握手建立连 ............

以上为书籍内容预览，如需阅读全文内容请下载EPUB源文件，祝您阅读愉快。