这个问题是这样的：把网站设置为需要进行SSL双向认证（即通过https://的方式访问网站，还需要有客户端数字证书），如果服务端是基于Apache的话，那么客户端（也就是浏览器）每次访问一个页面，对于页面上的每一份资源（一个页面通常包含很多资源，例如被html页面引用的.js/.css文件，页面中的各个图片、flash等等），都需要做一次数字签名。奇怪的是IIS服务器就没有这种情况。

每访问一个资源就做一次数字签名，这是一件恐怖的事情。一般情况下一个html页面都会包含十几个甚至几十个资源（特别是一些装饰用的小图片和一些小图标等等，每个文件也就两三KB，但是也需要进行数字签名），早期使用数字证书的时候基本上都是将数字证书保存在计算机硬盘上，数字签名也是由CPU来进行，一次数字签名也就几个毫秒，看起来影响就不大，但是随着技术的发展，后来都是以USB Key来对数字证书进行存储和运算，为了安全，数字签名就只能USB Key内部进行。试想一下，处理器速度一般就几M，高的也就几十M的USB Key处理芯片，在做数字签名的时候效率比起计算机两三个G的运算速度低了不少，即使经过特别优化，一般的USB Key做一次数字签名也需要十多二十毫秒。这种情况下，每访问一个资源就需要做一次数字签名，在打开一个网页的时候，就会发现有明显的延时，现象就是页面文字都已经显示出来了，而USB Key的指示灯还在狂闪（USB Key上通常有一个指示灯，当USB Key正在工作的时候就会闪烁，以提醒用户），然后才能够看到页面上的图片内容一个一个的显示出来。

这几年里，对于这个问题我一直都不求甚解，当初想通过修改Apache配置来解决，也试图在PHP脚本中加入Keep-alive之类的标记，但是终不得其法，渐渐的也就有了一个错误的认识，那就是Apache无法做到SSL状态的缓存，客户端访问每个SSL资源都必须重新重新经历握手、产生会话密钥等过程，所以每访问一个资源就会做一次数字签名。

这个错误的认识一直延续了好几年，在这几年中，当有人问到我这方面的问题时，我都毫不犹豫的告诉他这是Apache的问题，是出于安全性考虑才这样做的。但是另一方面，在我内心深处，还是隐约觉得事情不应该是这样的。终于，在一次封闭开发的过程中，我弄明白了事情的真相。

前几天因为一个银行的项目，需要我们做一个客户端软件来登陆银行的网银系统，而不是直接使用浏览器。我的任务就是做这个客户端软件。当然，做这样一个客户端并不是很困难的事情，大约封闭开发了四天，客户端就基本完成了。在自我测试的时候，前面所讲的这个问题又一次出现在我面前。

看着漂亮的客户端软件界面（其实就是内嵌一个WebBrowser控件的对话框），再看着登录成功后还一直狂闪的USB Key指示灯，心中越来越郁闷。Apache不会这么弱智的呀，那么弱智的应该是我了。那么再看一遍Apache的文档吧，网上有一份翻译的非常棒的Apache 2.2的文档，是金步国先生翻译的（赞一个先，感谢这样默默无私奉献的人！！！）。在mod_ssl模块的文档中，关于“SSLSessionCache 指令”一段又反复读了几遍。对于“SSLSessionCache”指令，官方解释是“这个指令指定了全局/进程间SSL会话缓存的类型。SSL会话缓存机制(可选的)可以加速对并发HTTPS请求的处理速度。对于同一个服务器进程处理的 HTTP keep-alive连接，OpenSSL自身已经在本地缓存了SSL会话信息。但是由于现代浏览器会使用多个并发连接请求页面内的图片等其他资源，服务器就不得不使用不同的进程来处理这些连接，因此能够在不同进程之间缓存SSL会话信息就有助于避免不必要的握手过程。”也就是说，Apache肯定是支持SSL缓存的。其推荐的方式是使用shm（也就是共享内存方式）来做SSL的状态缓存，再看看Windows版Apache安装后其配置文件中缺省使用的是shmcb的方式（这种方式在文档中并未提及），而我的Apache配置一直使用的是这个缺省配置。

我的天，该不会是shmcb方式是有问题的吧。把shmcb改为shm，果然，问题解决！！！

我不知道该哭还是该笑~~~ 困扰我五、六年的问题就这样改动两个字母就搞定了！