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

基于WebSocket的实时数据的通信和展示

网络通信提供了一种方便的、超链接的，无状态的信息交换，但在实时数据交换时仍存在着一些问题。WebSocket协议降低了网络通信的开销，同时给Web服务器和客户机之间提供了一种高效地、状态化的通信。为了确定WebSocket通信是否比HTTP轮询更快，作者创建了一个web应用来测量以4Hz的速度发送实时风速传感器数据时的单向传输时延。他们实现了一个Jetty Servlet讲一个HTTP连接升级为WebSocket连接，这里他们将WebSocket协议的传输时延与HTTP轮询和长轮询的进行了对比。

时延在一些应用里是一个十分重要的问题，例如像网络控制系统这种为了保证对工业生产过程的充分控制，更新频率在10到500毫秒的应用^[1]。通过对往返时延的建模并使用UDP仅考虑最近的数据以及可能丢弃延迟的分组可以实现对因特网的闭环控制^[2]。然而，当应用必须以对等方式通过因特网连接提供实时数据时（当远程传送实时股票报价或医疗信号用于进一步处理时），时延变得非常重要。

如果消息传输间隔已知，则HTTP轮询被视为传递实时信息的良好解决方案——即当数据传输速率恒定时，如当发送传感器读数例如每小时的温度或水位时。在这种情况下，应用程序开发人员可以在已知数据可用时同步客户端以请求数据。然而，当速率增加时，HTTP轮询重复有效的报头信息的固有开销又增加了时延。由于实时HTTP Web应用的复杂性，早期的研究假设HTTP不是为实时的全双工通信而设计的^[3]。因此，HTTP只能以高代价——增加时延，高网络流量来模拟实时通信。

长轮询是HTTP轮询的一种变体，它模拟从服务器到客户端的信息推送。Comet Web应用程序模型^[4]，例如，旨在将数据从服务器推送到浏览器而不使用浏览器HTTP请求，但通常使用长轮询来实现多种浏览器的适配。在人们看来长轮询并没有对传统轮询做多大的改进。

WebSocket协议支持通过单个TCP套接字在客户端和远程主机之间进行全双工通信^[6]。WebSocket API目前是一个W3C工作草案^[7]，但相比于半双工的HTTP轮询应用，该协议估计可以减少2/3的时延^[5]。

这里，我们比较在一个实时应用中WebSocket、长轮询以及最佳情况的HTTP轮询的单向传输时延（参见“WebSocket使用方面的相关工作”侧栏，在这个领域的其他研究）。我们以4 Hz速率验证了典型的低容量通信（大约每秒100字节的传感器数据）的实时传感网络中的时延行为。

Web客户机-服务器通信

为了评估互联网的实时数据交换的有效性，我们将WebSocket通信与HTTP通信进行了比较。我们没有考虑其他互联网协议，如UDP^[8]，因为它们设计用于流式实时数据，当最新的数据更重要，允许删除较旧的信息。

HTTP轮询

HTTP轮询包括一系列请求响应消息。客户端向服务器发送请求。在接收到该请求时，服务器用新消息（如果有的话）响应请求，如果没有新消息可用于该客户端，则返回空响应。在短时间Delta;（称为轮询间隔）之后，客户机再次轮询服务器以查看是否有任何新消息可用。各种应用包括聊天，在线游戏和短信都使用HTTP轮询。

HTTP长轮询

与轮询相关联的一个缺点是当服务器没有用于客户端的新消息时对服务器进行的不必要请求的数量。长轮询作为轮询技术的一种变体，有效地处理从服务器推送到客户端的信息。
使用长轮询，服务器在意识到没有新消息可用于客户端之后不立即发送空响应。相反，服务器保存请求，直到新消息可用或超时到期。这减少了当没有新消息可用时的客户机请求数。

WebSocket

使用连续轮询，应用程序必须在来自客户机的每个请求和来自服务器的每个响应中重复HTTP头。对于应用程序来说，这会增加通信的开销。WebSocket协议提供了一个全双工，双向通信通道，通过Web上的单个套接字可以 帮助构建可扩展的实时Web应用程序^[5]。

