简介
在最近的 developerWorks 系列 在 Web 服务上下文中使用 SLA 中，我谈论了使用 SLA 保证的一些功能：保护多个 Web 服务、使用防火墙保护 Web 服务以及降低漏洞风险。尽管存在各种各样的性能和标准规范，我还是侧重讨论了生产商为客户提供高可用性服务的重要性。
本文将首先对 Asynchronous JavaScript + XML（Ajax）进行概述，提出一些漏洞问题、讨论 SLA 影响，然后解释为什么具有高效带宽的 Ajax 应用程序不能保证降低或消除漏洞风险。本文还介绍了一些提高 Ajax 应用程序性能并避开 Web 服务漏洞的方法。
Ajax 概述
Ajax 通过将用户的浏览器体验（例如，企业对企业交易）转换为一个基于 XML 的 Web 服务门户（例如企业对消费者交易），实现了响应式和交互式 Web 服务。Ajax 使用的方法是在 Web 页面和服务器之间，通过 HTTP 协议构建一个额外的处理层。该层拦截来自用户的请求，然后在后台与服务器通信并异步获得所需的 HTTP 协议内容。服务器请求和响应不需要匹配用户操作，例如一个更新数据库记录的请求和一个更新成功的响应。
Web 服务漏洞
让我们解决一些有关额外处理层的问题。由于它依赖 XML 作为请求和响应负载的内容类型，Ajax 增加需要传输的 XML 流量。当出现大量的请求和响应时，Ajax 应用程序会阻塞网络通信。而更严重的问题是，大量的通信会使 Ajax 应用程序受到 Web 服务漏洞的威胁。如果这些漏洞被人利用，应用程序或系统的性能将受到损害。
让我们看看四个漏洞实例：
过高的带宽
破损数据
频繁的小型 HTTP 请求
内存泄漏
过高的带宽
文本格式的 XML 消息可能是二进制数据带宽量的两倍之多。传输 XML 消息所需的带宽越多，系统或应用程序用来执行其他任务的可用资源就越少。例如执行复杂算法来获取期望结果。过高的带宽可能导致由系统超载引起的性能减退
破损数据
过高的带宽将导致 Ajax 应用程序输出破损的数据，因为没有足够的资源生成干净的数据。这意味着 Web 服务门户（Ajax 应用程序属于其中的一部分）将把破损数据暴露给门户的其他部分，从而导致畸形消息和过度解析。如果威胁者利用了这个漏洞，则会引起浏览器崩溃。
频繁的小请求
Ajax 的一个缺点就是允许您生成大量较小的请求，而不是一个大的 post-back。频繁的、较小的 HTTP 请求会加重后端服务器、负载均衡程序和防火墙的负担，结果是造成过高的带宽，最终导致性能降低。它们还会超出浏览器或较慢的网络连接的接受能力，从而导致网络性能瓶颈。
内存泄漏
在一个典型的 Web 应用程序中，Web 页面经常重新加载，清除该页面的内存并开始一个干净的页面。使用 Ajax 时，等待 Web 服务门户呈现下一部分内容的时候不需要重新加载页面。使用 Ajax 可以在浏览器中保持一个单页面应用程序长达数天，这使内存或其它资源泄漏更加严重。过度的内存泄漏（以及过高的带宽和频繁的 HTTP 请求）可能会造成 Web 门户出现破损数据，增加了黑客从 Internet 中利用系统漏洞的风险。
风险评估
对于上面的四个例子，您需要判断威胁方利用系统和服务器漏洞的风险级别以及对业务造成的影响。如果风险较高，需要使用一些保护措施提高 Ajax 应用程序的性能。其中一种保护是使用 SLA 保证增强服务正常运行时间可用性。
Service Level Agreement
无论怎样修改 Ajax 代码来提高带宽效率，始终存在一些风险和漏洞，需要您进行监视并解决。部署高效带宽 Ajax 应用程序并不能保证 SLA 中的服务级别保持在或高于指定的性能阈值点（例如 99.9 或 99.999%）。在 Ajax 应用程序中，当应用程序通过 Internet 从浏览器应用程序转移到服务器门户时，它将更容易受到攻击，特别是用来构建 Web 服务以检测性能问题（例如包丢失）的 XML 部分
您需要考虑三件事情来改善服务运行时间的可用性。首先，要提高 Ajax 应用程序性能，应该使用一些方法改善性能而不是优化带宽（例如 XML 内容过滤和 XML 加速）。其次，要保护 Ajax 应用程序，应该考虑 Web 安全标准，例如 WS-Security（WSS）、Application Vulnerability Description Language（AVDL）以及其他标准。第三，考虑将监视这些应用程序的通信量作为度量性能的一种工具。
改进 #1. 加速应用程序
让我们查看以下这些可以加速 Ajax 应用程序的选项：
专门的硬件加速器
优化软件
消除代码冗余
XML 加速功能
解决互操作性问题
专门的硬件加速器
用硬件加速器加速 XML 通信。如果不使用加速器，加密、复杂图形和语音识别算法会占用应用程序和相关资源，因为必须执行复杂的计算才能获得理想结果。加速器通常不用于服务器端脚本。一种替代方法是将硬件加速器和优化软件结合使用。
优化软件
优化软件用于修改和压缩系统，这样应用程序执行速度更快或操作更少的内存存储量和其他资源。优化软件在便携电脑中耗电更少。要减少从服务器下载的体积和时间，需要两个步骤：
使用 ASP.Net 或 JavaScript 技术分析 Ajax 应用程序负荷。
根据负荷分析开发优化软件。
消除代码冗余
消除代码冗余的一个例子是减少 Ajax 回调的数量以及每个回调的负荷。如果回调之间存在复杂的交互，请查找并消除冗余代码。另一个例子是将 Ajax 应用程序分成多个模块，然后合并功能类似的模块，从而减少冗余。
XML 加速功能
取决于应用程序的复杂性，解析基于文本的大型 XML 文件产生了大量开销，这就抵销了使用硬件加速器和优化软件消除代码冗余带来的好处。基于文本的 XML Web 服务应用程序体积较大并且会逐渐膨胀，因此从网络、处理器和存储性能的角度来看，不具备良好的带宽效率。当使用大量的大型文件时，这些 Web 服务会阻塞网络通信，导致系统超载
Web 服务性能的一个主要阻碍因素是与 XML 有关的网络和处理开销。因此，行业趋向于标准化 XML 的二进制编码模式，例如 XML-binary Optimized Packaging Specification（XOL）Package。如系列文章的 第 7 部分（关于在企业级 SOA 中处理 Web 服务）中所述，我讨论了这种包处理大型二进制文件的效率为何高于 XML 解析器处理基于文本的文件的效率。
解决互操作性问题
不论 Ajax 应用程序如何优化，使用了哪些硬件加速器，如何降低或消除了代码冗余，您仍然需要解决互操作性问题。例如，当 Ajax 应用程序转换为企业无法控制的 Web 服务时，您要根据共享语义和合同义务确保它们在外部可以进行互操作。语义的错误理解（例如专有语义）和合同漏洞（多平台差异）会造成互操作性问题，例如将 Ajax 应用程序集成到遗留系统中。
改进 #2. Web 服务标准
让我们看一些针对 Ajax 应用程序的 OASIS Web 服务标准（OASIS 表示 Organization for the Advancement of Structured Information Standards，由 International Open Standards Consortium 领导。参见 参考资料 获得站点链接）。
WS-Security Extensions（WS-SX）
Security Access Markup Language（SAML）
Service Provisioning Markup Language（SPML）
Digital Signature Services（DSS）
Application Vulnerability Description Language（AVDL）
Ajax 通过 Internet 从浏览器应用程序转移到服务器门户产生了越来越多的安全漏洞，因此所有这些标准都是为了降低安全漏洞风险。如果应用了 XOL 包或其它二进制 XML 模式，这些标准会更高效。
WS-SX
该标准提供了实现安全功能的技术基础，例如实现更高级别的 Ajax Web 服务应用程序时保持消息的完整性和保密性。由于 WSS 只关注单个的消息交换，因此可以扩展为 WS-SX，以支持涉及多个消息交换的可信 SOAP 消息交换，并定义管理消息的格式和标记的安全策略。Web Services SecureConversation、SecurityPolicy 和 Trust 规范为 WS-SX 的开发做了不少贡献
SAML
这种标记语言定义并保持了一种基于 XML 的标准框架，用于在在线合作伙伴之间创建和交换安全信息。SAML 现在被用于 Web 单点登录、基于属性的授权和保护 Web 服务。
SPML
该标准提供了一种 XML 框架，用于管理企业内部/之间的身份信息和系统资源的供给和分配。此外，SPML 1.0 规范允许使用 WSS、XML Digital Signatures 和 XML Encryption。
DSS
该标准定义了一个可以处理 Web 服务和其他应用程序的数字签名的 XML 接口。DSS 在电子商务和其他 Web 应用程序安全性方面扮演着重要角色，它可以确保在交换并从存储中检索应用程序时 Web 数据的可靠性。DSS 规范包括用于签名创建、签名检验、时间戳和上述功能集合的服务。
AVDL
AVDL 的目标是定义一种语言，用于描述可以保护这种应用程序的信息。这些信息包括（但不限于）安全漏洞信息、已知的合法使用信息。
如果请求与响应的时间间隔非常大，中断阈值所达到的水平将会对提供运行时间可用性的 SLA 保证产生不利影响。为了减少产生这种不利影响的机会，文章 讨论了如何降低在异构的面向服务架构（SOA）中暴露 Web 服务漏洞的风险。使用 XOL 包可以进一步降低中断阈值的影响。但是降低这种影响并不代表实现了 SLA 保证。
改进 #3. 监视通信流
积极地监视通信流可以持续地度量 Ajax 应用程序的网络流量性能。它可以模仿网络数据和 IP 服务，并实时收集 Ajax 应用程序的网络性能信息。收集的内容包括：有关响应时间的数据、带宽量、单向延迟、抖动、包丢失和服务器响应时间。
对于同一个连接，可以针对不同的通信级别进行性能监视（例如高、中和低优先级）。通过将数据放入实时日志中，您可以查看在哪些位置何时出现大量的包丢失和抖动事件，响应变慢的原因以及如何通过修改应用程序的优先级来改善通信流性能。
结束语
要提高 Ajax 应用程序的性能，同时避开 Web 服务漏洞，您的团队需要由开发人员、测试人员、系统管理员和潜在用户组成。要消除冗余和内存泄漏，同时降低带宽和小的 HTTP 请求的数量，您必须提前规划 Ajax 性能改善项目的创建、测试和部署。解决了这些问题将使改善 Ajax 应用程序的性能变得更加轻松。
关于作者
Judith M. Myerson 是一名系统架构师和工程师。她研究的领域包括开源工具、中间件技术、企业级系统、数据库技术、应用程序开发、网络管理、安全性、性能管理、RFID 技术、RFID 技术和项目管理