到目前为止，我们已经深入到实时世界，因为许多应用程序使用实时数据。 现在正是以技术立场解释所有导致这一点的事件的时候了。 所以，这里......

目前，应用程序正在从利用数据库中的陈旧数据或在实际事件之后的实时体验中事件触发后即时创建的数据转变。 我们在实时应用程序中首先想到的是 WebSockets 。 但是，尽管很多人不断在技术圈中围绕这个术语，但实际上似乎存在与其意义和工作相关的巨大误解。

让我们破解行话并了解正在发生的事情！

HTTP - >长轮询 - > WebSockets

回到当天，HTTP的无状态请求 - 响应机制非常适合当天的用例，让任何两个节点通过互联网进行通信。 由于它都是无状态的，即使连接断开，您也可以轻松地从那一点恢复通信。

然而，随着应用程序转向实时实现，即确保在现实世界中创建共享数据时的最小延迟，传统的请求 - 响应周期被证明是一个巨大的开销。 为什么？ 高频请求 - 响应周期导致更多延迟，因为每个周期都需要每次都建立新连接。

从逻辑上讲，下一步是为相同数量的数据流最小化这些周期的方法。 解？ 长轮询！

通过长轮询，底层TCP套接字连接可以持续一段时间，即连接可以保持打开状态比平时更长。 这不仅使服务器有机会整理多个数据以在单个响应中发回，而不是在单个响应中发送，而且，它几乎完全消除了由于缺少数据而返回空响应的情况。现在服务器只要有实际回馈的数据就可以返回响应。

但是，即使长轮询技术也涉及连接建立和频繁的请求 - 响应周期，类似于传统的HTTP，当然，这会导致更多的延迟。

对于大多数实时应用程序而言，数据的速度（最接近最接近的毫秒数）绝对至关重要，因此上述两种选项均未被证明是有用的。

然后怎样呢？

自从我通过提及WebSockets开始撰写文章以来，你显然会猜到我得到了什么。

因此，与HTTP不同，WebSockets是一种通过TCP工作的有状态通信协议。

通信最初是作为HTTP握手开始的，但如果两个通信方同意继续通过WebSockets，则连接只是提升，从而产生全双工，持久连接。 这意味着连接在应用程序运行时的整个持续时间内保持打开状态。 这为服务器提供了一种启动任何通信并将数据发送到预订客户端的方法，因此他们不必继续发送询问新数据可用性的请求。

实际应用程序实际上发生了很多事情，而不是我在本文中简单总结的内容。 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/31557424/viewspace-2219832/，如需转载，请注明出处，否则将追究法律责任。