英语原文共 9 页，剩余内容已隐藏，支付完成后下载完整资料
使用WebSocket通信和显示实时数据
互联网通信提供了方便，超链接，无状态的信息交换，但在需要实时数据交换时可能会产生问题。WebSocket协议减少了互联网通信开销，并提供了Web服务器和客户端之间高效，有状态的通信。为了确定WebSocket通信是否比HTTP轮询更快，作者构建了一个Web应用程序来测量以4 Hz的速率发送实时风速传感器数据的单向传输延迟。他们实现了一个Jetty servlet来将HTTP连接升级到WebSocket连接。在这里，他们将WebSocket协议延迟与HTTP轮询和长轮询进行比较。
延迟是网络控制系统等应用中的一个重要问题，在这些系统中，工业过程的适当控制需要更新频率为10至500毫秒（ms）。通过对往返延迟进行建模并仅考虑最近的数据使用UDP，可能会丢弃延迟的数据包，就可以在Internet进行闭环控制。但是，当应用程序必须以点对点的方式通过互联网连接提供实时数据时（例如，为远程处理提供实时股票报价或医疗信号时），延迟变得非常重要。
如果消息传输间隔是已知的，即当数据传输速率不变时，如发送传感器读数（如小时温度或水位），HTTP轮询就被认为是传送实时信息的一个很好的解决方案。在这种情况下，应用程序开发人员可以在客户端已知可用时同步客户端以请求数据。然而，当速率增加时，HTTP轮询自带的开销会重复重要的头信息，从而增加延迟。此前的研究表明，由于实时HTTP Web应用程序的复杂性，HTTP并未设计用于实时全双工通信。因此，HTTP只能以较高的代价模拟实时通信 - 增加延迟和较高的网络流量。
WebSocket使用中的相关工作
许多研究人员已经测试并继续测试实时应用程序的WebSocket使用情况。 Bijin Chen和Zhiqi Xu开发了一个框架，该框架使用基于浏览器的多人在线游戏的WebSocket协议。他们使用WebSocket实现并使用Wireshark软件在LAN以太网网络中评估性能，以捕获并分析IP数据包的大小网络。在三个游戏客户端状态更新之间的时间间隔为50毫秒时，他们的测试表明WebSocket协议足以处理每秒96,257字节（758个数据包）的服务器负载。
Peter Lubbers和Frank Greco在每秒更新股票报价的应用程序中将WebSocket协议与HTTP轮询进行比较。他们的分析显示，三比一的延迟减少和HTTP报头流量的减少最多可达500比1。然而，这项研究尚未回答的一个问题是，WebSocket协议通信的开销较少的优势是否在广域网上持续存在。
我们在主要文章中的调查探讨了WebSocket协议通过互联网长距离传输的效率。我们与位于不同国家和不同时间的客户进行实验验证，以探测各种网络条件。
参考文献
1.B. Chen和Z. Xu，“使用Webgl和Websocket的基于浏览器的多人在线游戏框架”，Proc。 国际会议 多媒体技术（ICMT 11），IEEE Press，2011，第471-474页。
2.P. Lubbers和F. Greco，“HTML5Web Sockets：网络可扩展性的一次飞跃”，SOA世界杂志，2010年3月; http://soa.sys-con. com/node/1315473.
长轮询是HTTP轮询中的一种变体，它模拟从服务器到客户端的信息推送。 例如，Comet Web应用程序模型设计用于在没有浏览器HTTP请求的情况下将数据从服务器推送到浏览器，但通常使用长轮询来实现以适应多个浏览器。 相对于传统的轮询，长时间轮询不会提供任何实质性改进。
WebSocket协议允许通过单个TCP套接字在客户端和远程主机之间进行全双工通信.WebSocket API目前是W3C的工作草案，但该协议估计可提供三比一的延迟，双工HTTP轮询应用程序。
在这里，我们比较实时应用程序中WebSocket的单向传输延迟，长轮询和HTTP轮询的最佳情况（请参阅本文的其他研究的“WebSocket用法的相关工作”侧栏）。我们通过实验验证了实时传感器网络典型的低容量通信（大约每秒100个字节的传感器数据）在4 Hz速率下的延迟行为。
Web客户端 - 服务器通信
为了评估互联网对实时数据交换的有效性，我们比较了WebSocket与HTTP的通信。我们并没有考虑其他互联网协议，例如UDP，因为它们是为最新数据更重要的流式传输实时数据而设计的，并允许丢弃较旧的信息。
HTTP轮询
HTTP轮询由一系列请求 - 响应消息组成。客户端向服务器发送请求。 收到此请求后，服务器会响应新消息（如果有），或者如果没有新消息可用于该客户机，则响应为空响应。经过一段时间（称为轮询间隔）后，客户端再次轮询服务器以查看是否有新消息可用。包括聊天，在线游戏和短信在内的各种应用程序都使用HTTP轮询。
HTTP长轮询
与轮询相关的一个弱点是在客户端没有新消息时向服务器发出的不必要请求的数量。长轮询是轮询技术的一种变体，可有效处理从服务器到客户端的信息推送。通过长轮询，服务器在意识到没有新消息可用于客户端后，不会立即发送空响应。相反，服务器保存请求，直到有新消息可用或超时过期。 当没有新消息可用时，这减少了客户端请求的数量。
通过连续轮询，应用程序必须在来自客户端的每个请求以及来自服务器的每个响应中重复HTTP标头。取决于应用程序，这可能会导致通信开销增加。 WebSocket协议提供了一个全双工的双向通信通道，通过Web上的单个套接字进行操作，可以帮助构建可伸缩的实时Web应用程序。
WebSocket协议有两部分。 握手由来自客户端的消息和来自服务器的握手响应组成。第二部分是数据传输。 Jetty的WebSocket API实现完全集成到Jetty HTTP服务器和servlet容器中（请参阅http://jetty.codehaus.org/jetty）。 因此，Jetty servlet可以处理并接受将HTTP连接升级到WebSocket连接的请求。有关WebSocket通信过程的更多详细信息可在我们之前的工作中获得。
结构
我们使用WebSocket协议的WindComm Web应用程序有三个主要组件：风力传感器，基站计算机（服务器）和客户端。基站计算机使用运行名为WindComm的Web应用程序的Jetty服务器。此应用程序与传感器通信并管理来自客户端的HTTP和WebSocket请求。客户端访问Web应用程序以使用支持WebSocket协议和HTML5的Canvas元素的Web浏览器查看实时风传感器数据。
风传感器
Gill WindSonic是一款功能强大的超声波风速传感器，不含可测量风向和风速的移动部件（请参阅www.gill.co.uk/products/austomometer/windsonic.html）。我们将WindSonic通过RS232输出电缆通过适配器连接到基站计算机的USB串行端口，从而将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 ms，比传感器的输出速率高出50 ms。
在PollingWindComm中，servlet不保存客户端请求。将超时设置为250 ms将假定延迟为0 ms。我们知道等待时间明显高于此，所以将Delta;设置为250 ms将导致PollingWindComm运行速度非常缓慢，因为处理传感器观测的累积队列需要更长的时间。因此，我们将客户端的轮询间隔Delta;设置为150 ms，比传感器的输出速率小100 ms。我们还考虑了在再次轮询服务器之前客户端解析并显示从服务器接收到的传感器观察值的时间。我们不会在延迟观察中计算这个分析和显示时间，但是在设置轮询间隔时必须考虑它。
实验设计
我们的实验比较了WindComm，LongPollingWindComm和PollingWindComm Web应用程序在客户端和服务器之间的单向延迟。图1显示了一个具有与我们的测试相关的标记事件的时间线。对于LongPollingWindComm，时间线类似于轮询时间线，除了不一定发生在或之后。如果客户端请求被保留，则在之后，servlet使用Continuations接口继续，并立即将数据包发送到客户端。该小服务程序将尚未传输的测量数据保存在缓冲区中。每次轮询版本发生轮询时，它会发送所有缓冲数据。
我们对WindComm Web应用程序的所有三个版本的延迟定义是 - 。 为了报告这种单向延迟，应用程序在服务器上为取时间戳，在时在客户端上取第二个时间戳。为了使时间戳具有可比性，客户端和服务器必须同步。
图1.我们记录时间戳以评估延迟的时间轮次。在所有情况下，延迟定义为- ，不包括解析和显示传感器测量的时间。
时间同步
网络时间协议（NTP）广泛用于同步互联网上的计算机时钟.10 NTP数据包是端口123上携带的UDP数据报。对于Linux，NTP作为守护程序实现以连续运行。该守护程序NTPd将系统时间与NTP时间服务器保持同步。我们在基站计算机上配置了NTPd，并且所有四台客户机测试计算机都与NTP时间服务器同步。在开始测试之前，我们（或位于客户端的同事）在客户端和服务器上运行命令“ntpq -p”，直到它们各自报告的偏移量低于2 ms。服务器始终报告1毫秒以下的偏移量。我们在每次测试之后重复了命令，以确保偏移量保持在2 ms以下。以这种方式同步时间后，客户通过输入适当的URL（例如http://131.202.243.62:8080/WindComm）将其支持HTML5的浏览器（Firefox 6.0.2或更高版本）指向三个Web应用程序之一/）。
一旦客户端收到一条消息，它就会使用本地时间戳。然后客户端解析收到的消息，提取服务器时间戳，计算延迟时间，并将其保存在一个数组中。当1,200个延迟的数组被填满时，测试结束，客户端将数组的内容发送到服务器。我们选择了1,200的阵列大小，以连续4Hz的速率对应大约五分钟的测量。
测试
我们的测试在当地三个不同时间运行WindComm，LongPollingWind-Comm和PollingWindComm，直到每个应用程序成功交付1,200条消息。为每个测试运行三个应用程序所需的总时间约为15分钟，加上延迟时间，启动应用程序的时间以及将结果从客户端报告给基站的时间。我们计划在早上8点左右进行第一次测试（不忙），第二次测试大约在下午1点左右。（正常交通），第三次测试大约在晚上8点左右。（忙）。我们选择这些时间来改变网络状态。尽管运行测试散布消息会引起人们的兴趣 - 也就是说，一个来自WindComm的消息随后是一个来自LongPollingWindComm的消息，然后是一个来自PollingWindComm的消息，以便为每个协议提供更可比较的网络状态 - 这是不可能的。我们的基站计算机中只有一个运行过程（一个Web应用程序）可以一次访问风速传感器。
我们在位于加拿大东部新布伦瑞克大学的服务器与加拿大埃德蒙顿的客户之间进行了测试;委内瑞拉加拉加斯;瑞典隆德;和日本的长冈。请注意，除了隆德之外，所有客户均位于大学校园内。这意味着我们的测试数据可能通过连接大学校园的研究网络而不是商业互联网。隆德的客户位于公司办公楼内。
在所有36次测试中N=1200，粗体行表示选择进行进一步分析的测试。
* WS：WebSocket; LP: 长轮询; P: 轮询
图2. WindComm Web应用程序通信行为我们展示（a）WebSocket行为; （b）le;125 ms时的长查询行为; 和（c）gt; 125 ms时的长轮询行为。 测量以每Mms一次的恒定速率进行。
结论
表1显示了我们评估的结果。我们针对每种方法（WebSocket（WS），长轮询（LP）和轮询（P））共进行了12次测试，每个测试都与四个国家/地区的客户重复进行三次测试。在所有36个测试案例中，服务器在开始测试后的5分钟和1秒内向客户端交付了1200次测量结果。表1报告了每个测试的测试开始时间，观察到的平均潜伏期mu;（ms，对于N = 1,200），样本标准偏差s（ms）和或的比率r。粗体测试是我们选择进行进一步分析的测试。
对于此处使用的实时低量连续数据，所有测试都显示HTTP轮询平均延迟显着高于WebSocket或长轮询的2.3-4.5倍。与长轮询相比，WebSocket协议可能具有更低或更高的平均延迟。在距离较远的地方（比如到日本
全文共9297字，剩余内容已隐藏，支付完成后下载完整资料
资料编号：[13571]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