WebSocket协议有两个部分。握手包括来自客户端的消息和来自服务器的握手响应。第二部分是数据传输。 Jetty的WebSocket API的实现完全集成到Jetty HTTP服务器和servlet容器中（见http://jetty.codehaus.org/jetty）。因此，Jetty servlet可以处理和接受将HTTP连接升级到WebSocket连接的请求。关于WebSocket通信过程的更多细节在我们以前的工作中可以找到^[9]。

架构

我们的WindComm Web应用程序使用WebSocket协议有三个主要组件：风传感器，基站计算机（服务器）和客户端。基站计算机使用称为WindComm的运行Web应用程序的Jetty服务器。此应用程序与传感器通信，并管理来自客户端的HTTP和WebSocket请求。客户端使用支持WebSocket协议和HTML5 画布元素的Web浏览器访问Web应用程序以查看实时风传感器数据 。

风传感器

Gill Windsonic是一种坚固的超声波风速传感器，没有测量风向和速度的移动部件（见www.gill.co.uk/products/anemometer/windsonic.html）。我们通过使用适配器适配器连接到基站计算机中的USB串行端口的RS232输出电缆将WindSonic连接到基站计算机。我们用振荡风扇模拟动态风。 WindSonic在三种模式下运行：连续，轮询和配置。我们使用连续模式和4 Hz的数据速率连续地发送 22字节的消息。

基站计算机

基站计算机运行实现Jetty servlet的WindComm Web应用程序。应用程序使用RXTX Java库（http://rxtx.qbang.org/wiki/index.php/Main_Page）与传感器进行通信，以访问计算机串行端口。WindComm为传感器数据提供了一个接近实时的通道，并且必须跟上传感器的4 Hz输出速率。我们实现了三个版本的WindComm Web应用程序。第一个，称为WindComm，使用Jetty的HTML WebSocket协议实现的。第二个，LongPollingWindComm，实现了HTTP长轮询，第三个，PollingWindComm，使用HTTP轮询。在所有三种方法中，我们实现了一个线程以通过基站计算机串行端口建立和维持与风传感器的通信。

对于LongPollingWindComm，我们使用Jetty的Continuations接口，它允许servlet挂起和保持客户端请求，直到事件发生或超时到期。对于LongPollingWindComm，事件是一个新的传感器测量，我们将超时设置为300毫秒，比传感器的输出速率大50毫秒。

在PollingWindComm中，servlet不保存客户端请求。将超时设置为250 ms将假设延迟为0 ms。我们知道时延明显高于此值，因此将Delta;设置为250 ms将导致PollingWindComm运行非常缓慢，因为它需要更长的时间来处理传感器观测的累积队列。因此，我们设置客户端的轮询间隔Delta;为150 ms，比传感器的输出速率小100 ms。我们还考虑了客户端解析的时间并且在再次轮询服务器之前显示从服务器接收的传感器观察。我们不会在延迟观察中计算此解析和显示时间，但是在设置轮询间隔时必须考虑它。

实验设计

我们的实验比较了WindComm，LongPollingWindComm和PollingWindComm Web应用程序的客户端和服务器之间的单向时延。图1显示了具有与我们的测试相关的标记事件的时间轴。对于LongPollingWindComm，除了t2不一定发生在t1或t0之后，时间轴类似于轮询时间轴。如果客户端请求已被保持，则在t1之后，servlet使用Continuations接口恢复，并立即将该报文发送给客户端。 servlet保留尚未在缓冲区中传输的测量数据。每个轮询版本进行轮询时，它发送所有缓冲的数据。

图1. 我们记录时间戳以评估延迟的时间历元。在所有情况下，延迟被定义为t4-t0，并且不包括解析和显示传感器测量的时间。

我们对所有三个版本的WindComm Web应用程序的延迟定义为t4 - t0。要报告此单向延迟，应用程序在服务器上为t0采用时间戳，而在客户端为t4采用第二个时间戳。为了使时间戳可比，客户端和服务器必须同步。

时间同步

