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

使用WebSocket通信和显示实时数据

互联网通信提供了一种方便，超链接，无状态的信息交换，但在需要实时数据交换时可能会出现问题。WebSocket协议减少了Internet通信开销，并在Web服务器和客户端之间提供高效，有状态的通信。为了确定WebSocket通信是否比HTTP轮询更快，作者构建了一个Web应用程序来测量以4Hz的速率发送实时风传感器数据的单向传输延迟。他们实现了一个Jettyservlet来将HTTP连接升级到WebSocket连接。在这里，他们将WebSocket协议延迟与HTTP轮询和长轮询进行比较。

延迟是网络控制系统等应用中的一个重要问题，其中需要10到500毫秒（ms）的更新频率才能充分控制工业过程。[1]通过对往返延迟进行建模和使用，可以实现因特网上的闭环控制[2]，由于UDP仅考虑最新数据，可能丢弃延迟数据包。然而，当应用程序必须以互联网方式通过互联网连接提供实时数据时（如远程提供实时股票报价或医疗信号以进行进一步处理），延迟变得非常重要。HTTP轮询被认为是提供实时信息的良好解决方案。消息传递间隔是已知的-也就是

说，当数据传输速率恒定时，如传输传感器读数，例如每小时温度或水位。在这种情况下，应用程序开发人员可以同步客户端，以便在已知可用时请求数据。但是，当速率增加时，HTTP轮询固有的开销会重复显著的头信息，从而增加延迟。早期的研究表明，由于实时HTTPWeb应用程序的复杂性，HTTP并不是为实时全双工通信而设计的[3]。因此，HTTP只能以高价格模拟实时通信—增加延迟和高网络流量。

长轮询是HTTP轮询的一种变体，它模拟从服务器到客户端的信息推送。例如，CometWeb应用程序模型[4]用于在没有浏览器HTTP请求的情况下将数据从服务器推送到浏览器，但通常使用长轮询来实现，以适应多个浏览器。与传统轮询相比，长轮询不会提供任何实质性的改进[5]。WebSocket协议通过单个TCP套接字实现客户端和远程主机之间的全双工通信[6]。WebSocketAPI目前是W3C工作草案，但是该协议估计可以减少针对半双工HTTP轮询应用程序的延迟达到三比一[5]。在这里，我们比较WebSocket的单向传输延迟，长轮询和HTTP轮询的最佳情况。实时应用程序（请参阅“WebSocket使用中的相关工作”侧栏以了解该领域的其他研究）。我们通过实验验证了实时传感器网络典型的低容量通信（传感器数据大约每秒100字节）的4Hz速率的延迟行为。

Web客户端-服务器通信

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

HTTP轮询

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

HTTP长轮询

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

WebSocket

通过连续轮询，应用程序必须在来自客户端的每个请求和服务器的每个响应中重复HTTP标头。根据应用程序的不同，这会导致通信开销增加。WebSocket协议提供全双工双向通信通道，可通过Web上的单个插槽进行操作，并可帮助构建可扩展的实时Web应用程序[5]。

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

架构

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

风传感器

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

基站计算机

基站计算机运行了实现Jettyservlet的WindCommWeb应用程序。应用程序与传感器通信使用RXTXJava库(http://rxtx.qbang.org/wiki/index.php/Main_Page)访问计算机串行端口。WindComm为传感器数据提供近实时通道，并且必须跟上传感器的4Hz输出速率。我们在三个版本中实现了WindCommWeb应用程序。第一个叫做WindComm，它使用Jetty实现的HTMLWebSocket协议。第二个是LongPollingWindComm，它实现HTTP长轮询，第三个是PollingWindComm，它使用HTTP轮询。在所有这三种方法中，我们实施了一个线程，通过基站计算机串口建立并保持与风传感器的通信。

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

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

实验设计

我们的实验比较了WindComm，LongPollingWindComm和PollingWindCommWeb应用程序的客户端和服务器之间的单向延迟。图1显示了标记事件的时间轴，这些事件与我们的测试相关。对于LongPollingWindComm，时间轴类似于轮询时间线，除了t2不一定在t1或t0之后发生。如果已经保留了客户端请求，则在t1之后，servlet将使用Continuations接口恢复，并立即将数据包发送到客户端。servlet保存尚未在缓冲区中传输的测量数据。每次轮询版本发生轮询时，它都会发送所有缓冲的数据。我们对WindCommWeb应用程序的所有三个版本的延迟定义是t4-t0。为了报告这种单向延迟，应用程序在服务器上为t0采用时间戳，在客户端为t4采用第二个时间戳。要使时间戳具有可比性，必须同步客户端和服务器。

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

时间同步

网络时间协议（NTP）广泛用于通过Internet同步计算机时钟.10NTP数据包是端口123上承载的UDP数据报。对于Linux，NTP实现为守​​护进程以连续运行。此守护程序NTPd使系统时间与NTP时间服务器保持同步。我们在基站计算机上配置了NTPd，并且所有四台客户端测试计算机都与NTP时间服务器同步。在开始测试之前，我们（或客户端位置的其他同事）在客户端和服务器中运行命令“ntpq-p”，直到他们每个都报告偏移幅度低于2毫秒。服务器始终报告低于1毫秒的偏移量。我们在每次测试后重复该命令，以确保偏移保持在2ms以下。在以这种方式同步时间之后，客户端通过输入适当的URL（例如http://131.202.243.62:8080/WindComm/）将其支持HTML5的浏览器（Firefox6.0.2或更高版本）指向三个Web应用程序之一）。

客户端收到消息后，会立即获取本地时间戳。然后，客户端解析收到的消息，提取服务器时间戳，计算延迟，并将其保存在数组中。当填充1,200个延迟的数组时，测试结束，客户端将数组的内容发送到服务器。我们选择1,200的阵列大小以对应于以连续4Hz速率进行的大约五分钟的测量。

测试

我们的测试在三个不同的本地时间一个接一个地运行WindComm、LongPollingWindComm和PollingWindComm，直到每个应用程序成功传送1,200条消息。每次测试运行三个应用程序所需的总时间约为15分钟，加上延迟，启动应用程序的时间以及从客户端向基站报告结果的时间。我们计划在上午8点左右（不忙的时候）进行第一次测试，第二次测试时间为下午1点左右。（正常速度），第三次测试在晚上8点左右。（忙碌的时候）。我们选择这些时间来改变网络状态。尽管运行测试穿插消息会很有趣-

也就是说，来自WindComm的一条消息后跟一条来自LongPollingWindComm的消息，然后是来自PollingWindComm的一条消息，为每个协议提供更具可比性的网络状态-这是不可能的。我们的基站计算机中只有一个运行进程（一个Web应用程序）可以一次访问风传感器。我们在位于加拿大东部新不伦瑞克大学的服务器与加拿大埃德蒙顿、委内瑞拉的加拉加斯、瑞典的隆德和日本的长冈的客户端之间进行了测试。请注意，除隆德外，所有客户都位于大学校园内。这意味着我们的测试数据很可能通过连接大学校园而不是商业互联网的研究网络进行。隆德的客户端位于公司办公楼。

结果

表1显示了我们的评估结果。我们为每种方法运行了总共12次测试-WebSocket（WS），长轮询（LP）和轮询（P），在四个国家/地区与客户端重复每次测试三次。在所有36个测试案例中，服务器在开始测试后的5分钟和1秒内向客户端提供了1,200个测量值。表1报告了测试开始时间，观察到的平均潜伏期mu;（ms，对于N=1,200），样本标准偏差s（ms）以及每个测试或的比率r。标记为粗体的测试是我们选择用于进一步分析的测试。<!--

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

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