1995年，Internet Communications在Internet Navigator中雇用了脚本写作能力。在十天内，JavaScript语言出生于现代Javascript，其语言作为一种语言的能力起初非常有限。它具有与浏览器的文档对象模型（DOM）相互作用的能力有限。JavaScript主要用于提供有限的增强以丰富文档的使用功能。现有文档中的html。
随着浏览器战争的加热，微软的Internet Explorer进入了第四版甚至更高版本，最强大的功能的竞争导致Microsoft引入了最终的内容。十多年来，所有浏览器通常都支持此功能。
长轮询问实际上是原始旋转技术的更有效形式。对服务器的重复请求将浪费资源，因为必须建立每个新的传输连接，必须对HTTP标头进行解析，并且必须执行新数据的查询。并生成和交付响应（通常不提供新数据）。然后，您必须关闭连接并删除所有资源，而不是多次重复每个客户端的过程，直到给定客户端可用。该服务器选择尽可能长时间地保持客户端连接。只有在数据可用后，响应才能可用或达到超时阈值。
长期查询将在稍后实施，几乎得到设备的一般支持，因此通常不必支持进一步的保留层。但是，何时必须处理异常，或者您可以查询服务器以获取新数据但是不要支持长期查询（更不用说其他更现代的技术标准），基本旋转有时仍然有限使用，Andyou可以通过简单的HTML脚本标签使用或通过JSONP使用。
长期查询在服务器上更加密集。可靠的消息排序可能是长期咨询的问题，因为可以同时执行来自同一客户端的多个HTTP请求。例如，如果客户端打开两个浏览器，则使用相同的服务器资源的选项卡，客户端应用程序将持续到本地存储（例如OR）的数据中，没有构建的 - 保证数据将不会被编写多次。
根据服务器的实现，消息接收到客户端实例的确认也可能导致另一个客户端实例，因为服务器可能会错误地相信客户端已收到了预期数据，因此无法收到预期消息。
大多数图书馆并非独立于其他传输来实现长轮的查询，因为一般而言，长轮的查询通常伴随着其他传输策略，并且这些变速箱用作储备作为储备或长-RIM查询。2018年及之后，独立的长期咨询库特别罕见，因为面对对更现代的替代方案的广泛支持，这项技术正在迅速失去相关性。在这里，有几种类型的长期开源库中不同语言：
在2008年左右，开发人员迈克尔·卡特（Michael Carter）和伊恩·希克森（Ian Hickson）特别感受到了实现任何强大功能时使用彗星的痛苦和局限性。通过在IRC和W3C邮件列表上合作，他们制定了一项计划，以在互联网上引入新的现代真实时间通信的新标准，因此创建了这个名字。
这个想法输入了W3C HTML标准。不久之后，迈克尔·卡特（Michael Carter）写了一篇文章，将彗星社区介绍给WebSockets。在2010年，Google Chrome 4是第一个完全支持WebSockets的浏览器。在接下来的几年中，其他浏览器供应商也遵循。在2011年，RFC 6455（WebSocket协议）已发布到IETF网站。
简而言之，WebSockets是一个在设备TCP/IP堆栈上建立的薄变速箱层。目的是为Web应用程序开发人员提供尽可能接近原始TCP通信层的接近，同时添加一些抽象以消除与某些可能的摩擦相关的摩擦。网络工作方法。他们还迎合了一个事实，即该网络有其他安全考虑，他们必须考虑这些因素以保护消费者和服务提供商。
WebSocket是一个事件驱动的协议，这意味着它可用于Real -Time Communication.unlike HTTP（必须连续要求更新），并且在更新时将立即发送使用WebSockets。
WebSockets保持单个持久的连接，同时消除了基于HTTP请求/响应发生的延迟问题。
WebSockets通常不使用XMLHTTPREQUEST，因此您需要每次发送更多信息从服务器发送更多信息。此依次减少发送到服务器的数据加载。
当连接终止时，Websocket将不会自动恢复。这是一种需要自己在应用程序开发中实施的机制。这也是许多客户开源库的原因之一。
2011年初的浏览器无法支持Websocket连接。现在可以忽略这一点。
在上一篇文章中，有非常详细的介绍。如果您有兴趣，请参考“ Websockets的概念和实践”。
通常，Websocket将是一个更好的选择。
长时间的查询在服务器上占有很多资源，服务器上的WebSockets的职业空间很小。长期查询也需要在服务器和设备之间进行多次跳跃。这些网关通常具有不同的关于允许典型连接保持开放的时间的观点。如果它使其打开太久，则可能会杀死它，即使它正在做一些重要的事情。
为什么要使用Websocket构建：