网络时间协议（NTP）广泛用于通过Internet同步计算机时钟[10]。 NTP数据包是端口123上携带的UDP数据报。对于Linux，NTP是为守​​护程序连续运行而实现。此守护程序NTPd将系统时间与NTP时间服务器保持同步。我们在基站计算机和所有四个客户端测试计算机上配置NTPd以与NTP时间服务器同步。在开始测试之前，我们（或客户端位置的同事）在客户端和服务器中运行命令“ntpq -p”，直到它们报告的偏移量值都低于2 ms。服务器总是报告低于1 ms的偏移量。我们在每次测试后重复该命令，以确保偏移保持在2毫秒以下。以这种方式同步时间后，客户端通过输入相应的URL（例如http://131.202.243.62:8080/WindComm）将其支持HTML5的浏览器（Firefox 6.0.2或更高版本）定向到三个Web应用程序之一）。一旦客户端接收到消息，它需要一个本地时间戳。客户端然后解析接收的消息，提取服务器时间戳，计算延迟，并将其保存在数组中。当1200个延迟的数组被填满时，测试结束，客户端将数组的值发送到服务器。我们选择1,200的阵列大小以对应于以连续4-Hz速率的大约五分钟的测量。

测试

我们的测试在三个不同的本地时间一个接一个地运行WindComm，LongPollingWindComm和PollingWindComm，直到每个应用程序成功传递1,200个消息。每次测试运行三个应用程序所需的总时间大约为15分钟，加上延迟，启动应用程序的时间以及将结果从客户端报告给基站的时间。我们计划在上午8:00（不忙）进行第一次测试，下午1:00（正常交通）进行第二次测试，以及下午8:00（忙碌）进行第三次测试。我们选择这些时间来改变网络状态。虽然运行测试分散消息是很有趣的，也就是说，来自WindComm的一条消息后面是来自LongPollingWindComm的消息，然后是来自PollingWindComm的消息，以便为每个协议提供更可比的网络状态 —— 这是不可能的。在一个时间内，我们的基站计算机中只有一个运行的进程（一个Web应用程序）可以访问风力传感器。

我们在位于加拿大东部新不伦瑞克大学的服务器和加拿大埃德蒙顿、委内瑞拉加拉加斯、瑞典隆德以及日本长冈的客户机之间进行测试。注意，除了隆德，所有的客户机都位于大学校园。这意味着我们的测试数据可能通过连接大学校园的研究网络，而不是通过商业互联网，隆德的客户机位于一家公司的办公楼。

研究结果

表1显示了我们的评价结果​​。我们对每种方法（WebSocket（WS），长轮询（LP）和轮询（P））共进行了12次测试，在四个国家中与客户端重复三次测试。在所有36个测试用例中，服务器在开始测试后5分钟和1秒内向客户端发送1,200次测量。表1报告了测试开始时间，观察到的平均延迟mu;（ms，N = 1,200），样本标准偏差s（ms）和每个测试的 或的比率r。测试中粗体的部分我们将进行进一步的分析。

对于这里使用的实时，低容量连续数据，所有测试显示HTTP轮询时间时延明显高于WebSocket或长轮询的时间（高2.3至4.5倍）。 WebSocket协议可以具有比长轮询更低或更高的平均时延。距离较长时（例如到日本），WebSocket协议具有比长轮询显着（平均延迟3.8和4.0倍之间）更低的平均时延。

在Edmonton的选定（粗体）测试结果中，我们观察到轮询的平均延迟比WebSocket协议（151.3和40.3 ms）长3.75倍。均值统计检验的差异（具有未知的和不同的总体方差）表明零假设H0：mu;_WS-mu;_P= 0在99％置信水平上被拒绝，有利于备选假设H1：mu;_WS - mu;_Plt;0。因此，我们有足够的证据证明WebSocket协议比加拿大的HTTP轮询快得多。事实上，我们所有的统计测试都提供了强有力的证据表明，WebSocket协议总是具有比轮询低得多的延迟，低于这里进行的低容量，实时数据通信测试。从上午9:10开始的5分钟测试周期的长轮询平均延迟仅比WebSocket延迟长1.0ms。尽管如此，零假设H0：mu;_WS -mu;_P = 0在99％置信水平上被拒绝而支持备选假设H1：mu;_WS - mu;_Plt;0成立。平均等待时间为1.0ms的差值小于偏移阈值为2ms的时间同步。在所

剩余内容已隐藏，支付完成后下载完整资料

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