摘要
这篇文章论述安全web服务器的部署，使用它们作为后端系统的代理、SSL负载均衡、及如何解决其他大规模系统的性能和可靠性问题。我们调查了在多服务器环境下安全事务处理的影响,并且研究了负载共享技术创新的途径。这里包括分布式会话缓存、交叉计算机的CPU增强操作(针对专有硬件)，而且对合并的加密硬件的加速问题和密钥管理系统进行了优化。
背景
这文章的目标是考察关于你的 Web服务器执行安全事务的效果；特别地它怎样影响你的系统的性能和布局。我们按照大量站点使用的机器布局和配置，在标准的http解决方案下，看看它们是否可以扩大到足以处理安全事务（https）。虽然有一些解决方案处于专有的硬设备空间中，但是我们要考察用什么方法使你能使用 Apache服务器做相同的事情。
最近公共社区正在关注软件中维护私人密钥的问题，所以如果有其他制造你自己的安全系统的方法，我们要看看谁将会受到这个影响。我们试图了解是否基于硬设备的密码系统装置是一个代价有效的解决方案，并且给你提供基本的知识，帮助你搞清那些厂商宣称的系统的真实情况。
因为大多数浏览器和服务器支持SSL和TLS安全协议，我们将特别集中在它们的讨论上。既然这是一个关于Apache服务器的讨论，虽然很多其他的服务器有这样的概括性的材料到（也包括安全相关的那些服务）,但我们不去考虑其他的服务器，或深入研究太多供应厂商的产品具体细节，。
Apache服务器中的SSL
所以在安全连接和非安全连接之间的差异是什么？当你使用"https"前缀访问一个站点时，你在试图建立一个使用SSL或TLS协议的连接。一旦地那个连接建立，在浏览器和服务器之间的请求和回应被加密编码成为端到端(1)的连接。这个连接的二个阶段是；握手协议（认证和密钥协定）和隧道协议（请求和回应通过加密编码往返传输(2)）。
SSL密码系统
一旦浏览器和服务器已经完成握手协议,它们可以使用一个诸如DES或RC4的标准加密算法将其余的通讯译成密码进行数据交换。这个算法被称为加密，并且这个技术称作对称密码系统。对称密码系统使用一个公用密钥用于双方加密并且解密数据，使得这个密码系统通常运行的飞快。但是在浏览器和服务器之前可能之前没有交互，它们需要一些方法用来建立公用密钥。这个过程在握手协议过程中由密钥交换技术完成，该技术基于非对称加密算法（公共/私有密钥密码系统）。这是通常基于RSA算法(3)，典型地使用一对1024位组的RSA密钥。如同以下表格说明的那样（显示了不同的平台下1024位组RSA签名的速度试验），公钥密码是一种CPU密集型的任务。
在表格1中的图形是在使用了一闲置的机器上所有的可用的CPU资源，并且使用优化组合的RSA算法的版本获得的结果。
因此，为了估计一个提供SSL支持的服务器所需要进行的工作，我们必须检验加密操作产生有效的系统开销，并判定它们多久需要进行一次。除了这些RSA签名操作以外，和一旦初始的SSL事务（握手协议）已经完成、是否那写加密请求的时间和响应数据是有效的呢？原来对于大多数机器而言，这些对称加密算法有着极低的系统开销，并且那些额外的传送未加密数据上的开销相对可以忽略不计。表２说明了在不同的闲置机器上大量的数据每秒可以同时使用二个公共的SSL密码进行加密。
你的密钥在哪里 ？
当Web服务器在处理SSL事务时，为了完成SSL私有密钥的操作，需要有一份服务器的私有密钥保存在它的内存里。在 1999初，ncipher发现了一个很有效的方法大——通过扫描大量数据来寻找私有密钥。
在某些配置下，一些操作系统允许应用程序以同一个用户的身份运行，该程序可以读取其他进程的内存区域。由于CGI程序通常运行于这种方式，在同一个Web 服务器上任何一个能够访问的CGI程序，潜在地都可以扫描该Web服务器的内存，以发现该服务器上所有安全站点的私有密钥。 ncipher示范了一个CGI程序，扫描内存并返回运行在服务器上的所有安全虚拟主机的私有密钥。
他们提出了这个问题的解决方案：安全地将你的密钥写入一个外部硬件装置，比如说写入到一个硬件加速器中。然后，加速器不但执行密钥的操作，而是它也有唯一的密钥拷贝。Web服务器不需要向加速器提供密钥，实际上通常将在该装置内部产生密钥并且不会输出它们。然后Web服务器必须手动切断该硬件加速器上的全部密钥操作，因此每个Web服务器都需要具备自己附属的硬件加速器。
nCipher示范的攻击仅仅工作在几个操作系统上，这些操作系统允许其他的进程读取每个存储空间，甚至在那些系统上这些攻击很简单就击败了这些系统。 Apache仅需在开始时作为 root用户，并允许同非root用户混合以便提供网页服务（事实上这是缺省值配置）。即使 Apache作为非root用户启动，你仅仅被影响，是否允许人们编写他们自己的用于安全事务的CGI程序并将之运行在一个Web服务器上。令人遗憾的是这并不完全是被最近覆盖该问题的催促发行的画面。
SSL 会话高速缓冲存储器
为了加速该请求的处理,当打开一新的连接时,SSL协议特别地允许一客户要求该服务器预先地给出协议会话的摘要。因此一旦该客户机和服务器已经执行了公众密钥操作并协商一对对话密钥（i.e.４版本或keep - alive功能被配置为低的超时以保持打开的连接的数目并且进程在控制下完成该握手协议），然后一个将来产生的新连接理论上不需要执行CPU密集的公开密钥操作。每个会话必须有一超时期同它关联（出于安全理由），因此该服务器管理员可以强制一个新的会话，例如，至少每天或每小时被建立一次。
这个意味着如果想要利用这个特色，该服务器必须有一个方法的存储该会话的信息；一个会话高速缓冲存储器。用Apache1.3服务器，我们情况复杂化了：持有大量独立的派生子进程，子进程运行在那个没有公共存储的服务器上。每个进入Apache服务器的请求可能通过不同的子进程来终结。在SSL中，当客户程序标志出它所希望恢复的服务器会话时，会话恢复过程被初始化。即使该客户程序已经就每个子进程进行了会话协商，并且正确地猜测它已经连接的子进程，它也仅能恢复一个SSL会话。对负载很重的已经有上千个子进程的站点来说，这不是有效的方法，而且一个会话高速缓冲存储器会在全部需要该缓存的Apache子进程之间共享。
尽管这是一个十分简单概念，也要需一段时间来了解清楚安全Apache服务器的解决方案。Apache服务器- SSL(5)服务作为一个外部进程，同会话高速缓冲存储器一起开始运行。每个子进程将为那些需要内存高速缓存的会话进程建立一个独立的连接。
但是这种解决方案对于服务器管理员来说实际上是十分难操纵的，因为该Web服务器不得不将它的外部进程重新启动。同样地，由于该Web服务器将继续运行并且试图对那些始终失败的请求进行服务，所以如果这些进程已经被杀死或者崩溃，这个问题还是依然存在，无法解决。
mod_ssl (6)有它自己的解决方案。它和Apache服务器的SSL扩展服务以相同的方式启动，然后转移到一个会话高速缓冲存储器，这个缓冲存储器通过一个轻量级数据库而不是外部进程来实现。在最近的几个月，mod_ssl开始支持类似堡垒（Stronghold）的方法--使用共享内存高速缓冲存储器。
随着新的会话高速缓冲存储器的到来，有责任正确地配置它。如果系统需要越多的并发操作会话和更长的会话终止时间，就需要更大的内存块来做会话高速缓冲存储器。检验会话高速缓冲存储器的关键速度结果将同样重要。在该会话高速缓冲存储器内全部的读取和写入操作必须被同步以避免数据损坏，因此如果该高速缓冲存储器很大并且仅有一个 Apache服务器的子进程能够同时与之通信，它本身可能变成性能的限制因素而不是解决的办法。例如，一个负载很重地服务器，正在运行大量的密集型的 SSL密钥操作，将相应地引起所有的会话高速缓冲存储器操作，并增加了那些为了访问它的子进程排队等候的可能性，从而导致系统速度大大减慢。
由于我们将密钥操作看作同样的情况，在同一个Web服务器系统上运行SSL会话高速缓存服务是有缺点的。如果该高速缓冲存储器太大的，同步化法访问可能变成该瓶颈，否则它可能仅仅耗费太多的共享资源。如果高速缓冲存储器不是足够的大，它就会在即将期满之前很快被输入项目填满。当该会话高速缓冲存储器被写满时，将选择遵循已经设定的会话超时值（而在这样情况下新的SSL会话根本不会被高速缓存，直到在高速缓存内的输入项目超时），否则将导致过早地终止旧的会话。令人遗憾地大多数SSL Apache服务器服务器按照前者的方式运行，但是两者也都不是特别理想。
Table 3- 使用通用SSL解决方案的高速缓存技术
可能的话将SSL会话高速缓存运作为一个专用服务运行在另一个系统上，于是它能够独立于那个Web服务器进行资源扩展和缩放管理。
1、https请求总是经由服务器验证并且选择性地被客户端验证。
2、任何时候，在SSL/TLS协议许可中任何一个的连接结束时，它要强制一个重新协商的过程。大多数服务器和浏览器不允许这么做（不会改变正在讨论的重点），所以我们将不会更深入的考虑这个问题。
3、RSA现有的备选方案有DSA--基于证书和密钥的系统，但是这些技术不是如此广泛地受到支持。因此在最差的情况下，每个到服务器的连接都需要一个新的签名操作，这将大大地限制我们的Sparc机器的速度——每秒处理小于27个连接。甚至假定那些机器在执行RSA签名操作以外，极少处理其他的浏览器的 https请求的应答工作。实际上HTTP1.1协议能够保持一个打开的连接，并使得后继的多重请求都在这个连接上进行通信（相继地而不是并发地进行）。不幸的是这个"keep alive"功能并不总是在服务器端允被许。
4、另外、我们发现浏览器为了下载WEB页面的内嵌图像或是这类文件，经常通过打开大量的到Web服务器的同时连接，以避免相继地执行每个请求而因此带来延迟。
5、Ben Laurie的 Apache-SSL服务 , http://www.apache-ssl.org/
6、Ralf Engelschall的mod_ssl, http://www.modssl.org/
转载：LinuxAid
*****************************************************************************
本文由正泰linux http://linux-down.kmip.net 搜集，整理，如需转载，请注明出处！
本站有大量的linux电子教程，软件，技术文档，欢迎大家访问！站长阿泰qq：253222170
******************************************************************************
加速CRYPTO
一旦这些软件的问题被解决，并且我们有一个能够快速工作的会话高速缓冲存储器和支持会话恢复的浏览器，我们是否使用keep - alive连接就不再重要了。现在，新的限制因素变成：我们每秒可以服务多少新的安全请求，概念上我们要知道建立一新的安全连接的延迟是多少（在非稳定缓慢增长的情况下，服务器可以支撑的负载极限的水平是多少）。这样在处理正常的http上我们有一个好处，就是安全地址很少需要被通告，因此也很少会出现在极短的时标上获取一个新的安全连接这样的现象（这类现象体现为负载峰值）。但是在最坏情况下，假设，有200个新的连接到你的站点，而你的站点每一秒仅能处理50签名，那么你潜在的客户为了新的连接最少要等待４秒，这就有可能就会导致这个潜在客户的流失。来自Zona研究一个报告表明，顾客在放弃发出他们的订单之前是没有耐心等待超过8秒钟的（而且这还必须包括处理全部请求的时间，而不仅仅只是处理SSL 连接的那部分）那么有什么解决方案能够解决现有的这种问题呢？
高性能的机器部件
你可以购买一个更快的机器--一个每秒可以处理更多连接的机器。我们已经展示了一台采用廉价的Athlon处理器的机器，在进行RSA签名操作上比更为昂贵的Sparc Ultra 5机器要快上三倍！实际上，工程师们正在发展整个新的系列的处理器，这些将来的处理器特别用于加速诸如密钥签名等加密操作的处理。Ultrasparc III处理器将包含能够进行公共密钥加密操作的更有效率的指令。美国英特尔公司也已经声称他们的新的Itanium 64位处理器可以以10倍于当前最快的32位Xeon处理器的速度来执行SSL操作。
密码加速方法
在处理器上处理密码操作的替换方法是使用一些"协处理器"，它们能够处理你的Web服务器上所有的和数学计算相关的任务。这是许多制造密码加速器硬件公司所乐于采用的方法。
现在大量的密码加速器主要采用包括Rainbow、DEC和nCipher加密算法。你可以通过购买加速硬件板来满足特定性能水平要求的加密功能，用于处理 CPU密集型的耗时的RSA加密操作。当Web服务器获取一个新的连接时，它将相关的数学计算任务传递到加速板上，在板上执行计算后将结果送回Web服务器--有希望在极短的时间内完成计算并且可以继续处理Web服务器转发过来的计算任务。
一旦初始的SSL会话被建立，加速板将不会在同一个SSL会话的后续连接中其作用。虽然这些板能作够做到对称加密，但事实上比起直接在CPU进行加密解密处理，单独将计算任务发送到加速硬件上进行计算，其花费的总体系统开销总是相对高的多（不管是在延迟还是系统资源的消耗上都是如此）。这导致密码加速器通常以附加硬件的形式，典型地通过PCI或SCSI总线进行连接，并且通常允许多个这样的设备串在一起为单台机器提供可伸缩性能的支持（包括容量的可伸缩性）。
你希望加速板有什么样的性能价格比以及如何测定它？这些公司通常引用加速板每秒能够支撑的1024位RSA签名操作的数目来判定，因此他们容易地同其他的加速器或我们的纯图形化软件做一比较。因为Web服务器子进程必须通过一些软件和硬件层与加速板通信以等待应答，因此在处理上显然会存在一点延迟。然而，这些块通讯对于CPU没有任何影响，CPU专注于其他的任务，因此，这类延迟的增大并不会明显影响系统的吞吐量（除了那些需要运行大量子进程的任务，结果是消耗了大量的块通讯时间）。
我们已经对主要的一些加密硬件生产厂商所提供的产品价格进行了调查，并作为ICSA信息安全杂志一份报告公布于众。
我们隐藏了供应商和模型的名称，仅仅列出那些主要供应商多提供的产品中能够进行RSA密钥操作和密钥管理的产品，形成一个可以对照的产品特性列表。这些不同的单元能够显示不同产品之间的安全特性之差异，以解释各个产品之间价格差异的主要原因。
我们可以比较在通用的统一平台下进行同样加密操作时，不同产品之间性能和价格之间的差异。
我们发现如果借助一些负载均衡软件在几个CPU之间平衡负载，我们能在已有的三台AMD Athlon朱基上产生和高端加密硬件产品一样好的吞吐量，要知道这些专有的加密产品其价格至少是这些ADM机器的三倍。同时，我们也将拥有一个更易于升级和配置的系统结构，借助大量的系统级冗余，其实已经不再需要专有的控制系统来管理加密硬件设备了。但是目前的软件尚不能实现加密计算的集群构架，因此由单独的每一台机器处理各自的SSL连接，而在处理SSL连接之间则会先进行负载平衡的任务分配工作，这个负责分配的均衡器角色需要安置在这些加密处理机之前。
采用专有硬件密码加速器的另一个问题时，如果你的Web服务器超过一台，你就需要为每一台新的web服务器单独配置一个硬件密码加速器。如果，你仅仅是出于利用冗余的Web服务器保证容错能力而考虑的话，你就会为这些实际上并不需要的硬件加速器多支付额外的高昂费用。这就是目前大多数硬件加速器被设置为一对一服务和一对多服务两种方式的主要原因（一个加速器可以连接到一个或者多个Web服务器上，防止亦然）。
另外，许多的站点使用密码硬件加速器主要是为了密钥管理的需要而不是加速加密操作。这样，内部产生的私有密钥在使用上就会有严格的限制，可以有效地防止外部的干扰并且对于外部访问者而言是不可见的，因为加密器不会输出密钥的内容。甚至Web站点的系统管理员都无法访问这个密钥的具体内容，要知道站点管理员拥有多大的权限：启动和停止 Web服务器！同时，对于站点里那些知晓某些可以解析私有密钥方法的系统操作者，这样的防范也是很有效的。
假设，你拥有10个Web服务器并且已经将他们用于处理大量的数据库查询任务和Web访问逻辑，但你的系统中SSL相关的处理任务有非常小；但是处于安全考虑，你不得不在每一台Web 服务器上配置单独的密码加速器以管理好你的硬件密钥。实际上，这样的效果并不理想：由于SSL负载很低，你的大多数硬件加速器总是处理很低的利用率下，严重浪费了你的投资！
移除性能瓶颈
对于普通的HTTP请求，存在着大量的软硬件解决方案来处理负载平衡的问题。处理负载平衡的一般方法是，监视进入的HTTP请求，然后根据某种规则在服务器节点列表中选择一台Web服务器，将这个请求传递给这台被选中的服务器节点。由于HTTP是一种无状态的协议，因此可以针对每一个网络连接进行传递操作，将不同的HTTP请求（包括在同一个网页中，单独的图片、媒体文件、HTML文本都是独立的发出连接请求）转发给不同的后段服务器。因此这种模型可以工作的很好不会出现任何问题。然而，在SSL环境下我们不希望出现这种情况，大多数不同的HTTP连接请求需要发往同一个后台主机，以避免新的HTTP请求要同新的服务主机重新协商并建立新的SSL连接以获取密钥。我们应该采用必要的技术手段避免这种问题的出现，要知道，可能由于不断的计算新的SSL加密密钥，这个问题还可能演变成用户浏览网页时电击页面的响应性能问题。某些负载均衡技术可以通过判断请求包的源地址，以强制所有从同一个客户端发出的请求都会发向同一个后端服务主机。但是，这种做法本身在原理上就违背了负载均衡的基本理念，因为大量的客户可能通过同一台ISP拨号服务器或者是公司的代理服务起来访问站点，这些用户的地址最终将表现为同一个IP地址，你怎么区分他们？！
如果你需要硬件加速器来加速密钥计算任务，并且你拥有多个后端主机用于处理，你将不得不为每一个处理主机配置单独的硬件加速器（11）。这就意味着你需要大量的硬件加速器（和你的服务器数目相当），而你的加速器供应商会非常喜欢你！同时，这也意味着它将变成一笔高昂投资，而你实际上购买了多余的硬件加密授权来用于你那利用率并不高的 SSL加密任务。那么，既然普通HTTP请求的负载均衡技术如此的易于应用，我们不妨来看一下现有几种流行的负载均衡技术能否适用于处理HTTPS下的 SSL连接的负载均衡任务。
DNS轮询
DNS 轮询是负载均衡技术中最为简单的一种。请求的主机域名将会被域名服务器转换成一组实际服务器中的某个IP地址，而每一次的这种转换过程都是基于轮流的方式动态选择的，域名服务器为此维护一个域名到一组IP的转换表。当系统需要更强更多的处理能力时，可以添加服务器并将新的IP地址加入转换表。但是这种方法甚至对于普通的HTTP负载均衡任务来说都没什么价值：因为它无法处理重载的后端服务器（它把所有的后端服务器当作是一样的情况），同样它也无法反映出后端服务器的运行时状态，如果后端服务器出现故障，域名服务器还是会把请求转发给故障节点，导致用户无法访问。另一个问题时，当大量的用户是通过一个代理服务器或者域名缓冲服务器来访问站点的话，这种方法也会导致负载失衡，例如AOL的所有用户由于使用了代理和域名缓冲服务器，他们将会访问同一个Web服务器，导致这种负载均衡完全无效。
本质上，这类问题的出现是由于负载平衡在这里是被服务环境之外角色所管理而不是服务器环境内部的某个节点管理。这样，一旦某个浏览器获得了域名服务器解析的某个IP地址，他就会持续的同这个IP地址进行通信，这样当大量的浏览器都出现这种集中在某一台服务访问的情况时，整个负载均衡系统中的其他节点就会得不到或者得到很少的服务请求，而大量的服务请求都被加在单独的一台服务器上，负载均衡彻底实效！而由于DNS缓存的广泛使用，大多数使用ISP方式上网的用户都会遇到这种情况。
从上面的分析看来，使用DNS轮询至少可以让SSL的负载均衡开始工作，在一定程度上它可以使得下一个的HTTPS请求能够被转发到同一台后端服务器上，这就保证了SSL会话的一致性，不需要重新建立SSL的连接认证了。
基于硬件的流量交换机
许多硬件厂商生产基于硬件的流量交换机来处理负载平衡，例如Cisco生成的LocalDirector交换机就能够在多台的服务之间分配网络流量。在 LocalDirector分配的服务器群里面，服务器可以随意的添加或者移除以及改变。同样的，LocalDirector能够监视到这些服务器的变化并能根据最新的信息动态的将处理任务分配到某一个服务器上。
然而，前面提到的问题再一次出现：LocalDirector很可能将一个SSL会话中的不同的连接请求分配到不同的服务器上（比如通一个页面中的不同图片会通过各自独立的HTTPS 请求发往服务器），这就需要为每个新的HTTPS连接请求建立SSL会话。此时，系统的额外开销大大增加、系统性能下降并且更多的服务器将被加入以应付沉重的系统负荷。
但是Cisco的产品跟上了需求的变化，能够适应SSL请求的特殊要求：负载平衡器（硬件）能够识别每一个SSL请求并跟踪后端服务器已经建立起的每一个 SSL会话的必要信息。然后它会试图将新的SSL请求转发到已经建立好SSL会话认证的后端服务器上，保证SSL会话的一致性。
然而，平衡器仍需要考虑负载的均衡分布和处理所有中断的、不可用的WEB服务等问题，这样新的SSL连接将来可以被转发到其他已经建立SSL会话的服务器上。
软件网关（Apache镜像代理服务器）
在普通HTTP连接负载平衡的流行技术里，使用Apache的代理模块是一个比较常用的做法，它能够模仿硬件负载平衡器的功能实现对HTTP连接的负载均衡。这种情况下，需要有一台前端的机器处理所有的WEB连接请求，它能够无缝地将需要耗时处理的网络请求转发到后端的服务器上（这个工作可以借助数据库来实现）。例如，作为系统管理员的你可能决定让所有的HTML和JPEG文件在本地的服务器服务（那台能够处理所有WEb请求的前端机），当客户需要访问 CGI程序时，前端机负责把请求转发到后端的其他服务系统上，可能是一台运行在较高性能机器上的UNIX系统，上面运行着Apache的服务器程序并且能够响应CGI请求。这种做法具有很高的可扩展性，甚至可以把多台不同体系结构的服务器系统映射到同一个URL地址空间，例如，可以将用户发出的ASP页面请求（在微软的网页服务器体系中作为CGI的替代品）通过镜像代理服务转发到后端运行NT系统的IIS服务器上。当然，既然这种做法是使用单台的服务器处理所有的网络请求，那么就应该把所有耗时的任务和那些资源紧缺（一般是前端机所不具备的特殊资源）的任务转发到后端的机器去处理（例如，常常用后端服务起来进行数据库相关的查询任务或者是运行ASP程序这样的事情）。
多年来我们一直看到许多系统管理员坚持使用微软的IIS服务器或这是网景的Web服务起来进行主要的电子商务工作，而系统总是处于较低的安全水平--总所周知这是某些公司的问题；因此他们不得不采用一种变通的方法来保障系统整体的安全性：在一台备用服务器上安装带有完全版本SSL的Apache服务器以充当HTTPS到HTTP协议转换的网关。
因为现在许多简单的静态页面和图像文件能够很快地被服务和响应，SSL网关就可以被配置成能够自己服务这些请求，而对于其它类型的请求仅仅是做传递工作。尽管密码系统现在能够由单台服务器来负担，还是需要有一个或者多个的硬件加速器配合服务器以应付必要的负载需求。使用上述镜像代理的方法可以很好地为 SSL连接请求负载平衡的任务来服务；你可以结束由单个服务器处理SSL请求的工作方式了，前端服务器按照需要建立会话（包括SSL握手、生成密钥信息等等），并将任务转交给后台的服务起来执行实际的WEB操作。这正是我们正在集中讨论的"组件化"主题，在组件化的处理方式下，CGI或者ASP请求能够以独立于被请求资源的方式来处理，将资源和访问资源的程序分开处理以保证可预知的SSL系统开销。然而这种方法存在着管理上的风险，并且对于一些较大的站点来说可能由于该技术缺乏弹性而无法适应大容量的访问需求∶
⒈对于加到单台服务器上的硬件加速器的数目会有一个上限。
⒉内部的处理速度和系统级的某些原因有可能使得服务器最终成为瓶颈。
⒊这种体系结构容易出现单点失效--代理网关，因为所有的后端服务器都完全依赖于代理网关来运行。
硬件网关
至少已经有一个厂商开始考虑使用硬件网关来代替软件网关来作为这种环境下的解决方案。Intel公司生产的iPivot硬件网关是一种能够替代软件网关进行 SSL负载平衡工作的设备，该产品还包含了一些加密加速器的功能。它通常不能在本地处理网页服务（需要将网页请求转发到后端服务器），比起Apache的代理系统它也很不易于升级。当互联网的访问需求快速增长的时候，硬件网关由于不易升级的缺点很能适应需求的快速变化，而使用软件网关可以有效的提高系统的可扩展性:更换更快的处理器或者添加硬件加密加速器就可以有效提高系统的性能。
软件网关也具有更高的可定制性：允许你建立客户端证书规则并保持同Web服务器配置之间的同步，还可以将SSL连接请求的主要头信息加工后传递到后端的服务器上，其中包括使用何种加密算法或者是和客户端证书有关的信息。
解决这个问题
综上所述，通过检验现有支持Apache SSL功能的解决方案，我们发现存在以下的几个主要限制：
一）会话高速缓存需要的是更强的缩放性，并且不能局部地限制于服务于某一台Web服务器。
二）密钥操作相关的资源需要具有独立于Web服务器的更强的可扩展性能（比如常见的RSA或者DSA加密算法）。有可能要为每个操作分别提供独立的计算资源。这种系统非常适合于执行密钥操作，而不擅长作为运行Web服务器和Web程序的平台。
三）私有密钥和密钥操作需要被Web服务器应用程序保护起来。同样地，区分Web服务器管理和私有密钥访问之间的权限也是至关重要的。
四）现有的体系结构不允许系统的资源随着站点访问流量的动态变化而变更。不同的处理任务可能会有不同的平台适合它，例如你可能希望采用Intel的平台来处理RSA的密钥操作，而将Web服务器程序运行在Sparc的机器上。同样地，即使我们的网页服务能力和会话高速缓存依然资源充足，我们仍有可能需要增强我们处理密钥操作的性能。
我们的解决方案
我们提供的解决方案和多数的Web应用系统采取后端数据库服务器的解决方案不同，这类方案通过内部局域网将服务组件和连接组建分开来处理，即我们前棉讨论的几种方式。和采用后端数据库的方式相类似，在处理请求过程中涉及的延迟会少量地增加网络的通信量（建立新的SSL会话所需要进行的协商过程，以及处理 HTTPs请求所必要的通信消耗），但是我们这种解决方案能够在整体上提高系统的处理能力、吞吐量和性能。
在Web服务器内部及宁的密钥操作和SSL高速缓存操作所需的延迟是无法预先的只得，但是Web服务器必须调整资源以尽可能满足三类服务的条件需要。我们建议将这个解决方案作为系统的辅助措施，但对于大多数的常见的情况，在不同服务之间的通信信道上传递消息的延迟还是存在的，但是系统的整体吞吐量在这种方法下可以被很好的提高，每个服务也能通过调整各自的资源以适应具体的需求。比起某些CPU密集型的操作，加密算法仅需要更少的内存、更小的存储器、磁盘和网络I/O性能就能很好的运行，对于系统的功能也要求的更为简单，而性能表现却要好得多。Web服务器已经在事实上具备了相对的条件，因此这样的解决方案就能够提供更多的选择和更好的可伸缩性。它还可以用于观察是否系统某一个服务的过载会直接影响到系统中其他服务的性能。例如，一个新的Https请求由于其突发的高负荷会引起服务器的加密服务和SSL缓存服务段时间内负担很重，性能下降，但这并不会影响到Web服务器处理其他非SSL类型的网络请求。
我们现在来概括一下先前提到的四点问题在我们所介绍的方法下将被如何考虑和处理：
一）会话高速缓存作为一个服务独立于后端的Web服务节点池（那里存在着一组服务器专门响应所有的Web请求），这样就可以对这个独立的服务进行资源分配和定制了。同样的，浏览器发出的不同请求允许被定位到不同的后端WEB服务器上，但这些连接可以被保证恢复到同一个SSL会话中，以免重复进行会话的建立，这里不需要负载平衡器做出任何所谓"智能化"的路由工作。这同样也帮助了对web服务器失效故障事件的处理。
二）密钥操作可以在任何配置的机器上或者密码加速器上甚至同时在二者上执行，Web服务器群会分享这些资源。不但能够保证这些专有资源的独立性，而且纯SSL流量完全不会影响到非SSL流量的处理，也不会减慢web服务器的处理速度。
三）密钥被存储在远离那些WEB服务器所能访问的地方，非常安全：WEB服务器仅能通过公共密钥（证书）来进行相关的密钥操作和管理工作，而且web服务器不会自动获得对比较重要的私有密钥的访问授权。
四）我们可以为每一个服务组件分别选择正确数量的软硬件处理单元，这也允许我们为整个体系建立冗余部件以提高可用性。
精选的例子
我们已经预先说明了如何通过大量的方法在普通的站点配置中所发现的一种或者其它形式的性能限制。这里我们敬爱能够要通过一些案例来说明现实中我们能够通过哪一种模型来有效的解决系统性能限制，改善系统的可扩展性、整体性能和成本有效性。
(1)Web服务器处于高负荷，低SSL需求的环境下，并且需要基于硬件的密钥管理设备
这个例子中，该站点的许多web服务器处于较高的服务负载下，而仅有少量的SSL请求响应任务（明显的表现为具有较高的HTTP请求流量）。同时，这个站点也采用了硬件密钥管理器策略来管理所有的私有密钥并且负责存储它们。由于SSL的负载比较低，而为每一个web服务器都附带一个加速器是非常贵的，因为我们只需要硬件管理密钥的功能，其他的处理能力都是多余。将一个或者两个专有的硬件加速器安置在一台或者两台电脑上，就足以满足这个系统处理SSL加密和 SSL高速缓存的全部性能需求。实际上，在一台机器里SSL会话高速缓存任务就可以很好地被硬件密码装置所控制。
我们已经通过实际证明使用这种方法，可以借助两个较小的系统提供整个系统所需要的硬件密钥管理和会话高速缓存的全部要求，这两个系统可以被所有的WEB服务器所共享。任何SSL条件的变化都可以直接由专用服务器进行处理和资源定位，而无需改变Web服务器的资源配置情况。硬件密钥的预先管理已经迫使系统将安置在每一个Web服务器上的硬件密码装置分离独立开来，而此后在Web服务器之间已经没有再对SSL会话进行共享的操作了。
(2) 高SSL请求负载并且有突发静态网页访问的情况
这种情况典型地表现为站点具有较高的页面点击率，但所服务的内容大部分是比较简单的静态页面和小文件。来自于不同客户端的访问将产生大量的SSL流量。传统的做法是在WEB服务器群之前构架一个只能负载平衡器，将不同用户的网络请求按照平衡的规则转发到后端的服务器上。而每一个WEB服务器需要维护大量会话信息导致了产生了大量的并发用户的会话信息。每台Web服务器都需要高性能的处理器以满足加密操作的计算需求，同样也需要一个良好的多任务操作系统以解决大容量并发访问下的IO性能问题。
通过将加密操作和缓存操作分布到一组具有较高性能价格比的基于Intel平台的机器上，可以为整个Web服务器群提供必要的加密资源。这种加密服务器仅需要很少的物理内存、存储空间和 IO吞吐能力；他们主要作为CPU密集型的运算设备而购买。现在，这个站点就不需要如此大量的Web服务器对SSL加密进行处理，这些任务可以被转移到其他地方操作；Web服务器变得更加简单，仅需要具有足够的磁盘空间和网络传输性能就能够处理所有的静态内容的页面请求（因为所有依赖于CPU的计算操作都交给专有的后端服务器处理，web服务器可以专心做他们所擅长的任务）。
为了满足所有的服务需求（静态页面服务、SSL加密、动态网页等等）而该买高档的Web服务器将会花费高昂的费用，这种服务器要能够满足大并发数量任务下的网页服务和其他服务，具有很强的可扩展性。例如，假设SSL请求的数量没有立刻增加但是对于Web 服务的请求在不断增长，这就需要部署更多的Web服务器设备来满足要求（而且都是同样规格的高端Web服务器）。可以看得出，这种方式实际上是对Web服务器处理能力的一种浪费，本来服务的内容以Web页面为主，却要为Web服务器多余的功能多付出许多不需要的费用——加密、SSL会话缓存等等。如果我们按照模块化思想来设计这个站点，把处理网页请求、CPU密集型的SSL处理和动态网页解析等功能分别部署在不同的机器中，每种机器专著于自身的任务，就能够在系统的整体性能、可扩展性和成本有效性上获得令人满意的结果，而且也便于系统的管理。
我们应该怎么做呢？
Although most of the approaches we have discussed in this paper are readily available
today, a system to implement our final solution is not. However, all of the conceptual
ideas discussed (and the solution) can be implemented by extensions to existing open
source software. The authors already have a functioning prototype that distributes key
operations from a number of web-servers to a number of key-servers. This prototyped
framework is a proof-of-concept, and it is expected that this functionality will be
released as open source once completed.
7 如果一个服务器仅能支撑每秒20个新的连接，但是实际中每秒收到了40个连接请求，那么服务器将要以比它所能够处理的速度更快地处理收到的连接请求。这样，系统于是将最终减速直至停止（或者到系统响应延迟变成用户无法接受的程度，站点开始仅能响应每秒不到20个的网络请求）。
8例如，当一个在线购物广告在网页载入的最开始的期间就立刻显示，这个站点主页可能会收到突发的大量的网页请求，但是实际上能够坚持浏览下去，并且按照设想进行安全购物的浏览者数目反而会戏剧性的降低。
9、这里的价格基于我们在2000年一月份所能得到的产品价格列表。
10、该产品价格来自于美国的供应商，其中还包括一系列低端的监视器、软件和附件等等。
11、如果你想要使用硬件密码加速器来管理私有密钥（显然这样会安全一些），这种做法显然是必要的。但对于仅仅是为了加速的目的而采用硬件加速器的话，或者为该系统将采用非常复杂的前端负载均衡设备来处理任务分配，或者仅为一部分的服务器安装硬件加速器，否则一部分服务器的过载而另一部分服务器轻载这种不平衡的情况就会出现。
