基于XMLHttpRequest, Server-Sent和WebSocket的网络系统的性能分析外文翻译资料

英语原文共 13 页，剩余内容已隐藏，支付完成后下载完整资料

基于XMLHttpRequest, Server-Sent和WebSocket的网络系统的性能分析

摘要 这篇文章作者的目标是为了分析基于网络并使用XMLHttpRequest, Server-Sent事件和WebSocket的系统的性能。专用工具的出现使上述技术的性能研究成为可能。展示了说明在调查从客户端到服务端、从服务端到客户端及双向的传输事件中工具的操作方法的图表。研究的结果基于针对两个网络服务器和四个浏览器的在本地网络和互联网的专用工具的帮助。获取的结果经过讨论并得出了适当的结论。未来研究的方向也被确定。

关键词 网络系统bull;性能分析bull;XMLHttpRequestbull;Server-Sent事件bull;WebSocket

1 绪论

基于网络的系统性能可以用许多方式提高，其中一个方法可以通过使用现有的与应用领域不同的解决方案。在这篇文章中[1]，作者强调提高通过创建在线游戏的惯例支持远程协作的操作的问题。诸如丢包、移动和无线网络的弱覆盖和受限的传输带宽等问题都被多人游戏的创造者解决，并且他们的经验可以在例如构建支持远程协作的系统中应用。

许多有关缩减的网速和大型的传输消息的问题可以被数据压缩手段解决。正如这篇文章[2]描述的，并且包括GMC（General Message Compressor通用消息压缩器）压缩技术的研究。这种技术的开发者通过文章中的研究证明了他们的创造的有效性。这种工具的使用可以使常用消息格式的基于纯文本的消息相比原大小减少至多20%，对于XML格式可以减少至多8%。压缩是数据传输的复杂过程中可以寻找提升的众多领域之一。

对网页应用开发者来说，为应用需求量身选择合适数据传输技术是非常重要的。这个问题是本文的主题，在一下文献[3, 4, 5]中被广泛讨论。在文章[5]中作者检测了基于以下技术构建的应用程序的性能：XHR, Java小程序和WebSocket。在测试中，从浏览器到服务器和相反方向每秒发送的消息数量被选为性能尺度。根据这个研究，作者指明了WebSocket是产出最好结果的技术。

鉴于以上论据，可行技术的研究和分析、使创造越来越好的网页应用解决方案成为可能的工具和远离受限的桌面应用的运动支持着高效和快捷可行的网页应用。网页应用的性能是一个多方面的问题，因此提升可以从许多领域搜寻。

本文作者的目标是分析使用XMLHttpRequest[6], Server-Sent事件[7]和WebSocket[8, 9]的基于网络的系统的性能。另一个提出的论点是，技术的优劣特征和技术表现最好的应用情况的确认。

W. Słodziak bull; Z. Nowak (@)

Wrocław University of Technology, Wrocław, Poland

e-mail: ziemowit.nowak@pwr.edu.pl

2 性能测量工具的描述

出于测试的目的，专用工具被开发用来测量发送一条消息和一对消息的平均时间，依靠使用的技术和测试场景。该工具由客户端（在浏览器一侧）和服务端两部分组成。

客户端部分用来生成消息、控制测试和显示结果。为了这个目标，创建了执行操作客户端和服务端的图形界面。通过界面，测试序列可以被执行，界面也可以读取结果和控制影响发给或来自服务器的消息数量和类型的参数。可以被设置给每个被调查的技术的参数包括：

• 在一个序列中发送的消息数量，
• 消息类型：
• 固定大小的消息-以字节为单位指定的大小，
• 随机大小的消息-以字节为单位指定最小值和最大值范围，
• 增长大小的消息-以字节为单位指定每个随后消息的增量。

服务端部分负责接收和发送消息给浏览器。为了从服务端到客户端传输消息，消息生成方法是以客户端实现相同的方式。

