h.APR通道是个怎么回事

APR通道是Tomcat比较有特色的通道，在早期的JDK的NIO框架不成熟的时候，因为java的网络包的低效，Tomcat使用APR开源项目做网络IO，这样有效的缓解了java语言的不足，提供了一个高性能的直接通过jni接口进行底层IO通信内存使用的这么一个通道。

但是，当JDK的后续版本推出之后，JDK的网络底层库的性能也上来了，各种先进的IO模型，线程模型和APR开源项目几乎不相上下，这个时候，经常会出现一种测试场景是，加上APR通道之后并没有太多的实质提升，这是可以理解的，但是JDK中的SSL信道的性能至少从目前的角度来看，和APR通道基于openssl的引擎信道实现，还有不小的差距，因为SSL协议中定义的握手协议，交互次数比较多，而openssl项目经历多年，性能极为高效，因此从目前的Tomcat的APR通道来看，主推的就是这个SSL/TLS协议的高效支持：

除了上述的1,2两点，对于FIPS 140-2,中文名：美国联邦信息处理标准。外文名：Federal Information Processing Standard。根据FIPS 140-2，密码模块为“硬件(Hardware)、软件(Software)、和/或固件(Firmware)的集合，它们实现了经过经认可的安全功能（包括密码算法和密钥生成），并包括在一定的密码系统边界(Boundary)之内。整体来说，FIPS 140-2是一个高标准定义的密码安全的认证，这个被openssl所支持，而因为APR连接器使用了openssl。

看一下tomcatAPR通道中的架构图：

1.APR通道

从上图中可以看到，对于Connector通道总共有几种通道，BIO是阻塞式的通道，NIO是利用高性能的linux（windows也有）的poll或者epoll模型，APR通道就是本文中讲的内容，对于目前的JDK还支持NIO2的通道，关于这些通道的概况，我们可以从下图中进行详细查看：

这张图就是这几个通道的区别，对于APR来讲，SSL Support区别最大，使用的是openssl作为SSL的信道支持，另外从IO模型角度来看，对于Http请求头的读取，SSL握手因为调用的JNI也是阻塞的，这个是与NIO和NIO2的差距，但是从SSL信道的支持上用的是高效的openssl。

因此，如果从这个角度去分析，上面的一些测试场景得出结论就很容易解释得通。

简单看看APR通道的代码，其依然有APREndpoint，可以看到其中的组件：

依然有Acceptor接收线程池，Poller轮询，Worker工作线程池，这些和其它通道的架构区别不大，重要的是其关于socket调用和SSL的握手等内容。

看一下Acceptor中的socket接收：

直接调用的就是native；

对于SSL握手也是一样，可以看一下APREndpoint中的SSLContext的创建：

SSLContext上下文都在底层，对于java这块仅仅返回一个值是告诉是否创建成功或者一些标识吗：

到这里为止，我们可以对APR通道做一个总结，APR通道和其它的通道结构差不太多，也是几个线程池组件共同起作用，只不过因为调用方式的不同在阻塞和非阻塞上和其它几个通道有区别，对于socket建立，SSL信道建立都是调用下层的native包来做的。

2.Tomcat-Native

tomcat中对于这些jni的调用部分，做出了一个tomcat的子项目，叫做Tomcat-native，在这个调用层级中，一部分是java部分，也就是上述AprEndpoint中看到的native方法：

这些java的包，对应调用的就是jni的native的C的代码，是 一一对应的：

我们可以看看Tomcat-native发布目录的组成：

对于tomcat-native最好的教程应该是example目录中，这个目录使用一个例子完整的复现了Tomcat前端APREndpoint的几个线程组件的工作模式；对于test目录也可以从这个点切入进去，是一个好的调试tomcat-native代码的过程。

3.APR高性能网络库

tomcat-native项目，可以说是作为一个集成包，有点类似于TomEE对于JAVA EE规范的集成，它集成的内容一个是openssl，这个是ssl信道的实现，另外一个是高性能的apr网络库。

APR高性能网络库是什么？

Apache Portable Runtime (APR) project，这个库定位于在操作系统的底层封装出一层抽象的高性能库，在于屏蔽掉操作系统的差异。可以分析出来，APR相当于JDK的一个角色了，只不过它关注的大多在网络IO相关的这块：

以一个IO多路复用的例子为例：

从这个角度上来讲，没有提供windows的多路复用的技术，这点是一个遗憾，可以从Unix系统中的几种常见的IO多路复用模型上看到，epoll,poll,select,甚至freebsd中的kqueue都有，从这个角度来讲，APR支持的还算可以。

对于lock的部分也是一样：

对于更多的系统环境都进行了支持。

总结一下，APR提供了对于底层高性能的网络IO的处理，可以解决Tomcat早期网络IO低效的问题。

4.openssl库

tomcat-native除了调用APR网络库保证高性能的网络传输以外，对于SSL/TLS的支持还调用了openssl。

对于OpenSSL项目来说，选择市面上大多数的SSL信道实现都是用OpenSSL做的，这也就是说，如果要OpenSSL暴露出一个漏洞出来，那破坏性都是惊人的。

openssl目录结构合代码流程很清晰，这里就不再缀余了。

总结：

APR通道很小的一部分是java，大部分的源码都是C的，而且和操作系统的环境有这密切的关系，不同操作系统定制的接口不同，性能特色也不同

来自为知笔记(Wiz)