英语原文共 4 页，剩余内容已隐藏，支付完成后下载完整资料
一种基于WebSocket的基础架构的介绍
Gabor Imre, Gergely Mezei acute;
自动化和应用信息学系
布达佩斯科技经济大学
布达佩斯，匈牙利
Email: imre.gabesz@aut.bme.hu, gergely.mezei@aut.bme.hu
Robert S acute; arosi acute;
迪尔盒有限公司
布达佩斯，匈牙利
Email: robert.sarosi@erinnovations.net
摘要
WebSocket协议是一种基于HTTP (S)协议的、在服务器客户端间实现全双工实时通信的标准，是一种典型的浏览器应用程序。无论是在客户端还是服务器端，和传统的以XHR为基础的通信方式相比，WebSocket标准的性能都有显著的提高。然而当前WebSocket却还没有得到充分发掘。在本文中我们提出了一种WebSocket基准的架构，以此来测量服务器端的WebSocket协议的性能。此架构可使用能独立地运行在服务器端的黑箱测量法测试。我们也使用了3种应用于工业的WebSocket工具来验证所提出的这一架构。
一．导言
WebSocket规范[1]是一种新兴的网络开发标准。Websocket的出现是为了真正地实现服务器和客户端之间的实时、双向通信。和基于传统的XHR方式的通信方式（指轮询或长轮询，在文献[2]中有关于这两种方式的部分描述）相比，Websocket则显得十分高效。虽然有关静态文件服务、动态文件服务和REST架构API的理论、实践都已经颇为深入和成熟，但目前对于WebSocket和这些所使用的套接字的性能分析还是了解尚少。
完善的CDN（内容分发网络架构）和可扩展的传统web服务器的搭配是一个很强大的组合。当还在写这篇文章的时候[3]，StackOverflow就已然是一个访问量位列第49的大网站。拥有这家网站的Stack Exchange网络在它所有的25个服务器[4]1中，全部的服务器都使用了强大的传统网站服务器架构。当我们面临着开发出一种大规模的实时网络应用程序时，我们所面临的问题是WebSocket这种崭新的技术是否足以媲美发展成熟而且完善的传统通信方式。这篇文章的目的就是回答这个问题。
许多使用WebSocket的案例针对的是同步用户数量偏少或中等的情形。例如，可同时让100位用户使用的聊天室，又或者是一个同步实时浏览器游戏。然而我们能够想象真实的实时网络应用应该是拥有着上千万同时在线的用户的应用。对于这个问题，目前已经有了一些很好的解决方案，比如基于REST（资源表述性状态转移设计风格）的API请求，又或者说是每秒从CDN（内容分发网络架构）中以轮询的方式获取json数据这种方法2。
1：包括了日志记录、 备份、 辅助系统。这是成为一家顶尖的 IT 网站的方法。
2：我们见识了一场匈牙利电视才艺大赛的实时投票软件的流量作为案例。
如果采用此方法，即便是一个国家的所有人都在采取DDoS方式攻击一台服务器，这种方法仍然能够抵御攻击而正常工作。（批注：因为使用了CDN中转隐藏了服务器的真实IP地址）
但我们认为，使用基于WebSocket的解决方案，有与此类似的性能，甚至更好的性能都能够得以实现。
本文的目的是提出一个可以于评估使用WebSocket技术的服务器端性能的框架，这些WebSocket应用主要针对日常生活领域。在测试中，我们使用了发展成熟的、有社区支持的软件包和库。这些包和库都是工业上的必备条件，并且已得到过广泛使用。
二．背景
A WebSocket协议的性能
美国阿格沃尔等人[2]声称，相比于原生TCP套接字，XHR和WebSocket 标准对于高性能应用程序来说就真的像是路障一样，开销很大。原生TCP套接字的好处是不言而喻的。然而，业务和架构决定着我们是否需要优化性能，重写一个性能更佳的解决方案。这时，所要求的应用程序必须是一个web应用程序，而不是本地应用程序。在本文中我们只考虑现有标准，而不去评价是否有必要使用更好的标准。
迈克彭尼斯也提出了一种基准[5]。他测量了输出延迟后，声称Socket.io（多种通信方式的封装）[6]退化成了长轮询是巨大的性能缺陷。这个差异的原因可能是使用不当，还可能是次优架构是专门为WebSocket优化，而不是为长轮询而优化，等等。但长轮询的性能开销是不容置疑的。除此之外，领导着Node.js WebSocket 应用领域的Socket.io框架性能3，正直接关系到使用的应用程序的性能。
我们提出的基础构架可以用于将使用WebSocket协议的解决方案与基于XHR（轮询）方式和使用原生TCP Sockets方式的解决方案作比较。
3：基于GitHub Stars
图1. 测量方法框架
B．测量方案
通常有三种WebSocket用例:
bull;类似REST风格的操作:客户→服务器
bull;直接发消息:服务器→单个客户端
bull; 广播︰ 服务器 → 所有客户端或一组客户机
与基于 XHR的解决方案相比，已有的WebSocket连接方式的好处是在建立连接阶段时间耗费更少、更加高效。在由服务器端发起的小数据的传输上，与轮询和长轮询方式相比，WebSocket方式省去了不必要的应答。
现有的基于广播的测量方法有迈克彭尼斯的方法[5]和德鲁哈利的方法 [7]。德鲁哈利提出了基于Node.js和Socket.io的9-10k的机器同时连接到3.3GHz至强X5470处理器的机器上的测量方法。服务器仍能稳定广播消息给客户端。
三．测量基础构架
我们的主要目标是测量单一服务器WebSocket高负载情况下的工作状况和性能。测量方法结构如图1所示。
在这次测量，服务器被看作是一个黑箱，即性能测量是间接计算在客户机上。这样的测量方法消除了测量开销，以摒弃服务器工作细节为代价，计算出服务器的实际输出。我们不测量内核空间和用户空间操作之间的比率值，也不测量该方法的开销情况。
重负载的WebSocket的应用程序大多使用CPU。 在我们的案例中，瓶颈不是内存使用，也不是网络带宽，更不是硬盘驱动器操作。我们看重的是处理能力。 接下来我们看看每个组件的细节。
a）服务器实例：服务器应用程序是一个简单的基于WebSocket协议的响应服务。该服务可接收连接，侦听具有可选有效载荷的ping消息和发送带有有效载荷的pong消息。 默认情况下payload是包含时间戳的JSON序列化对象。
b）客户端实例：我们使用100个虚拟机实例作为客户端。 每个客户端最多可以有1000并行Socket连接。 每个连接的行为完全独立于其他连接。 客户端发送ping消息到服务器，并等待响应，以测量延迟。 客户端由客户端主机控制。
c）客户端主机实例：客户端主机作为管理接口、客户端的控制器和数据收集器。 新的测量在主机开展。测量活动的即时状态可以在主机上进行监测。 主机保存测量数据到本地文件中，并立即将数据发送给实时监控代理DataDog4。
四．技术决策
我们对所呈现的性能测量方法做出了一些严格的技术决策。这些决策一部分代表了我们的发展要求，一部分是根据我们自己偏好，但总体上它们是建立在可用的、流行的、工业上已经广泛使用的、优选开源和免费的工具之上的。
A.主机
我们选择了Google Cloud作为我们的云托管服务。我们使用1,2或4核心标准机器为我们的服务器，正如每次测量的配置中所详尽描述的那样。客户端运行在可抢占的标准VM实例上[8]其余的实例是非抢占式的。 “对于n1系列的机器类型，在2.6GHz的Intel Xeon E5（SandyBridge），2.5GHz Intel Xeon E5 v2（Ivy Bridge）或2.3 GHz英特尔至强E5 v3（Haswell）上，虚拟CPU作为一个独立的硬件超线程。
B.语言和包
在这项研究中，GitHub用作开源开发的标准，用GitHub开始测量并区分测量方法在开发者中是否已广泛使用。在服务器端，我们使用Go语言作为我们的服务器语言，采用Gorilla包[10]实现WebSocket。 这个包是最流行的Go语言实现的WebSocket实现方案。 我们已经尝试了几个其他实现方案（拥有ws的Node.js和Socket.io，使用WebSocket 的C ，拥有Cowboy的Erlang），我们发现C 实现的方案和所选的Go语言实现的方案似乎具有相对更好的性能。我们没有在客户端的性能上设限，而只是简单地统计了分配的客户端的数量。 我们使用了带有ws库[11]的Node.js客户端，每个客户端都最多支持1000个并发连接。这个标准是为了进一步扩展本文未列入的未来的开发环境和解决方案。
图2. 当稳步增加每个客户端连接数时消息延迟的情况（单位：ms）
C.测量任务
选择正确的任务是测量的关键。因为有很多基准能够评估广播的性能，因此，在本文中，我们不衡量广播通信，而是评估一个特定的echo服务器的性能。 测量的元任务是成对的REST式的ping（客户端到服务器）和pong（服务器到单个客户端）消息.echo服务器是一种很清晰的而且很容易实现的衡量非广播通讯的方式。 进一步的研究可以去比较的这种“直接”消息和广播消息两种方式的开销，或比较接收消息和发送消息的开销。
D.性能成本
服务器端WebSocket操作成本花费在重负载CPU上：
bull;建立连接，包括WebSocket升级（内核模式，用户模式）
bull;接收ping消息（内核模式）
bull;处理传入消息，发送pong消息（用户模式）
bull;发送pong消息（内核模式）
我们将这些组件的成本放在一起计算。 CPU负载达到100%时，在服务器上，我们观测到接受新的连接延迟，甚至超时，服务器发送的消息数量也达到了上限。 （虽然每秒偏差相对较大）。
五．验证
A.客户端测量的错误
我们面临的第一个问题是这种测量架构是否仅仅测量服务器的性能，是否存在着由客户端造成的重大测量错误。为此我们验证了延迟和吞吐量的测量。
组态：
bull;1/2/4个客户端（而不是通常的100）
bull;每个客户端最多生成1.5k连接，每个客户端秒新增一个连接。
bull;每个活跃连接每秒发送一条消息。
图3. 已发送消息数目
图4. 被挂起的消息数量
基于结果（图2），我们可以得出：
bull;在不同最大连接数（1500，3000，4500）的情况下，特性非常相似。我们可以下结论：所显示延迟只有客户端，除峰值点外。
bull;当每个客户端有1500个活动连接时，平均延迟线性上升到最大值90ms。
bull;网络延迟非常十分小，小于2ms5。
bull;即使在1500连接数的情况下，客户端吞吐量依旧没有问题。
我们在计算精确延迟时做了校正：每个客户端连接计数为0.06 ms。 每个客户端少于1000个连接数时，最大能产生60毫秒的延迟。 在许多情况下这种差异可以忽略。 即使没有计算这些差异，校正起来也很简单。
5: 客户端位于同一个Google Cloud域中。 我们使用外部IP的服务器，而不是内部IP。
B.独立的连接要求
服务器自己提供的WebSocket消息的数量不是服务器性能的有效度量。处理来自相同连接的消息比来自不同连接的服务消息消耗更少的功率。因此，创建独立的连接对于有效测量是至关重要的。这种验证证明需要单独的连接; 如果连接级联，那么测量会有所减损。
组态：
bull;1个标准服务器实例（2个内核），100个客户端
bull;10次消息峰值，每个峰值传送80k条消息
bull;变量：80k个连接，40k个连接，20k个连接 - 意味着每个连接发送1,2或4个消息
图3和图4显示了发送和挂起的数量消息。 结果证明当发送相同量的消息时，通过更少的连接发送，吞吐量高得多。 我们需要进一步分析得出定量的结论，但这个测量只验证使用分离的连接的必要性。
C.单客户端多连接的验证
基于之前的测量，我们要验证拥有多个连接数的单客户端时，应该检查测量是否受提供相同连接数的机器数量的影响。 我们希望与不同实例打开多个连接相比，从单个实例打开同等数目的连接不应产生任何性能增益。（所以使用单独的连接是必要的 - 见前面测量 - 但使用单独的实例不是必需的。）
在这种情况下，我们逐渐建立WebSocket连接，而每个成功连接的连接每秒发送一条消息。 因此传入的ping消息数量不断增加。 50个客户端实例（第一个方案）和1
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[138823]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
课题毕业论文、外文翻译、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
