了解应用程序代理应用程序代理是一种软件，作为垫片插入到应用程序数据流（通常在 OSI 模型的第 4-7 层之间运行）中间，以 “修复 “应用程序中导致其在广域网连接中性能不佳的特性。
这些 “修复 “往往分为两种：
- 有助于重复数据删除的应用数据；或
- 有助于减少两个应用端点通过广域网连接所需的通信总量（”聊天”）。
应用代理（Riverbed 等传统广域网优化供应商使用）是一项老技术，如今在广域网优化领域的使用频率越来越低。 
以下是这种转变的五大原因：1) 应用程序代理很容易 “破坏 “许多它们声称可以帮助的应用程序。这是迄今为止广域网优化技术在很大程度上脱离 “七层代理 “模式的最大原因。 应用程序代理需要按照应用程序协议的准确规范编写。 对于稳定的低级协议（如 SSL）来说，这通常没有问题，但对于高级的专有协议（如 MS-SQL 或 Citrix ICA）来说，这就成了问题。 这些协议经常变更，变更后的协议不会公布。 在网络管理员的世界里，服务器升级是经常发生的事情，而当用户开始抱怨应用程序无法正常运行时，第一个线索就是应用程序协议发生了变化。 一旦确定应用程序代理是造成故障的原因，就需要升级代理，使其与新的应用程序版本兼容。 而且，由于这些协议通常必须由代理提供商进行反向工程，因此这种故障的 “修复 “可能需要几个月或更长的时间（取决于它是否被视为 “广泛使用”）才能提供。 这样，网络管理员就只有两个选择： 1) 告诉服务器管理员网络不支持新的应用程序版本；或 2) 将应用程序代理设置为忽略（旁路）新应用程序，基本上不对应用程序进行任何优化。 2) 某项协议慢慢停止使用。 如今，一些专有加密协议（如 MAPI）就是这种过渡的一个例子。
MAPI 是微软专有的 Exchange Server 电子邮件协议，但随着更多基于云和 SaaS 应用程序的发展，SSL 正迅速成为 SOHO 和移动用户首选的企业协议。
由于微软也支持 SSL 用于 Exchange 电子邮件的传输，许多公司正在从 MAPI 转向非专有的 SSL。
随着应用程序从专有协议发展而来，这些类型的代理服务器就会过时。 3) 广域网优化技术已经发展到不再需要特定代理的地步。 NFS 就是一个很好的例子。
NFS v3 作为一种文件共享协议，在吞吐量和与广域网延迟相关的终端用户响应时间方面存在一定的局限性。
这主要是因为协议的设计方式限制了在不接收应用程序响应的情况下一次传输的数据量。
与此同时，现有的广域网优化技术主要侧重于重复数据删除，以此来减少需要在广域网上来回发送的数据总量，从而消除拥塞，缩短响应时间。
但这些老式广域网优化技术使用的是一种数据块级重复数据删除，对 NFS 流量效果不佳，因为要匹配一个数据块，必须知道传输中数据部分的起始位置。
在 NFS 协议传输中，数据部分的位置可能会有所不同。
当时，”解决 “NFS 广域网问题的最佳方案是编写一个应用程序代理，人为减少协议所需的通信量，同时找出 NFS 传输中数据部分的位置，以便有效地进行块级重复数据删除。
传统的广域网优化供应商仍需要使用垫片来优化 NFS，因为他们仍在使用较早的重复数据删除技术，但较新的供应商可以优化 NFS 流量，而无需特定的应用程序代理，代理优化的最小化意味着网络中需要破坏的东西更少！ 4) 一些 10 年前在广域网连接上不能很好工作的应用程序或协议，经过演变或重新设计，可以在广域网上工作，而无需中间垫片。 我们再来看看 NFS。
时至今日，NFS v4.x 的后期版本已经修复了大部分与聊天和吞吐量相关的协议限制。
剩下的限制通过通用 TCP 优化来解决，而不需要针对特定应用的垫片。 5) 从业务和开发的角度来看，”应用程序代理 “技术架构不是一种可持续的模式。 首先，它的维护成本非常高。
每当应用程序供应商发布新版本的应用程序或其更新时，都必须为应用程序代理开发新的特定优化机制。
以 Citrix ICA 为例，他们拥有该协议，可以随时更改协议规格；从一个版本到另一个版本，甚至在一个服务包更新中。
跟踪所有这些应用程序代理并继续支持过时的协议并不是一种非常有效的商业模式。
它还限制了未来的可扩展性。
代理的本质是代表远程服务器行事。
为此，代理必须终止并跟踪每个应用程序会话。
这在硬件要求方面造成了非常高的开销，导致需要越来越大的盒子。
幸运的是，曾经由应用层代理解决的问题现在都能以更有效的方式得到解决，从而使旧代理技术的一些原有优势变得过时。
目前仍有一些应用层协议（如旧版本的 CIFS 或 SMB）需要使用特定代理来优化广域网，但这一名单正在不断缩短。
通过减少对特定应用层代理的依赖，当今的技术可以提供更好的优化，同时提高可靠性并消除潜在的故障点。
