QoE基准在诸多方面都面临着挑战。在大多数环境中是许多网络技术一起协作的。它们支持多种协议类型，并且最终支持多种类型的应用。我不相信与EMA一起工作的仅仅是单个IT或服务供应商，而且他们也不可能只有一个简单的、独立在网络上发布应用服务的需求集。

图1：下面哪一种技术是你当前的网络所使用的？

我们先看看目前出现在大多数IT组织中的网络传输技术，如图1。许多老的技术，如帧中继和ATM无线耦合、VPN和MPLS网络等，都是作为核心Ethernet传输的虚拟覆盖。WAN、LAN和VLAN技术是一起存在的，它们与许多WiMAX技术一起构成无线网络的最后补充。

而关于QoE基准的答案都与这些所有的传输技术的问题密切相关。如果你关心QoE，你需要真正地了解你的网络的设计和性能，以便完美地使用一些可以有效地将用户“体验”与实现网络传输问题联系在一起的技术。

图2：你在网络上发布或计划发布哪一些应用？

关于QoE的更关键的是，它还与许多应用技术和应用类型有关，如图2所示。你可以从2007年获取的数据看出——EMA已经多次重复杂讨论这些数据并都得到几乎相同的结果——对于管理网络应用的性能，Web应用明显占据主导位置。这其中许多应用类型都与某种协议一起出现，比如AJAX、JAVA或ActiveX和SOAP，并且它们逐渐成为模块化的应用，这样就有更多的不同应用出现在各种地方，这扩大了用户终端（笔记本电脑、台式电脑、移动设备）和其他设备的复杂性。而随着SOA架构的普及，这种复杂性只会变得越来越大。2007年中的数据显示，SOA技术已经开始给业务经理所关注的VoIP协议带来了新的挑战。

由于篇幅所限，本文将主要关注于这个主流问题：基于Web的应用，它不同于VoIP或者视频，当然VoIP和视频也都有它们各自的问题，但这些问题应该分开讨论。其中第一个问题是：QoE要能发现网络中真实的最终用户体验。如果你还没有弄清这些事务驱动的细节，你就不能够衡量网络的性能，这往往需要借助辅助工具和比网络管理方案所提供的更多的面向应用的监测工具。所以，我准备主要关注于这些用于获取事务层状况的技术和解决方案。

近几年来讨论最热门的一个话题就是关于应用响应的“混合事务（Synthetic Transactions）”和“观察事务（Observed Transactions）”的区别。这个问题讨论的另一部分是事务监测的地点应该在哪里——如，数据中心，数据中心边界，或者在终端。而对于终端，它是否有在每一个分支办公室安装有监测工具？或者你是否需要地地毯式覆盖大范围的最终用户终端？

对于混合事务和观察事务的对比，事实上它们两个都是很有价值的。混合测试是主动的，它可以给你更一致的适合SLA需求的数据，也可以让你知道可用性是否丢失，这是观察事务一般情况下不能做到。许多混合测试也提供了诊断值，特别是当使用优化脚本去查看发生在现实世界特定类型的事务行为。另一方面，混合测试是以特定周期进行的，因此可能会无法捕捉发生在特定间隔时间内的现实问题。它们可能会为你最关心的各种用户的现实体验创建极其简单的截图。此外，许多观察功能已经逐渐变得丰富，并正在开始提供更细粒度的观测，这曾经只用在混合测试中。所以事实是，混合和观察事务都应该考虑——如果你真的关心QoE的话。

位置也是一个更应该考虑的选择，但你应该应用在哪里是基于业务需要和成本考虑的，而不是出于盲目的技术最优化目的。以数据为中心的事务监控可以提供后端办公网络的细节，这对于诊断来说是非常有用的，但是同时它也将提供大量关于QoE问题的内在信息——在某些情况下，它以影片的形式回放实际事务。这些方法能捕捉Web应用的设计问题，甚至是布局和图形化问题，这些是你可能从网络的角度上认为是完全与问题无关的。但是，当你由于网络性能下降而受到责怪，而恰恰这是由于拙劣的应用设计造成的，你就不会这样认为了。然而，还有一些解决方案提供了从用户终端提供完全服务的回放，这会更彻底地捕捉到不同动态集——它与用户终端所看到的完全一致的。同时，这其中有很多，特别是那些经过针对大量事务细节优化的都是对分支办公网络的优化，而非地毯式部署优化。这两者都是可以用的，而且坦率地说，它们提供大量的补充价值。

然后更多以网络为中心的QoE基准确定解决方案是位于数据中心边界的，它计算最终用户的体验，在某些情况下还会深入到后台办公事务中去。有些方法也提供了侦测，或者基于侦测，它们都关注于网络片段，并优化对每个应用使用带宽的评估。这些功能中许多是在网络第三层和第四层的，但几乎所有的都至少支持HTTP监控，或者支持会话层（第五层）事务的详细捕捉，而且还有一些提供了第七层的更细粒度的事务分析。虽然这些对于真正意义上的QoE而言都不是最“中肯”的，但是，有了这些观察功能，你可以更快的对问题的原因执行实际诊断，同时其中某些功能还能满足预判在远程位置上的性能下降问题。

我将以一部分供应商的列表来结束本文，他们在某个或多个方面对QoE有深刻的认识。这些包括诸如Keynote 和Gomez的服务，它们都可以提供全面的有价值的深入分析，但是都是依据传统的综合测试套件产生的。数据中心面向事务的监控工具，如Empirix（由Web和VoIP呼叫中心的交互组成）和TeaLeaf（作为细粒度事务重放和分析）由强大的终端的可见性来补充，如AlertSite、Coradiant、Symphoniq 和 Xangati。同样也有来自大型供应商的QoE的多用途功能，如Compuware、Fluke Networks、OPNET 和Quest。最后，更多的以网络中心的QoE方法补充还有来自于这些公司的产品：Apparent Networks、NetScout、NetQoS 和Shunra。

再次重申，你如何选择解决这个棘手问题的方法是一个实用性问题，其中包括成本和用以了解所有问题细节所需要的总体资源。但是，同样你该意识到QoE基准是一个广泛操作尝试，甚至理想情况下也应该与应用开发和QA/Test有关。当你还没有这方面的经验的时候，你是不能够对网络进行优化的。

关于作者：Dennis Drogseth 是Enterprise Management Associates（EMA）的副总裁。EMA是一所从事IT管理研究、分析和咨询的公司。Dennis于1998年加入EMA，目前管理New Hampshire分公司。他主导了EMA的New England的成立。Dennis在系统和网络的市场和事务计划方面有着24年的经验。他带领着一支分析员团队，专注于Networked Services Management的实际领域，其中涉及企业和电信市场的性能可用性和服务管理领域。他的团队同时还从事会计、结算、QoS、外包和其他与这些市场相关业务。