工具被设计成一种对被研究的技术的可行比较。为了这个目标，三种模块被实现用来比较相同应用的多种技术组合：

• 从客户端到服务端通信，
• 从服务端到客户端通信，
• 双向通信。

在每个模块中，两组技术被用来满足相同需求，但自身实现方式不同。

2.1 从客户端到服务端通信

为了从客户端到服务端的通信，XMLHttpRequest和WebSocket技术被运用（图1）。WebSocket也允许在相反方向发送消息，不过在这种组合中并没有使用。

图1 从客户端到服务端通信的图表：a XMLHttpRequest技术，b WebSocket技术

在运用XMLHttpRequest技术的情况下，在浏览器和服务器之间提前建立一个特殊连接是不必要的，因为接收HTTP协议消息是一个标准的网络服务器功能。

对于WebSocket技术情况不同，它需要客户端的初始化（浏览器）。浏览器报告它愿意打开TCP连接（通过JavaScript），然后服务端协调，提供运行在它上面的实现了功能的应用。建立的连接通过通信来维持。

2.2 从服务端到客户端通信

Server-Sent事件和WebSocket技术被用于从服务端到客户端通信（图2）。两种技术都允许从服务器到浏览器（客户端）发送消息。WebSocket也允许在相反方向发送消息，不过在这种组合中并没有使用。

Server-Sent事件技术基于HTTP协议。浏览器通过在URL参数中创造（通过JavaScript）一个事件源对象列表发起连接，一个Java Servlet实现的SSE被分配。服务器，为了建立一个持续的连接，返回一个部分的HTTP回应，带有HTTP Content-Type = text/event-stream头部。

图2 从服务端到客户端通信的图表：a Server-Sent事件技术，b WebSocket技术

图3 双向通信的图表：a Server-Sent事件 XMLHttpRequest技术，b WebSocket技术

2.3 双向通信

Server-Sent事件连同XMLHttpRequest和WebSocket技术被用于双向通信的目的（图3）。第一组技术可以连续地从服务端到客户端和从客户端到服务端发送消息，他们的结合使双向通信成为可能。WebSocket则是一种自身保证这种通信的技术。

Server-Sent事件和XMLHttpRequest技术的结合是一个完全基于HTTP协议的解决方案。这种通信的初始化需要，如前所述，JavaScript和一个特殊的实现SSE的Java Servlet。从客户端到服务端传输消息除了获取HTTP Post消息不需要一个额外的实现。

3 性能测试

该研究涉及两种服务器，Apache Tomcat和Glassfish，它们都有一个内建的模块用于运行Java Servlet的Web容器。这两种服务器的不同之处在于，Tomcat仅仅是一个Servlet的容器而Glassfish也是一个Java EE容器，意味着扩展了它的功能。也可以用其他更流行的服务器，但是那种情况需要安装Web容器模块。该研究使用了两台计算机进行，其中一个安装了应用服务器用于运行测试，另一个安装了四个流行网页浏览器的当前版本：

• Chrome-版本43，
• Firefox-版本37
• Opera-版本29
• IE-版本11

使用的计算机有以下的特征参数：

• 服务端
• 操作系统-Windows 7 Pro x64，
• 处理器-Intel Core 2 Duo T6600，
• 内存-4GB RAM，
• 硬盘-300GB。
• 客户端
• 操作系统-Windows 8.1 x64，
• 处理器-Intel Core i7-4710HQ 2.5GHz，
• 内存-8GB RAM，
• 硬盘-128GB SSD

研究使用LAN和WAN网络进行。在涉及LAN网络的测试中，客户端和服务端之间的连接由WiFi接入点提供，作为路由器持续运行。在涉及WAN网络的测试中，客户端通过弗罗茨瓦夫理工大学的国际学术漫游网络的WiFi接入点连接到到互联网，而服务端通过Neostrada网络（ASDL）的WiFi接入点。

