英语原文共 9 页
与WebSocket通信和显示实时数据
Internet通信提供了方便、超链接、无状态的信息交换，但在需要实时数据交换时可能存在问题。WebSocket协议减少了Internet通信开销，并在Web服务器和客户机之间提供高效、有状态的通信。为了确定WebSocket通信是否比HTTP轮询更快，作者构建了一个Web应用程序来测量以4赫兹。他们实现了一个jetty servlet来将HTTP连接升级到websocket连接。在这里，他们将WebSocket协议延迟与HTTP轮询和长轮询进行比较。
延迟是网络控制系统等应用程序中的一个重要问题，在网络控制系统中，需要10到500毫秒（ms）的更新频率来充分控制工业过程。1通过模拟往返延迟并使用UDP仅考虑最新数据（可能是discar）2，可以在Internet上进行闭环控制。叮当延迟的包。然而，当应用程序必须以对等方式通过互联网连接提供实时数据时（如远程传递实时股票报价或医疗信号以进行进一步处理），延迟变得非常重要。如果消息传递间隔是已知的——也就是说，当数据传输速率恒定时，例如在传输传感器读数（如小时温度或水位）时。在这种情况下，应用程序开发人员可以同步客户机以在已知可用时请求数据。但是，当速率增加时，HTTP轮询固有的开销会重复重要的头信息，从而增加延迟。早期的研究认为，由于实时HTTP Web应用程序的复杂性，HTTP不是为实时、全双工通信而设计的。3因此，HTTP只能在高价格增加延迟和高网络流量的情况下模拟实时通信。
许多研究人员已经测试并继续测试实时应用程序中WebSocket的使用情况。陈碧金和徐志奇开发了一个框架，将WebSocket协议用于基于浏览器的多人在线游戏。1他们使用WebSocket实现，并使用Wireshark软件评估局域网中的性能，以捕获和分析网络上传输的IP包的大小。三个游戏客户端状态更新之间的时间间隔为50毫秒，测试表明WebSocket协议足以处理每秒96257字节（758个数据包）的服务器负载。Peter Lubbers和Frank Greco在一个每秒更新股票报价的应用程序中比较了WebSocket协议和HTTP轮询。2他们的分析显示，延迟减少了三对一，HTTP头流量减少了500对一。这项研究还没有发现一个问题
然而，答案是，在广域网络上，WebSocket协议通信开销较低的优势是否仍然存在。我们在本文中的研究探讨了WebSocket协议通过互联网进行长距离传输的效率。我们与位于不同国家和不同时间的客户进行了实验验证，以探测各种网络条件。
长轮询是HTTP轮询的一种变体，它模拟从服务器到客户机的信息推送。例如，Comet Web应用程序模型4的设计目的是在没有浏览器HTTP请求的情况下将数据从服务器推送到浏览器，但通常使用长轮询来实现，以适应多个浏览器。与传统的轮询相比，长轮询并不能提供任何实质性的改进。5 WebSocket协议能够在单个TCP套接字上实现客户端和远程主机之间的全双工通信。6 WebSocket API目前是W3C的工作草案，7但据估计，该协议可以减少三对一的延迟。NST半双工HTTP轮询应用程序。5这里，我们比较了WebSocket的单向传输延迟、长轮询以及实时应用程序中HTTP轮询的最佳情况（有关此领域的其他研究，请参阅“WebSocket使用中的相关工作”侧栏）。我们通过实验验证了典型的实时传感器网络的低容量通信（大约每秒100字节的传感器数据）在4赫兹速率下的延迟行为。为了评价网络客户端-服务器通信对实时数据交换的有效性，我们将WebSocket通信与HTTP通信进行了比较。我们没有考虑其他的互联网协议，比如udp，8，因为它们是为实时数据流而设计的，当最新的数据更多的时候重要并允许删除旧信息。
HTTP轮询
HTTP轮询由一系列请求响应消息组成。客户机向服务器发送请求。在接收到这个请求时，服务器将用一条新消息（如果有）进行响应，或者如果没有新消息可供该客户机使用，则用一条空响应进行响应。在短暂的时间Delta;（称为轮询间隔）之后，客户机再次轮询服务器以查看是否有任何新消息可用。各种应用程序（包括聊天、在线游戏和文本消息）都使用HTTP轮询。
HTTP长轮询与轮询关联的一个弱点是当服务器没有新的客户端消息时，向服务器发出的不必要请求数。长轮询是轮询技术的一种变体，它可以有效地处理从服务器到客户机的信息推送。对于长轮询，服务器不会在意识到没有新消息可供客户端使用后立即发送空响应。相反，服务器将保留请求，直到新消息可用或超时结束。当没有新消息可用时，这会减少客户端请求的数量。
网络套接字
通过连续轮询，应用程序必须在来自客户机的每个请求和来自服务器的每个响应中重复HTTP头。根据应用程序的不同，这可能会导致通信开销增加。WebSocket协议提供了一个全双工双向通信通道，该通道通过Web上的单个套接字进行操作，有助于构建可扩展的实时Web应用程序。5
WebSocket协议由两部分组成。握手包括来自客户机的消息和来自服务器的握手响应。第二部分是数据传输。Jetty对WebSocketAPI的实现完全集成到Jetty HTTP服务器和servlet容器中（请参见http://jetty.codehaus.org/jetty）。因此，Jetty servlet可以处理并接受将HTTP连接升级到WebSocket连接的请求。有关WebSocket通信过程的更多详细信息，请参阅我们之前的工作。
建筑
我们使用websocket协议的windcomm web应用程序有三个主要组件：风传感器、基站计算机（服务器）和客户机。基站计算机使用一个运行名为windcomm的Web应用程序的Jetty服务器。此应用程序与传感器通信，并管理来自客户端的HTTP和WebSocket请求。客户机使用支持WebSocket协议和HTML5的canvas元素的Web浏览器访问Web应用程序以查看实时风传感器数据。
风传感器
Gill Windsonic是一种坚固的超声波风传感器，没有可测量风向和风速的移动部件（请参阅www.gill.co.uk/products/airmeter/windsonic.html）。我们通过RS232输出电缆将Windsonic连接到基站计算机，该电缆通过适配器连接到基站计算机中的USB串行端口。我们用振荡风扇模拟了动态风。
Windsonic在三种模式下工作：连续、轮询和配置。我们使用连续模式和4赫兹的数据率连续发送22字节的信息。
基站计算机
基站计算机运行windcomm web应用程序来实现jetty servlet。应用程序使用RXTX Java库（HTTP://RXTX.QBANG）与传感器进行通信。org/wiki/index.php/main_page）访问计算机串行端口。windcomm为传感器数据提供近乎实时的通道，必须跟上传感器的4赫兹输出速率。我们在三个版本中实现了windcomm Web应用程序。第一个称为windcomm，使用jetty的HTML websocket协议实现。第二个是long pollingwindcomm，实现HTTP长轮询；第三个是pollingwindcomm，使用HTTP轮询。在这三种方法中，我们实现了一个线程，通过基站计算机串行端口与风传感器建立和维护通信。
对于longpollingwindcomm，我们使用了jetty的continuations接口，该接口允许servlet挂起并保持客户机请求，直到事件发生或超时结束。对于longpollingwindcomm，事件是一个新的传感器测量，我们将超时设置为300 ms，这比传感器的输出速率高50 ms。
在pollingwindcomm中，servlet不保存客户机请求。将超时设置为250 ms将假定延迟为0 ms。我们知道延迟明显高于此值，因此将Delta;设置为250 ms将导致轮询windcomm运行非常缓慢，因为处理传感器观测的累积队列需要更长时间。因此，我们将客户机的轮询间隔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时间服务器同步。在开始测试之前，我们（或客户机位置的同事）在客户机和服务器中运行该命令，直到他们各自报告的偏移量低于2 ms。服务器始终报告的偏移量低于1 ms。我们在每次测试后重复该命令，以确保偏移量低于2 ms。在同步T之后以这种方式，客户端通过输入适当的URL（如http://131.202.243.62:8080/windcomm/）将支持HTML5的浏览器（firefox 6.0.2或更高版本）定向到三个Web应用程序之一。
客户机一收到消息，就需要一个本地时间戳。然后，客户机解析接收到的消息，提取服务器时间戳，计算延迟，并将其保存在一个数组中。当填充1200个延迟的数组时，测试结束，客户机将数组的内容发送到服务器。我们选择了一个1200的阵列，对应于连续4赫兹频率下大约5分钟的测量。
测试
我们的测试在三个不同的本地时间依次运行windcomm、longpollingwindcomm和pollingwindcomm，直到每个应用程序成功地传递了1200条消息。每次测试运行三个应用程序所花费的总时间约为15分钟，加上延迟、启动应用程序的时间以及从客户端向基站报告结果的时间。我们计划在上午8:00左右（不忙）进行第一次测试，下午1:00左右（正常流量）进行第二次测试，晚上8:00左右（忙）进行第三次测试。我们选择这些时间来改变网络状态。虽然在消息之间进行测试是很有趣的，也就是说，一条来自windcomm的消息，一条来自longpollingwindcomm的消息，一条来自pollingwindcomm的消息，为每个协议提供更具可比性的网络状态，但这是不可能的。我们的基站计算机中只有一个正在运行的进程（一个Web应用程序）可以一次访问风力传感器。
我们在位于加拿大东部新不伦瑞克大学（University of New Brunswick）的服务器之间运行测试，客户位于加拿大埃德蒙顿（Edmonton）、委内瑞拉加拉加斯（Caracas）、瑞典隆德（Lund）和日本长冈（Nagaoka）。请注意，除了Lund，所有客户都位于大学校园内。这意味着我们的测试数据可能是通过连接大学校园的研究网络而不是通过商业互联网传输的。隆德的客户位于公司办公楼。
结果
表1显示了我们的评估结果。我们为每个方法——WebSocket（ws）、长轮询（lp）和轮询（p）总共运行了12个测试，在四个国家与客户重复每个测试三次。在所有36个测试案例中，服务器在启动测试后5分钟1秒内将1200个测量值传递给客户机。表1报告了测试开始时间、观察到的平均延迟（ms，n=1200）、样本标准偏差s（ms）以及每个测试的mu;or比率r。粗体测试是gamma;gamma;WSLPgamma;gamma;WS磷
我们挑选出来作进一步分析。
对于使用的实时、低容量连续数据，所有测试表明，HTTP轮询平均延迟明显高于WebSocket或长轮询（高出2.3到4.5倍）。WebSocket协议的平均延迟可能低于或高于长轮询。在较长的距离内（如日本），WebSocket协议的平均延迟显著低于长轮询（3.8到4.0倍）。
在为埃德蒙顿选择的（粗体）测试结果中，我们观察到轮询的平均延迟比WebSocket协议长3.75倍（151.3 vs 40.3 ms）。均值统计检验的差异（具有未知和不同的总体方差）表明，无效假设h0：minus;=0在99%的置信水平下被拒绝，有利于替代假设h1：minus;lt;0。因此，我们有足够的证据证实WebSocket协议比加拿大境内的HTTP轮询快得多。事实上，我们所有的统计测试都提供了有力的证据，证明WebSocket协议总是比在这里进行的低容量实时数据通信测试的轮询具有明显的低延迟。
从上午9:10开始的5分钟测试周期的长轮询平均延迟仅比WebSocket延迟长1.0 ms。尽管如此，在99%的置信水平下，零假设h0：minus;=0也被拒绝，而支持替代假设h1：minus;lt;0。平均延迟1.0 ms的差异小于2 ms的时间同步偏移阈值。在所有Edmonton情况下，
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