在开始目标测试之前，进行了初始模拟来确定测试序列中发送消息的数量，给出满意的结果。为了达到这样的目标，客户端-服务端模块和XHR技术的许多测试通过不同数量的消息以测试序列发送来进行。选定的总量是1000，因为与2000的标准差差别很小，也出于缩短测试时间的需要，与每序列的消息数量直接成比例。值得注意的是在一个测试序列中消息数量越大，测试结果越好，因为有关当前由于在两台机器上额外进程运行和意外网络负载导致的噪声的错误被减少了。

目标研究由三个工具内实现的通信模块进行。

测试序列的结果是传输1000条独立或成对的消息（双向通信条件下）的平均时间。时间被测量，正如描述工具内通信的图（图1，2和3）展示的那样。进行的研究涉及以下调整过的参数：

• 客户端（浏览器），
• 服务器，
• 网络类型（LAN/WAN）
• 单个序列的消息数量。

由于研究的限度，只有选定的结果会被展示。

3.1 从客户端到服务端通信

研究的第一种消息传输类型是从客户端到服务端通信。在这种情况下，工具让一种使用XMLHttpRequest另一种使用WebSocket技术。

在图4中可以看出一种本地网和全球网之间结果的大体传播趋势。选定的技术在本地网获得了比全球网更好的结果，这是符合逻辑的因为得益于包传输路径短，本地网络下通信几乎是即时的。此外，因为网络负载情况，通信伴随着更少的噪声，因此生成了更稳定的结果。

对于Tomcat服务器，XMLHttpRequest技术在本地网和全球网都比WebSocket得出了更差的结果。

图4 在Chrome浏览器及Tomcat服务器上不同大小消息传输时间

图5 在本地网络不同大小消息传输时间（各浏览器性能表现算术平均值）

图5展示了一个给定技术在Tomcat和Glassfish服务器上的性能比较。它显示了当使用Tomcat服务器时，XMLHttpRequest技术总是比同条件的WebSocket慢。当使用Glassfish服务器时，两种技术有相似的时间并且图形在两处交汇。WebSocket只在小型消息时有很大优势。

从图表可以得出结论，Tomcat服务器在客户端到服务端通信时更高效。在任何情况下，同种技术在Tomcat服务器上都表现更好。此外，在大多数研究的消息大小情况下，XHR技术在Tomcat上都得到了比WebSocket在Glassfish上更短的时间。相反的结果仅在消息大小小于5000字节的情况。

3.2 从服务端到客户端通信

工具的服务端到客户端通信模块被用来比较Server-Sent事件和WebSocket技术。因为IE浏览器不支持SSE技术，前者被从之后的研究中剔除。

图6显示了不同大小的消息从Tomcat服务器到Opera浏览器的平均传输事件。细心的观察者会发现WebSocket技术在更大消息的情况下全球网得到的结果比本地网更好。这是一个预料之外的结果，因为LAN没有像全球网那样的延迟。这个结果可能是随机现象导致的，比如网络或CPU的突然异常负载。它没有在测试的每一种浏览器上发生。

另一个适用于其他浏览器的现象，是在消息大小大于7500字节时，Server-Sent事件技术的消息发送平均事件明显变长。这种现象并没有在使用Glassfish服务器的测试中被观察到，如图7所示。

图6 不同大小的消息对于Opera浏览器和Tomcat服务器消息传输时间

图7 不同大小的消息对于Chrome浏览器和Glassfish服务器消息传输时间

在Glassfish服务器情况下WebSocket和SSE技术获得了非常相似的结果。对小型消息传输序列来说，LAN比WAN时间更短。对消息大小在7500-10000字节时，全球网开始获得优势，无论是什么浏览器。这种表现可能是因为在LAN下客户端和服务器使用了相同的WiFi接入点（该设备因此处理双倍工作）导致的。 剩余内容已隐藏，支付完成后下载完整资料

资料编号：[23165]，资料为PDF文档或Word文档，PDF文档可免费转换为Word